Những hành trình đầy cảm hứng
Theo dõi những câu chuyện của các học giả và các chuyến thám hiểm nghiên cứu của họ
Cách Tiết Kiệm Thời Gian và Cải Thiện Giao Tiếp Giữa Kỹ Sư Thiết Kế và Kỹ sư Xác Minh Bán Dẫn
Cách Tiết Kiệm Thời Gian và Cải Thiện Giao Tiếp Giữa Kỹ Sư Thiết Kế và Kỹ sư Xác Minh Bán Dẫn
Người ta thường nói rằng "bí quyết của một cuộc hôn nhân tốt đẹp là giao tiếp tốt" nhưng điều này cũng đúng với một dự án IP hoặc hệ thống trên chip (SoC) thành công. Những dự án này vô cùng phức tạp với nhiều khả năng xảy ra hiểu lầm và diễn giải khác nhau. Cách duy nhất để tránh những vấn đề này là sử dụng một specification vàng thực thi được (executable golden specification) được liên kết bằng một quy trình tự động hóa.
Cách Hoạt Động Thông Thường - Nhưng Không Nên
Các dự án IP và SoC liên quan đến nhiều nhóm: kiến trúc sư, kỹ sư thiết kế, kỹ sư xác minh, lập trình viên nhúng, nhóm kiểm tra tiền-silicon và hậu-silicon (bring-up), cũng như các nhà viết tài liệu kỹ thuật. Theo truyền thống, tất cả họ đều làm việc dựa trên một specification dự án chung được viết bằng ngôn ngữ tự nhiên như tiếng Anh. Mỗi kỹ sư trong từng nhóm diễn giải specification này một cách độc lập, sau đó tự tạo các tập tin collateral cần thiết cho công việc của mình.
Ngôn ngữ tự nhiên vốn dĩ có tính mơ hồ, vì vậy các diễn giải này khác nhau rất nhiều. Điều đó có nghĩa là các tập tin được tạo ra bởi các nhóm khác nhau sẽ có hành vi khác nhau. Testbench xác minh và các bài kiểm tra có thể không khớp với phần cứng, mã nhúng có thể không khớp với phần cứng, môi trường kiểm thử có thể không tương thích với cả phần cứng lẫn mã nhúng, v.v. Ngay cả trong một nhóm, cũng có thể xảy ra mâu thuẫn, chẳng hạn như hai kỹ sư thiết kế có cách hiểu khác nhau về cách một giao diện chung nên hoạt động.
Những diễn giải không nhất quán này đặc biệt nghiêm trọng đối với giao diện phần cứng-phần mềm (HSI), nơi các kỹ sư thiết kế phát triển phần cứng mức register transfer level (RTL), còn lập trình viên viết mã để điều khiển nó. Nếu có bất kỳ sự khác biệt nào trong cách họ diễn giải specification, thiết kế sẽ không hoạt động như mong muốn. Nếu những khác biệt này không được phát hiện trước khi thiết kế được tape-out và chế tạo, hậu quả sẽ là lỗi hậu-silicon, đòi hỏi các vòng lặp sửa lỗi chip vô cùng tốn kém.
Cách Các Nhóm Cố Gắng Khắc Phục - Nhưng Không Thành Công
Các nhóm dự án biết rằng việc dựa vào cách diễn giải cá nhân của từng kỹ sư là có vấn đề, vì vậy họ cố gắng giảm rủi ro. Họ thiết lập các hệ thống ghi chú và chú thích specification trực tuyến, công cụ theo dõi lỗi, họp scrum và nhiều phương pháp khác để cải thiện giao tiếp giữa các nhóm. Những phương pháp này có ích, nhưng chúng không thể khắc phục được những điểm yếu cố hữu của quy trình dựa trên specification viết bằng ngôn ngữ tự nhiên và diễn giải thủ công.
Các nhóm dự án cố gắng phát hiện sự khác biệt trong quá trình làm việc. Xác minh (verification) về lý thuyết có thể phát hiện tất cả các lỗi thiết kế. Kiểm thử (validation) về lý thuyết đảm bảo phần cứng và phần mềm hoạt động như một hệ thống thống nhất. Tuy nhiên, luôn có những lỗ hổng trong các nỗ lực này. Các chỉ số phủ sóng (coverage metrics) được thiết kế để phát hiện những lỗ hổng này luôn không đầy đủ. Vấn đề đặc biệt nghiêm trọng đối với kiểm thử tiền-silicon, khi mà gần như không thể chạy tất cả các bài kiểm thử bring-up trong phòng thí nghiệm trước khi tape-out.
Việc diễn giải sai có thể còn nghiêm trọng hơn cả diễn giải không nhất quán. Nếu tất cả mọi người trong dự án cùng diễn giải specification theo một cách sai lầm giống nhau, thì thiết kế vẫn sẽ "hoạt động" nhưng không đúng như mong muốn ban đầu và sản phẩm cuối cùng có thể không đáp ứng được yêu cầu đặt ra. Quá trình xác minh và kiểm thử sẽ không phát hiện ra những vấn đề này và lỗi chỉ có thể bị phát hiện tại phòng thí nghiệm bring-up hoặc thậm chí sau khi con chip đã được xuất xưởng đến khách hàng.
Mọi Thay Đổi Đều Làm Tình Hình Tệ Hơn
Tình huống trên đã đủ tệ nếu nó chỉ xảy ra một lần trong mỗi dự án IP hoặc SoC. Các nhóm sẽ phát triển collateral files dựa trên specification, thực hiện xác minh và kiểm thử để cố gắng giải quyết khác biệt, và sửa những lỗi bị bỏ sót bằng một vòng lặp sửa lỗi chip—trong trường hợp dự án chưa bị hủy bỏ ngay lúc đó. Nhưng thực tế còn tệ hơn: mỗi specification luôn thay đổi nhiều lần trong suốt vòng đời dự án.
Có nhiều lý do dẫn đến điều này. Đôi khi những gì kiến trúc sư thiết kế quá khó hoặc quá tốn kém để thực hiện trên silicon. Một số chức năng có thể thay đổi qua lại giữa các bên trong HSI. Các đối thủ cạnh tranh hoặc cơ hội thị trường mới có thể đòi hỏi thêm tính năng mới vào thiết kế. Các vấn đề liên quan đến công suất, hiệu năng và diện tích (PPA) có thể yêu cầu thay đổi và tác động ngược lên specification gốc.
Bất cứ khi nào specification thay đổi thủ công, mọi nhóm dự án phải diễn giải lại thay đổi đó, đánh giá tác động và cập nhật lại các tập tin của họ. Điều này tạo ra vô số cơ hội mới cho các lỗi diễn giải và không thống nhất. Các bản cập nhật cũng có thể không đồng bộ với nhau. Xác minh và kiểm thử tiền-silicon phải được lặp lại trên thiết kế đã thay đổi, làm tăng đáng kể chi phí dự án và trì hoãn tape-out. Điều này xảy ra mỗi lần specification thay đổi—mà thay đổi thì luôn xảy ra.
Cách Quy Trình Nên Hoạt Động—Và Hoàn Toàn Có Thể
Có một cách tiếp cận tốt hơn, bao gồm ba thay đổi quan trọng trong quy trình phát triển chip:
- Sử dụng một specification vàng thực thi thay vì specification viết bằng ngôn ngữ tự nhiên.
- Tự động tạo càng nhiều tập tin thiết kế, xác minh, phần mềm, kiểm thử và tài liệu càng tốt từ specification thực thi.
- Lặp lại quy trình này mỗi khi specification thay đổi.
Cách tiếp cận này được gọi là "tự động hóa specification" (specification automation). Hiện nay có nhiều định dạng specification thực thi, và trí tuệ nhân tạo (AI) thậm chí có thể hỗ trợ sử dụng ngôn ngữ tự nhiên trong một số khía cạnh. Các công cụ có thể tự động tạo ra hàng loạt tập tin từ specification, không chỉ trong lần đầu tiên mà còn mỗi khi specification thay đổi. Quá trình xác minh và kiểm thử sẽ nhanh hơn đáng kể vì không còn các lỗi không nhất quán cần phải tìm và sửa.
Bản thân các specification thực thi trở thành công cụ giao tiếp giữa tất cả các nhóm và kỹ sư trong dự án. Kết quả là một thiết kế IP hoặc SoC chính xác ngay từ đầu, tiêu tốn ít tài nguyên hơn và giúp tape-out nhanh hơn nhiều.
Kết Luận
Các kỹ sư dự án không còn phải diễn giải thủ công specification và dựa vào các phương pháp giao tiếp không chính thức để đảm bảo thiết kế hoạt động đúng. Một quy trình tự động dựa trên specification vàng thực thi sẽ giúp tiết kiệm thời gian và đảm bảo giao tiếp trơn tru.
===
(*) Chú giải các từ viết tắt:
- IP (Intellectual Property) – Tài sản trí tuệ, trong ngữ cảnh này đề cập đến các khối thiết kế phần cứng có thể tái sử dụng trong thiết kế vi mạch.
- SoC (System-on-Chip) – Hệ thống trên một vi mạch, một con chip tích hợp nhiều thành phần phần cứng như CPU, bộ nhớ, giao tiếp ngoại vi.
- HSI (Hardware-Software Interface) – Giao diện giữa phần cứng và phần mềm, nơi phần cứng (hardware) và phần mềm (software) phải hoạt động cùng nhau một cách chính xác.
- RTL (Register Transfer Level) – Mô tả thiết kế phần cứng ở cấp độ chuyển dữ liệu giữa các thanh ghi, thường được viết bằng ngôn ngữ mô tả phần cứng như Verilog hoặc VHDL.
- PPA (Power, Performance, and Area) – Các tiêu chí thiết kế vi mạch quan trọng: công suất tiêu thụ (Power), hiệu suất (Performance) và diện tích (Area).
- AI (Artificial Intelligence) – Trí tuệ nhân tạo, được đề cập đến trong bối cảnh tự động hóa phân tích và tạo tài liệu thiết kế.
Nguồn: Design Reuse
Biên dịch bởi Admin từ Diễn đàn Vi mạch Bán dẫn và Trí tuệ Nhân tạo Việt Nam
0 bình luận
Danh mục
Bài viết gần đây
Những thách thức đa vật lý trong thiết kế 3D IC
Wed, 05 Feb 2025
Thiết kế SoC: Tương lai của NoC sẽ ra sao?
Wed, 05 Feb 2025
để lại bình luận