AI Flow VLSIT: Từ đặc tả phần cứng đến RTL và cách xây dựng agent chuyên biệtBỏ qua mục lục, đến nội dung

Phân tích kỹ thuật · Thiết kế phần cứng có AI hỗ trợ

AI Flow VLSIT: Từ đặc tả phần cứng đến RTL và cách xây dựng agent chuyên biệt

Tác giả: Lê Đại Quốc, Lê Trường Thịnh, Nguyễn H QuânNgày khảo sát: 29-09-2026Nguồn: GitHub VLSIT

AI hỗ trợ thiết kế RTLSystemVerilogtruy vết yêu cầuagent chuyên biệtSVAtestbenchkiểm chứng

Tóm tắt

Bài viết phân tích cách repository (kho mã nguồn) 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, cấu hình, sinh RTL, bộ kiểm thử (testbench) và các khẳng định SystemVerilog (SVA), đến mô phỏng, kiểm thử đột biến (mutation testing) và tài liệu. Điểm cốt lõi không phải một mô hình AI RTL được huấn luyện sẵn, mà là cách đóng gói chỉ dẫn theo vai trò thành lệnh Claude Code và kỹ năng dự án Codex CLI, kết hợp dữ liệu đầu ra có cấu trúc, công cụ EDA và các điểm kỹ sư rà soát. Bài viết giải thích giới hạn tự động hóa và nguyên lý tạo agent riêng với phạm vi, đầu vào, đầu ra, điều kiện dừng và bằng chứng kiểm tra rõ ràng.

1. Phạm vi và cách đọc kết quả

Bài viết khảo sát README, hướng dẫn sử dụng, prompt điều phối, một số prompt phase, project skill và quy tắc RTL của repository. Đây là phân tích hiện trạng tài liệu và cấu trúc repository, không phải báo cáo benchmark độc lập: bài viết không tuyên bố đã chạy lại các thiết kế hay xác nhận mọi kết quả bằng EDA trên một môi trường mới. README tự mô tả dự án là engineering prototype; các báo cáo đi kèm là snapshot của những lần chạy đã lưu, không thay thế regression tái lập, formal proof, STA hoặc sign-off ASIC. Nên đọc các số liệu ví dụ theo đúng phạm vi đó. README

2. “AI flow” ở đây nghĩa là gì?

Tên repository có cụm “AI Model”, nhưng nội dung hiện có không phải bộ trọng số LLM, pipeline huấn luyện/fine-tuning, hệ thống RAG hay một ứng dụng backend gọi LLM API độc lập. LLM được cung cấp bởi môi trường chạy bên ngoài — Claude Code hoặc Codex CLI. Repository cung cấp prompt/skill, quy tắc, schema, script và ví dụ để hướng mô hình thực hiện công việc trong một dự án thiết kế. README: phạm vi AI và kiến trúc

Vì thế, “AI flow” nên được hiểu 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ò yêu cầu LLM đọc một nhóm đầu vào, làm một nhiệm vụ cụ thể, ghi artifact ra project, rồi chuyển công việc sang phase kế tiếp. Các bước mà LLM không thể tự xác nhận bằng suy luận cần dựa vào công cụ thực thi như Verilator, Yosys hoặc simulator.

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; /autoflow hoặ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.

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.

Điểm quan trọng là slash command và skill không phải workflow engine có khả năng tự cưỡng chế mọi điều kiện. README nói việc tuân thủ gate và cập nhật artifact hiện chủ yếu dựa vào agent làm đúng chỉ dẫn; repository chưa có một bộ điều phối và validator chung để bảo đảm toàn bộ quy tắc. Do đó, một dòng “PASS” do agent tóm tắt chỉ đáng tin khi đối chiếu được với log và lệnh thực sự đã chạy. README: ba lớp kiến trúc

3. Luồng từ yêu cầu đến tài liệu

Luồng tiêu chuẩn bắt đầu từ một đặc tả phần cứng hoặc mô tả bằng ngôn ngữ tự nhiên, sau đó đi qua các phase sau. Tên phase và artifact dưới đây phản ánh cấu trúc trong README và hướng dẫn sử dụng. Hướng dẫn sử dụng

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

Hình 2. Trình tự phase và các cổng review được mô tả trong flow. Gate 2 và Gate 4 chỉ được auto-approve trong autoflow khi đạt điều kiện; ba cổng Gate 1, Gate 3b và Gate 5 vẫn dành cho human review.

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: người review cần đọc kết quả từng test, biết SVA có thực sự chạy hay không, xem mutation và requirement còn thiếu bằng chứng. Prompt verification quy định mutation score dưới 85% khóa sign-off tương ứng; một số trường hợp N/A được chính sách cho phép nhưng N/A không phải mutation pass. Gate 5 được duyệt cũng không có nghĩa mọi REQ-ID đều đã sign-off. Autoflow prompt · Hướng dẫn: các điểm review

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.

4. Tự động hóa: làm được gì và dừng ở đâu?

Những thao tác có thể tự thực hiện theo prompt

Autoflow hỗ trợ hai cách bắt đầu: đưa vào file spec có sẵn hoặc yêu cầu agent tạo spec từ mô tả (--describe). Agent sau đó gọi các phase theo thứ tự, đọc/ghi artifact, trình bày summary, dùng giá trị mặc định nếu chưa có cấu hình override, và cho phép tiếp tục từ phase cụ thể dựa trên artifact đã lưu. Hướng dẫn resume nêu các điểm như phase3b, phase5 và phase6. Autoflow prompt · Codex autoflow skill

Agent cũng được hướng dẫn dừng khi thiếu đầu vào hoặc gặp lỗi nghiêm trọng, báo lint/compile/simulation fail và không đi tiếp qua một số bước nếu điều kiện chưa đạt. Khả năng tạo mã, chạy lệnh và đọc log phụ thuộc quyền truy cập project, shell, toolchain, thư viện PDK và license của môi trường.

“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

Có một điểm dễ hiểu nhầm về chạy song song. Nội dung tự động mô tả RTL và testbench là các công việc độc lập sau Gate 2, nhưng cùng prompt lại yêu cầu chạy Phase 3a trước rồi mới Phase 4; README cũng nói trong một session autoflow thực hiện tuần tự và repository không có scheduler chạy song song. Vì vậy nên đọc “độc lập” là không phụ thuộc logic về mặt công việc, không phải cam kết thực thi đồng thời. README: kiến trúc và autoflow · Autoflow prompt

5. Nguyên lý tạo agent riêng trong flow này

5.1 “Agent riêng” hiện được hiện thực hóa bằng chỉ dẫn có vai trò

Repository biểu diễn từng vai trò bằng file chỉ dẫn:

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.md dưới .agents/skills/<skill-name>/. Phần đầu file có metadata name và description, sau đó là hướng dẫn mà agent đọc và làm theo. Trong repository, bộ 9 skill ánh xạ một-một với 9 command phase.
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.

Đây là các cấu hình/prompt theo vai trò bên trong host agent. Không nên mặc định rằng tạo file skill sẽ tạo ra một process LLM độc lập, một model riêng, hay năng lực chạy đồng thời. Skill Codex trong repository còn ghi rõ phase kế tiếp được đọc trực tiếp từ file skill tương ứng; đây là cách chuyển chỉ dẫn và thực hiện, không phải tuyên bố về một hệ thống multi-agent scheduler. README: commands và skills · Codex autoflow skill

Hình 3. Mô hình vai trò phù hợp với repository: điều phối qua chỉ dẫn và artifact dùng chung, có con người duyệt các quyết định quan trọng. Hình không hàm ý các vai trò là 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

Đây là ví dụ đề xuất để giải thích cách thiết kế, không phải file có sẵn trong repository. Agent này chỉ đọc và phát hiện sai khác giữa interface spec với khai báo port RTL, 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ế.

Nội dung trên thể hiện “nguyên lý agent” ở cấp độ thực dụng: agent được giới hạn vào một công việc, có artifact đầu vào/đầu ra và chịu trách nhiệm giải thích bằng chứng. Có thể hiện thực hóa dạng skill trong Codex CLI hoặc dạng command Markdown cho Claude Code. Cú pháp kích hoạt cần tuân theo host tương ứng; project hiện ánh xạ tên skill Codex và slash command Claude qua README. README: ánh xạ skill-command

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.md có name, description cù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 mapping và tài liệu. Ghi rõ lệnh/skill mới trong README hoặc guideline, thêm vào preflight, cập nhật sơ đồ và danh sách artifact.
Rà soát tương thích IP. Các prompt hiện có có giả định về module, signal, schema và công cụ của RV32IM hoặc môi trường EDA cụ thể. Đổi IP yêu cầu rà soát mapping của parser, configuration, RTL hierarchy, SVA, test plan và tài liệu đồng bộ.
Kiểm chứng bằng một fixture nhỏ. Tạo spec test có kết quả mong đợi; kiểm tra cả trường hợp pass, thiếu input, mâu thuẫn, tool unavailable và resume sau khi input đổi. Ghi nhận log và review bởi kỹ sư. Đây là khuyến nghị cho quy trình phát triển agent; repository chưa có validator chung bảo đảm mọi điều kiện.

Một nguyên tắc thiết kế hữu ích là phase worker nhỏ, orchestrator mỏng: worker chuyên một loại suy luận/sản phẩm; orchestrator lo thứ tự, dependency, trạng thái và cổng duyệt. Nếu mọi thứ nhét vào một prompt lớn, khó tìm lỗi và khó cập nhật; nếu tách ra quá nhiều worker mà không có schema/gate, các vai trò dễ ghi đè artifact hoặc hiểu khác nhau về baseline.

6. Hướng dẫn sử dụng thực tế

6.1 Chuẩn bị

Repository hướng tới môi trường Linux/Bash có Environment Modules và EDA tools. Trước khi chạy, cần xem lại sourceme.sh, phiên bản tool, đường dẫn PDK và module có tồn tại trên máy. Hướng dẫn mô tả Verilator cho lint, Yosys cho synthesis, thư viện GF180MCU Liberty cho technology mapping và simulator phù hợp; VCS cần cài/license riêng. Đường chạy Icarus được nêu cho một số ví dụ nhưng bỏ qua SVA. Script PDF cần Python 3 và Matplotlib. Các giả định đường dẫn/module cần chỉnh cho host cụ thể. README: yêu cầu môi trường và cách chạy · Guideline

Trên Windows, Bash script không chạy trực tiếp trong PowerShell; hướng dẫn đề xuất dùng môi trường Linux phù hợp như WSL hoặc máy chủ EDA rồi cấu hình lại đường dẫn/công cụ. Repository không tự cài EDA, không cấp license và không tạo PDK.

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 ở đúng vị trí mà prompt tham chiếu. Kiểm tra các snapshot đầu ra không bị nhầm với template/prompt cùng tên.

README cảnh báo một số prompt và script gắn với giả định về cấu trúc IP/môi trường cụ thể. Vì vậy không nên chỉ đổi spec rồi kỳ vọng mọi agent đã tự hiểu thiết kế khác.

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. Để chạy có kiểm soát, gọi riêng các phase theo bảng ở mục 3; hướng dẫn đặt testbench trước SVA review để có test stimulus cho đánh giá property.

Tiếp tục một flow đã gián đoạn bằng cách nêu phase cần resume cho agent hoặc dùng tham số --from được mô tả trong prompt. Trước đó, xác nhận spec, config, RTL và báo cáo thuộc cùng baseline. Nếu thay đổi spec/config, chạy lại các bước bị ảnh hưởng thay vì giữ lại approval hoặc report cũ. Guideline: chạy flow, từng bước và resume

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

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

rtl_rule.md mô tả SystemVerilog-2012 synthesizable subset, naming conventions cho port/parameter/register/wire, reset active-low, quy tắc module, assertion và coding pattern. Quy tắc chung làm đầu ra dễ đọc/review hơn, nhưng vẫn cần được cập nhật theo quy ước của IP thật. RTL coding rules

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

Flow được hướng dẫn đọc các artifact trong thư mục schema để tiếp tục sau gián đoạn. Việc lưu trạng thái vào file có lợi hơn chỉ dựa vào hội thoại, nhưng chỉ an toàn khi artifact mang cùng baseline và khi thay đổi input kích hoạt chạy lại các bước phụ thuộc.

7.5 Có ví dụ thiết kế và snapshot

README trình bày snapshot RV32IM processor và AXI4-Stream data-width downscaler để minh họa cách đọc artifact. Với downscaler, flow ví dụ chia beat 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. Các số liệu trong snapshot phản ánh từng lần chạy, không phải cam kết tổng quá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. README nêu không có flow STA/place-and-route và sign-off đầy đủ.
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.

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 được giữ lại trong bài và trong repository. 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 của chúng 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ụ. Trong repository này, vai trò chủ yếu được mô tả bằng prompt hoặc skill, không mặc nhiê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 repository, vai trò này được mô tả bằng prompt autoflow.
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; repository hiện không cung cấp scheduler riêng cho các phase.
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; repository này không cung cấp pipeline đó.
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 có giá trị thực hành để hướng LLM tham gia chuỗi công việc RTL: chia nhiệm vụ thành phase, chuẩn hóa coding rules, lưu intermediate artifacts, duy trì RTM và giữ các điểm review của kỹ sư. Điểm mạnh nằm ở cách tổ chức quy trình và truy vết yêu cầu, không phải một model RTL độc lập hay cam kết rằng code được sinh ra có thể tự sign-off.

Muốn áp dụng hiệu quả, cần xem prompt/skill là đặc tả hành vi cho agent, còn JSON/RTM và log là hợp đồng dữ liệu/bằng chứng giữa các bước. Muốn tạo agent riêng, hãy bắt đầu từ một nhiệm vụ nhỏ có 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 tích hợp vào orchestrator và review trên baseline thật. Kỹ sư vẫn giữ trách nhiệm xác nhận spec, ngữ nghĩa assertions, mức bao phủ verification và sign-off cuối.

Tài liệu tham khảo

↑ Về đầu trang

VLSI TECHNOLOGY

Thứ Tư, 30 tháng 9, 2026