Thiết kế IC số?

[pzeter]

Sau khi Specification, viết Code mô tả(dungHDL ) xong thì làm gì nữa?
Bác nào biết thì chỉ dùm em với!

[abcded]

Theo mình được biết thì trong quá trình thiết kế số sau quá trình Specification là quá trình Achitecture Design, rồi đến Logic DeSign, Circuit Design, Phisical Design.

[hithere123]

Chào bạn,

Theo mình thì khi viết code xong sẽ có một số công đoạn như sau:

[1] Mô phỏng kiểm tra code ở mức RTL (đúng về logic)
Thông thường để cho khách quan thì sẽ có một đội riêng biệt làm việc này gọi là Verification Team. Ở mức thiết kế concept thông thường các kỹ sư cũng định nghĩa luôn các testcases cần có khi design (có thể gọi là test plan). Đội kiểm tra sẽ dựa vào test plan này để design test bench. Ví dụ mô phỏng kiểm tra ở mức top-level của một MCU 32-bit đã có khoảng ~400 testcases, Tuy nhiên vì là mô phỏng logic nên thời gian chạy cho mỗi trường hợp là rất nhanh (~ vài phút - vài chục phút). Nói thế không có nghĩa là người viết code không phải chạy mô phỏng mà người viết code vẫn phải tự thiết kế test bench cho riêng thiết kế của mình để đảm bảo bản thiết kế RTL là clean và đã đúng chức năng, thông số code coverage đạt ~100%, . . .

[2] Pre-layout synthesis và phân tích timing
Ở bước này, người kỹ sư sẽ phải viết các constrain cho mạch điện để công cụ Compiler có thể dùng các thư viện linh kiện từ nhà sản xuất tổng hợp ra pre-layout netlist của mạch điện (thường là verilog netlist)
Tiếp đó là kiểm tra equivalence giữa netlist và code RTL.
Sau đó là insert scan cho các Flip-Flop (tham khảo thêm DFT_Design For Test)
Cuối cùng là chạy kiểm tra equivalence giữa bản netlist có insert scan và bản netlist trước đó để đảm bảo vẫn đúng về mặt logic.
Và với bản netlist này, bạn có thể chạy STA (phân tích timing) để phát hiện sớm các big timing violation, vì các thư viện linh kiện chuẩn đều đã bao gồm các thông số về timing của linh kiện.

[3] Tới đây có thể dùng bản netlist này để layout
Ở bước này vì thông thường là auto layout nên kỹ năng viết script, sử dụng công cụ là rất cần thiết.
Kết quả bước này là một bản netlist hoàn chỉnh (gate netlist)

[4] Kiểm tra equivalence giữa gate netlist và pre-layout netlist.
Mục đích chủ yếu là đảm bảo bản gate netlist vẫn đúng về mặt logic như yêu cầu thiết kế.

[5] Kiểm tra timing và estimate power
Ở bản netlist này đã có đầy đủ thông số về điện trở cũng như tụ điện ký sinh của bản layout mạch điện.
Khi timing clean thì ta có thể có thêm file mô tả các thông số ký sinh (sdf file) bao gồm cả các thông số phụ thuộc vào công nghệ, điện áp hoạt động, nhiệt độ, . . . . sdf file sẽ được dùng để mô phỏng cùng với gate netlist.

[6] Cuối cùng là bước ATPG_Tạo ra các data dùng cho việc test chip sau khi silicon out.
Ở đây thông số test coverage là rất quan trọng, thông thường yêu cầu đạt từ 95% trở lên

Các bước Verification, Synthesis, Layout, Equivalence check, STA, ATPG nên được tổng hợp thành các bài viết riêng vì có rất nhiều khía cạnh mà bài viết này chưa đề cập tới. Hy vọng mọi người cùng đóng góp.

Hy vọng bài viết này đã có thể trả lời bạn một cách tổng quan nhất các bước cần phải làm sau khi viết xong code.

Thân mến.

[abcdef]

Khâm phục trình độ hiều biết của anh Hithere thật, mà cái này hình như là Digital pk ạ?

[TL138]

Cao thủ ẩn danh nhiều quá!

[tonyvandinh]

Nếu design có timing mà khó đạt, cần phải có thêm phần "floor planning". Phần này giúp đặt những cell/gate mà liên hệ gần nhau để tránh bị trễ timing.

Sau khi xác nghiệm RTL mà muốn biết thêm design đã được xác nghiệm kỹ càng, nên dùng thêm "formal equivalent, gate to RTL". Phần này có tác dụng nhiều nhất là khi có lỗi, sửa design ở gate và RTL riêng nhưng vẫn kô chắc là nó có hoạt động giống nhau hay kô.

tvd

[tonyvandinh]

Các bước Verification, Synthesis, Layout, Equivalence check, STA, ATPG nên được tổng hợp thành các bài viết riêng vì có rất nhiều khía cạnh mà bài viết này chưa đề cập tới. Hy vọng mọi người cùng đóng góp.

Tôi xin đóng góp thêm về các bước trên:

1) Synthesis (Tổng hợp)
Tổng hợp là cách chuyển biến từ abstract cao tới abstract thấp hơn. Hiện nay có 2 mức tổng hợp:
* C/C++/systemC (untime/partial time) tới RTL (Register Tranfer Level). Đây là công nghệ đang trên đà tiến để nâng cao sức thiết kế (giảm thời gian thiết kế khoảng 50% cho lần đầu tiên, 80% cho những phần thay đổi của thiết kế)
* RTL tới dạng cổng (gate) - Đây là dạng tổng hợp thông thường và đã được sử dụng trên 20 năm nay.

Công việc của tổng hợp là phải làm sao có được kết quả vừa nhanh, gọn và tiêu dùng ít nhiên liệu. Những công cụ tổng hợp của mấy công ty FPGA như Xilinx, Altera thì đơn giản hơn vì chỉ phải chuyển qua cấu trúc của riêng họ. Mục đích của mấy công ty này là làm cách nào để bán nhiều phần cứng của họ cho nên công cụ của họ không cần phải tóm gọn kết quả. Kết quả càng bự chừng nào càng lợi cho họ chừng đó. Công cụ tổng hợp của mấy công ty EDA thì ngược lại. Mục đích là càng dùng công cụ lâu chừng nào càng tốt. Những công cụ này sẽ vận động để làm kết quả càng nhanh, gọn và ít nhiên liệu. Tạo cơ hội để những kỹ sư tìm tòi làm kết quả hữu hiệu hơn (nhiều thời gian dùng công cụ hơn). Giá cả của những công cụ này rất mắc tiền không như của công ty FPGA thường thì cho free khi mua phần cứng của họ.

Quá trình của tổng hợp là:
* Language parser hay còn gọi là compile để chuyển thiết kế từ ngôn ngữ nguồn tới primitive netlist (cấu trúc nguyên thủy của tổng hợp, AND, OR, FF, SHIFT, số toán + - * / và vân vân).
* Boolean optimization - Tóm gọn logic, constant propagation (ví dụ "a AND 1 = a", "a AND 0 = 0", "a OR 0 = a", "a OR 1 = 1" và vân vân)
* Liên hệ thời gian với target technology (Virtex, Stratix, 90nm, 25nm, etc...) rồi dùng STA (Static timing analysis) để kiểm soát thời gian (cổng vào tới FF, FF tới FF và FF tới cổng ra).
* STA chỉ dùng để kiểm soát thời gian mà không cần chi tiết về cách hoạt động với mục đích để chạy cho nhanh và đỡ tốn memory cho nên đôi lúc sẽ hiểu lầm về trễ thời gian. Chẳng hạn như reset chỉ chuyển có một lần trong thời gian hoạt động nhưng STA không biết cho nên vẫn xét thời gian ở mỗi chu kỳ.
* Clock tree synthesis (CTS) - Xung clock thường chạy khắp nơi cho nên có rất nhiều load. CTS dùng để bão hòa load cho xung clock để thời gian tới địa điểm càng ít sai lạc càng tốt.

Xin hẹn các bạn kỳ tới để nói thêm về những bước khác.

Chào
Tony

[tonyvandinh]

2) Scan Insertion và ATPG
Tương tự như bên thiết kế board, mọi điểm trên thiết kế cần phải được giám sát để đề phòng sự trục trặc khi làm ra sản phẩm. Có nhiều điểm trên mạch IC không có thể giám sát hoặc điều khiển từ ở ngoài (khi thử chip, chỉ có thể trực tiếp giám sát va điều khiển ở mấy chân của chip mà thôi. Không thể nhìn thấy hoặc đụng những điểm ở bên trong). Scan Insertion tạo điều kiện để có thể chuyển vô bên trong IC những pattern để có thể điều khiển (controllability) rồi sau đó chuyển ra ngoài những chi tiết để dựa vào đó mà có thể giám sát (observability) tình trạng của những điểm ở bên trong. Những pattern dùng để điều khiển và giám sát này là Automatic Test Pattern Generation (ATPG)

Hẹn lại ở bước tới
Tony

[hithere123]

Các bước Verification, Synthesis, Layout, Equivalence check, STA, ATPG nên được tổng hợp thành các bài viết riêng vì có rất nhiều khía cạnh mà bài viết này chưa đề cập tới. Hy vọng mọi người cùng đóng góp.

Bài viết dưới đây là phần dẫn nhập cho bước đầu tiên: Functional Verification

Trong thiết kế FPGA, các thiết kế (RTL code) trước khi được chuyển xuống chip FPGA thường qua công đoạn chạy mô phỏng. Cũng giống như vậy trong thiết kế ASIC, trước khi tiến hành bước tổng hợp (synthesis), RTL code cần qua bước mô phỏng kiểm tra về mặt chức năng (functional verification). Hiện nay công việc này chiếm phần lớn thời gian trong toàn bộ quy trình thiết kế ASIC do sự gia tăng đáng kể về kích thước và mức độ phức tạp của thiết kế. Có thể nói lỗi về logic và function chiếm gần một nửa số lỗi làm cho không đạt được “first time right silicon”. Chính vì vậy mô phỏng chức năng ngày càng trở nên quan trọng hơn. Để có thông tin thêm về lĩnh vực này các bạn có thể tham khảo lại các bài viết trước đây của anh Tony:

http://www.dientuvietnam.net/forums/...l-Synthesis%29

http://www.dientuvietnam.net/forums/...9Bi-FPGA/page2

http://www.dientuvietnam.net/forums/...1-verification


Trong phạm vi bài viết này mình muốn đề cập tới khía cạnh testbench. Testbench chính là thành phần nằm giữa "Test Case" và DUT (device under test). Trước đây, với những thiết kế chưa phức tạp lắm thì người ta thường dùng directed HDL testbenches (VHDL hay Verilog), chủ yếu đưa trực tiếp những kích thích đầu vào sau đó thu thập những đáp ứng ở đầu ra ở mức Boolean. Tuy nhiên khi mức độ phức tạp của thiết kế tăng lên thì testbench kiểu này không tỏ ra hiệu quả (xem lại yếu tố time và untime mà anh Tony có đề cập trước đây).

Trước khi đề cập tiếp tới cấu trúc của một testbench, mình giới thiệu với các bạn hai tài liệu:
- System Verilog For Verification: Cuốn này khá thông dụng khi đề cập tới SystemVerilog Testbench. Bạn nào có bản mểm thì đưa lên chia sẻ cùng mọi người nhé, dưới đây là link giới thiệu về cuốn sách này:

http://www.chris.spear.net/systemverilog/default.htm

- Open Verification Methodology Cookbook: Tài liệu này cũng thông dụng với các kỹ sư làm về verification. Các bạn có thể download ở trang OVM mà anh Tony đưa link trước đây:

http://www.ovmworld.org/

(bổ xung thêm, OVM là sản phẩm của sự hợp tác giữa Mentor và Cadence)

Dưới đây là một số khái niệm chính mình dự định đề cập tới cho cấu trúc của một testbench:

- Test control
- Transaction
- BFM (bus functional model)
- Monitor
- Scoreboard
- Reference Model

Mình không chắc là các khái niệm trên đã tương đối đầy đủ chưa, hy vọng sẽ nhận được nhiều bổ xung từ mọi người cho bài viết này và những bài viết sau để có được cái nhìn đầy đủ về bước đầu tiên trước khi chuyển RTL code thành silicon.

Rất mong

[tonyvandinh]

Rất đúng, thời gian để làm kiểm tra tốn hơn là thiết kế. Nó có thể chiếm đến 80% tổng số thời gian làm sản phẩm. Đây là một nỗi lo lắng lớn cho người thiết kế. Kỹ thuật kiểm tra đã phải thay đổi từ AVM qua OVM rồi UVM. Để tiếp nhận kỹ thuật kiểm tra này đòi hỏi thời gian và nhân lực cho nên vẫn không được mọi người hưởng ứng. Hiện giờ những công ty hiện đại đang tìm kiếm cách giải quyết khác. Một trong những giải quyết này là làm kiểm tra ở tầng cao cấp hơn (higher abstraction)
Theo tôi thì sẽ có một thay đổi mới về cách thiết kế trong một vài năm tới.

[hithere123]

Dưới đây là đường dẫn tới một số video giới thiệu về TLM, các bạn có thể tham khảo để hiểu thêm về một bộ phận của công việc xây dựng test-bench.

TLM2-0 in Action Video Tutorial

Thân mến,

[Rommel.de]

Tớ không làm về TLM nên mảng này tớ không biết nhiều lắm nhưng cũng muốn trao đổi với mọi người một chút. Nếu tớ không nhầm thì systemc và TLM được đưa ra để tăng tốc độ chạy mô phỏng trong các hệ thống bao gồm cả hardware và software. Nếu dùng verilog để chạy mô phỏng thì chỉ có thể chạy một số chức năng cơ bản của phần cứng chứ khó mà có thể chạy nguyên một phần mềm ví dụ như boot một hệ điều hành lên được. Trong khi đó TLM thì khác. Nó sẽ không mô phỏng theo kiểu phần cứng mà lại mô phỏng hoàn toàn theo kiểu chạy của phần mềm nên rất nhanh. Nhưng ở đây có một luận điểm tớ muốn các bạn cùng trao đổi xem liệu có nên sử dụng systemc và TLM hay không?

Nếu tớ không nhầm thì ở chỗ tớ để chạy nguyên cả một phần mềm người ta dùng fpga emulator. Nó là một cái máy, kích thước cũng cỡ như một máy chủ, bên trong có rất nhiều fpga board. Người ta sẽ đem RTL code phân chia ra rồi nạp lên các board này vậy là fpga emulator này đã có thể chạy tương tự như một phần cứng thật sự. Tốc độ của emulator này rất chậm, dưới 10 MHz, nhưng cũng hoàn toàn đủ để chạy nguyên một phần mềm. Việc kiểm tra các tín hiệu bên trong khi đang chạy tương đối khó khăn hơn là dùng phần mềm mô phỏng nhưng nói chung vẫn có thể đọc ra để kiểm tra được. Hình như một cái máy fpga emulator này của synopsys bán cũng chỉ khoảng 100K chẳng là gì so với một công ty làm bán dẫn. Thêm một điểm nữa là fpga emulator chạy chính xác hơn nhiều so với dùng TLM vì TLM không quan tâm đến vấn đề thời gian.

[hithere123]

Theo mình biết thì những dự án lớn, phức tạp người ta hay dùng tới emulator, còn những loại tầm tầm như MCU 8-bit chẳng hạn thì có thể dùng mô phỏng để kiểm tra. Hơn nữa có một số phần việc mà dùng emulator không hiệu quả thì người ta sẽ dùng mô phỏng. Ví dụ như việc phân tích CPU load (đo thời gian tương tác của các ngắt theo những kịch bản khác nhau) bằng emulator là không đơn giản vì rất khó để có được những thông tin chi tiết về PC hay interrupt theo thời gian thực nếu quan sát bằng board mạch.

Thân mến,

[tonyvandinh]

Để mô phỏng một hệ thống, dùng C với native data type là lẹ nhất. SystemC với bit accurate data type thì chậm hơn nhiều nhưng có lợi điểm là xác thực hơn để mô phỏng phần cứng. TLM dung hòa ở giữa. Tùy theo mục đích mà xử dụng cho thích hợp.

Emulation thì lẹ hơn systemC nhưng phải có RTL và rất tốn kém cho nên không thích hợp để mô phỏng cả hệ thống. Thường thì để làm nhanh vấn đề thử nghiệm ở chip level.

Tony

Sent from my K1 using Tapatalk

[azuredragonk]

ủa cho mình hỏi là custom ic design là analog ic design chứ ko phải digital design đúng không vậy