Tóm tắt. VLSIT tổ chức quy trình hỗ trợ thiết kế RTL bằng mô hình ngôn ngữ lớn (LLM): từ đặc tả phần cứng, phân rã yêu cầu và cấu hình đến sinh RTL, testbench, assertion SystemVerilog (SVA), mô phỏng, kiểm thử đột biến (mutation testing) và tài liệu. Trọng tâm là phối hợp chỉ dẫn theo vai trò với artifact có cấu trúc, công cụ EDA và các điểm kỹ sư rà soát. Bài viết phân tích luồng này, xác định ranh giới tự động hóa và trình bày nguyên lý tạo agent chuyên biệt có phạm vi, hợp đồng đầu vào/đầu ra, tiêu chí hoàn tất và điều kiện dừng rõ ràng.
1. Mục tiêu và phạm vi phân tích
Bài viết xem VLSIT như một nguyên mẫu kỹ thuật cho quy trình thiết kế và kiểm chứng RTL có AI hỗ trợ. Phân tích tập trung vào kiến trúc các vai trò, luồng artifact, mức tự động hóa, cách tạo agent chuyên biệt và điều kiện cần để đánh giá kết quả. Đây là phân tích thiết kế quy trình, không phải báo cáo benchmark độc lập: các ví dụ và số liệu được đọc từ những lần chạy đã lưu, không được chạy lại trong một môi trường EDA mới. Vì vậy, chúng giúp minh họa cách vận hành chứ không thay thế regression có thể tái lập, chứng minh hình thức, phân tích timing tĩnh hay sign-off ASIC [1].
Mạch lập luận của bài đi từ ranh giới giữa LLM và công cụ thiết kế, sang cách các phase trao đổi dữ liệu; từ đó mới đánh giá phần nào có thể tự động hóa, vai trò nào nên tách thành agent và cách vận hành flow trên một IP cụ thể.
2. Khái niệm AI flow và ranh giới chức năng
VLSIT không phải một bộ trọng số LLM, pipeline huấn luyện/tinh chỉnh mô hình, hệ thống tăng cường truy xuất tri thức hay backend gọi API độc lập. Mô hình ngôn ngữ được cung cấp bởi môi trường chạy như Claude Code hoặc Codex CLI. Phần quy trình gồm chỉ dẫn theo vai trò, quy tắc RTL, lược đồ dữ liệu, script và artifact dự án; LLM dùng chúng để thực hiện từng công việc trong vòng đời thiết kế [1].
Do đó, “AI flow” ở đây là một quy trình kỹ thuật được điều khiển bằng chỉ dẫn cho agent, chứ không phải một công cụ EDA mới. Mỗi vai trò nhận một nhóm đầu vào, thực hiện nhiệm vụ giới hạn, ghi artifact ra project rồi bàn giao cho phase kế tiếp. LLM có thể phân tích và tạo mã, nhưng không thể tự biến suy luận thành bằng chứng thực thi; lint, synthesis và mô phỏng phải do Verilator, Yosys hoặc simulator chạy trên thiết kế thật.
Ba lớp kiến trúc
- Lớp chỉ dẫn và điều phối: 9 Claude Code commands dưới
.claude/commands/và 9 Codex CLI project skills dưới.agents/skills/. Mỗi phase có thể được gọi riêng;/autoflowhoặc skill autoflow mô tả trình tự tổng thể. - Lớp dữ liệu và truy vết: đặc tả, JSON artifacts, JSON Schema và Requirement Traceability Matrix (RTM). Chúng giúp các phase trao đổi một baseline cụ thể, thay vì dựa hoàn toàn vào lịch sử hội thoại.
- Lớp thiết kế và bằng chứng: SystemVerilog, script Bash/Yosys, lint, synthesis, simulation và các log/báo cáo do công cụ tạo ra.
Ba lớp này tạo thành một chu trình: chỉ dẫn định hình công việc của LLM, artifact lưu trạng thái thiết kế, còn EDA tạo bằng chứng từ mã và cấu hình đã lưu. Việc phân lớp giúp phân biệt rõ nơi sinh ra kết quả với nơi kiểm tra kết quả.
| Lớp kiến trúc | Thành phần | Vai trò trong flow |
|---|---|---|
| Điều phối AI | LLM, command và project skill | Đọc đầu vào, thực hiện phase, chuyển tiếp theo chỉ dẫn. |
| Dữ liệu và truy vết | Đặc tả, JSON Schema, artifact và RTM | Lưu baseline, cấu hình và quan hệ giữa requirement với bằng chứng. |
| Thiết kế và kiểm tra | RTL, SVA, testbench, EDA và log | Tạo thiết kế, chạy kiểm tra thực thi và ghi kết quả. |
Hình 1. AI, prompt, project artifact và EDA có vai trò khác nhau. Prompt hướng dẫn; artifact lưu trạng thái; EDA tạo bằng chứng thực thi.
Slash command và skill không tự thân là workflow engine cưỡng chế mọi điều kiện. Thứ tự phase, điểm dừng và cách cập nhật artifact hiện được mô tả trong các chỉ dẫn; tính nhất quán vì vậy phụ thuộc vào cách agent thực hiện và việc đối chiếu với công cụ. Một dòng “PASS” trong phần tóm tắt chỉ là kết luận đáng tin khi có lệnh và log tương ứng để kiểm tra [1, 3, 6].
3. Luồng từ yêu cầu đến tài liệu
Khi đã tách được ba lớp kiến trúc, có thể theo dõi cách dữ liệu đi qua hệ thống. Luồng bắt đầu từ đặc tả phần cứng hoặc mô tả bằng ngôn ngữ tự nhiên, sau đó chuyển thành yêu cầu có mã định danh, cấu hình, RTL, test và bằng chứng verification [2].
| Phase | Vai trò chính | Artifact hoặc bằng chứng cần xem |
|---|---|---|
| 0 — Viết spec (tùy chọn) | spec_writer chuyển mô tả ban đầu thành bản đặc tả có cấu trúc hơn. |
spec/<ip_name>_spec.md |
| 1 — Phân tích spec | spec_parser tách requirement, gán REQ-ID, đánh dấu mơ hồ, ánh xạ module/parameter và gợi ý property. |
schemas/structured_spec.json; review tại Gate 1 |
| 2 — Chốt cấu hình | config_ui chọn parameter và kiểm tra ràng buộc. Đây là tương tác trong hội thoại, không phải GUI riêng. |
schemas/final_config.json; Gate 2 |
| 3a — Sinh RTL | rtl_generator tạo SystemVerilog theo spec, cấu hình và coding rules; chạy lint, rồi synthesis khi môi trường sẵn sàng. |
src/rtl/, file list và synth_report.json |
| 4 — Sinh testbench | tb_generator tạo test plan và testbench SystemVerilog. |
src/tb/, selected_testplan.json; kiểm tra compile |
| 3b — Sinh assertions | sva_generator tạo SVA, bind và cập nhật traceability; cần đánh giá ý nghĩa property và vacuity. |
src/sva/, rtm.json; review tại Gate 3b |
| 5 — Verification | verification nối testbench và SVA với compile, simulation, mutation khi có công cụ phù hợp, cập nhật các verification gap. |
Log thực thi, verification_report.json, RTM; review tại Gate 5 |
| 6 — Tài liệu | spec_pdf_generator tổng hợp artifact và RTL thành tài liệu Markdown/PDF. |
docs/specification.md, PDF nếu chuyển đổi thành công |
| Trình tự | Phase / vai trò | Đầu ra và cổng review |
|---|---|---|
| 1 | Phân tích đặc tả | structured_spec.json; Gate 1 do kỹ sư review. |
| 2 | Chốt cấu hình | final_config.json; Gate 2 có thể tự xác nhận khi đạt điều kiện. |
| 3a và 4 | Sinh RTL; sinh testbench | RTL, lint/synthesis, test plan và compile check; hai phase được chạy tuần tự trong một session. |
| 3b | Sinh SVA | Assertion, bind, RTM; Gate 3b review ý nghĩa property và vacuity. |
| 5 | Verification | Compile, simulation, mutation khi có tool; Gate 5 review log và gap. |
| 6 | Tổng hợp tài liệu | Markdown/PDF sau khi kết quả đã qua review. |
Hình 2. Trình tự phase và các cổng rà soát. Gate 2 và Gate 4 có thể tự xác nhận trong autoflow khi đạt điều kiện; Gate 1, Gate 3b và Gate 5 yêu cầu kỹ sư xem xét.
Gate là gì và vì sao cần giữ lại?
- Gate 1 — baseline yêu cầu: kỹ sư xác nhận yêu cầu đã được tách đúng, không còn quyết định mơ hồ chưa xử lý và mapping sang module/parameter là hợp lý. Nếu lỗi ở đây, mọi artifact sau đó có thể nhất quán về cú pháp nhưng sai chức năng.
- Gate 2 — baseline cấu hình: autoflow có thể chọn giá trị mặc định, trừ khi có override từ spec hoặc hội thoại; có thể tự xác nhận khi không lỗi. Việc này thuận tiện nhưng cần đưa giá trị cấu hình quan trọng vào spec, tránh dựa vào mặc định mà người dùng không chủ ý.
- Gate 3b — review property: con người cần xác nhận assertion diễn tả đúng intent, bind đúng tín hiệu và không bị vacuous do stimulus không kích hoạt điều kiện. Compile pass chỉ chứng minh cú pháp/khả năng biên dịch, không chứng minh property đúng.
- Gate 4 — testbench: theo autoflow, có thể tự xác nhận nếu compile check pass. Compile testbench không đồng nghĩa test có kiểm tra hành vi đủ mạnh.
- Gate 5 — verification/sign-off: kỹ sư cần đọc kết quả từng test, xác nhận SVA có thực sự chạy, xem mutation và các requirement còn thiếu bằng chứng. Flow khóa sign-off của requirement tương ứng nếu mutation score dưới 85%; trường hợp
N/Acó thể được chính sách cho phép nhưng không phải mutation pass. Gate 5 được duyệt cũng không đồng nghĩa mọi REQ-ID đã sign-off [2, 5].
RTM: trục chính của khả năng truy vết
RTM kết nối chuỗi:
REQ-ID → khối/file RTL → SVA đã review → test case được chọn → kết quả chạy → trạng thái sign-off
Khi có yêu cầu thay đổi, chuỗi này hỗ trợ trả lời: requirement nào bị ảnh hưởng? Có RTL implement không? Có assertion kiểm soát không? Có test kích hoạt và bằng chứng pass không? Vẫn còn requirement pending/locked nào? Đây là giá trị kỹ thuật đáng chú ý hơn việc chỉ sinh một tập file RTL. Tuy nhiên RTM chỉ hữu ích nếu mapping được kiểm tra và trạng thái không bị sao chép từ một lần chạy cũ. Một JSON hợp lệ về cấu trúc chưa đảm bảo nội dung đúng về ngữ nghĩa.
RTM vì thế là cầu nối giữa việc sinh thiết kế và việc quyết định có đủ bằng chứng hay chưa. Để hiểu vai trò thực tế của AI, cần tách rõ những thao tác có thể giao cho agent với các điểm vẫn cần con người phê duyệt.
4. Ranh giới của tự động hóa
Những thao tác có thể tự động hóa
Autoflow có thể bắt đầu từ file đặc tả có sẵn hoặc từ mô tả thiết kế (--describe). Sau đó, agent gọi các phase theo thứ tự, đọc và ghi artifact, trình bày tóm tắt, dùng giá trị mặc định khi chưa có override, và tiếp tục từ phase đã chọn dựa trên trạng thái đã lưu. Các điểm resume được hỗ trợ gồm phase3b, phase5 và phase6 [3, 6].
Khi thiếu đầu vào hoặc gặp lỗi nghiêm trọng, flow cần dừng, báo lint/compile/simulation thất bại và không chuyển tiếp nếu điều kiện chưa đạt. Khả năng tạo mã, chạy lệnh và đọc log còn phụ thuộc quyền truy cập project, shell, toolchain, thư viện PDK và license trên máy chạy.
“Automatic” không có nghĩa là thiết kế tự duyệt
| Có thể tự động hóa trong flow | Vẫn cần kỹ sư quyết định hoặc kiểm tra |
|---|---|
| Soạn draft spec, phân tích thành requirement có mã định danh | Tính đúng, đầy đủ và không mơ hồ của spec |
| Đọc parameter và tạo file cấu hình | Giá trị cấu hình có phù hợp mục tiêu sản phẩm hay không |
| Sinh RTL/SVA/testbench theo prompt và coding rules | Ý nghĩa chức năng, giao thức, corner case và chất lượng stimulus |
| Gọi lint, synthesis, compile, simulation nếu tool có sẵn | Log có phản ánh đúng baseline; phạm vi kiểm chứng có đủ hay không |
| Cập nhật JSON/RTM và tổng hợp tài liệu | Chấp nhận gate, ký sign-off, quyết định xử lý verification gap |
RTL và testbench là hai đầu ra có thể phát triển độc lập sau Gate 2, nhưng autoflow hiện gọi Phase 3a trước rồi đến Phase 4 trong cùng session. Không có scheduler để thực thi đồng thời; “độc lập” ở đây mô tả quan hệ công việc, không phải bảo đảm về chạy song song [1, 3].
Ranh giới này cũng giúp xác định đúng vai trò của agent: tự động hóa được những thao tác có đầu vào và tiêu chí rõ, còn quyết định về yêu cầu, ngữ nghĩa property và sign-off cần người chịu trách nhiệm xem xét.
5. Nguyên lý tạo agent riêng trong flow này
5.1 Agent chuyên biệt là một vai trò có hợp đồng rõ ràng
Trong VLSIT, mỗi vai trò được hiện thực hóa bằng một bộ chỉ dẫn gắn với môi trường chạy:
- Với Claude Code, mỗi command là một file Markdown dưới
.claude/commands/, ví dụrtl_generator.md. - Với Codex CLI, mỗi project skill là thư mục có file
SKILL.mddưới.agents/skills/<skill-name>/. Phần đầu file có metadatanamevàdescription, sau đó là hướng dẫn mà agent đọc và làm theo. Bộ hiện có 9 skill, tương ứng với 9 command phase của Claude Code. - Với autoflow, vai trò điều phối gọi/đọc các phase khác và dựa vào artifact đã lưu để xác định trạng thái tiếp theo.
Command và skill là cấu hình vai trò bên trong host agent. Tạo một skill không tự sinh ra process LLM độc lập, model riêng hay năng lực chạy đồng thời. Các phase chuyển giao bằng cách đọc skill kế tiếp và trao đổi qua artifact; muốn chạy song song cần có cơ chế điều phối thực sự, không chỉ chia prompt [1, 6].
| Vai trò | Trách nhiệm | Bàn giao |
|---|---|---|
| Agent điều phối | Theo dõi phase, dependency, trạng thái và gate. | Chỉ định phase kế tiếp dựa trên artifact. |
| Agent phân tích spec / cấu hình | Tách requirement, ambiguity và parameter. | structured_spec.json, final_config.json. |
| Agent RTL / testbench / SVA | Tạo các sản phẩm thiết kế và verification theo phạm vi riêng. | RTL, test plan, testbench, assertion và RTM. |
| Agent verification | Chạy công cụ sẵn có, tổng hợp kết quả và gap. | Log và verification report. |
Điểm kiểm soát: kỹ sư duyệt yêu cầu, property và bằng chứng sign-off. Việc chia vai trò không đồng nghĩa các agent chạy đồng thời.
Hình 3. Mô hình vai trò: agent điều phối giao việc cho các vai trò chuyên biệt, artifact giữ trạng thái giữa phase và kỹ sư duyệt quyết định quan trọng. Các vai trò không mặc nhiên là những tiến trình LLM chạy đồng thời.
5.2 Bảy nguyên tắc để tạo một agent hữu dụng
- Đặt một nhiệm vụ hẹp và có lý do tồn tại. Ví dụ “kiểm tra tính nhất quán giữa port RTL với interface trong spec” dễ đánh giá hơn “thiết kế IP hoàn chỉnh”.
- Khai báo đầu vào và nguồn sự thật. Nêu rõ agent phải đọc file nào, phiên bản nào là chuẩn và điều gì được xem là thiếu. Khi spec và RTL mâu thuẫn, agent nên báo mâu thuẫn thay vì tự chọn một phía.
- Định nghĩa đầu ra có thể kiểm tra. Ghi tên file, schema/trường bắt buộc, format summary và cách liên kết finding với REQ-ID. Tránh output chỉ là một đoạn nhận xét tự do nếu bước sau cần tiêu thụ dữ liệu.
- Nêu quyền và giới hạn thao tác. Agent có được sửa RTL không, hay chỉ đọc và báo cáo? Có được chạy lệnh nào? Khi input không rõ, cần dừng hay được dùng giả định nào? Quy định này hạn chế việc agent âm thầm mở rộng phạm vi.
- Viết điều kiện đạt và điều kiện dừng rõ ràng. Ví dụ: mọi requirement interface được map; lint phải thực sự chạy; tool không có thì kết quả là “not run”, không phải pass; lỗi blocker thì không chuyển phase.
- Thiết kế phase để nối với flow. Mô tả phase trước/sau, artifact cần đọc/ghi và ảnh hưởng của việc sửa input. Autoflow nên điều phối phase, còn mỗi agent chuyên trách nên giữ một nhiệm vụ duy nhất.
- Tạo khả năng truy vết và resume. Ghi REQ-ID, baseline/phiên bản, lệnh và log tương ứng; không tái sử dụng approval hoặc báo cáo cũ nếu spec/config đã thay đổi.
Có thể nhớ công thức:
Vai trò + đầu vào chuẩn + hành động cho phép + đầu ra có cấu trúc + tiêu chí đạt + điều kiện dừng + bàn giao
5.3 Mẫu skill minh họa: agent rà soát interface
Ví dụ dưới đây minh họa cách thu hẹp nhiệm vụ thành một agent có thể đánh giá được. Agent chỉ đọc và phát hiện sai khác giữa đặc tả giao tiếp với khai báo port RTL; nó không tự sửa thiết kế.
---
name: source-command-interface-auditor
description: "Review interface consistency between an approved hardware specification and SystemVerilog RTL."
---
# Interface Auditor
## Mục tiêu
Đối chiếu interface của module với spec đã được duyệt; không sinh hoặc sửa RTL.
## Đầu vào bắt buộc
- schemas/structured_spec.json
- schemas/final_config.json
- Danh sách file RTL/top module của baseline đang review
- REQ-ID liên quan nếu được cung cấp
## Thực hiện
1. Xác định spec và cấu hình thuộc cùng baseline với RTL.
2. Trích tên, hướng, độ rộng và nhóm clock/reset của từng port.
3. Đối chiếu từng trường với yêu cầu nguồn.
4. Ghi finding có mức độ, file/port, REQ-ID, bằng chứng và cách tái hiện.
5. Không suy đoán giá trị còn thiếu; ghi là unresolved và dừng nếu ảnh hưởng đến kết luận.
## Đầu ra
- reports/interface_audit.md: tóm tắt, findings, unresolved items và baseline
- schemas/interface_audit.json: status, checked_ports, findings, source_files
## Tiêu chí hoàn tất
- Mọi port top-level thuộc phạm vi đã được kiểm tra.
- Tool/log chỉ được đánh dấu pass nếu thực sự đã chạy và đọc kết quả.
- Nếu spec thiếu hoặc baseline không khớp, kết quả là blocked, không phải pass.
## Bàn giao
Chỉ đề xuất Gate review khi không còn finding blocker. Chờ kỹ sư quyết định mọi thay đổi thiết kế.
Ví dụ cho thấy nguyên lý cốt lõi: giới hạn agent vào một nhiệm vụ, xác định artifact đầu vào/đầu ra và yêu cầu nó giải thích bằng chứng. Vai trò đó có thể được đóng gói thành project skill của Codex CLI hoặc command Markdown của Claude Code; cách kích hoạt phụ thuộc môi trường chạy [1, 6].
5.4 Đưa agent mới vào autoflow
Tạo file skill hoặc command thôi chưa làm agent mới tự chạy. Để tích hợp đúng, cần thực hiện tuần tự:
- Chọn vị trí và tên rõ ràng. Với Codex CLI, tạo thư mục skill và
SKILL.mdcóname,descriptioncùng nội dung hướng dẫn. Với Claude Code, tạo command Markdown ở vị trí command mà project đang dùng. - Xác định artifact contract. Thêm JSON Schema nếu đầu ra cần được phase sau tiêu thụ có kiểm tra trường. Chọn đường dẫn ổn định và mô tả owner của mỗi artifact.
- Viết hướng dẫn độc lập. Một skill phải có đủ ngữ cảnh để host agent biết lúc nào dùng, đọc gì, làm gì, tạo gì và báo gì nếu thiếu tool. Hạn chế phụ thuộc ngầm vào một cuộc hội thoại trước.
- Thêm phase vào orchestrator. Chỉ định phase chạy sau/before nào, gate nào bảo vệ bước đó, điều kiện được đi tiếp và cách resume. Nếu không sửa điều phối thì agent mới chỉ có thể gọi thủ công.
- Cập nhật điều phối và tài liệu dự án. Đăng ký phase mới trong orchestrator, preflight, sơ đồ và danh sách artifact để agent có thể được gọi đúng lúc.
- Rà soát tương thích IP. Các vai trò mẫu chứa giả định về module, tín hiệu, schema và môi trường EDA. Khi đổi IP, cập nhật đồng bộ mapping của parser, cấu hình, hierarchy RTL, SVA, test plan và tài liệu.
- Kiểm chứng bằng fixture nhỏ. Tạo spec thử có kết quả mong đợi; kiểm tra trường hợp đạt, thiếu input, mâu thuẫn, tool không sẵn sàng và resume sau khi input đổi. Lưu log để kỹ sư review. Điều phối chỉ đáng tin khi các điều kiện này có thể được kiểm tra, thay vì chỉ dựa vào lời khẳng định của agent.
Nguyên tắc thiết kế phù hợp là worker theo phase, orchestrator gọn: mỗi worker chịu trách nhiệm một loại suy luận hoặc sản phẩm; orchestrator giữ thứ tự, dependency, trạng thái và cổng duyệt. Một prompt quá lớn khó bảo trì; ngược lại, tách quá nhiều worker mà thiếu schema và gate dễ làm các vai trò ghi đè artifact hoặc lệch baseline.
Sau khi xác định hợp đồng của từng vai trò, bước tiếp theo là chuẩn bị môi trường và dữ liệu đầu vào để flow có thể chạy trên một thiết kế cụ thể.
6. Vận hành flow trên một IP cụ thể
6.1 Chuẩn bị
Flow cần môi trường Linux/Bash có Environment Modules và công cụ EDA. Trước khi chạy, kiểm tra sourceme.sh, phiên bản tool, đường dẫn PDK và module có sẵn trên máy. Verilator dùng cho lint, Yosys cho synthesis, thư viện GF180MCU Liberty cho technology mapping và simulator phù hợp cho kiểm chứng. VCS cần cài đặt và license riêng; một số đường chạy Icarus bỏ qua SVA. Script tạo PDF cần Python 3 và Matplotlib. Mọi giả định về đường dẫn và module phải khớp với host thực tế [1, 2].
Trên Windows, Bash script cần chạy trong môi trường Linux như WSL hoặc máy chủ EDA, không chạy trực tiếp trong PowerShell. Flow không tự cài EDA, cấp license hay tạo PDK; các thành phần này phải được chuẩn bị riêng.
Khi môi trường đã sẵn sàng, chất lượng đầu vào quyết định phần lớn mức độ ổn định của các phase sinh mã.
6.2 Chọn đầu vào và điều chỉnh cho IP mới
- Làm việc trên branch hoặc bản sao riêng để giữ snapshot tham khảo.
- Viết spec tại
spec/<ip_name>_spec.md, mô tả interface, parameters, clock/reset, hành vi chức năng, timing và error behavior. - Với IP mới, điều chỉnh parser mapping, module hierarchy, constraint/config, RTL rules, SVA, test plan và format tài liệu.
- Chuẩn bị JSON Schema tại đường dẫn mà phase sử dụng. Phân biệt rõ file đầu vào, template và artifact được sinh ra, kể cả khi chúng có tên gần giống nhau.
Các template hiện có chứa giả định về cấu trúc IP và môi trường EDA cụ thể. Vì vậy, đổi spec thôi chưa đủ để áp dụng flow cho một thiết kế khác; cần rà soát các mapping, cấu hình, phân cấp module, property và test plan liên quan.
6.3 Chạy toàn bộ flow
Trong Claude Code, mở project root và nhập command trong hội thoại:
/autoflow spec/<ip_name>_spec.md
Nếu mới có mô tả thiết kế:
/autoflow --describe
Trong Codex CLI, gọi project skill trong phiên làm việc:
$source-command-autoflow
Dùng spec/<ip_name>_spec.md
Tên skill Codex khác cú pháp slash command Claude; không nhập chúng như lệnh Bash trong terminal. Để kiểm soát từng bước, gọi riêng các phase theo bảng ở mục 3. Sinh testbench trước khi review SVA giúp kỹ sư kiểm tra property trong bối cảnh stimulus dự kiến.
Nếu flow bị gián đoạn, có thể yêu cầu tiếp tục từ phase cần thiết hoặc dùng tham số --from. Trước khi resume, xác nhận spec, cấu hình, RTL và báo cáo thuộc cùng baseline. Thay đổi spec hoặc config có thể làm mất hiệu lực các bước sau; khi đó cần chạy lại các phase phụ thuộc thay vì giữ approval hay report cũ [2].
6.4 Những file cần đọc sau khi chạy
Thông thường nên xem:
schemas/structured_spec.json: requirement IDs, ambiguity và mapping.schemas/final_config.json: parameter thực tế đã chốt.src/rtl/vàschemas/synth_report.json: RTL, file list, lint/synthesis.src/tb/vàschemas/selected_testplan.json: test plan, testbench, requirement coverage.src/sva/,schemas/rtm.json,GATE3_REVIEW.md: assertions, mapping và vacuity review.- Log simulation/mutation và
schemas/verification_report.json: bằng chứng thực chạy, failure và gap. docs/specification.md/PDF: tài liệu tổng hợp.
Không xem file được sinh là thay thế log. Nếu một bước bị bỏ qua do thiếu tool, ghi rõ “not run” và không suy diễn thành pass.
7. Tính năng đáng chú ý
Khi một lần chạy tạo đủ artifact và log, giá trị của flow không chỉ nằm ở lượng mã sinh ra mà còn ở khả năng giải thích mã đó đáp ứng yêu cầu nào và đã được kiểm tra bằng cách nào.
7.1 Requirement traceability
REQ-ID được giữ xuyên qua spec, RTL, SVA, test case và verification status, cho phép đánh giá coverage theo yêu cầu thay vì chỉ đếm số module hoặc test.
7.2 Quy ước và kiểm tra nhất quán
Quy tắc RTL chuẩn hóa SystemVerilog-2012 synthesizable subset, cách đặt tên port/parameter/register/wire, reset active-low, module, assertion và coding pattern. Quy tắc chung giúp đầu ra dễ đọc và review hơn, nhưng cần được điều chỉnh theo chuẩn của IP đích [7].
7.3 Tách biệt sinh mã và kiểm chứng
Các vai trò RTL, SVA, testbench và verification có trách nhiệm riêng. Về nguyên tắc, điều này giúp tránh kết luận “RTL đúng vì chính prompt sinh RTL nói vậy”. Công cụ lint/simulation/mutation có thể cung cấp một phần bằng chứng bên ngoài LLM; độ mạnh phụ thuộc cấu hình và phạm vi test/property.
7.4 Resume và artifact tái sử dụng
Các artifact trong thư mục schema lưu trạng thái để flow tiếp tục sau gián đoạn. Cách này đáng tin hơn việc chỉ dựa vào lịch sử hội thoại, miễn là artifact thuộc cùng baseline và thay đổi input làm chạy lại đúng các phase phụ thuộc.
7.5 Có ví dụ thiết kế và snapshot
Hai snapshot minh họa cho các loại thiết kế khác nhau: lõi xử lý RV32IM và bộ chuyển đổi độ rộng dữ liệu AXI4-Stream. Downscaler chia beat theo thứ tự LSB-first và truyền TKEEP/TLAST; đây là chuyển độ rộng dữ liệu, không phải giảm độ phân giải ảnh. Số liệu của mỗi snapshot chỉ phản ánh lần chạy tương ứng [1].
Những khả năng này hữu ích khi artifact được nối với bằng chứng có thể kiểm tra. Phần tiếp theo nêu giới hạn cần tính đến trước khi dùng kết quả cho quyết định kỹ thuật.
8. Giới hạn và rủi ro khi diễn giải kết quả
- Chưa phải sign-off sản xuất. Lint, synthesis mapping và simulation không tự chứng minh timing closure, CDC/RDC an toàn, physical implementation hoặc đầy đủ chức năng. Flow hiện chưa bao gồm STA, place-and-route hay quy trình sign-off đầy đủ [1].
- Evidence có thể thiếu hoặc lệch baseline. Một số log cuối cùng, mutation working files hoặc artifact cần để tái lập không có trong snapshot. Báo cáo JSON không thay thế log nguồn.
- SVA có thể compile nhưng không hữu ích. Assertion vacuous, bind sai tín hiệu hoặc stimulus không kích hoạt property đều có thể làm kết quả trông “sạch” mà không kiểm tra hành vi mong muốn.
- Pass count có thể che khuất test N/A. Cần đọc từng test case và điều kiện pass/fail; số TC tổng hợp không nói được mọi requirement đã được kiểm chứng.
- Chênh lệch giữa command, template, schema và ví dụ. Một số phiên bản chỉ dẫn, schema và snapshot chưa hoàn toàn đồng nhất; ví dụ synthesis cũ cũng có thể không phản ánh các cập nhật mới. Phần tự động mô tả RTL/TB độc lập nhưng trình tự thực thi trong một session là tuần tự. Trước khi chạy, cần chọn một baseline và rà soát tính nhất quán [1, 3].
- Giả định toolchain/PDK.
sourceme.shgiả định module, Bash và đường dẫn PDK cụ thể; các snapshot có thể chứa đường dẫn tuyệt đối. Không nên xem script là gói cài đặt portable. - Chưa xác định quyền sử dụng. Bản công khai được khảo sát không kèm file
LICENSE; cần xác nhận quyền sử dụng và phân phối với chủ sở hữu, đồng thời tuân thủ license riêng của EDA/PDK [1].
Những giới hạn này không làm mất giá trị của khung quy trình; chúng xác định loại kết luận có thể rút ra từ artifact và loại quyết định vẫn cần kỹ sư chịu trách nhiệm. Các thuật ngữ dưới đây được dùng theo nghĩa đó.
9. Giải thích các thuật ngữ tiếng Anh
Bảng dưới đây giải nghĩa những cụm từ kỹ thuật tiếng Anh được giữ lại trong bài. Một số thuật ngữ có bản dịch ngắn, nhưng phần giải thích tập trung vào ý nghĩa trong quy trình thiết kế RTL.
| Thuật ngữ | Cách gọi tiếng Việt và ý nghĩa trong bài |
|---|---|
| AI flow / workflow | Luồng công việc có AI hỗ trợ: chuỗi bước, điều kiện chuyển tiếp và người chịu trách nhiệm. |
| AI-assisted RTL | Thiết kế RTL có AI hỗ trợ; AI giúp phân tích yêu cầu hoặc đề xuất mã, còn tính đúng phải được kiểm tra. |
| Agent | Tác tử AI được giao một vai trò/nhiệm vụ. Một vai trò có thể được mô tả bằng prompt hoặc skill mà không cần là một tiến trình AI riêng. |
| LLM (Large Language Model) | Mô hình ngôn ngữ lớn, sinh/diễn giải văn bản và mã dựa trên ngữ cảnh được cung cấp. |
| Prompt | Chỉ dẫn đầu vào cho mô hình, nêu mục tiêu, ngữ cảnh và cách thực hiện. |
| Slash command | Lệnh bắt đầu bằng dấu gạch chéo, được nhập trong Claude Code để gọi một quy trình chỉ dẫn. Đây không phải lệnh Bash. |
| Project skill | Bộ hướng dẫn theo vai trò đặt trong dự án để Codex CLI biết khi nào và cách thực hiện một nhiệm vụ. |
| Orchestrator | Bộ điều phối: xác định thứ tự phase, dependency, trạng thái và các điểm duyệt. Trong VLSIT, autoflow đảm nhiệm vai trò này bằng cách hướng dẫn agent đi qua các phase. |
| RTL (Register-Transfer Level) | Mô tả phần cứng ở mức thanh ghi và luồng dữ liệu; thường được viết bằng Verilog/SystemVerilog để tổng hợp thành mạch. |
| Specification / spec | Đặc tả: mô tả có cấu trúc về chức năng, giao tiếp, tham số, clock/reset, timing và hành vi lỗi mà thiết kế phải đáp ứng. |
| Requirement | Yêu cầu cụ thể, có thể truy vết và kiểm tra; trong flow được gán mã REQ-ID. |
| REQ-ID | Mã định danh duy nhất của requirement, ví dụ REQ-001, dùng nối yêu cầu với RTL, assertion, test và kết quả. |
| Requirements traceability | Truy vết yêu cầu: theo dõi một requirement xuyên suốt thiết kế và kiểm chứng. |
| RTM (Requirement Traceability Matrix) | Ma trận truy vết yêu cầu; bảng/JSON liên kết requirement với RTL, SVA, test case, kết quả và sign-off. |
| Artifact | Sản phẩm trung gian/đầu ra được lưu thành file, như JSON, RTL, testbench, log hoặc tài liệu. |
| Schema / JSON Schema | Lược đồ dữ liệu; quy định trường, kiểu dữ liệu và cấu trúc mà một file JSON cần tuân theo. |
| Baseline | Phiên bản chuẩn của spec, cấu hình, RTL và báo cáo được dùng làm mốc cho một lần chạy. |
| Phase | Giai đoạn công việc có nhiệm vụ và đầu ra riêng trong flow. |
| Gate / review gate | Cổng rà soát: điểm phải thỏa điều kiện hoặc được con người duyệt trước khi flow tiếp tục. |
| Human review | Kỹ sư/con người rà soát kết quả và đưa ra quyết định; khác với việc agent tự tạo báo cáo. |
| Parameter / override | Tham số cấu hình của thiết kế / giá trị ghi đè lên giá trị mặc định. |
| Interface / port | Giao tiếp giữa các khối / một tín hiệu đầu vào, đầu ra hoặc hai chiều của module. |
| Testbench (TB) | Môi trường kiểm thử mô phỏng: kích thích đầu vào, quan sát đầu ra và đánh giá kết quả của RTL. |
| Test plan | Kế hoạch kiểm thử, mô tả các test case và requirement mà từng test dự kiến kiểm tra. |
| Compile / compile check | Biên dịch / bước kiểm tra rằng source được công cụ chấp nhận về cú pháp và khả năng kết hợp. Compile thành công chưa chứng minh thiết kế đúng chức năng. |
| Lint | Phân tích tĩnh để phát hiện lỗi cú pháp, vấn đề coding, độ rộng tín hiệu, latch ngoài ý muốn và các cảnh báo khác. |
| Synthesis | Tổng hợp logic: chuyển RTL thành biểu diễn mạch/cell logic theo thư viện công nghệ và ràng buộc được cung cấp. Không thay thế STA hay physical design. |
| Simulation | Mô phỏng hành vi thiết kế theo testbench và stimulus đã chọn. Kết quả chỉ bao phủ các tình huống thực sự được chạy. |
| SVA (SystemVerilog Assertions) | Các khẳng định/thuộc tính viết bằng SystemVerilog để kiểm tra hành vi hoặc quan hệ theo thời gian của thiết kế. |
| Property | Thuộc tính cần kiểm tra; ví dụ khi có request thì response phải xuất hiện trong một khoảng thời gian nhất định. |
| Bind | Cơ chế gắn assertion hoặc checker vào module/instance thiết kế mà không nhất thiết sửa trực tiếp RTL của module đó. |
| Vacuity / vacuous property | Assertion “đạt” một cách rỗng vì điều kiện kích hoạt không bao giờ xảy ra; do đó không có tình huống thực để kiểm tra property. |
| Verification | Kiểm chứng: thu thập bằng chứng cho thấy thiết kế đáp ứng yêu cầu bằng test, assertion và phân tích kết quả. |
| Verification gap | Khoảng trống kiểm chứng: requirement chưa có đủ test/property/bằng chứng hoặc chưa được sign-off. |
| Mutation testing | Kiểm thử đột biến: cố ý tạo thay đổi nhỏ có lỗi trong thiết kế/mã rồi xem test có phát hiện được thay đổi sai đó không. |
| Mutation score | Điểm/tỷ lệ đột biến bị test phát hiện trên tổng số đột biến hợp lệ đã thử; đây là chỉ số đánh giá độ nhạy của test, không phải phần trăm chức năng đúng. |
| Coverage | Độ bao phủ kiểm thử: mức requirement, tình huống hoặc cấu trúc đã được test kích hoạt/kiểm tra. Có nhiều loại coverage và chúng không đồng nghĩa với nhau. |
| Sign-off | Phê duyệt chính thức rằng một hạng mục đáp ứng tiêu chí đã định; không nên ký chỉ dựa trên summary do AI viết. |
| Regression | Chạy lại tập kiểm thử sau khi thay đổi để kiểm tra rằng hành vi đã đúng trước đó không bị hỏng. |
| Formal proof / formal verification | Chứng minh hoặc kiểm chứng hình thức bằng phương pháp toán học trên mô hình và giả thiết đã khai báo; mạnh hơn mô phỏng ở một số phạm vi nhưng phụ thuộc tính đúng của model/assumptions. |
| STA (Static Timing Analysis) | Phân tích timing tĩnh: kiểm tra đường truyền tín hiệu so với ràng buộc thời gian/clock mà không cần mô phỏng vector. |
| CDC / RDC | Kiểm tra tín hiệu đi qua miền clock khác nhau / miền reset khác nhau, nhằm tìm nguy cơ đồng bộ hoặc phục hồi/reset không an toàn. |
| PDK (Process Design Kit) | Bộ dữ liệu công nghệ bán dẫn, gồm mô hình và thư viện cần cho thiết kế/kiểm tra theo một tiến trình cụ thể. |
| Liberty library | File thư viện mô tả đặc tính cell chuẩn, như hàm logic, timing và công suất, dùng trong synthesis và phân tích liên quan. |
| Process corner | Góc công nghệ/điện áp/nhiệt độ (ví dụ TT hoặc SS) dùng để đánh giá đặc tính cell trong điều kiện khác nhau. |
| Timing closure | Đạt các ràng buộc timing sau các bước thiết kế vật lý và phân tích; chỉ chạy synthesis chưa chứng minh đã timing closure. |
| IP (Intellectual Property) | Khối thiết kế phần cứng có thể tái sử dụng, như bộ xử lý, bộ điều khiển hoặc khối giao tiếp. |
| Toolchain | Bộ công cụ và phiên bản phối hợp để thực hiện lint, synthesis, simulation và xử lý artifact. |
| Environment Modules | Cơ chế trên máy Linux/HPC để nạp và chuyển phiên bản công cụ/thư viện vào môi trường làm việc. |
| Scheduler | Bộ lập lịch điều phối công việc đồng thời hoặc theo tài nguyên. VLSIT hiện thực hiện các phase tuần tự trong một session, chưa có scheduler chạy chúng đồng thời. |
| Resume | Tiếp tục flow từ một phase sau khi gián đoạn, dựa trên artifact đã lưu và baseline còn phù hợp. |
| LSB-first | Truyền/xử lý phần bit ít quan trọng nhất trước; trong ví dụ downscaler, đây là thứ tự tách các lát dữ liệu. |
| TKEEP / TLAST | Tín hiệu AXI4-Stream: TKEEP đánh dấu byte hợp lệ trong beat; TLAST đánh dấu beat cuối của một packet/frame. |
| EDA (Electronic Design Automation) | Công cụ tự động hóa thiết kế điện tử, gồm lint, tổng hợp, mô phỏng và các bước phân tích thiết kế chip. |
| Engineering prototype | Nguyên mẫu kỹ thuật dùng để thử nghiệm quy trình/ý tưởng; chưa đồng nghĩa sản phẩm đã hoàn thiện hoặc sign-off. |
| Snapshot | Bản chụp artifact/log tại một thời điểm chạy; không mặc nhiên là kết quả có thể tái lập hoặc baseline hiện hành. |
| RAG (Retrieval-Augmented Generation) | Sinh nội dung có tăng cường truy xuất: tìm tài liệu liên quan rồi đưa vào ngữ cảnh của mô hình trước khi tạo câu trả lời. |
| Fine-tuning | Tinh chỉnh mô hình bằng dữ liệu bổ sung để thay đổi khả năng/hành vi; đây không phải thành phần của kiến trúc VLSIT đang phân tích. |
| Backend / API | Dịch vụ phía máy chủ / giao diện lập trình để phần mềm gửi yêu cầu và nhận kết quả từ một dịch vụ khác. |
10. Kết luận
VLSIT đưa ra một khung thực hành để đưa LLM vào chuỗi công việc RTL: chia nhiệm vụ thành phase, chuẩn hóa quy tắc coding, lưu artifact trung gian, duy trì RTM và giữ các điểm kỹ sư review. Giá trị chính nằm ở cách tổ chức quy trình và truy vết yêu cầu; việc sinh mã tự động không tự tạo ra một model RTL độc lập hay bảo đảm sign-off.
Khi áp dụng, prompt/skill định nghĩa cách agent hành động; JSON/RTM và log tạo hợp đồng dữ liệu và bằng chứng giữa các bước. Một agent riêng nên bắt đầu từ nhiệm vụ nhỏ, input chuẩn, output kiểm tra được, quyền thao tác rõ, tiêu chí đạt và điều kiện dừng; sau đó mới được tích hợp vào orchestrator. Kỹ sư giữ trách nhiệm xác nhận đặc tả, ngữ nghĩa assertion, mức bao phủ verification và sign-off cuối.
Tài liệu tham khảo
- VLSIT_RTL_Generator_AI_Model — README
- Hướng dẫn sử dụng — guideline.md
- Prompt điều phối — autoflow.md
- RTL Generator prompt
- Verification prompt
- Codex CLI autoflow skill
- Quy tắc RTL — rtl_rule.md
