1

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

một ứng dụng cụ thể. Khi nói thiết kế ASIC thì có thể hiểu rằng đang nói về một phươ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.

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 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. Gần như con người chỉ làm việc với các cấp

độ cao (cấp độ cổng – Gate Level). Các công cụ tự động này cho phép con người

Hình 1.1 Các phương pháp thiết kế vi mạch tích hợp

2

có thể thực hiện khối lượ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.

Standar Cell: 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

từ cấp độ Cổng trở lên.

Gate Array: 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

xuất thành các chip vật lý sẵn có nhưng chỉ ở dạng các cổng logic rời rạc mà chưa

đượ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

xuất là cần thiết nhưng chỉ cần cho việc liên kết, đi dây nhằm kết nối các đơn vị

logic sẵn có.

Programmale Logic: 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

Hình 1.2 Phương thức chế tạo ASIC

3

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 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 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: 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ẩm trí tuệ có thể tạm gọi là một

gói phần mềm (Trong công nghiêp: <file>.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 (Diện tích,

năng lượng, tốc độ …).

Fabrication: Với thông tin từ <file>.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

Development

Fabrication

Hình 1.3 Hai bước chính trong sản xuất chip ASIC

4

FrontEnd: Tại 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.

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à <file>.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…

Hình 1.4 Các bước trong quy trình phát triển một vi mạch ASIC

5

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 MOSF T 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.

Hình 1.5 Mặt cắt P MOS đơn giản

6

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

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 d ng để 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 MOSF T 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ó

c ng 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ể.

Hình 1.6 Vùng hoạt động của CMOS

7

III- Chi tiết quy trình thiết kế chip ở bước thiết kế FrontEnd

1- Đặc tả chức ă ch h – 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

8

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ụ

Hình 1.7 Các khái niệm và vấn đề trong bước thiết kế SLD

9

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

Platform: 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.

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.

10

Để 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.

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

Hình 1.8 Ví dụ mô hình hóa phần cứng của một MCU

Hình 1.9 Vai trò của SLD trong quy trình phát triển ASIC

11

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ữ erilog DL để mô hình hóa lại kiến trúc

12

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 Goel trong m a đông năm 1983 1984. 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.

Combination Test: 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.

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ó.

13

Để 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ừ Test ench

đượ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

14

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 d ng 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 d ng 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 t y chọn khi sử dụng phần mềm này.

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 d ng 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

Hình 1.10 Trạng thái COMMAND LINE gọi phần mềm VCS

Hình 1.11 Giao diện DVE với sóng tín hiệu

15

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

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.

Hình 1.12 Ngôn ngữ sử dụng để viết thiết kế và testbench

Hình 1.13 Cách thức kích thích ngõ vào của thiết kế

16

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ý…

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.

Hình 1.14 Hai vấn đề cần quan tâm trong thiết kế Testbench

Hình 1.15 Ví dụ các thành phần trong file testbench

17

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.

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ì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.

Hình 1.16 Ví dụ minh họa task

Hình 1.17 Một số hàm hệ thống trong Verilog

18

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. Người d ng đ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.

Hình 1.18 Mô hình Unit Test cho hệ thống nhận dạng giọng nói

19

Đầ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 S ITC được kích hoạt, kết quả

nhận dạng sẽ hiện ra đèn L D. 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.

Hình 1.19 Mô hình kiểm tra thiết kế vi mạch nhận dạng giọng nói trên FPGA

20

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

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ự.

Hình 1.20 Mô hình system test giả lập với Core NiosII trên FPGA

Hình 1.21 Các vấn đề cần quan tâm trong bước tổng hợp xuống lớp cổng

21

Để 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:

Để 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 <file>.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ế <file>.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.

Hình 1.22 Các file đầu vào và đầu ra thông qua phần mềm DC

22

Các ràng buộc <file>.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

<file>.v : 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 .

<file>.ddc : 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.

<file>.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

55 55

DFF timing

Hình 1.23 Multiplexer được viết dưới cấp độ Primitive

Hình 1.24 Nội dụng của file sdf

23

Để 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

Để 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

Start point: Data input, clock port of DFF End point: Data output, Data input of DFF

Hình 1.25 Khái niệm đường dữ liệu được phân tích

Hình 1.26 Khái niệm clock path

24

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

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 đó.

Hình 1.27 Khái niệm clock path

Hình 1.28 Khái niệm Asynchrnonous path

25

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

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.29 Khái niệm “Clock Latency”

Hình 1.30 Khái niệm “Net Delay”

26

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

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ẽ d ng để 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

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.

Hình 1.31 Khái niệm “Cell Delay”

Hình 1.32 Khái niệm “Propagation Delay”

27

Clock 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

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ó.

Hình 1.34 Khái niệm “Setup Time & Hold Time”

Hình 1.33 Khái niệm Clock Skew

28

Removeval & 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 Width Violation

Clock Period Violation

Clock Skew Violation

Setup Time Violation

Hold Time Violation

Setup/Hold time violation

Removal/Recovery Violation

Hình 1.35 Khái niệm “Removal & Recovery”

Hình 1.36 Các trường hợp vi phạm ràng buộc

29

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.

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ẽ

d ng để 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

Hình 1.37 Ví dụ cấp độ thiết kế lớp cổng được tạo ra sau quá trình tổng hợp

Hình 1.38 Kiểm tra netlist bằng công cụ Formality

30

Như đã giới thiệu, phần mềm này d ng để 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 <file>.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.

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 Front nd 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

ack nd .

Hình 1.39 Lỗi FM_1_1 khi chạy phần mềm Formality

31

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.

M IST : D ng để kiểm tra các bộ nhớ có trong hệ thống.

L IST : D ng để 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ó M IST 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, M IST được hình thành.

Như đã phân tích M IST d ng để 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 M IST đượ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

M IST đã 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 M IST để 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.

32

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ẽ

Hình 1.40 Giao diện một khối MBIST

Hình 1.41 Ví dụ về mô hình LBIST (1)

33

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.

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à L IST. Đầu tiên khái niệm đường scan chain được hiểu khi phân tích

hình vẽ

Hình 1.42 Ví dụ mô hình LBIST (2)

Hình 1.43 Đường “scan chain”

34

Ở 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â t ch và đá h iá độ trể thời gian - Static Timing Analysis - STA

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ỹ.

Hình 1.44 Bước STA trong thiết kế ASIC

35

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

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 c ng của thiết kế.

3- Sắp xếp và đi dây - Place & Route – P&R

Hình 1.45 Sơ đồ tóm tắt các bước ước lượng hiệu năng

Hình 1.46 Vị trí Place&Route trong quy trình phát triển ASIC

36

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 v ng. 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 v ng 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 c ng 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

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.47 Các công đoạn nhỏ trong bước Place&Route

Hình 1.48 Các ngõ vào và ngõ ra của bước Place&Route

37

Theo như hình 1.48, 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à <file>.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ử : <file>.tf

là file chứa các phép toán d ng để tối ưu và tính toán hiệu năng trong quá trình Place &

Route tự động và <file>.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à <file>.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ống kê các file trong quy trình phát triển ASIC

38

REFERENCES

[1] TSMC 65nm CLN65LP HVT Process 1.2-Volt 12-Track Advantage TM

v2.1Standard Cell Library Databook - Copyright 1997-2006 ARM Physical IP, Inc.

All Rights Reserved. Confidential.

[2] CS ® CSi™ User Guide Version Y-2006.06-SP2 March 2008 – Synopsys

Company

[3] Verilog ® -XL Reference Product Version 3.4 January 2002 – Cadance Company

[4] SystemC:From The Ground Up y David C. lack and Jack Donavan, klectic

Ally, Inc. – Springer

[5] http://systemC.com

[6] http://www.synopsys.com