Hierarchical netlist in ASIC Layout design

[tarzanaly]

Mọi người có ai có kinh nghiệm về mảng này không cho em hỏi tý.

Em đang làm việc về ASIC layout design, công việc tóm gọn lại là lấy RTL, Place&Route rồi verify. Chỉ có điều là design thì ngày càng lớn, cả triệu gate cho một block còn chip thì mấy chục triệu nên place&route cũng lâu phải mấy ngày; mà design có lúc phức tạp đến mức tools behave rất lạ và rất đau đầu, với kiểu quay vòng mấy ngày mới có kết quả thì không ổn. Sếp phán em tìm hiểu về hierarchical design để có gì dùng hierarchical netlist chứ không flatten nó ra rồi để tools tự xử nữa. Có nhiều khả năng là công việc sẽ nhanh hơn, dùng lại được các module được instantiate nhiều lần và dễ debug các vấn đề hơn. Tuy nhiên cũng không chắc chắn là dễ route và dễ meet timing hơn. Công ty em từ trước tới giờ chỉ có 2 level of hierarchy là chip_top-level -> blocks; giờ muốn thêm.

Mọi người cho em hỏi, có ai biết về hình mẫu design này, và nó có thực tiễn, có phổ biến không? Moị người nghĩ sao về nó? Ai có kinh nghiệm làm rồi thì giúp em chia sẽ chút kinh nghiệm hay một số vấn đề được không?

Mình thì mới, mà sếp cũng mới lên nên cũng ambitious, khổ thế

Cám ơn mọi người trước

[tonyvandinh]

Mọi người có ai có kinh nghiệm về mảng này không cho em hỏi tý.

Em đang làm việc về ASIC layout design, công việc tóm gọn lại là lấy RTL, Place&Route rồi verify. Chỉ có điều là design thì ngày càng lớn, cả triệu gate cho một block còn chip thì mấy chục triệu nên place&route cũng lâu phải mấy ngày; mà design có lúc phức tạp đến mức tools behave rất lạ và rất đau đầu, với kiểu quay vòng mấy ngày mới có kết quả thì không ổn. Sếp phán em tìm hiểu về hierarchical design để có gì dùng hierarchical netlist chứ không flatten nó ra rồi để tools tự xử nữa. Có nhiều khả năng là công việc sẽ nhanh hơn, dùng lại được các module được instantiate nhiều lần và dễ debug các vấn đề hơn. Tuy nhiên cũng không chắc chắn là dễ route và dễ meet timing hơn. Công ty em từ trước tới giờ chỉ có 2 level of hierarchy là chip_top-level -> blocks; giờ muốn thêm.

Mọi người cho em hỏi, có ai biết về hình mẫu design này, và nó có thực tiễn, có phổ biến không? Moị người nghĩ sao về nó? Ai có kinh nghiệm làm rồi thì giúp em chia sẽ chút kinh nghiệm hay một số vấn đề được không?

Mình thì mới, mà sếp cũng mới lên nên cũng ambitious, khổ thế

Cám ơn mọi người trước

Tôi thì có kinh nghiệm ở front end hơn là ở back-end, nhưng cũng xin đóng góp một ít ý kiến nho nhỏ. Thường thì layout bị trở ngại vì hạn chế ở diện tích và đạt chỉ tiêu về thời gian. Nếu bị hạn chế về diện tích thì làm "flat" hay "hierarchy" đều có trở ngại giống nhau. Nếu trở ngại ở layout là vì không đạt được mục tiêu về thời gian, thì hierarchy design có thể giúp để giảm đi những trở ngại đó. Điều này cần để ý ngay từ lúc đầu làm thiết kế (viết RTL). Khi phân vùng (partition), cần phân làm sao để những đường thời gian tối trọng (critical timing path) nằm trong cùng một khu vực. Vấn đề này có thể kiểm tra khi làm "static timing analysis". Trước khi đi vào layout (P&R), cần phải làm "floor planning" để ước lượng về thời gian. Nếu không ổn thì phải chỉnh ngay tại bước này vì tốn it thời gian hơn ở layout nhiều. Chỉnh ở đây có thể phải viết lại RTL để phân vùng trở lại hoặc đặt thêm pipeline stages. Khi ổn rồi thì có thể dựa vào floor planning để làm placement rồi tới route. Có người dùng ước lượng của routing delay sau khi placement để giám sát lại thời gian trước khi routing.

Hy vọng những tin tức này giúp bạn được phần nào.

[tarzanaly]

Cám ơn anh Tony. Có khi em chia sẻ chút về công việc của back-end luôn cho mọi người tham khảo.
Công việc của em cũng phải communicate với khách hàng (front-end team). Thực ra là netlist đã được khách hàng run synthesis và STA rồi, cũng đã có bước tiến để khách hàng chạy DCT (Design Compiler Topographical) với floorplan của mình. Tuy nhiên không phải lúc nào synthesis meets timing là có thể place&route được và hầu như là không được nên còn phải feedback để thêm pipe-stage (latency) chia block lớn ra nhiều block nhỏ hơn và đủ thứ cả. Vấn đề là thời gian để có được kết quả place&route thậm chí chỉ placement thôi và analysis tìm vấn đề feedback cho customer càng ngày càng lâu; lên đến cả tuần cho block, và thậm chí cả tháng để có cả full-chip feedback.

Cả chip có nhiều hierarchy, nhưng bên em chỉ lấy top, rồi 1 level dưới là block, rồi flatten luôn để place&route blocks rồi integrate lên top place&route tiếp. Việc sử lý netlist của khách hàng (như test-insertion, rồi flatten/group nó mất khoảng 2-3 ngày). Sau đấy sẽ có flat netlist cho từng block để build (place&route, DFT v.v). Em đang nghĩ thêm khoảng 1-2 hierarchy nữa cho block, runtime có thể cải thiện được chút, nhưng area chắc phải increase một chút, timing cũng khó meet hơn, vì khối logic trong cùng block có thể communicate với nhau một cách phức tạp vì thể placement/routing có thể không được optimized lắm. Hơn nữa là vấn đề timing-constraint cho sub-block nhỏ không hiểu phải làm như thế nào, không biết là tools có thể support không hay cần individual constraint cho từng sub-block; hi vọng là không phải làm thế; không thì phức tạp chết; cái này em phải hỏi EDA vendors (tools vendors).

Vấn đề của em như em nói trong bài trước đó là feedback time quá lâu, nếu tìm ra vấn đề, khách hàng có thể add thêm latency đề giải quyết timing issue, có thể hy sinh functional performance chút để kịp tiến độ. Vì thế mà sếp mới consider cái này; vì thực ra nếu quyết định làm, methodology phải thay đổi rất nhiều, scripts rồi tool command cũng phải đổi, project này có thể mất một team trong nửa năm, có khi cả năm để thực hiện. Thời gian đấy có thể làm cả con chip kiếm chục triệu rồi.

Chút background về việc build block cho mọi người tham khảo.

Như em nói ở trên, một chip có nhiều blocks, 1 block có nhiều sub-block (hay module) dưới nữa cũng là module và dưới cùng là cell (dưới cell là gate (primitive)). Hiện tại thì chip chia ra làm 2 level, chip-top và blocks. Khi block được build (hiểu đơn giản là place&route) thì top cũng được build, với nhiều vấn đề phức tạp hơn chỉ là place&route mà em không tiện đi sâu không thì loãng (như pads rồi package L1 L2 v.v)

Để build một block, cần netlist (em dùng verilog) lúc này đã được flatten (không có hierarchy, chỉ cells và wire). Trong block còn có IP (intellectual property) chủ yếu là memories hoặc một vài cái khác như esd. Việc đầu tiên là floorplan (pre-place các IP này vì nó quyết định placement của logic liên quan, mà tools không làm tốt nhiệm vụ này lắm nên phải tự làm). Floorplan còn có nhiệm vụ assign port location nữa (các cổng giao tiếp với bên ngoài block). Để đảm bảo các path ra ngoài block meets timing, cần phải có constraint cho các ports (input delay, input transition, output delay, output load ..v..v) như là một modeling cho mạch bên ngoài block. 3 thông tin cần thiết để place&route là thế netlist/floorplan/constraint. Khái quát thế thôi chứ chi tiết bên trong còn nhiều thứ nữa phục vụ nhiều mục đích khác ví dụ như constraint thì còn có clock definition, multicycle và false path v.v
3 files trên qua một loạt các bước pre-optimize, như output buffering để có thể drive một cái long route ở top-level. Input receiver (để nối diode ground, giảm antenna) rồi test insertion, restructure netlist v.v đại loại là các phụ kiện để đảm bảo kỹ thuật cho block chứ chưa đả động gì đến functional.
Tiếp theo block sẽ được place với ideal clock. Build clock tree, propagate clocks rồi mới được route. Nói chung tóm gọn là place&route. Riêng cái này cũng đủ là một topic dài nên hẹn dịp khác nói tiếp vậy.
Nếu sau khâu này, timing pass thì block sẽ được qua giai đoạn mông má chuẩn bị cho manufacturing và qua khâu verification cuối cùng. Cũng có nhiều cái check, nhưng những cái chính là functional verification (formal), Design rule check (DRC) để sản xuất.
Sau đấy block sẽ được đưa lên top-level để time, và nếu có vấn đề gì (vì constraint có thể không chính xác) sẽ được build lại với những modify cần thiết.

Thôi thế thôi, có gì hẹn dịp khác.
Thân

[hithere123]

Mọi người cho em hỏi, có ai biết về hình mẫu design này, và nó có thực tiễn, có phổ biến không? Moị người nghĩ sao về nó? Ai có kinh nghiệm làm rồi thì giúp em chia sẽ chút kinh nghiệm hay một số vấn đề được không?

Theo như bạn mô tả, mình tạm thời chia chip của bạn ra thành hai mức là top và core. Và bạn đang bàn đến hierarcial layout cho core. Tức là sẽ chia các “digital logic” của core thành một vài block sau đó các block này sẽ được layout riêng biết và được nối với nhau bởi bước “Place&Route” sau đó. (Khác với “Flat” là layout toàn bộ các digital logic của core như là layout một block đơn.)

Ở bên mình, thiết kế và layout ngồi gần nhau nên không gặp vấn đề “feedback time” như bên bạn, tuy nhiên bọn mình hay chia thành hai nhóm fast domain (ví dụ như core-CPU, memory, local bus, …) và Slow domain (ví dụ như các control unit) khi làm layout cho những chíp có độ phức tạp cao (đạt đến giới hạn của công cụ (tool) khi làm flat layout). Sau đó có thể layout Fast và Slow cùng mức (level) hoặc Fast là một sub-level cho Slow. Tuy nhiên tất cả các blocks không thể được layout đồng thời vì cần “sub-level frame view” để bắt đầu layout top.

Theo mình, nếu không có yêu cầu đặc biệt về thời gian (độ phức tạp không cao) và chíp hoạt động với tần số cao (contraining margins cho các subblock sẽ còn rất ít) thì Flat Layout được ưu tiên lựa chọn hơn.
Để làm rõ hơn ý kiến trên, mình thử liệt kê một số ưu nhược điểm của flat layout (theo mình) như sau:

[1] Ưu điểm:
- diện tích ít hơn
- không phải xác định nhiều lần các tham số hình dạng (shape), pin, contraints của các block, subblock, …
- và đặc biệt là các sripts có hiệu suất tái sử dụng rất cao.
[2] Nhược điểm:
- thời gian chạy sẽ lâu hơn nhưng chủ yếu là ở giai đoạn chuẩn bị đầu tiên (preparation phase)
- phức tạp khi thực hiện ECO với “final run”
- và nếu thiết kế rất phức tạp (số lượng gate lớn) thì sẽ đụng tới giới hạn của công cụ (tool).

Ngoài ra cũng nên chú ý tới hai vấn để sau để cải thiện thời gian chạy cho Flat Layout:
- Khi viết constraint thì không nên “fit” với sign-off timing ngay từ đầu, mà nên “over-constraining margins” sau đó nới lỏng dần dần constraints trong suốt quá trình.
- Một số nhóm có tính lặp lại cao như SRAM chẳng hạn thì không nên chạy auto-placement mà nên dùng manual placement.

Hy vọng là đúng với ý bạn muốn trao đổi. Hì

Thân mến.

[tonyvandinh]

tarzanaly
Nếu timing ở front end đã chuẩn mà back end vẫn còn bị vấn đề thì nên coi lại STA của front end. Thường thì front end dùng wire load model để ước lượng timing. Max transition và driver cũng ảnh hưởng đến timing. Điều quan trọng hơn hết là nên calibrate the process. Nếu front end và back end không có sự đồng ý về timing, bạn sẽ ở trong cái vòng lẩn quẩn này hoài.

Bạn còn có thể chia nhóm cho net từ critical tới non-critical. Route critical trước rồi từ từ tới non critical (static signals).

[tarzanaly]

cám ơn mọi người. Ý kiến chia sẻ em sẽ cân nhắc, tìm hiểu thêm để còn báo cáo. Dù gì thì em cũng phải build một cái flow, chạy thử để có kết quả so sánh (chỉ back-end thôi).

Bên em bị cái khách hàng cũng không thể và không muốn giải thích chi tiết functionality của cả chip được; chỉ cho cái dataflow đơn giản. Những cái được coi là critical đến với em thì chỉ là mấy cái fast IO interface, và critical logic blocks. IO thì không ngại lắm vì constraint có thể thương lượng với khách hàng và do top-level không có logic nên không khó để floorplan in favor cho mục đích đấy. Còn trong block, logic chồng chéo phức tạp, high fanout nên dù muốn cũng khó tránh khỏi việc thêm buffer để drive long wire, cái mà synthesis không thể thấy được. Vấn đề là customer đã làm tốt, mình thì cần người ta làm tốt hơn nữa.
Thực ra sống chết cho ra chip thì cũng được thôi nhưng không phải hay, có giới hạn về diện tích (thêm tý cũng là thêm đống tiền), về power nữa khi mà nhà nhà đua nhau giảm power. Bên em bị cái mỗi khách hàng có cái đặc thù riêng về chip của họ nên memories, standard cells bị giới hạn theo customer lớn nhất. Chính thế mà tốc độ không nhanh, bù lại dùng ít layer hơn giảm tiền, nhỏ hơn, ít công suất hơn v.v.
Cái sếp giao cho em là tìm hiểu về cái methodology kia thôi, còn ông ý cũng có plan cho các khâu khác. Dù sao thì cũng cám ơn mọi người, biết thêm không bao giờ là thừa