CHƯƠNG 1. Quy Trình Thi ết K ế ASIC I- Giớ i thiệu tổng quan và v ị trí c ủa ASIC trong mô hình thi ết k ế
ASIC (Application Specific Intergrated Circuit) đượ c hiểu là vi mạch tích h ợ p dùng cho ằng đang nói về một phương một ứng dụng cụ thể. Khi nói thi ết k ế ASIC thì có th ể hiểu r ằng pháp trong nhiều phương pháp thiế t k ế vi mạch tích hợ p mật độ cao. Hình vẽ sau mô t ả việc thống kê các phương pháp thiế t k ế vi mạch tích h ợ p mật độ cao.
ế vi m ạch t ích h ợ p H ình 1.1 Các phương pháp thiế t k ế
Dựa trên mô hình 1.1 có th ể th ấy đượ c hai nhánh chính trong vi ệc phân chia các phương pháp là: Fully Custom và Semi Custom. Việc phân chia hai mô hình này d ựa trên cách th ức mà mạch tích hợ p đượ c xây d ựng.
Fully Custom: V ới phương pháp này,
gần t ất c ả các công đoạn thiết k ế m ạch tích hợp đều có s ự tham giam c ủa con ngườ i từ cấp độ thấ p nhất (cấp độ CMOS – CMOS Level) cho đế n cấp độ cao nh ất (cấp độ chip – Chip Chip Level). Các công c ụ tự động không được đánh giá cao trong mô hình này, chủ yếu chúng ch ỉ nhằm mục đích hổ tr ợ ợ, t ạo môi trường để định tính và định lượng. Các phương thứ c t ối ưu và hiệu năng phụ thuộc chủ yếu vào yếu tố con người. Do đó, phương pháp này chỉ phù h ợ p vớ i các luồng thiết k ế chip quy mô nh ỏ (IO cell), các thi ết k ế có tính k ế thừa (Memory) và các thi ết bị vi mạch tương tự (Analog device). Semi Custom: Ngượ c lại với phương pháp trên, các công cụ tự động đượ c sử dụng
nhiều trong mô hình này. Các tác v ụ phức t ạ p và nhiều công đoạn đượ c các công cụ tự động chia sẽ bớt cho con ngườ i.i. Gần như con ngườ i chỉ làm việc vớ i các cấ p độ cao (cấp độ c ổng – Gate Gate Level). Các công c ụ tự động này cho phép con ngườ i 1
có thể th ực hi ện khối lượ ng ng công vi ệc l ớn hơn. Điều này cho phép mô hình t ạo ra các vi m ạch tích hợ p phức tạ p vớ i nhiều chức năng hơn (CPU, các IP xử lý ảnh, âm thanh, dữ liệu …). Trong mô hình Semi Custom, 3 phương pháp nhỏ khác lại đượ c phân d ựa trên đặc tính của các đơn vị logic và cách mà các đơn vị logic k ết nối vớ i nhau. Các cell ( AND, OR, DFF…) đượ c các nhà s ản xuất cung cấ p sẵn dướ i dạng các b ộ thư viện theo các công ngh ệ khác nhau (180 nm, 65 nm, 28 nm,…). Mỗi một công ngh ệ sẽ có m ột hay nhiều bộ thư viện tương ứng. Các k ỹ sư thiết k ế dựa trên các b ộ thư viện này để phát triển các vi m ạch tích hợ p mật độ cao ở lên. từ cấp độ Cổng tr ở lên.
Standar Cell:
Gate Array:
Programmale Logic:
Cũng tương tự như Standard Cell, Gate Array cũng được xem như một thư viện cổng có s ẵn. Điều khác bi ệt giữa chúng là các Gate Array đã đượ c sản ời r ạc ạc mà chưa xuất thành các chip v ật lý sẵn có nhưng chỉ ở d d ạng các c ổng logic r ờ đượ c liên k ết. Các k ỹ sư có nhiệm vụ liên k ết các cổng này để tạo nên các ứng dụng tương ứ ng. Vớ i mô hình này, vi ệc thiết lậ p các mặt nạ trong quá trình s ản ết, đi dây nhằm k ết nối các đơn vị xuất là cần thiết nhưng chỉ cần cho việc liên k ết, logic sẵn có.
Cũng tương tự Gate Array nhưng việ c t ạo các m ặt nạ trong quá trình sản xuất thì không cần nữa. Những chip v ật lý dạng này tuy chưa hình thành các ứng d ụng c ụ th ể nhưng các cổng logic và các dây d ẫn k ết nối đã có sẵn và ngườ i k ỹ sư có thể lập trình trên các chip này để tạo các k ết n ối cho những ứng dụng cụ thể mà không c ần đến bất cứ quy trình sản xuất nào từ nhà máy n ữa.
Trong các mô hình s ản xuất trên, ASIC đượ c thể hiện bở i khu vực đươc đánh dấu qua hình 1.2
ế t ạo ASI H ình 1.2 Phương thứ c ch ế ASI C 2
có thể th ực hi ện khối lượ ng ng công vi ệc l ớn hơn. Điều này cho phép mô hình t ạo ra các vi m ạch tích hợ p phức tạ p vớ i nhiều chức năng hơn (CPU, các IP xử lý ảnh, âm thanh, dữ liệu …). Trong mô hình Semi Custom, 3 phương pháp nhỏ khác lại đượ c phân d ựa trên đặc tính của các đơn vị logic và cách mà các đơn vị logic k ết nối vớ i nhau. Các cell ( AND, OR, DFF…) đượ c các nhà s ản xuất cung cấ p sẵn dướ i dạng các b ộ thư viện theo các công ngh ệ khác nhau (180 nm, 65 nm, 28 nm,…). Mỗi một công ngh ệ sẽ có m ột hay nhiều bộ thư viện tương ứng. Các k ỹ sư thiết k ế dựa trên các b ộ thư viện này để phát triển các vi m ạch tích hợ p mật độ cao ở lên. từ cấp độ Cổng tr ở lên.
Standar Cell:
Gate Array:
Programmale Logic:
Cũng tương tự như Standard Cell, Gate Array cũng được xem như một thư viện cổng có s ẵn. Điều khác bi ệt giữa chúng là các Gate Array đã đượ c sản ời r ạc ạc mà chưa xuất thành các chip v ật lý sẵn có nhưng chỉ ở d d ạng các c ổng logic r ờ đượ c liên k ết. Các k ỹ sư có nhiệm vụ liên k ết các cổng này để tạo nên các ứng dụng tương ứ ng. Vớ i mô hình này, vi ệc thiết lậ p các mặt nạ trong quá trình s ản ết, đi dây nhằm k ết nối các đơn vị xuất là cần thiết nhưng chỉ cần cho việc liên k ết, logic sẵn có.
Cũng tương tự Gate Array nhưng việ c t ạo các m ặt nạ trong quá trình sản xuất thì không cần nữa. Những chip v ật lý dạng này tuy chưa hình thành các ứng d ụng c ụ th ể nhưng các cổng logic và các dây d ẫn k ết nối đã có sẵn và ngườ i k ỹ sư có thể lập trình trên các chip này để tạo các k ết n ối cho những ứng dụng cụ thể mà không c ần đến bất cứ quy trình sản xuất nào từ nhà máy n ữa.
Trong các mô hình s ản xuất trên, ASIC đượ c thể hiện bở i khu vực đươc đánh dấu qua hình 1.2
ế t ạo ASI H ình 1.2 Phương thứ c ch ế ASI C 2
Do ASIC đượ c hiểu như các vi mạch mang tính năng cố định không thay đổ i nên mô hình Custom Design và StandardCell la hai mô hình tiêu bi ểu. Thuyết minh chỉ đề cập đến mô hình sử d ụng Standar Cell ở các các phần ti ế p theo vì tính phù h ợ p c ủa nó cho các ứng d ụng lớ n và mật độ tích hợ p cao trong các các sản phẩm xử lý tín hiệu âm thanh mà thuy ết minh tiế p cận. II- Quy trình s ản xuất chip ASIC 1. Quy trình s ản xuất chip
Quy trình sản xu ất chip ASIC - StandarCell đượ c minh họa t ổng quan bở i hai bướ c chính trong hình 1.3
Development
Fabrication ản xu ấ t chip ASI H ình 1.3 Hai bướ c chí ch ín h tr ong on g s ASI C
Development: Dựa vào các thư viện đượ c cung c ấ p sẵn bở i nhà sản xuất, các k ỹ sư
sẽ thiết k ế phát triển các vi m ạch tích h ợ p dựa trên các ràng bu ộc tương ứng c ủa thư viện này. Trong bướ c này, các ch ức năng mong muố n của vi mạch tích hợ p đượ c hình thành d ựa trên sự liên k ết giữa hàng triệu các cổng logic. K ết thúc của bướ c này, các k ỹ sư thiết k ế s ẽ cho ra m ột s ản ph p hẩm trí tuệ có thể t ạm gọi là một gói phần mềm (Trong công nghiêp: .gds). Gói file này ch ứa các thông tin layout của toàn bộ thiết k ế cùng v ớ i các s ố liệu hiệu năng tươ ng ng ứng (Diện tích, năng lượ ng, ng, tốc độ …).
Fabrication: V ớ i
thông tin t ừ .gds từ bướ c phát triển thiết k ế, các k ỹ sư sản xuất sẽ thiết k ế mặt nạ sản xuất vớ i công ngh ệ tương ứng. Dựa trên mặt nạ này, các vi mạch tích hợp đượ c sản xuất trên các đĩa silicol wafer tương ứng.
Do đề tài tiế p cận quy trình phát tri ển của một vi mạch tích h ợ p nên chỉ bướ c Development đượ c tham khảo và phân tích. Các bướ c nh ỏ trong quy trình phát tri ển m ột vi mạch tích hợ p theo mô hình ASIC được đặc tả bở i hình vẽ 1.4. Tiế p tục phân chia quy trình phát tri ển thành hai quy trình chính là FrontEnd và BackEnd
3
bướ c này, các ch ức năng chính ở m ức logic của thiết k ế đượ c thiết k ế đầy đủ. Khi hoàn tất bướ c này, các ch ức năng của chip cũng được đả m bảo chính xác nhờ các công đoạn kiểm tra lỗi vớ i sự hỗ tr ợ của các công c ụ tương ứng.
FrontEnd: T ại
ạch ASIC H ình 1.4 Các bướ c tr ong quy trình phát tr i ể n m ột vi m
BackEnd: Tại bướ c
này, các đặc tính vật lý hay hi ệu năng (Thờ i gian tr ễ, diện tích …) của thiết k ế đượ c kiểm tra và t ối ưu. Khi kế t thúc các thông s ố hi ệu năng đượ c tổng hợ p. Các thông s ố này cũng chính là thông số của thiết k ế. Sản phẩm cuối cùng của bướ c này chính là .gds s ẽ đượ c gửi đến nhà máy s ản xuất.
Trong hình 1.4, các công c ụ hổ tr ợ đều của công ty Synopsys, m ột trong những công ty h ổ tr ợ công cụ thi ết k ế vi mạch lớ n nhất th ế giớ i. Các sản ph ẩm của t ừng bướ c nh ỏ đượ c li ệt kê là các sản phẩm tiêu biểu. Những thông tin chi ti ết hơn về công cụ và sản phẩm của các bướ c nhỏ sẽ đượ c phân tích chi ti ết hơn ở các mục sau. Thuyết minh tiế p cận các ph ần mềm từ Synopsys vì tính th ống nhất và sự đảm bảo uy tín của các ph ần m ềm này đã được đánh giá bở i nhiều công ty l ớ n trên thế giới. Do đó, các phầ n sau s ẽ đề cập đến các ph ần mềm từ Synopsys mà không ph ải các phần mềm từ các công ty khác. 2. Một số thông tin vê công ty Synopsys
Đượ c thành lập vào năm 1986 bở i Tiến sĩ Aart de Geus và một đội ngũ kỹ sư từ Trung tâm vi điện t ử B ắc Carolina, Synopsys là công ty chuyên cung c ấ p các phần mềm t ự động nhằm giúp các k ỹ sư thiết k ế tiết kiệm thờ i gian cho vi ệc phát triển các sản phẩm vi mạch. Ngoài các phần mềm chuyên d ụng, Synopsys còn h ổ tr ợ các giải pháp thiết k ế cũng như các thiết k ế có s ẵn. Hiện này, Synopsys đang dẫn đầ u trong các công ty phát tri ển phần m ềm trong lĩnh vực này. Một số công ty tương tự như sau: Cadence, Mentor Graphic, Magma, Aldec … 4
Trong mô hình thi ết k ế ASIC, Synopsys h ổ tr ợ đầy đủ các phần mềm chuyên d ụng từ môi trườ ng phát triển đến môi trườ ng kiểm tra để các k ỹ sư phát triển t ừ bướ c Specification đến P&R . Do đó, Synopsys luôn là sự l ựa ch ọn ưa thích cho các công ty s ản xu ất các sản ph ẩm ASIC. 3. Các khái niệm cơ bản về thư viện và công ngh ệ CMOS 3.1.C hệ C
Trong thập kỉ này, những con chip được thiết kế chế tạo từ công nghệ CMOS. CMOS là linh kiện bán dẫn loại -xít Kim Loại. Nó bao gồm tran -sít-to NMOS và PMOS. Để hiểu CMOS hơn, đầu tiên chúng ta cần biết về Tran -sít-to MOS (FET) ở phần sau. Trong mô hình thiết k ế ASIC, những k ỹ sư thiết k ế chỉ làm việc ở mức th ấ p nh ất là mức c ổng (AND, OR, …) chứ không làm vi ệc ở mức CMOS. Bản chất các cổng logic này đượ c c ấu thành từ các CMOS. Tuy nhiên trong mô hình thi ết k ế ASIC, công vi ệc cấu thành các c ổng từ các CMOS là việc của các nhà s ản xu ất. Họ k ết n ối các CMOS t ạo nên các c ổng khác nhau ho ặc các cổng cùng lo ại nhưng khác về hiệu năng (tốc độ , diện tích, độ dẫn điện …) và tậ p khổng lồ các cổng này t ạo nên một thư viện. Thư viện này đượ c các nhà s ản xu ất cung cấ p cho các nhà thiết k ế. Dựa trên thông số của thư viện này, các nhà thi ết k ế có thể phát triển các vi mạch của họ một cách tùy ý v ớ i cấp độ thấ p nhất là lớ p cổng. Sau đây mộ t số nét về Transistor CMOS đượ c giớ i thiệu. -t-to MOS MOS thuộc về tran-sít-to hiệu ứng trường, loại linh kiện bán dẫn ô -xít kim loại. MOS là đơn vị cơ bản trong thiết kế những mạch tích hợp kích c lớ n. Nó là được điều khiển bằng điện áp. Những tran -sít-to này được hình thành tương tự như ý tưở ng làm một bánh sandwich bao gồm các lớp bán dẫn, kim loại, l ớp cách điện x ế p ch ồng lên nhau . Những lớp này được làm theo một mô hình sẵn có để mà cho phép những tran -sít-to được hình thành trong vật liệu bán dẫn (chất nền) tran -sít-to MOS bao gồm 3 cực: Nguồn, Máng, và cổng. Cực Nguồn và Máng thì tương tự nhau, và được đánh dấu dựa trên điểm mà nó kết nối. Nguồn là loại đầu cuối, hoặc nút, hoạt động như nguồn của các h ạt mang điện; các hạt mang điện ra khỏi nguồn và đi tới máng. Đối với MOSFT kênh N (NMOS), cực nguồn mang điện tích âm hơn trong các cực với kênh P (PMOS), nó mang điện tích dương hơn trong các cực. ng bên dưới cổng ô -xít được gọi là kênh. ình bên dưới là Tran -sít-to MOS.
ắt P MOS đơn giản H ình 1.5 M ặt c 5
Vớ i các điều kiện cung cấp điện áp ở cực Cổng và c ực Máng, hoạt động của các tran-sít-to đượ c phân chia làm 3 vùng rõ r ệt. Vùng tắt (không có dòng điệ n ch ạy t ừ c ực máng đến c ực nguồn), vùng tuyến tính (Dòng điện tăng dầ n chạy từ c ực máng đến cực nguồn) và vùng bảo hòa (dòng điện giữ nguyên giá tr ị chạy từ cực nguồn đến cực máng). ình vẽ sau mô t ả 3 vùng nêu trên của CMOS
ủa CM OS H ình 1.6 V ùng ho ạt động c
Công nghệ CMOS dựa trên các tran -sít-to NMOS và CMOS. Những thiết bị linh kiện bán dẫn b -xít kim loại (CMOS) có mức lô-git thường được sử dụng với độ nhạy cao, một số lượng lớn tran-sít-to tích hợp trong các mạch được tìm thấy trong mọi thứ, từ con vi xử lý phức tạp cho tới những mạch truyền tải và xử lý tín hiệu. Cấu trúc CMOS rất phổ biến bởi vì đặc tính tiêu thụ năng lượng thấp, tốc độ xung clock hoạt động cao, và dễ dàng thực hiện ở các cấp độ tran-sít-to. Các mạng tran -sít-to bổ khuyết kênh p và kênh n được dng để kết nối đầu ra của các thiết bị có mức lô -git với cả nguồn ung cấp dd và ss cho một trạng thái logit đầu vào có sẵn. Các tran -sít-to MOSFT có thể được coi như các công tắc đóng ngắt đơn giản. Công tắc được đóng (dẫn) khi có dòng chảy giữa Nguồn và Máng. Các hạt mang điện trong tran-sít-to PMOS là lỗ trống và hạt mang điện trong NMOS là các ê-léc-tron. Độ linh động của các ê -léc-tron thì gấp lần các lỗ trống. ì điều này,ng ra tăng và giảm vài lần là khác nhau. Để bằng nhau, chỉ số L của tran -sít-to PMOS được tạo ra cao gấp lần tran -sít-to NMOS. ằng cách này, PMOS và NMOS tran -sít-to sẽ có cng khả năng d ẫn và truyền điện. Trong một thư viện mẫu chính thống, độ dài L của một tran-sít-to là luôn luôn không đổi. Độ rộng được thay đổi để có sức mạnh điều khiển khác nhau cho mỗi cổng. Trở kháng được tính theo L. Do đó nếu tăng độ rộng, trở kháng suy giảm. Ở vi mạch s ố, ch ủ yêu CMOS đượ c kích thích ho ạt động ở hai phân vùng t ắt và bảo hòa. Việc chuyển tr ạng thái giữa hai phân vùng (vùng tuy ến tính) đượ c rút ngắn nh ất có thể nhằm giúp CMOS đạt tr ạng thái ổn định trong thờ i gian nhỏ nhất có thể. 6
III- Chi ti ết quy trình thi ết k ế chip ở bướ c thiết k ế FrontEnd 1-
Đặc tả chức ă chh – Specification
Đầu tiên, dựa trên các yêu c ầu của khách hàng đề ra, những sơ khở i và chức năng chính của thiết k ế đượ c hình thành. Ở bướ c này, các ch ức năng được đặc tả ở dướ i dạng các hình v ẽ sơ đồ khối, giao diện cũng như nhữ ng hiệu năng ban đầu mong muốn đạt đượ c. Gần gũi nhất đối v ớ i các bản đặc t ả này có l ẽ là các b ản DataSheet của các IP hay các thiết bị. Có thể hiểu r ằng các bản DataSheet là phiên bản hoàn thiện của các bản đặc tả khi mà chip đã đượ c sản xuất.
Do đó, các thông số hi ệu năng trên các DataSheet cũng như giao diệ n, kiến trúc khối là chính xác và đã được đả m bảo. Ngượ c lại ở các b ản đặc tả, những giao diện, k ết nối và những thông số này ở d ạng ước lượ ng hay mong mu ốn đạt đượ c và có thể s ẽ đượ c chỉnh s ửa nhiều lần trong quá trình thi ết k ế. Dựa vào quy mô thi ết k ế mà có thể hi ểu đặc t ả ch ức năng đượ c chia làm hai lo ại mà tạm gọi là General Specification và Intenal Specification.
General Specification:
Các đặc tả chức năng chỉ ở dạng khối. Các k ết nối giữa các khối cũng như giao diệ n cấp độ chip đượ c liệt kê chi tiết. Các thông s ố hiệu năng được đặc tả cho từng khối. Nói chung, đặ c tả theo khối đượ c thể hiện.
Internal Specification:
Đặc tả theo dạng này dành cho các k ỹ sư thiết k ế phần cứng mức độ RTL. Các đặc tả này đượ c chi tiết hóa đến các mức cổng và FlipFlop. Do đó, các chức năng chính củ a thiết k ế cũng đượ c chi tiết hóa một cách rõ ràng vớ i các bảng giá tr ị cũng như nhữ ng liên k ết sâu bên trong các kh ối chính trong thiết k ế.
2- Thiết k ế mứ c hệ thống – System Level Design - SLD
Khái niệm thiết k ế hệ thống (SLD) đượ c xem là khái ni ệm mớ i trong thậ p k ỷ vừa qua. ướ c thiết k ế này đượ c thêm vào cùng v ớ i những thuận lợ i mà nó tạo ra nhằm giải quyết các vấn đề chính như sau.
Giảm thiểu tối đa thờ i gian chip ra th ị trườ ng từ lúc có yêu c ầu của khách hàng.
Giảm thiểu tối đa số chip lỗi trướ c và sau quá trình s ản xuất.
Để hiểu tại sao có th ể giảm thiểu đượ c những số liệu này, ti ế p tục phân tích hình 1.7 để hiểu r hơn nhữ ng khái ni ệm mới và cách mà bướ c thiết k ế này thực hiện
7
SL D H ình 1.7 Các k hái ni ệm vàv ấn đề trong bướ c thi ết k ế 2.1 C++ trong thiết k ế phần cứ ng
Là một trong những ngôn ngữ lậ p trình hướng đối tượ ng cấ p cao. C++ k ế thừa toàn bộ các thư viện C chuẩn k ết hợ p với đặc tính hướng đối tượ ng, nó tr ở thành một ngôn ngữ đượ c đánh giá mạnh mẽ trong những công đoạn mô phỏng hay mô t ả hành vi cho ph ần cứng. Trong thiết k ế phần cứng, C++ đã tr ở thành công c ụ quen thuộc trong các môi trườ ng kiểm tra thiết k ế vì tính linh độ ng và thờ i gian ch ạy r ất ngắn của chúng.
Ở đây, những ưu điểm của C++ được khai thác trong lĩnh vự c phần cứng mà không đề cậ p trong lĩnh vực phần mềm. Một ví dụ minh họa dễ hi ểu cho thấy việc thiết k ế hành vi của một IP thông thườ ng, sau khi hi ểu đượ c những đặc tả của thiết k ế, một ngườ i k ỹ sư có kinh nghiệm chỉ mất khoảng phân nữa thời gian để thiết k ế và ki ểm tra hành vi của nó so vớ i ngườ i thiết k ế bằng ngôn ngữ phần cứng (Verilog & VHDL). Do đó, C++ được ưa chuộ ng trong mô hình ki ểm tra thiết k ế phần cứng. Nó mô t ả hành vi của ph ần c ứng và so sánh k ết quả của nó vớ i k ết quả phần cứng c ần ki ểm tra và cho nh ững k ết quả so sánh cu ối cùng. Trong thuyết minh không chi ti ết hóa ngôn ng ữ C++ vì nó được xem như công cụ ngôn ngữ hổ tr ợ trong quá trình phát tri ển vi mạch. 2.2 SystemC Class
Mặc d C++ được đánh giá là ngôn ngữ mạnh mẽ trong việc hổ tr ợ thiết k ế các mô hình mô phỏng hành vi của phần cứng nhằm kiểm tra và đánh giá so vớ i các phần cứng thật. Tuy nhiên C++ v ẫn còn tồn tại nhiều hạn chế như sau.
Hạn chế trong việc mô phỏng các tác v ụ song song và tính ưu tiên giữ a các tác v ụ
8
Hạn chế trong việc mô phỏng các hi ệu năng như thờ i gian, hiệu suất.
Hạn chế trong việc mô phỏng các giao th ức bắt tay của phần cứng.
Bở i thế, các nhóm nghiên c ứu đã phát triển một lớ p dữ liệu mớ i cho C++ là System C nhằm mục đích khắ c phục các nhược điểm trên. Thông qua các đối tượ ng trong lớ p SystemC, các chức n ăng của ph ần c ứng đượ c mô hình hóa gi ống thật hơn. Ngoài ra, một s ố chức năng tháo g lỗi như xem waveform cũng đượ c hổ tr ợ.
Tương tự như các lớ p dữ liệu khác, SystemC đượ c sử dụng như một lớ p dữ liệu bình thường. Ngườ i dùng sau khi khai báo đề u có thể sử dụng mọi đối tượ ng mà lớ p này cung cấ p. 2.3 Mô hình truyền tải – Transaction Level Model – TLM
Vớ i C++ và l ớ p SystemC, các mô phỏng hành vi ph ần cứng gần như hoàn thiệ n. Tuy nhiên vẫn còn một số hạn chế về các giao th ức giao tiế p giữa các kh ối kiến trúc vớ i nhau. Tiêu biểu cho điều này là các giao th ức Bus nói riêng. N ếu sử dụng ngôn ngữ để mô tả các giao th ức bắt tay sao cho gi ống như các giao thứ c mà phần cứng thể hiển, đó là một điề u hết sức khó khăn vớ i những k ỹ sư mô phỏng hành vi. M ặt khác tính k ế thừa mất đi mặc dù chỉ một số thay đổi nhỏ trong giao thức. ơn nữa hi ệu năng về mô phỏng thờ i gian thực cũng sẽ b ị h ạn chế khi theo phương thức cũ này. Chính vì những hạn chế này, mô hình TLM đượ c phát triển bở i Thorsten Grötker vào năm 2000, một trong những người đứng đầu của bộ phận R&D thuộc công ty Synopsys. B ằng ngôn ngữ C++ vớ i sự hổ tr ợ của lớ p SystemC, mô hình TLM được ra đờ i nhằm thống nhất mô phỏng các giao th ức. Nói một cách đơn giản, TLM được xem như một lớ p dữ liệu mớ i nhằm h ổ tr ợ C++ trong v ấn đề mô hình hóa các giao th ức truyền nh ận và b ắt tay giữa các IP hay các core x ử lý. Tương tự lớp SystemC, TLM cho phép ngườ i dung sử dụng những đối tượ ng mà nó cung c ấp để phát triển các phương pháp đánh giá riêng cho IP cũng như hệ thống trong quá trình b ắt tay hay truyền tải dữ liệu. 2.4 Platform and SystemC Model
Khái niệm platform đượ c giớ i thiệu trong bướ c thiết k ế này nhằm ám chỉ toàn bộ mô hình phần c ứng đượ c mô hình hóa b ằng m ột gói phần m ềm mà gói phần mềm này đượ c phát triển d ựa trên nền t ảng C++ và SystemC. Khi m ột hệ th ống m ớ i ra đờ i, những thay đổi đáng kể hay không đáng kể s ẽ đượ c c ậ p nh ật. D ựa trên những đặc tính cậ p nh ật này, gói ph ần m ềm cũ sẽ đượ c c ải ti ến sao cho mô hình hóa gi ống vớ i hệ thống m ớ i. Công vi ệc này s ẽ tốn r ất ít thờ i gian vì việc cải tiến hành vi phần mềm trên nền tảng C++ là m ột công việc dễ dàng. Khái ni ệm Platform có thể hiểu giống như khái niệ m một khuôn mẫu có sẵn để s ản xu ất các mặt hàng và ngườ i sản xuất có thể chế biến thay đổi các mẫu cụ thể dựa trên khuôn m ẫu tổng quát này.
Platform:
SystemC Model: Ám chỉ phương pháp mô hình hóa phầ n cứng trên nền tảng C++ vớ i
sự hổ tr ợ bởi các đối tượ ng trong lớ p SystemC. 9
Để hi ểu hơn về tính liên k ết giữa các khái ni ệm trên, hình 1.8 đượ c giớ i thiệu. Trong hình 1.8, một MCU (micro controller) tổng quan vớ i các IP tiêu bi ểu bên trong đượ c giớ i thiệu.
Các hành vi c ủa các IP cũng như CPU, DMAC,… đượ c mô hình hóa trên n ền tảng ngôn ngữ C++ vớ i sự hổ tr ợ của lớ p SystemC. Các khối IP và CPU đượ c liên k ết v ới nhau thông qua bus. us này đượ c mô hình hóa bởi mô hình TLM đượ c giớ i thiệu ở trên.
Khi các mô hình đượ c phát triển và đượ c n ối v ớ i nhau, chúng hình thành nên m ột Platform hay ta nói m ột MCU giả lập đượ c phát triển trên nền tảng ngôn ngữ lậ p trình cấ p cao. Ở phương diện thiết k ế có thể xem đây là một gói phần mềm.
ụ mô hình hóa ph ần c ứn g c ủa m ột MCU H ình 1.8 Víd Như
vậy, để tr ả lờ i cho các câu h ỏi đã nếu t ừ trướ c là tại sao cần bướ c thiết k ế SLD trong quy trình phát triển ASIC, thêm một hình vẽ nữa đượ c thể hiện
ủa SLD tr ong qu y tr ình phát tr i ển ASIC H ình 1.9 Vai tr ò c 10
Trong hình 1.9, khi k ết thúc bướ c SLD, một ph ần c ứng giả l ậ p đượ c t ạo ra. Mô hình này sau đó đượ c ki ểm tra và đánh giá hiệu năng. Khi các kế t qu ả đánh giá đượ c cho là th ỏa mãn và phù hợ p v ớ i yêu cầu mong muốn ban đầu cũng có nghĩa là những yêu cầu đặt ra ở bướ c đặc tả hợp lý. Ngượ c lại, trong quá trình kiểm tra và đánh giá hiệu năng củ a mô hình phần cứng, những k ết quả không phù h ợ p hay các l ỗi về đặc tả đượ c phát hiện sẽ đượ c hồi tiế p. Lúc này các yêu c ầu ban đầu trong đặ c tả sẽ đượ c cải thiện hoặc đổi mớ i hoàn toàn n ếu đó là những lỗi đáng kể.
Như vậy, k ết thúc của bướ c SLD sẽ cho ta m ột platform tương ứng vớ i mô hình ph ần cứng và một đảm bảo cho bản đặc tả hệ th ống cần thiết k ế (golden specification). D ựa trên hai s ản phẩm này, những lợi ích sau đượ c phân tích. Vớ i việc đảm bảo tính đúng đắ n và kh ả thi của bản đặc tả, việc thực thi viết thiết k ế ở cấ p độ thấp hơn (RTL) dựa trên bản đặc tả đạt tính an toàn cao. Nh ững lỗi mắc phải khi xung độ t giữa thiết k ế phần cứng và đặc tả đượ c hạn chế b ớt. Điều này có giá tr ị r ất lớn đối vớ i những xung đột đượ c phát hiện muộn (ở những khâu sau cùng c ủa việc thiết k ế). Đó là lý do làm cho sản phẩm phần cứng tránh đượ c r ủi ro và làm th ời gian đưa ra thị trườ ng nhanh chóng. Mặt khác, những mô hình phần mềm chạy trên nền tảng phần cứng luôn đượ c thiết k ế song song vớ i phần cứng. Các ph ần mềm này luôn đượ c phát triển vớ i tốc độ nhanh hơn phầ n cứng. Tuy nhiên, vi ệc phát triển nhanh hơn sẽ tr ở nên vô ích n ếu chúng không đượ c kiểm duyệt và cải thiện. Việc ch ờ đợ i ph ần c ứng là một điều b ất kháng đối v ớ i những k ỹ sư phần mềm ở nh ững thời điểm trước. Khi platform đượ c t ạo ra, các ph ần m ềm này có th ể chạy giả lậ p m ột cách dễ dàng trên các Platform này. Vi ệc này giúp gi ảm b ớ t thờ i gian chờ đợ i ph ần cứng cũng như kiểm tra đượ c s ự phù hợ p giữa ph ần c ứng và phần mếm t ừ r ất s ớm. Đôi khi các lỗi của phần cứng có thể đượ c phát hiện ở bướ c này. Một y ếu t ố thu ận l ợ i n ữa ở bướ c thiết k ế SLD là môi trườ ng thiết k ế và kiểm tra đơn giản chỉ c ần m ột trình biên dịch cho C++. Điều này luôn là điều d ễ dàng không nh ững trong môi trườ ng h ọc thuật mà còn trong môi trườ ng công nghi ệ p vì có r ất nhiều trình biên dịch miễn phí hoặc dễ dàng phát triển chúng dựa trên một nền tảng sẵn có.
Như vậ y, SLD ngày càng tr ở nên quan tr ọng trong quy trình s ản xu ất chip ASIC vớ i m ật độ tích hợp cao. Trong tương lai gần, nó sẽ thay thế ngôn ngữ lậ p trình phần cứng (Verilog/VHDL) trong việc thiết k ế phần cứng vớ i các công c ụ hổ tr ợ tổng hợ p xuống cấp độ cổng từ C++ và SystemC. 3- Thiết k ế mứ c thanh ghi – RTL design
Sau khi hoàn thành bướ c SLD nh ằm đảm bảo các đặc tả là chính xác và kh ả thi, bướ c thiết k ế RTL đượ c th ực hi ện. RTL (Register Transfer Level) đượ c hi ểu là thiết k ế ở c ấp độ thanh ghi. Ở c ấp độ thi ết k ế này, các lu ồng d ữ li ệu luân chuyển bên trong các kh ối ki ến trúc đượ c làm rõ ở cấp độ từ thanh ghi này qua thanh ghi khác. Ngôn ngữ đượ c sử dụng ở cấp độ thiết k ế này là Verilog ho ặc VHDL. Dựa trên các đặc t ả có từ trướ c, k ỹ sư thiết k ế sử dụng ngôn ngữ erilogDL để mô hình hóa l ại kiến trúc
11
phần cứng. Thuyết minh tiế p cận ngôn ngữ Verilog là ngôn ng ữ sẽ đượ c sử dụng để phát triển đề tài vì tính tiện dụng và gần gũi của nó đớ i với ngườ i lậ p trình. Verilog, đượ c chuẩn hóa theo IEEE 1364, là m ột ngôn ngữ mô tả phần c ứng (DL) đượ c sử dụng để mô hình hóa các h ệ thống điện tử. Nó thường đượ c sử dụng trong việc thiết k ế và kiểm tra mạch k ỹ thuật số ở cấ p độ truyền dữ liệu giữa thanh ghi (RTL level) . Nó cũng đượ c sử dụng trong việc kiểm tra hành vi các vi m ạch tương tự và mạch tín hiệu hỗn hợ p (số và tương tự). Verilog là ngôn ngữ mô tả phần cứng đầu tiên được phát minh. Nó đượ c tạo ra bở i Phil Moorby và Prabhu Go el trong ma đông năm 19831984 . Hi ện nay, đã có các phiên bả n 95, 2001 và 2005. Ngoài ra, m ột ngôn ngữ khác là System erilog đã xuấ t hiện dựa trên nền tảng của Verilog nhằm cung cấ p nhiều tác vụ và hàm h ệ thống phục v ụ cho việc vi ết các trườ ng hợ p kiểm tra lớ n. Có m ột lưu ý về ngôn ngữ thiết k ế ph ần c ứng và vai trò c ủa thiết k ế ở c ấp độ RTL. Mục đích chính của cấp độ này là mô hình hóa ph ần cứng b ằng ngôn ngữ phần cứng nhưng sản phẩm coding phải có kh ả năng tổng hợ p xuống lớ p cổng đượ c. Ngôn ng ữ phần cứng chỉ mang ý nghĩa công cụ nghĩa là kỹ sư có thể sử dụng ngôn ngữ này tùy bi ến. Hay nói cách khác có th ể vi ết mô phỏng phần c ứng v ớ i nhiều cách th ức, đoạn code khác nhau. M ặc dù v ề chức năng chúng vẫn đả m bảo chạy đúng như đặ c tả nhưng chỉ có những đoạn code thỏa mãn các ràng buộc thì mớ i có thể tổng hợp đượ c. Do đó khi sử dụng ngôn ngữ phần cứng vào mục đích thiết k ế phần cứng cần phải chú ý nh ững tiêu chí sau
Phiên bản ngôn ngữ phần cứng mà công c ụ biên dịch hổ tr ợ.
Các ràng buộc và điều kiện để có thể tổng hợ p xuống lớ p cổng.
Cách thức viết để có thể dễ dàng hiểu và tái sử dụng.
4- Kiểm tra thi ết k ế mứ c RTL – RTL Verification
Sau khi kiến trúc đượ c thiết k ế ở cấp độ RTL dướ i dạng các đoạn mã Verilog/VHDL, chúng sẽ đượ c ki ểm tra và đánh giá các chức năng logic. Có rấ t nhiều mô hình ki ểm tra các đoạn code RTL, ở đây tạm chia làm 3 mô hình chính.
Unit Test: Kích
thích tr ực tiế p vào ngõ vào c ủa thiết k ế nhằm tạo ra các trườ ng
hợ p cần kiểm tra. Nối khối kiến trúc cần kiểm tra (Design Under Test - DUT) vớ i một số khối liên k ết khác trong h ệ thống. Mô hình hóa sao cho các ngõ vào c ủa DUT nhận các tín hi ệu từ các khối liên k ết. Việc thay đổi các tín hiệu này t ừ các khối liên k ết cũng chính là các trườ ng hợ p cần kiểm tra của DUT.
Combination Test:
System Test:
K ết nối kh ối kiến trúc vào trong m ột hệ thống hoàn ch ỉnh. Viết các đoạn chương trình tạo hoạt động cho hệ thống sao cho DUT đượ c sử dụng trong đoạn chương trình đó. Các trườ ng h ợ p kiểm tra phụ thuộc vào đoạn chương trình mà hệ thống chạy trên nó.
12
Để hiểu r hơn về các mô hình ki ểm tra này, t ừng mô hình đượ c rút trích và phân tích. 4.1 Unit Test
Thông thườ ng sau khi thi ết k ế ở cấp độ RTL, Unit Test đượ c thực hiện luôn bở i những k ỹ sư phát triển code Verilog. Các trườ ng h ợ p ki ểm tra đượ c liệt kê dướ i dạng các file tài li ệu. Sau đó, dựa trên các tài li ệu này, các trườ ng hợ p kiểm tra đượ c phát triển cùng vớ i môi trườ ng để thực hiện công đoạ n kiểm tra này. Để hi ểu r hơn về quy trình ki ểm tra Unit Test này, m ột môi trườ ng và cách th ức thực thi mà thuyết minh sẽ tiế p cận đượ c giớ i thiệu.
Môi trườ ng thiết k ế và ki ểm tra: Hệ điều hành Linux. Ngôn ngữ thiết k ế đượ c chọn : Verilog.
Công cụ hổ tr ợ: Phần mềm VCS của Synopsys và ph ần mềm DVE.
Môi trườ ng soạn thảo code Verilog: Trình so ạn thảo VI trong Linux.
Các trườ ng hợ p kiểm tra cũng như cách kích thích các tín hiệ u ngõ vào c ủa thiết k ế đượ c mô tả bở i ngôn ngữ erilog và cũng trên trình soạ n thảo VI. Từ Testench đượ c s ử dụng để ám chỉ đoạn mã code erilog mà trong đó chứa cách th ức ki ểm tra, thiết k ế cần kiểm tra và các trườ ng hợ p kiểm tra thiết k ế đó.
4.1.1 Linux và trình so ạn thảo VI
Linux là tên gọi của m ột hệ điều hành máy tính và cũng là tên hạt nhân của h ệ điều hành. Có r ất nhiều phiên b ản sau này d ựa trên nhân c ủa nó. Nó có l ẽ là một ví dụ nổi tiếng nhất của phần mềm t ự do và của vi ệc phát triển mã nguồn mở … Trong môi trườ ng công nghi ệ p, đặc biệt là môi trườ ng lậ p trình thiết k ế phần cứng, Linux là hệ điều hành đượ c dung r ộng rãi. Gần như tất cả các công đoạn phát triển vi mạch đều đượ c thực hiện trên môi trườ ng này. Vớ i môi trườ ng thiên về h ổ tr ợ các tác v ụ d ựa trên các l ệnh, Linux phù h ợ p cho nh ững tác vụ có tính lặp đi lặ p lại hay nh ững mã l ệnh hồi quy… Trình soạn thảo I cũng là môi trường tương tác giữa ngườ i dung vớ i máy tính. Thông qua trình soạn thảo này, ngườ i dùng có th ể viết những câu lệnh để gọi các phần mềm hay soạn thảo những đoạn code trên chính giao di ện này. Việc sửa lỗi cũng như g lỗi đượ c hổ tr ợ tích cực bở i trình soạn thảo này bở i các tác v ụ bằng lệnh nhanh nh ẹn. Có thể nói sử dụng trình soạn thảo VI trên n ền Linux là m ột trong những k ỹ năng không thể thiếu của k ỹ sư thiết k ế phần cứng 4.1.2 VCS và DVE
VCS là một trong những công cụ mà Synopsys h ổ tr ợ để kiểm tra hành vi, chức năng về tính logic các thi ết k ế phần cứng cấp độ RTL. Có thể dùng cụm từ Dynamic erification cho công vi ệc mà phần mềm VCS hổ tr ợ. Có thể hiểu r ằng phần mềm chỉ hổ tr ợ kiểm tra tính logic của thiết k ế mà không ki ểm tra hay đánh giá các hiệu năng về thờ i gian, diện tích, năng
13
lượng …CS có thể hổ tr ợ cho nhi ều loại ngôn ngữ ở cấp độ RTL cùng m ột lúc như erilog, VHDL hay System Verilog. Có hai tr ạng thái sử d ụng CS đó là trạ ng thái sử dụng GUI hoặc tr ạng thái COMMAND LINE. Ở tr ạng thái sử dụng GUI, người dng tương tác trự c tiế p lên giao di ện của phần mềm để thực hiện ý đồ của mình. Trong tr ạng thái COMMAND LINE, tất cả các thao tác đượ c thực thi bằng các l ệnh, người dng thông qua các file tườ ng thuật (report file) để hiểu và nắm bắt quát trình thực hi ện. Trong môi trườ ng công nghi ệ p, tr ạng thái COMMAND LINE luôn đượ c khuyến khích khuyên dùng. Hình v ẽ dưới đây mô tả cách gọi phần mềm VCS và sử dụng ở tr ạng thái COMMAND LIN cũng như các ty chọ n khi sử dụng phần mềm này.
ềm VCS H ình 1.10 Tr ạng tháiCOM M AND L I NE g ọi ph ần m
Sau khi hoàn t ất thiết k ế (thiết k ế viết bằng ngông ng ữ erilog) và môi trường để kiểm tra thiết k ế (Môi trường đượ c viết bằng ngôn ngữ Verilog bao gồm các trườ ng hợ p kiểm tra cách thức kiểm tra thiết k ế). Phần mềm CS đượ c gọi ra và thực thi nhằm kiểm tra sự tương đồng và chính xác c ủa thiết k ế so vớ i mong muốn. Người dng quan sát các file tườ ng thuật để nắm bắt các lỗi mà thiết k ế vi phạm. Tuy nhiên, m ột số lỗi đặc bi ệt ví dụ như Rising (lỗi một tín hiệu đượ c kích thích t ừ hai nguồn tín hiệu khác nhau) khó có th ể kiểm tra bằng m ắt qua các file tườ ng thuật. Để hổ tr ợ cho việc g lỗi đượ c tiện lợi và nhanh hơn, phầ n mềm D đượ c k ết hợ p sử dụng để xem các file d ạng sóng tín hi ệu mà phần mềm VCS tạo ra. Dựa trên giao diện DVE, dạng sóng của tín hiệu được tườ ng thuật tr ực quan. Điều này giúp ngườ i dùng nhận ra các l ỗi đặc biệt nhanh chóng. Hình v ẽ dưới đây là một trong những giao diện của DVE
ớ i sóng tín hi ệu H ình 1.11 Giao di ện DVE v 14
4.1.3 TestBench
TestBench là tên g ọi đượ c nhiều ngườ i ám chỉ đến môi trườ ng kiểm tra thiết k ế cấp độ RTL hay cũng đượ c ám chỉ đến file (viết b ằng erilog) mà trong đó các trườ ng hợ p kiểm tra và thiết k ế cũng như cách thức kiểm tra đượ c thể hiện.
Để hi ểu rõ khái niệm này, một mô hình tr ừu tượng đượ c th ể hi ện qua hình các hình minh họa sau đây
ữ s ử d ụng để vi ết thi ết k ế vàtestbench H ình 1.12 N gôn n g
H ình 1.13 Cách th ứ c kích thích ngõ và o c ủa thi ết k ế
Phân tích hình 1.13 cho th ấy cách th ức mà testbench đượ c s ử d ụng để kích thích ngõ vào của thiết k ế. Các ngõ vào c ủa thiết k ế đượ c k ết n ối v ớ i các bi ến reg – d ạng thanh ghi, các ngõ ra của thiết k ế đượ c liên k ết vớ i biến wire – dạng dây. Các biến này đượ c khai báo bên trong file testbench (Vi ết bằng Verilog). Khi muốn kiểm tra các trườ ng hợ p mong muốn, các biến thanh ghi ngõ vào được thay đổi giá tr ị nhằm t ạo các giá tr ị ki ểm tra trên ngõ vào thi ết k ế. Các ngõ ra c ủa thiết k ế sau đó đượ c c ậ p nh ật và so sánh v ớ i giá tr ị mong muốn. K ết qu ả so sánh s ẽ được ngườ i dùng bắt l ấy và xem xét thông qua các file tườ ng thuật hoặc gi ảng đồ xung.
15
Có một số vấn đề cần quan tâm là khi s ố lượng trườ ng hợ p kiểm tra lớ n thì cách th ức thực hiện như thể nào trong file testbench đượ c xem là phù hợ p. M ột v ấn đề n ữa là cách th ức mà ngườ i dùng sử d ụng để lấy đượ c thông tin so sánh k ết quả như là vào thời điể m nào thì hợ p lý…
ấn đề c ần quan t âm tr ong thi ế t k ế T estbench H ình 1.14 Hai v
Một ví dụ cho thấy các bướ c cần thực hiện và m ột đoạn code mẫu khi viết một file testbench. Các bướ c liệt kê có thể xáo tr ộn thứ tự do ngôn ngữ lậ p trình phần cứng không thực thi theo th ứ t ự t ừ trên xuống mà song song theo th ờ i gian. Khi nhìn vào các kho ản m ục Declare Testcases và Catch the output sẽ thấy đượ c hai v ấn đề c ần quan tâm đượ c nêu ở trên.
ụ các thành ph ần tr ong fi le testbench H ình 1.15 Víd 16
Một trong những giải pháp cho v ấn đề nhiều trườ ng hợ p kiểm tra là s ử dụng các tác v ụ Task. ình vẽ tiế p theo minh họa cho giải pháp này.
ụ minh h ọa task H ình 1.16 Víd
Phân tích hình 1.16 cho th ấy các trườ ng hợ p kiểm tra đượ c gói gọn trong các tác v ụ cpu_write hoặc cpu_read, các đoạn code mô t ả các tác v ụ này có th ể đượ c viết ở các file khác hoặc trên cùng m ột file vớ i file testbench. Cách làm này giúp vi ệc thêm và bớ t các trườ ng hợ p kiểm tra tr ở nên dễ dàng, linh động và độ c lậ p.
Đối v ớ i v ấn đề th ứ hai cần quan tâm là cách l ấy đượ c k ết qu ả so sánh ở ng ra đúng thờ i điểm. Ngôn ngữ Verilog hổ tr ợ r ất nhiều hàm hệ thống (System Functions) có s ẵn cho mục đích này. Tuy nhiên chỉ một số đượ c sử dụng thườ ng xuyên
ố hàm h ệ th ố n g trong Veril og H ình 1.17 M ột s
Hình vẽ sau đây mô tả cách ti ế p c ận vi ệc xây dựng mô hình kiểm tra trong hệ th ống nhận dạng giọng nói. Mô hình này đã đượ c xây dựng thành công ch ạy thử nghiệm trên tậ p từ vựng nhỏ r ời r ạc. 17
ận d ạng gi ọng nói H ình 1.18 M ô hình Un it T est cho h ệ th ố n g nh
Các thông số mô hình và các file gi ọng nói được lưu trữ trên hai vùng nh ớ RAM khác nhau. Khi ngườ i dùng chạy mô hình ki ểm tra, các file giọng nói lần lượt được đưa vào thiết k ế (DUV), tại đấy chúng s ẽ đượ c ki ểm tra tương ứng v ớ i các thông s ố mô hình lấy t ừ vùng nhớ RAM thông số. Các k ết quả sẽ đượ c kiểm chứng qua các file tườ ng thuật. 4.2 Combination Test
Mô hình kiểm tra này như đã giớ i thiệu ở trên cần có các ki ến trúc phụ tương tác. Các IP sau khi đượ c phát triển sẽ k ết nối vớ i các IP có s ẵn tạo nên một môi trườ ng kiểm tra. Các ngõ vào của IP cần ki ểm tra đượ c kích thích b ở i các ki ến trúc phụ tr ợ này. Có th ể xem việc ti ế p cận FPGA như một trong những phương thứ c kiểm tra của mô hình này. Sau khi thiết k ế đượ c phát triển ở c ấp độ RTL (Code Verilog) hoàn t ất, nó sẽ đượ c nhúng lên trên kít FPGA, các tín hi ệu ngõ ra và ngõ vào c ủa thiết k ế đượ c k ết nối vớ i các thiết bị trên kít FPGA. N gười dng điều khiển các thiết bị trên kít FPGA nhằm kích thích ngõ vào của thiết k ế đã nhúng trên FPGA. Kiể m tra ngõ ra b ằng cách ki ểm tra các thi ết b ị trên kit mà đã kết nối vớ i ngõ ra của thiết k ế. Thuyết minh cũng giớ i thiệu mô hình ki ểm tra trên FPGA đã tiế p cận và đạt thành công.
18
ận d ạng gi ọng n ói t rên F PGA H ình 1.19 M ô hình ki ể m tra thi ế t k ế vi m ạch nh
Đầu tiên các file d ữ liệu được lưu trữ trên SRAM, để lấy đượ c dữ liệu này ph ải sử dụng bộ điều khiển SRAM. Nối các chân điều khiển SRAM vớ i các SWITCH có th ể dễ dàng điều khiển SRAM. Tương tự như mô hình Unit Test, thông số mô hình được lưu trên FLAS RAM. Khi ngườ i thử nghiệm đọc t ừ mu ốn nh ận dạng, dữ li ệu s ẽ đượ c l ấy l ấy m ẫu và trích đặc trưng sau đó lưu lại lên SRAM. Sau thao tác này ngườ i dùng sử dụng SWITCH nối vớ i tín hiệu START nhằm khởi động quá trình nh ận dạng. Sau khi SITC đượ c kích ho ạt, k ết quả nhận dạng sẽ hiện ra đèn LD. Nhờ vào các led này, vi ệc kiểm tra k ết quả được tườ ng minh 4.3 System Test
Mô hình này r ất thường đượ c sử dụng trong môi trườ ng công nghi ệ p vì tính tái sử dụng của nó. Khi m ột IP hay ki ến trúc bất k ỳ đượ c hoàn tất, luôn luôn có s ẵn một hệ thống mà trước đó đã đượ c phát triển. IP này đượ c k ết nối vào hệ thống phực t ạ p có s ẵn này và ki ểm tra. Các trườ ng h ợ p ki ểm tra lúc này không đượ c vi ết thông thườ ng mà ph ải thông qua một CPU điều khiển.
Trong môi trườ ng h ọc thuật ở Vi ệt Nam hiện nay, môi trườ ng sử d ụng phần m ềm Quatus k ết h ợ p vớ i ph ần m ềm Nios của công ty Alter nh ằm gi ả l ậ p m ột h ệ th ống đầy đủ trên FPGA có ý nghĩa tương tự. Một hệ thống giả lập đượ c thực hiện vớ i core CPU NIOS. Vi ệc kiểm tra IP thông qua vi ệc nối IP đó vào môi trườ ng giả lậ p và lậ p trình cho core CPU NIOS này th ực hiện. Trong quá trình th ực hiện các l ệnh, các luồng dữ liệu sẽ tương tác vớ i IP nhằm kiểm tra các chức năng IP.
19
ớ i Core NiosII tr ên F PGA H ình 1.20 M ô hình system t est gi ả l ập v 5- Tổng hợ p logic - Synthesis
Khảo sát lại vị trí của bướ c này trên quy trình phát tri ển ASIC ta có hình v ẽ sau
ần qu an tâm trong bướ c t ổ ng h ợp xu ố ng l ớ p c ổ ng H ình 1.21 Các v ấn đề c
Sau khi thiết k ế đượ c phát triển và kiểm tra ở m ức RTL, thiết k ế s ẽ đượ c t ổng hợ p xu ống mức cổng tương đương với bước synthesis như trong hình 1.19. Có rấ t nhiều phần mềm hổ tr ợ cho bướ c này, tuy nhiên thuy ết mình chỉ đề c ập đến ph ần m ềm DC - Design Compiler của công ty Synopsys. Các ph ần mềm khác có cách s ử dụng tương tự. 20
Để có thể đượ c thiết k ế tối ưu nhất (tần số cao nhất có thể, diện tích nhỏ nhất có thể …), ở bướ c này, các ràng bu ộc được đưa vào. Phần mềm DC sẽ dựa trên các ràng bu ộc, thư viện của nhà sản xuất và thiết k ế RTL có s ẵn để tạo ra Để có thể t ổng h ợ p xu ống mức c ổng t ừ mã code Verilog ở c ấp độ RTL, hình 1.19 li ệt kê những vấn đề cần quan tâm.
Cách thức sử dụng phần mềm Design Compiler (DC) Các điều kiện ràng buộc về thờ i gian, diện tích… Phân tích các file tườ ng thuật sau khi ch ạy
Ở thuyết minh không đề c ập đến cách th ức s ử d ụng phần m ềm DC. Chỉ m ột s ố ràng buộc và phân tích file tườ ng thuật đượ c thuyết minh nhằm làm r hơn, tổng quát hơn cho bướ c thiết k ế này. Có thể tóm gọn các điều kiện cần thiết và các ngõ ra ra c ủa bướ c thiết k ế này bằng hình v ẽ minh họa như sau:
H ình 1.22 Các file đầu vào và đầu r a thông qua ph ần m ềm DC
Để có thể th ực hiện đượ c công vi ệc tổng hợ p m ức cổng vớ i ph ần mềm DC cần có các file như sau
Các thư viện .db đượ c cung cấ p bở i nhà s ản xuất. Các file này chưa thống số hiệu năng của các c ổng logic đượ c tạo nên từ các CMOS ở công nghệ nhất định. Các thiết k ế .v là các file ch ứa các đoạn code Verilog ở c ấp độ RTL đã thỏa mãn các bướ c kiểm tra trước đó và đượ c viết bở i các ràng bu ộc để có thể tổng hợ p xuống mức cổng. 21
Các ràng buộc .txt chứa các ràng bu ộc nhằm ràng buộc hi ệu năng của thiết k ế để thiết k ế có th ể đạt đượ c những hiệu năng mà đặc tả đã mong muố n từ trướ c.
Sau khi qua qua bướ c này, m ột số file chính sẽ đượ c xuất ra với các đặc tính như sau
Các k ỹ sư gọi file này là netlist, file này chứ a các source code Verilog đượ c viết ở cấp độ Primitive. Có thể hiểu là các source code Verilog ở mức độ RTL đượ c chuyển thể thành source code Verilog ở cấp độ thấp hơn. ình vẽ sau mô tả một Multiplexer dướ i dạng cấp độ Primitive. .v :
ấp độ Pri mitive H ình 1.23 M ul ti plexer đượ c vi ết dướ i c
: File này ch ứa các thông s ố về hiệu năng mà các bướ c sau s ẽ c ần như các file đầu vào c ần thiết.
.ddc
.sdf : File chứa các thông s ố thờ i gian của từng đườ ng dữ liệu bên trong thi ết k ế
ở m ức độ chi tiết. File cũng đượ c s ử d ụng như các file đầu vào của các bướ c tiế p sau đó. ình vẽ sau mô t ả phân tích thờ i gian của một D flipflop
DFF
ụng c ủa fi le sdf H ình 1.24 N ội d
22
Để có thể hiểu đượ c chi tiết hơn mục đích bướ c thiết k ế này, một số phân tích và các ràng buộc trong mạch đượ c chi tiết hóa ở phần tiếp theo sau đây. 5.1 Phân tích các ràng bu ộc
Data Path
Start point: Data input, clock port of DFF End point: Data output, Data input of DFF
ữ li ệu đượ c phân tích H ình 1.25 Khái ni ệm đườ ng d
Để phân tích đặ c tính thờ i gian của thiết k ế, thiết k ế được chia thành cá đoạn mạch nhỏ để phân tích. Khái ni ệm đầu tiên được đặt ra là việc quy ước các đườ ng dữ li ệu. Tốc độ thiết k ế phụ thuộc vào t ốc độ c ủa các đườ ng d ữ li ệu này. Gi ải thích một cách đơn giản giữa các kh ối logic là các flipflop xen k ẽ mà các fliplop này ho ạt động theo xung clock. Do đó, chỉ cần phân tích cá c đườ ng truyền dữ li ệu liên quan gi ữa các kh ối logic và các flipflop s ẽ cho ta k ết quả của toàn thiết k ế. Phân tích hình 1.25 cho th ấy khái niệm đặt ra cho các đườ ng dữ li ệu là các đường có điểm xu ất phát từ d ữ liệu ngõ vào của thiết k ế hoặc t ừ ngõ vào c ủa xung clock đến các flipflop. Điểm k ết thúc của đườ ng dữ liệu là ngõ ra c ủa thiết k ế hoặc ngõ vào d ữ liệu của các flipflop.
Clock path
H ình 1.26 Khái ni ệm clock path
23
Clock path là đườ ng truyền được định nghĩa điể m khởi đầu là nguồn clock (thạch anh) đến ngõ vào của các flipflop. Do trong thi ết k ế, các flipflop có m ặt ở r ất nhiều nơi và trướ c khi đến các flipflop này, các xung clock còn đi qua mộ t s ố c ổng logic khác nhau nên giá tr ị th ờ i gian tr ể của đườ ng này cho m ỗi flipflop là khác nhau.
Clock Gating Path
Là đườ ng dữ liệu tính từ chân của tín hiệu đến cổng mà tín hi ệu đó thực hiện phép tính logic vớ i xung clock
Asynchronous Path
Hình 1.28 Kh i ni m As nchrnonous ath
Là đườ ng dữ liệu tính từ chân của tín hiệu bất đồng bộ tớ i ngõ vào b ất đồng bộ của flipflop.
Tất cả các đườ ng dữ liệu đã nêu trên sẽ được phân tích và đánh giá trong quá trình phần mềm DC đượ c thực thi. Khi các k ết quả không mong mu ốn được tườ ng thuật trong file tườ ng thuật. Các đườ ng dữ liệu nào không th ỏa điều kiện s ẽ đượ c chỉ ra m ột cách chính xác. N ắm đượ c thông tin này, các k ỹ sư thiết k ế s ẽ phân tích chúng và đưa ra một số các gi ải pháp tiêu bi ểu sau:
Xem xét lại code RTL mà t ạo ra đoạn m ạch có đườ ng d ữ li ệu gặ p v ấn đề. N ếu giải thuật sử dụng trên RTL chưa đượ c tối ưu thì cần đượ c tối ưu lại và tổng hợ p xuống mức cổng lại sau đó.
24
Nếu không thể tối ưu RTL, các flipflop sẽ được chèn vào để giảm thiểu thờ i gian của các đườ ng dữ liệu này. Một s ố gi ải pháp thêm các c ổng inverter ho ặc thay đổi các c ổng trong thư việ n đượ c xem xét nh ằm tăng tốc độ truyền dữ liệu. Cuối cùng nếu không th ể cải thiện đượ c, các ràng bu ộc ban đầu sẽ đượ c s ữa lại ở cấp độ bớ t chặt chẽ hơn để phần mềm tổng hợ p có thể tổng hợ p dễ dàng.
Các mục ti ếp sau đây sẽ đưa ra các ràng buộc tiêu biểu mà ngườ i thiết k ế c ần khai báo để có đượ c hiệu năng tốt nhất cho thiết k ế
Clock Latency
H ình 1.29 Khái ni ệm “Clock Latency”
Là thờ i gian trì hoãn c ủa clock từ nguồn đến D fplipflop đượ c chia thành hai quá trình. Một là từ nguồn clock (thạch anh) đến ngõ vào c ủa thiết k ế gọi là Source Latency. ai là từ ngõ vào của thiết k ế đến D flipflop gọi là Network Latency. Tổng hai giá tr ị tr ị này t ạo nên clock delay.
Net Delay
H ình 1.30 Khái ni ệm “Net Delay”
25
Net Delay đượ c hi ểu là độ tr ể c ủa tín hiệu khi truyền t ừ cổng logic này đế n c ổng logic khác. Thông s ố này đượ c tính dựa trên thông số hai cổng liên k ết này và mô hình tính toán của nó. Mô hình tính toán đượ c thực thi bởi file mang tên wire_load_model mà ngườ i dùng phải thêm vào để thiết lậ p trong file ch ứa các ràng bu ộc khi sử dụng phần m ềm DC. File này là một trong những file thư viện mà nhà sản xuất cung cấ p.
Cell Delay
H ình 1.31 Khái ni ệm “Cell Delay”
Cell Delay là thông số chỉ độ tr ể c ủa c ổng logic. Nó không đượ c tính toán b ở i mô hình wire_load_model mà nó có sẵ n các thông s ố này cho riêng nó b ở i các c ổng này chính là thư viện mà nhà s ản xu ất đã cung cấ p (Wire_load_model dựa trên các thông s ố của các c ổng logic để tính Net_delay). Các thông s ố này sẽ dng để tính toán các th ờ i gian trì hoãn trên các đườ ng dữ liệu đã định nghĩa ở trên.
Propagation Delay
H ình 1.32 Khái ni ệm “Propagation Delay”
Tương tự như Cell Delay, Propagation Delay là thông số chỉ độ tr ể tính hiệu ngõ ra của D flipflop. Nó là thờ i gian tính từ cạnh lên của xung lock cho đế n khí tín hiệu ngõ ra được thay đổi ở tr ạng thái xác định là mức cao ho ặc mức thấ p.
26
Clock Skew
H ình 1.33 Khái ni ệm Cl ock Skew
Trong một số trườ ng hợ p, từ một nguồn clock có th ể chia làm nhi ều nhánh đi đến các Flipflop khác nhau. Ở m ỗi nhánh sẽ có những khoảng thờ i gian trì hoãn khác nhau do qu ảng đường đi và số cổng logic mà nó đi qua. Chính vì sự khác nhau này, khi xét hai c ạnh lên liên tiế p của clock tại hai flipflop khác nhau s ẽ có m ột khoảng thờ i gian lệch. Đó chính là Clock Skew.
Setup Time & Hold Time
H ình 1.34 Khái ni ệm “Setup Time & Hold Time”
Khái niệm này thể hiện mối quan hệ giữa dữ liệu ngõ vào và tín hi ệu clock của một flipflop. Setup Time là kho ảng thờ i gian mà d ữ liệu ng vào đượ c giữ cố định trướ c khi clock tích cực cạnh lên và Hold Time là kho ảng thờ i gian mà dữ li ệu ngõ vào phải giữ cố định sau khi clock tích cực c ạnh lên. ai điều ki ện này được đưa ra nhằ m vào vấn đề ổn định d ữ li ệu ng vào để cạnh lên xung clock có th ể bắt đượ c chính xác giá tr ị của nó.
27
Removeval & Recovery
H ình 1.35 Khái ni ệm “Removal & Recovery”
Đây là khái niệm dành cho các tín hi ệu b ất đồng b ộ và tín hiệu reset là một ví dụ điển hình. Khái niệm ám chỉ khoảng thờ i gian tối thiểu c ủa tín hiệu này thay đổi so vớ i cạnh lên của xung clock. Dựa trên mã code RTL, các ràng bu ộc và các thông s ố từ thư viện, phần mềm DC tổng h ợ p thi ết k ế xu ống m ức c ổng. Sau khi t ổng h ợ p xu ống m ức c ổng, các thông s ố hi ệu năng sẽ được tính toán và tườ ng thuật lại. Các đườ ng dữ liệu vi phạm các ràng bu ộc sẽ được tườ ng thuật. Dựa trên các tườ ng thuật này, ngườ i k ỹ sư sẽ có các gi ải pháp khắc phục riêng cho t ừng trườ ng h ợp như đã đề cập trên. Sau đây mộ t số nguyên t ắc vi phạm đượ c liệt kê
Clock Width Violation
Clock Skew Violation
Hold Time Violation
Setup/Hold time
Clock Width
Clock Period
Setup Time
Removal/Recovery Violation
vi ph ạm ràng bu ộc H ình 1.36 Các trườ ng h ợp 28
Sau khi các nguyên t ắc vi phạm đượ c sửa chửa, mạch tổng hợ p mức cổng đượ c tổng hợ p. Hình vẽ sau mô t ả một ví dụ minh họa dạng cổng sau khi t ổng hợ p từ mã Verilog.
ụ c ấp độ thi ết k ế l ớp c ổng đượ c t ạo r a sau quátr ình t ổ ng h ợ p H ình 1.37 Víd
Ngoài netlist mà ta thấy được trên hình 1.37, các file tườ ng thuật còn cho bi ết nh ững ướ c lượ ng về diện tích cũng như tốc độ tối đa mà chip có thể đạt đượ c. Những giá tr ị này chỉ mạng tính tương đố i vì ở các bướ c sau, một số m ạch sẽ đượ c chèn thêm v ớ i những mục đích khác nhau. Lúc này các hi ệu năng của mạch s ẽ được đánh giá lại một lần nữa (bướ c STA). Đó chính là lần quyết đinh hiệu năng cuố i cùng của mạch. 6- Kiểm tra mứ c cổng – Netlist Verification
Sau khi thiết k ế đã đượ c tổng hợ p xu ống lớ p cổng, bướ c tiế p theo (Netlist Verification) s ẽ dng để kiểm tra xem m ạch logic l ớ p cổng đã đượ c tổng hợp đúng đắn hay chưa. Có thể hiểu r ằng các k ỹ sư phần c ứng không hoàn toàn tin tưở ng tuyệt đối vào các ph ần mềm tổng h ợ p xuống mức cổng. Do đó, một công đoạ n kiểm tra là cần thiết. Phần mềm đượ c sử dụng cho công đoạ n kiểm tra này là Formality. Hình vẽ minh họa bước Netlist erification của mô hình thiết k ế ASIC
tr a netli st b ằng công c ụ Formality H ình 1.38 Ki ểm
29
Như đã giớ i thiệu, phần mềm này dng để kiểm tra sự tương đồng giữa source code Verilog và mạch logic sau khi t ổng hợ p. Cũng tương tự như phần mềm DC, các ràng bu ộc đượ c thiết lậ p ở trong .txt, phần mềm này sẽ tự hiểu các ràng bu ộc đã đượ c viết một cách chu ẩn hóa này và th ực thi. Các điểm không tường đồ ng s ẽ được tườ ng thuật dướ i d ạng file tườ ng thuật. Ngườ i k ỹ sư nắm lấy các thông tin c ủa file tườ ng thuật để kiểm tra và sửa lỗi tổng hợ p nếu có. Thực t ế khi phần m ềm này đượ c bán cho các nhà phát tri ển vi mạch có kèm theo các file hướ ng dẫn về các lỗi mắc phải. Ví dụ về các file tườ ng thuật thu đượ c sau khi ch ạy Fomality cho biết có lỗi x ảy ra. Lỗi này sẽ đượ c gán cho nó m ột ký hiệu. Ngườ i k ỹ sư sẽ ki ểm tra ký hiệu l ỗi này trong các file hướ ng d ẫn về các lỗi và kiểm tra nguyên nhân sinh ra l ỗi đó là do code Verilog hay do ph ần m ềm DC tổng h ợ p sai. Hình v ẽ sau mô t ả m ột trong những l ỗi vi phạm của phần mềm Formality.
ạy ph ần m ềm Formality H ình 1.39 L ỗ i F M _1_1 khi ch
Sau khi sửa lỗi ở các source code Verilog c ấp độ RTL, bướ c tổng hợ p bằng phần mềm DC đượ c lặ p lại r ồi k ế đến Formality lại đượ c kiểm tra một lần nữa. Chu trình đượ c thực hiện cho đến khi nào k ết thúc không có b ất cứ lỗi gì. Chú ý r ằng khi code Verilog ở cấp độ RTL đượ c sửa thì phải chạy lại quá trình kiểm tra chức năng của chúng b ằng các hình th ức UnitTest và Combine Test như đề cậ p ở trên. Sau khi đã hoàn thành bướ c Formality, có th ể xem như kết thúc phần Frontnd trong quy trình phát triển chip theo mô hình ASIC. Ph ần tiếp theo xin đượ c giớ i thiệu về phần acknd.
30
IV- Chi tiết quy trình thi ết k ế chip ở bướ c thiết k ế BackEnd 1- Thiết k ế phần kiểm tra – Design For Test - DFT
DFT (Design For Test) là c ụm t ừ mô t ả vi ệc chèn thêm các thi ết k ế ph ụ để ki ểm tra thiết k ế chính. Thông thường bướ c này s ẽ chỉ sử dụng cho các h ệ thống l ớ n. Một số IP đượ c bỏ qua bướ c này. Tuy nhiên, thuy ết minh cũng xin đề cậ p bướ c thiết k ế này cho hoàn ch ỉnh luồng thiết k ế ASIC. Hiện nay có hai phương pháp chính trong bướ c DFT là LBIST và MBIST. B ản chất chúng dành cho hai m ục đích riêng biệt và không ph ụ thuộc vào nhau.
MIST : Dng để kiểm tra các bộ nhớ có trong h ệ thống. LIST : Dng để kiểm tra chức năng và tính logic của hệ thống (Tương tự việc kiểm tra chức năng trong UnitTest, Combination Test hay System Test).
1.1 MBIST
Thông thườ ng trên một h ệ th ống, các b ộ nhớ chiếm phần trăm tài nguyên và diện tích khá lớ n. Mặt khác cũng trong mộ t h ệ th ống có r ất nhiều lo ại b ộ nh ớ khác nhau ph ục vụ cho mục đích khá nhau. Trước đây khi chưa có MIST tồ n t ại, khi chip đã đượ c s ản xuất, những l ỗi xảy ra trên các b ộ nh ớ r ất khó đượ c phát hiện. Do đó, để tăng cườ ng khả năng kiểm soát lỗi và sửa lỗi của các bộ nhớ trướ c và sau khi s ản xuất chip, MIST đượ c hình thành. Như đã phân tích MIST dng để kiểm tra các b ộ nhớ tồn tại trong hệ thống. Nó đượ c thiết k ế sao cho ch ỉ m ột IP MBIST có th ể ki ểm tra cho t ất c ả các b ộ nh ớ khác loại trên cùng một h ệ th ống. Điều này nói lên r ằng tính hiệu qu ả của MBIST so vớ i phần di ện tích và năng lượ ng mà MBIST ảnh hưởng đến hiệu năng của toàn hệ thống. Có thể xem MBIST như là một IP trong hệ thống muốn sản xuất. Thảo lu ận v ề ho ạt động c ủa MBIST có thể hi ểu đơn giản là hệ th ống luôn luôn có ít nh ất hai chế độ th ực thi. Một là chế độ ho ạt động bình thườ ng như đúng mục đích hệ th ống đượ c sản xuất. Hai là chế độ kiểm tra. Khi chế độ kiểm tra đượ c chọn, khối MIST đượ c kích hoạt để kiểm tra tất cả các bộ nhớ trong hệ th ống. Đườ ng dữ li ệu đầu vào của các khối bộ nhớ lúc này đượ c l ấy t ừ khối MBIST chứ không lấy t ừ các khối IP mà nó liên k ết nữa. Có thể hiểu r ằng có một bộ multiplexer để xử lý hai luồng d ữ liệu một từ MBIST và một từ IP liên k ết vào bộ nhớ . Việc đưa dữ liệu như thế nào, thay đổi ra sao đã được định sẵn trong các m ạch MBIST. Có thể nói giải thuật ki ểm tra các b ộ nh ớ đã sẵn có trên MBIST. Các k ỹ sư phát triển các mạch MIST đã thiết lậ p các gi ải thuật ki ểm tra bộ nhớ trên mạch MBIST bằng các th ủ thuật thiết k ế phần cứng. Hình vẽ 1.40 sau mô t ả kiến trúc bên ngoài so b ộ của một MBIST. Trong quá trình ki ểm tra, các b ộ nh ớ được đọc và ghi liên t ục, các d ữ li ệu ngõ ra của các bộ nhớ s ẽ đượ c tr ả v ề kh ối MIST để so sánh v ớ i k ết qu ả mong muốn. K ết qu ả đối chiếu sẽ đượ c xuất ra ở các chân ngõ ra MBIST (MBIST output) nh ằm thông báo cho ngướ i dùng biết k ết quả kiểm tra.
31
H ình 1.40 Giao di ện m ột kh ố i M BI ST
Một số khối MBIST còn có kh ả năng sửa đượ c các l ỗi của bộ nhớ nhờ các kiến trúc của bộ nhớ có những cell nhớ thiết k ế thừa ra cho những lỗi trong quá trình sản xuất. Chỉ khi nào các lỗi không thể sửa chửa bằng phần cứng, các k ỹ sư phát triển phần mềm mớ i can thiệ p. 1.2 LBIST
Để hiểu thế nào là LBIST, m ột vấn đề trong việc kiểm tra chức năng của thiết k ế (Giống kiểm tra chức năng trong mô hình Unit Test hoặc Combination Test) đượ c nêu lên qua hình vẽ
ụ v ề mô hình L BI ST (1) H ình 1.41 Víd
32
Phân tích hình vẽ có thể thấy r ằng các giá tr ị a4,…a7 được tính theo các hàm F1,…F4. Theo lẽ thông thường, để kiểm tra các giá tr ị a4,…a7, các giá trị a1, a… a6 sẽ được thay đổi nhằm để tạo ra các t ổ hợ p kiểm tra khác nhau nh ằm đảm bảo logic trong các kh ối Comb1, …Comb3 là chính xác. Tính khả thi cho phương pháp đố i v ới mô hình nay đượ c ch ấ p nh ận do số hàm F cần tính toán là r ất ít. Các trườ ng hợ p kiểm tra có thể đượ c k ỹ sư thiết k ế liệt kê một cách dễ dàng. Tuy nhiên, khi s ố lượng hàm F tăng lên đáng kể trong mô hình sau.
ụ mô hình L BI ST (2) H ình 1.42 Víd
Việc thiết l ậ p các giá tr ị ng vào để ki ểm tra tính logic cho các kh ối Comb3 là không th ể. Điều này tương tự cho các kh ối Comb ở gi ữa sâu bên trong thi ết k ế. Để có đuợc điều mong muốn là kiểm tra hết những khối Comb có thể ngay c ả khi bên trong thi ết k ế, một k ỹ thuật khác đượ c sử dụng là LIST. Đầu tiên khái ni ệm đường scan chain đượ c hiểu khi phân tích hình vẽ
H ình 1. 43 Đường “scan chain”
33
Ở m ỗi Flipflop, các k ỹ sư sẽ thêm vào đó một b ộ multiplexer nhằm ch ọn d ữ li ệu đầu vào của Flipflop. Một là từ các mạch logic khác như thiết k ế mô t ả. Hai là từ đường Scan chain (Đường màu đỏ trên hình 1.43). Như vậy tương tự MBIST khi ở tr ạng thái kiểm tra, dữ li ệu đi ra các Flipflop không còn là dữ li ệu thông thườ ng từ các mạch logic c ủa thiết k ế mà là t ừ đường Scan chain. Tín hiệu này được xem như là mộ t tín hiệu ngõ vào c ủa thiết k ế. Dựa trên đườ ng tín hiệu Scan Chain này (1 bit), các giá trị muốn kiểm tra được đưa vào sâu bên trong các kh ối Comb bên trong thi ết k ế. Tuy nhiên vi ệc t ạo ra các giá tr ị ki ểm tra và các giá tr ị so sánh đượ c thực hiện vớ i sự hổ tr ợ của phần mềm. Thuyết minh xin giớ i thiệu hai phần mềm phổ bi ến là ATPG của Synopsys và FastScan c ủa MentorGraphic. Một số công ty họ tự phát triển các ph ần mềm của riêng họ gọi là những Inhour Tool.
Như vậ y, ở bướ c thiết k ế này, các m ạch kiểm tra đượ c b ỏ thêm vào thiết k ế ban đầ u. Tuy những thiết k ế phụ tr ợ này r ất nhỏ nhưng cũng đã ảnh hưở ng tớ i hiệu năng (diện tích, tốc độ, năng lượng,…) củ a thiết k ế nói chung. Do đó, sau khi đã kiể m tra các bộ nhớ và các mạch Comb sâu bên trong thi ết k ế (Kiểm tra về mặt chức năng), một lần nữa các thông s ố hiệu năng được ước lượng và đánh giá lạ i bằng bướ c STA (Static Timing Analysis) k ế tiế p.
2- Phâ tch và đáh iá độ trể thờ i gian - Static Timing Analysis - STA
ASIC H ình 1.44 Bướ c STA tr ong thi ết k ế
Xem lại vị trí của bướ c này ở hình 1.44 cho th ấy STA được xem như Pre_ Layout . ướ c thiết k ế này giúp ước lượ ng hiệu năng của toàn thi ết k ế sau khi các m ạch kiểm tra đượ c thêm vào. Cũng tương tự như bước Synthesis, các ràng buộc đượ c thiết lậ p trong file.txt. Các cấu trúc lệnh ràng buộc mà phần mềm DC của bước Synthesis và phầ n mềm PrimeTime của bước STA là như nhau. Do trong quá trình phát triển còn chèn các thi ết k ế phụ tr ợ để kiểm tra nên một số thông số hiệu năng ở bước Synthesis không đượ c quan tâm và phân tích k ỹ.
34
STA là bướ c g ần cu ối trong đánh giá hiệu năng củ a c ủa thiết k ế. Do đó các file tườ ng thuật và hiệu năng đượ c phân tích k ỹ lư ng so sánh v ới đặc tả. Đến đây có thể hình dung các bướ c làm việc như hình vẽ sau
H ình 1.45 Sơ đồ tóm t ắt các bước ước lượ n g hi ệu năng
Khái niệm Pre_Layout xu ất hiện do sau khi Place&Route hoàn t ất, STA lại đượ c chạy một lần nữa do việc k ết nối các IP trong h ệ thống bới các đườ ng kim loại sẽ làm thay đổi hiệu năng thờ i gian của toàn h ệ thống. ướ c Place&Route ti ếp sau đây sẽ có đề cập đến khái ni ệm Post_layout cho quá trình ch ạy lại STA nhằm đánh giá hiệu năng sau cng củ a thiết k ế. 3- Sắp xếp và đi dây - Place & Route – P&R
ASIC H ình 1.46 V ị tr íPlace& Route trong qu y tr ình phát tr i ển
35
Place & Route là công đoạn cuối cùng của mô hình phát tri ển ASIC đượ c thể hiện trong hình vẽ 1.46. Ở công đoạn này, các v ị trí đặt các IP được khoanh vng. Sau đó các hiệu năng của các IP đượ c thiết l ậ p nh ờ các thông s ố đã có ở bước STA trước đó cho từng IP. K ế ti ế p, các IP đượ c sắ p xếp vào đúng vị trí đã khoanh vng trước. Đến lúc này các đườ ng xung clock đươc đi dây đến các ngõ vào c ủa các IP. Cu ối cng các đườ ng k ết n ối giữa các IP đượ c thiết lậ p. Sau tất cả quá trình này STA đượ c thực hiện một lần nữa nhằm lấy đượ c k ết quả hiệu năng cuối cùng. Có th ể tóm tắt các bướ c chính của công đoạ n Place&Route như sau
H ình 1.47 Các công đoạn nh ỏ trong bướ c Place& Route
Về những yêu cầu ngõ vào và ngõ ra c ủa bước này, hình 1.47 đượ c thể hiện
H ình 1.48 Các n gõ và o vàngõ ra c ủa bướ c Place& Route
36
Theo như hình 1.4 8, công cụ đượ c giớ i thiệu của công ty Synopsys là IC Compiler (ICC), những đòi hỏi ngõ vào c ủa phần mềm này là các file có đượ c từ các bướ c phát triển ASIC trước đó bao gồm: Netlist(erilog đượ c viết dướ i cấp độ Primitive) và .ddc/sdc bao gồm các thông s ố hi ệu năng của thiết k ế. Ngoài ra, các file thư viện cũng đượ c s ử : .tf là file chứa các phép toán dng để tối ưu và tính toán hiệu năng trong quá trình Place & Route tự động và .db là thư viện chứa thông s ố hiệu năng của các cổng logic. Tương tự các phần mềm khác, m ột file chứa các ràng bu ộc đượ c thiết lậ p nhằm đảm bảo các hi ệu năng không vi ph ạm và thỏa mản đặc tả như ban đầu. Ngõ ra của bước này đượ c quan tâm ch ủ yếu là .gds cung c ấp đầy đủ các thông tin cho nhà s ản xu ất. Ngoài ra một số file chứa các thông tin hi ệu năng và file tườ ng thuật quy trình Place & Route cũng đượ c xuất ra. Có thể tóm tắt hết quá trình phát triển c ủa ASIC và nổi bật các file cần thiết của bướ c cuối cùng Place & Route b ằng hình vẽ sau.
H ình 1.48 Th ố n g kêcác f ile tr ong quy trình phát tr i ể n ASIC
37
