[Phần 2] Từ một đoạn ý tưởng đến SoC RISC-V đã kiểm chứng: flow engine thiết kế ASIC có review gate, ưu tiên xác định

VLSI Technology with AI

[Part 2] From One Paragraph of Intent to a Checked RISC-V SoC: A Gated, Deterministic-First Flow Engine for ASIC Design

Từ một đoạn ý tưởng đến SoC RISC-V đã kiểm chứng: flow engine thiết kế ASIC có review gate, ưu tiên xác định (deterministic-first)

VLSI Technology — Q3TUI ASIC AI Design Flow

This is Part 2 of 2. Part 1 covers the abstract and Sections I–III (Introduction, Architecture, Chain and Updates). Figures and tables keep their numbering from Part 1 (Table VI and Figs. 7–10 appear here).

Đây là Phần 2/2. Phần 1 gồm tóm tắt và các mục I–III (Giới thiệu, Kiến trúc, Chuỗi và cập nhật). Hình và bảng giữ nguyên số thứ tự từ Phần 1 (Bảng VI và Hình 7–10 nằm ở đây).

IV. Case Study: What the Flows Produced — Nghiên cứu điển hình

The example design (rv32iv) is the complete output of a single unattended chain. One human wrote a 615-line intent document — goal, network, vector instructions, CPU, memory map, register plan, host load port, tools and open questions — and the flows produced everything else.

Thiết kế ví dụ (rv32iv) là đầu ra trọn vẹn của một chuỗi chạy unattended (không có người can thiệp). Một người viết tài liệu ý tưởng 615 dòng — mục tiêu, mạng nơ-ron, tập lệnh vector, CPU, bản đồ bộ nhớ, kế hoạch thanh ghi, cổng nạp từ host, công cụ và các câu hỏi mở — và các luồng làm ra phần còn lại.

The run used VCS for simulation, Verible and Verilator for lint and style, Quartus Prime Pro 25.1 for FPGA synthesis, VC Static for CDC/RDC analysis, RISC-V GCC 14.2 and Spike for firmware and cross-checking. Every gate ran in auto_answer: approvals were automatic and each question took the default the step proposed — the configuration that makes the evidence weakest, and therefore the interesting one to report.

Lần chạy dùng VCS để mô phỏng, Verible và Verilator để lint và kiểm style, Quartus Prime Pro 25.1 để tổng hợp FPGA, VC Static để phân tích CDC/RDC, RISC-V GCC 14.2 và Spike cho firmware và đối chiếu. Mọi gate chạy ở auto_answer: phê duyệt tự động và mỗi câu hỏi lấy giá trị mặc định do bước đề xuất — cấu hình khiến bằng chứng yếu nhất, và vì thế là cấu hình đáng báo cáo nhất.

Table VI. Case-study results, as reported by the flows — Bảng VI. Kết quả

Measure / Chỉ số	Result / Kết quả
Specification Đặc tả	21 sections, 87 requirements, locked configuration. 21 mục, 87 yêu cầu, cấu hình đã khoá.
Open questions Câu hỏi mở	47 (spec 7, parse 2, CSR 4, RTL 26, prepare 2, simulate 6), each closed with its proposed default. 47 câu (spec 7, parse 2, CSR 4, RTL 26, prepare 2, simulate 6), mỗi câu đóng bằng mặc định đề xuất.
RTL	38 modules, 7,306 lines; Verible format and style clean; Verilator 0 warnings. 38 mô-đun, 7.306 dòng; Verible sạch định dạng và style; Verilator 0 cảnh báo.
Verification Kiểm chứng	60 tests planned, 59 executed, 59 passing (1 test applies only to a 256-bit configuration); bit-exact comparison against a Python golden model. 60 test dự kiến, 59 chạy, 59 pass (1 test chỉ dành cho cấu hình 256-bit); so khớp bit-exact với golden model viết bằng Python.
System test Test hệ thống	100 images; slowest run 252,418 cycles ≈ 1.26 ms at 200 MHz ≈ 790 images/s. 100 ảnh; trường hợp chậm nhất 252.418 chu kỳ ≈ 1,26 ms ở 200 MHz ≈ 790 ảnh/giây.
FPGA synthesis Arria 10, Quartus 25.1, post-synthesis	8,690 ALMs (2 % of the device), 6,646 registers, 10 DSP blocks, 2.36 Mbit block memory; WNS +0.416 ns at 200 MHz, Fmax ≈ 218 MHz. 8.690 ALM (2 % device), 6.646 thanh ghi, 10 khối DSP, 2,36 Mbit block memory; WNS +0,416 ns ở 200 MHz, Fmax ≈ 218 MHz.

Two observations from the run are more informative than the headline numbers. First, the 26 questions raised inside the RTL flow were all about information the specification genuinely did not contain — port lists of internal modules, ownership of the halt flag, the priority of a stall against a redirect. That is the expected shape of a specification gap, and it is what a review gate exists to catch. Second, all six questions raised during simulation were resolved as testbench faults, not RTL faults: a test that overwrote its own data, queues not cleared between baud rates, missing plus-arguments, and a bus monitor that ignored reset. A flow that had allowed the testbench step to read the RTL would have been far more likely to hide those faults inside a “fix” to the design.

Hai quan sát từ lần chạy có nhiều thông tin hơn các con số hào nhoáng. Thứ nhất, 26 câu hỏi phát sinh trong luồng RTL đều về những thông tin mà đặc tả thật sự không có — danh sách cổng của các mô-đun nội bộ, ai sở hữu cờ halt, thứ tự ưu tiên giữa stall và redirect. Đó đúng là hình dạng của một khoảng trống đặc tả, và là thứ mà một review gate tồn tại để bắt. Thứ hai, cả sáu câu hỏi phát sinh trong mô phỏng đều được kết luận là lỗi testbench, không phải lỗi RTL: một test tự ghi đè dữ liệu của chính nó, queue không được xoá khi đổi baud, thiếu plus-argument, và một bus monitor bỏ qua reset. Một luồng cho phép bước testbench đọc RTL sẽ dễ dàng che các lỗi đó bằng một “bản sửa” vào thiết kế hơn nhiều.

V. Inside the Vector CPU — Bên trong CPU vector

Headline numbers hide the interesting question: what kind of hardware did the flows actually build? This section takes the generated design apart — system composition, scalar pipeline, vector datapath, the instruction sequence of one dot product, and finally the cost of one inference.

Những con số hào nhoáng che đi câu hỏi đáng quan tâm: các luồng thực sự đã dựng nên loại phần cứng nào? Mục này phân tích chi tiết thiết kế được sinh ra — thành phần hệ thống, pipeline vô hướng, datapath vector, chuỗi lệnh của một phép dot product, và cuối cùng là chi phí của một lần suy luận.

A. System composition. The top level (Fig. 7) holds one clock, i_clk_core, and one asynchronous reset, i_rst_n_core, and no clock-domain crossing at all. Around the core sit two memories and a bus: 32 KB of instruction memory at 0x0000_0000 with a one-cycle read, 256 KB of data memory at 0x1000_0000 with 16-byte alignment, and a 4 KB MMIO window at 0x2000_0000 that contains an APB4 register block and a UART. A host port writes both memories while the core is held in reset, which is how a testbench or a PC loads a program without a boot loader. A data access to the instruction-memory range is treated as unmapped: reads return zero and writes are ignored, rather than trapping.

A. Thành phần hệ thống. Cấp top (Hình 7) có một xung nhịp i_clk_core và một reset bất đồng bộ i_rst_n_core, không có bất kỳ đường CDC nào. Quanh lõi là hai bộ nhớ và một bus: 32 KB bộ nhớ lệnh tại 0x0000_0000 đọc trong một chu kỳ, 256 KB bộ nhớ dữ liệu tại 0x1000_0000 căn 16 byte, và cửa sổ MMIO 4 KB tại 0x2000_0000 chứa khối thanh ghi APB4 và một UART. Một cổng nạp từ host ghi được cả hai bộ nhớ khi lõi đang bị giữ reset, đó là cách testbench hoặc PC nạp chương trình mà không cần boot loader. Truy cập dữ liệu vào vùng bộ nhớ lệnh được coi là không ánh xạ: đọc trả 0 và ghi bị bỏ qua, thay vì trap.

Fig. 7. The generated SoC. A five-stage scalar core, a 128-bit vector unit, two memories, an APB4 register block, a UART and a host load port — one clock domain, no CDC.
Hình 7. SoC được sinh ra. Lõi vô hướng 5 tầng, khối vector 128-bit, hai bộ nhớ, khối thanh ghi APB4, UART và cổng nạp từ host — một miền xung nhịp, không có CDC.

The register block is worth a comment because it was not written by the model: it was generated by the CSR generator from a register description, and the generator’s output is what the RTL flow integrates. Six registers cover the whole software contract — ctrl (start), sts (busy, done, sticky error), result (the predicted digit), cycles (the vector-unit cycle count, read-only), uart_tx (data, send, busy) and uart_cfg (baud divisor, reset value 0x06C8). Only full 32-bit aligned writes are accepted; a partial write raises PSLVERR, which sets the sticky error bit in sts.

Khối thanh ghi đáng một lời bình vì nó không do mô hình viết: nó được CSR generator sinh từ một mô tả thanh ghi, và đầu ra của generator chính là thứ luồng RTL tích hợp vào. Sáu thanh ghi phủ toàn bộ hợp đồng phần mềm — ctrl (start), sts (busy, done, cờ lỗi sticky), result (chữ số dự đoán), cycles (số chu kỳ khối vector, chỉ đọc), uart_tx (data, send, busy) và uart_cfg (hệ số chia baud, giá trị reset 0x06C8). Chỉ chấp nhận ghi 32-bit đầy đủ và căn lề; ghi một phần phát sinh PSLVERR, đặt cờ lỗi sticky trong sts.

B. The scalar pipeline. The core is an in-order RV32I machine with the Zmmul multiply extension and no division, no traps, no interrupts and no privilege levels (Fig. 8). Five stages carry one instruction per cycle when nothing goes wrong. Three mechanisms keep it correct: forwarding from the EX/MEM and MEM/WB registers plus a write-to-read bypass in the register file; a single bubble when a load is followed immediately by its user; and a flush of the two younger instructions when a branch is taken, decided in EX, which costs about two cycles.

B. Pipeline vô hướng. Lõi là bộ xử lý RV32I in-order, có extension nhân Zmmul và không có phép chia, không có trap, không có ngắt, không có mức đặc quyền (Hình 8). Pipeline năm tầng chạy một lệnh mỗi chu kỳ khi không có sự cố. Ba cơ chế giữ cho nó đúng: forwarding từ các thanh ghi pipeline EX/MEM và MEM/WB cộng bypass ghi-đọc trong register file; một bubble khi lệnh load được lệnh kế tiếp dùng ngay (load-use); và flush hai lệnh phía sau khi nhánh được rẽ, quyết định ở EX, tốn khoảng hai chu kỳ.

Fig. 8. The five-stage pipeline and its hazard unit. A running vector instruction stops the scalar pipe until done arrives; an illegal instruction or ebreak halts the core.
Hình 8. Pipeline 5 tầng và khối xử lý hazard. Một lệnh vector đang chạy sẽ chặn pipeline vô hướng tới khi done đến; lệnh không hợp lệ hoặc ebreak làm lõi dừng.

Two details show that the flow respected its own rules rather than producing plausible-looking code. The core has no trap machinery at all: an illegal instruction asserts o_halt and o_err_illegal, and the system stops — a deliberate simplification recorded in the specification, not an oversight. And a wrong-path instruction that is flushed before it commits has no effect even if it is illegal, which is the kind of corner that a model writing a pipeline from a one-paragraph intent would normally get wrong. The testbench that checks it was written from the requirement, not from this paragraph.

Hai chi tiết cho thấy luồng tuân thủ đúng luật của chính nó thay vì sinh code trông có vẻ hợp lý. Lõi hoàn toàn không có cơ chế trap: lệnh không hợp lệ bật o_halt và o_err_illegal, hệ thống dừng — một đơn giản hoá có chủ ý được ghi trong đặc tả, không phải sơ suất. Và một lệnh sai nhánh bị flush trước khi commit không có tác dụng gì kể cả khi nó không hợp lệ, đúng loại corner case mà một mô hình viết pipeline từ một đoạn ý tưởng thường làm sai. Testbench kiểm điều đó được viết từ yêu cầu, không từ đoạn văn này.

C. The vector unit. m_vpu_top is a 128-bit vector unit with four 32-bit lanes and 32 architectural vector registers (Fig. 9). Element width can be 8, 16 or 32 bits; register grouping is fixed at LMUL = 1, so at SEW = 8 one register holds 16 elements and VLMAX = 16. A six-state sequencer (idle, decode, read, execute, write back, done) issues one instruction at a time, so every vector instruction costs at least five cycles and there is no overlap between instructions.

C. Khối vector. m_vpu_top là khối vector 128-bit với bốn lane 32-bit và 32 thanh ghi vector kiến trúc (Hình 9). Độ rộng phần tử có thể là 8, 16 hoặc 32 bit; register grouping cố định LMUL = 1, nên ở SEW = 8 một thanh ghi chứa 16 phần tử và VLMAX = 16. Một sequencer sáu trạng thái (idle, decode, read, execute, write back, done) phát một lệnh mỗi lần, nên mỗi lệnh vector tốn ít nhất năm chu kỳ và không có chồng lấn giữa các lệnh.

Fig. 9. Vector unit: decode and sequencer on the left, the register file and four lanes in the middle, the reduction tree below them, and a single 128-bit memory port. Every lane has an ALU, a multiplier and a narrowing unit.
Hình 9. Khối vector: decode và sequencer bên trái, register file và bốn lane ở giữa, reduction tree bên dưới, và một cổng bộ nhớ 128-bit. Mỗi lane có ALU, bộ nhân và khối narrowing.

The implemented instruction subset is small and deliberately chosen for INT8 dot products: configuration (vsetvli, vsetivli), unit-stride loads and stores (vle8.v, vle32.v, vse8.v, vse32.v), arithmetic (vadd.vv, vadd.vx, vsra.vi, vsra.vx, vmax.vx), widening multiply and reduction (vwmul.vv, vwredsum.vs), narrowing with rounding and saturation (vnclip.wi, vnclip.wx), and three moves (vmv.v.x, vmv.s.x, vmv.x.s). Everything else — masks, strided and indexed accesses, gathers and scatters, floating point, LMUL > 1, 16-bit memory operations — is illegal and halts the core, which is exactly what the specification says.

Tập lệnh được triển khai nhỏ và được chọn có chủ đích cho dot product INT8: cấu hình (vsetvli, vsetivli), load/store unit-stride (vle8.v, vle32.v, vse8.v, vse32.v), số học (vadd.vv, vadd.vx, vsra.vi, vsra.vx, vmax.vx), nhân widening và reduction (vwmul.vv, vwredsum.vs), narrowing có làm tròn và saturation (vnclip.wi, vnclip.wx), và ba lệnh chuyển (vmv.v.x, vmv.s.x, vmv.x.s). Mọi thứ khác — mask, truy cập strided/indexed, gather/scatter, dấu phẩy động, LMUL > 1, thao tác bộ nhớ 16-bit — là không hợp lệ và làm dừng lõi, đúng như đặc tả quy định.

D. One dot product, instruction by instruction. The listing below is the inner loop of one neuron of the first layer, or 784 pixels against 784 weights. It is where the vector unit earns its area:

D. Một phép dot product, từng lệnh một. Đoạn dưới là vòng lặp trong của một nơ-ron ở layer đầu tiên, tức 784 điểm ảnh nhân với 784 trọng số. Đây là nơi khối vector xứng đáng với diện tích của nó:

        vsetivli t0, 1, e32, m1     # one 32-bit element for the accumulator
        vmv.s.x  v8, x0            # accumulator v8[0] = 0
        addi     t1, x0, 49        # 784 / 16 = 49 passes
loop:   vsetivli t0, 16, e8, m1    # vl = 16 bytes, SEW = 8, LMUL = 1
        vle8.v   v1, (a1)          # 16 pixels
        vle8.v   v2, (a2)          # 16 weights
        vwmul.vv v4, v1, v2        # 16 products, 16-bit results in v4/v5
        vwredsum.vs v8, v4, v8     # v8[0] += sum of the 16 products (32-bit)
        addi     a1, a1, 16
        addi     a2, a2, 16
        addi     t1, t1, -1
        bne      t1, x0, loop
        vmv.x.s  t2, v8            # t2 = 32-bit sum
        add      t2, t2, a3         # + bias

Three design decisions are visible in nine instructions. The products are widened to 16 bits, because INT8 × INT8 does not fit in eight bits: the multiplier writes an even/odd register pair and the case −128 × −128 = 16,384 is handled correctly. The reduction accumulates in 32 bits, because a sum of 784 products exceeds 16 bits. And the result is narrowed back with vnclip, which shifts with round-to-nearest and saturates — two steps, 32 → 16 → 8 — rather than truncating. ReLU is a single vmax.vx against x0.

Ba quyết định thiết kế hiện ra trong chín lệnh. Các tích được mở rộng (widen) lên 16 bit, vì INT8 × INT8 không vừa tám bit: bộ nhân ghi vào một cặp thanh ghi chẵn/lẻ và trường hợp −128 × −128 = 16.384 được xử lý đúng. Phép rút gọn tích luỹ trong 32 bit, vì tổng của 784 tích vượt 16 bit. Và kết quả được thu hẹp lại bằng vnclip, lệnh này dịch với làm tròn tới gần nhất và saturation — hai bước 32 → 16 → 8 — thay vì cắt cụt. ReLU chỉ là một lệnh vmax.vx so với x0.

E. What one inference costs. The firmware runs a 784–128–10 multilayer perceptron with ReLU on a 28×28 greyscale image (Fig. 10). Layer one needs 128 neurons × 49 passes = 6,272 vector instructions; layer two needs 10 × 8 = 80. Weights occupy 100,352 bytes and 1,280 bytes respectively, well inside the 256 KB data memory; the quantization is symmetric with one scale per tensor and a power-of-two scale, so requantization is a shift. The worst of 100 images takes 252,418 cycles, which at 200 MHz is 1.26 ms, or roughly 790 images per second — a number the flow reads back from the cycles register rather than estimating.

E. Một lần suy luận tốn bao nhiêu. Firmware chạy một perceptron nhiều lớp (MLP) 784–128–10 với ReLU trên ảnh xám 28×28 (Hình 10). Layer 1 cần 128 nơ-ron × 49 lượt = 6.272 lệnh vector; layer 2 cần 10 × 8 = 80. Trọng số chiếm lần lượt 100.352 byte và 1.280 byte, thừa chỗ trong bộ nhớ dữ liệu 256 KB; lượng tử hoá đối xứng với một scale cho mỗi tensor và scale là luỹ thừa của 2, nên tái lượng tử hoá chỉ là một phép dịch. Trường hợp xấu nhất trong 100 ảnh tốn 252.418 chu kỳ, ở 200 MHz là 1,26 ms, tức khoảng 790 ảnh mỗi giây — con số luồng đọc lại từ thanh ghi cycles chứ không ước lượng.

Fig. 10. What the firmware does: two dot-product layers on the vector unit, an argmax on the scalar core, and the memory layout that holds the weights, the image and the activations.
Hình 10. Việc firmware làm: hai layer dot product trên khối vector, một phép argmax trên lõi vô hướng, và bố cục bộ nhớ chứa trọng số, ảnh và activation.

F. Where the RTL departs from the standard. One deliberate deviation is documented rather than hidden: vwredsum.vs reads 16-bit source elements while SEW = 8, whereas the RISC-V specification defines the source width as SEW. The firmware used to cross-check against Spike therefore issues two standard 16-bit reductions, and the results agree bit for bit. Addresses are treated as 16-byte aligned (the low four bits are ignored) instead of trapping on misalignment, and tail elements beyond vl are left unchanged. These are the kind of choices an engineer would make in a small block — the point is that the flow recorded them, the specification states them, and the verification checks the behaviour the specification states, not an idealised ISA.

F. Chỗ RTL khác chuẩn. Một sai lệch có chủ ý được ghi lại chứ không giấu đi: vwredsum.vs đọc phần tử nguồn 16-bit trong khi SEW = 8, trong khi đặc tả RISC-V định nghĩa độ rộng nguồn bằng SEW. Vì thế firmware dùng để đối chiếu với Spike phát hai phép rút gọn 16-bit chuẩn, và kết quả khớp từng bit. Địa chỉ được coi là căn 16 byte (bốn bit thấp bị bỏ qua) thay vì trap khi lệch căn, và các tail element vượt vl được giữ nguyên. Đó là kiểu lựa chọn một kỹ sư sẽ làm trong một khối nhỏ — điểm cần nói là luồng đã ghi lại chúng, đặc tả nêu rõ chúng, và kiểm chứng kiểm đúng hành vi mà đặc tả nêu, không phải một ISA lý tưởng.

VI. Discussion — Thảo luận

Three design choices carried most of the value in this study. Requirements as the unit of traceability: because every artifact cites REQ-NNN identifiers, a patch can be scoped to the requirements that changed, and a checker can say which requirement it failed. A hard boundary between deterministic and generative work: the model writes, explains and repairs, while tools and code decide, which is what makes a claim such as “the RTL is lint-clean” a tool exit status rather than a sentence in a report. Isolation enforced below the prompt: denying directories in a tool hook converts a convention into a property of the runtime.

Ba lựa chọn thiết kế mang phần lớn giá trị trong nghiên cứu này. Yêu cầu là đơn vị truy vết: vì mọi artifact đều dẫn REQ-NNN, patch có thể giới hạn đúng các yêu cầu đã đổi, và checker có thể chỉ ra nó fail ở yêu cầu nào. Ranh giới cứng giữa phần xác định (deterministic) và phần sinh (generative): mô hình viết, giải thích và sửa; công cụ và code quyết — đó là điều khiến một câu như “RTL lint-clean” trở thành exit status của công cụ chứ không phải một câu trong báo cáo. Cô lập được áp đặt (enforce) bên dưới prompt: chặn thư mục trong hook công cụ biến một quy ước thành một thuộc tính của runtime.

What the study cannot show is equally clear. One design is not a benchmark; the block is small by industrial standards; the tool set is commercial and site-specific; and the engine does not yet address formal verification or the upgrade of existing RTL.

Điều nghiên cứu không thể chứng minh cũng rõ ràng không kém. Một thiết kế không phải một benchmark; khối này nhỏ theo chuẩn công nghiệp; bộ công cụ là thương mại và riêng theo site; và engine chưa xử lý kiểm chứng formal hay nâng cấp RTL sẵn có.

VII. Conclusion: Strengths, Weaknesses, and Required Improvements — Kết luận

A. Strengths.

1. Auditability. Every artifact carries requirement identifiers, and every compliance claim is a tool result. The chain from intent to netlist can be read file by file, step by step.
2. Predictable control flow. Flows are data and steps run in a computed dependency order; no model decides what happens next, so a run is reproducible and inspectable.
3. Controlled cost of change. Snapshots, diffs and scoped patches mean a one-requirement edit does not re-derive approved text; stage results are cached across interruptions.
4. Verification independence by construction. The hook-enforced boundary turned all six simulation failures into testbench bugs instead of silent “fixes” to the RTL.
5. Vendor neutrality. Tools are roles with command templates and log parsers, and a missing role is reported N/A rather than passed.
6. Non-trivial output. 38 modules and 7,306 lines with clean lint, 59/59 tests and a 218 MHz post-synthesis estimate is a real block, not a toy adder.

A. Ưu điểm.

1. Khả năng audit. Mọi artifact mang định danh yêu cầu, và mọi tuyên bố tuân thủ là kết quả công cụ. Chuỗi từ ý tưởng tới netlist đọc được theo từng tệp, từng bước.
2. Luồng điều khiển dự đoán được. Luồng là dữ liệu và các bước chạy theo thứ tự phụ thuộc do engine tính; không mô hình nào quyết bước tiếp theo, nên một lần chạy tái lập và kiểm tra được.
3. Chi phí thay đổi có kiểm soát. Snapshot, diff và patch có phạm vi nghĩa là sửa một yêu cầu không suy diễn lại văn bản đã duyệt; kết quả stage được cache qua gián đoạn.
4. Kiểm chứng độc lập theo thiết kế. Ranh giới do hook thực thi đã biến cả sáu lỗi mô phỏng thành lỗi testbench thay vì những “bản sửa” âm thầm vào RTL.
5. Trung lập với nhà cung cấp (vendor neutrality). Công cụ là vai trò với command template và log parser; vai trò thiếu được báo N/A chứ không phải pass.
6. Đầu ra không tầm thường. 38 mô-đun và 7.306 dòng với lint sạch, 59/59 test và ước lượng 218 MHz sau tổng hợp là một khối thật, không phải bộ cộng đồ chơi.

B. Weaknesses.

1. No human review in the evidence. Every gate ran in auto_answer and every question took its default, so the study measures the engine, not the engine plus an engineer.
2. The correctness claim is narrower than it sounds. Weights and images are synthetic: 59/59 means bit-exact agreement with the golden model, not recognition accuracy.
3. Implementation evidence stops at synthesis. No place-and-route, no hold-slack judgement, nothing on a board; ASIC synthesis was not run at all, so there are no standard-cell area or power numbers.
4. Scope gaps. No formal property checking, no DFT, no power intent (UPF), no physical design; the UVM path only covers AXI-style memory-mapped IP; existing RTL cannot be upgraded.
5. Reproduction depends on commercial tools. VCS, Design Compiler, VC Static and Quartus are required for the reported results, and the tool configuration is site-specific.
6. Operations are immature. Windows does not run end to end, cost accounting is only reliable for the primary model provider, and no token or dollar figure is published for the run.

B. Nhược điểm.

1. Không có người review trong bằng chứng. Mọi gate chạy auto_answer và mọi câu hỏi lấy mặc định, nên nghiên cứu đo engine, không đo engine cộng kỹ sư.
2. Tuyên bố về tính đúng đắn hẹp hơn vẻ ngoài. Trọng số và ảnh là dữ liệu giả: 59/59 nghĩa là khớp bit-exact với golden model, không phải độ chính xác nhận dạng.
3. Bằng chứng triển khai (implementation) dừng ở tổng hợp. Không place-and-route, không xét hold slack, không chạy trên board; tổng hợp ASIC không được chạy, nên không có số diện tích hay công suất thư viện standard-cell.
4. Khoảng trống phạm vi. Không kiểm chứng formal, không DFT, không power intent (UPF), không physical design; nhánh UVM chỉ phủ IP memory-mapped kiểu AXI; không nâng cấp được RTL sẵn có.
5. Tái lập phụ thuộc công cụ thương mại. VCS, Design Compiler, VC Static và Quartus là bắt buộc cho các kết quả báo cáo, và cấu hình công cụ riêng theo site.
6. Vận hành chưa trưởng thành. Windows chưa chạy end-to-end, việc theo dõi chi phí chỉ đáng tin với nhà cung cấp mô hình chính, và không có con số token hay đô-la nào được công bố cho lần chạy.

C. Required improvements. Each weakness maps to a next step, in the order that unblocks the others.

1. Real reviewers at the gates. Repeat the study with human gates and log every rejection. Success: reviewed gate decisions and a defect-escape count.
2. Real data. Train and export real MNIST weights; report measured accuracy as well as bit-exactness.
3. Implementation to silicon. Close timing through place-and-route, then run the ASIC flow against a real library. Success: post-route WNS/WHS, area, power, on-board measurement.
4. Formal and coverage closure. Add assertion and property checking to the DV flow, with coverage-driven exit criteria.
5. DFT, UPF and physical design. Add scan/MBIST, power intent and PD handoff steps to the chain. Success: ATPG coverage, UPF checks, DRC/LVS-clean handoff.
6. Cost and platform maturity. Publish tokens and dollars per flow, enforce budgets, finish Windows parity.
7. A benchmark, not an anecdote. Run five to ten blocks of different types through the same flows and gates. Success: pass rate and effort per block class.

C. Cần cải thiện. Mỗi nhược điểm ánh xạ thành một bước kế tiếp, theo thứ tự mở khoá các bước khác.

1. Người review thật tại các gate. Lặp lại nghiên cứu với gate human và ghi lại mọi lần từ chối. Tiêu chí: quyết định gate có người review và số lỗi thoát.
2. Dữ liệu thật. Huấn luyện và xuất trọng số MNIST thật; báo cáo độ chính xác đo được cùng với bit-exact.
3. Triển khai tới silicon. Đóng timing qua place-and-route, rồi chạy luồng ASIC với thư viện thật. Tiêu chí: WNS/WHS sau route, diện tích, công suất, đo trên board.
4. Formal và đóng coverage. Thêm kiểm tra assertion và property vào luồng DV, với tiêu chí thoát theo coverage.
5. DFT, UPF và physical design. Thêm các bước scan/MBIST, power intent và bàn giao PD vào chuỗi. Tiêu chí: coverage ATPG, kiểm tra UPF, bàn giao DRC/LVS-clean.
6. Chi phí và độ trưởng thành của nền tảng. Công bố token và đô-la theo từng luồng, áp ngân sách, hoàn tất tương thích Windows.
7. Một benchmark, không phải giai thoại. Chạy năm đến mười khối khác loại qua cùng luồng và gate. Tiêu chí: tỉ lệ pass và công sức theo từng lớp khối.

D. Closing remark. Design automation is usually judged by whether it can produce working RTL. This article argues that the more useful question is whether the process can account for the RTL it produces: which requirement each line serves, which tool proved which property, which decision a human approved, and what a change costs. Q3TUI is an implementation of that position — flows as data, steps as a dependency graph, stages as the only place a model may speak, gates as the place a human does. The reported run — 87 requirements, 38 modules, 59 passing tests, 8,690 ALMs and 218 MHz estimated F_max from a single intent document — is a first data point rather than a benchmark. The work that remains is not more autonomy; it is evidence: real reviewers, real weights, real silicon numbers, and a set of designs large enough to say something statistical.

D. Lời kết. Tự động hoá thiết kế thường được đánh giá bằng việc nó có tạo ra RTL chạy được hay không. Bài này cho rằng câu hỏi hữu ích hơn là quy trình có giải trình được cho RTL nó tạo ra hay không: mỗi dòng phục vụ yêu cầu nào, công cụ nào chứng minh tính chất nào, quyết định nào do con người duyệt, và một thay đổi tốn bao nhiêu. Q3TUI là một triển khai của quan điểm đó — luồng là dữ liệu, bước là đồ thị phụ thuộc, stage là nơi duy nhất mô hình được lên tiếng, gate là nơi con người lên tiếng. Lần chạy được báo cáo — 87 yêu cầu, 38 mô-đun, 59 test pass, 8.690 ALM và F_max ước tính 218 MHz từ một tài liệu ý tưởng — là điểm dữ liệu đầu tiên chứ chưa phải benchmark. Việc còn lại không phải thêm tự chủ, mà là bằng chứng: người review thật, trọng số thật, con số silicon thật, và một tập thiết kế đủ lớn để nói được điều gì đó mang tính thống kê.

Authors and Roles — Tác giả và vai trò

All authors are members of VLSI Technology. Roles follow the team page at nguyenquanicd.blogspot.com/p/about.html. / Tất cả tác giả là thành viên VLSI Technology; vai trò theo trang thành viên nêu trên.

• Lương Triển Thắng — IC design engineer: multimedia IPs, AI flow / kỹ sư thiết kế vi mạch: IP đa phương tiện, luồng AI
• Lê Trường Thịnh — IC design engineer: peripheral IPs, AI flow / kỹ sư thiết kế vi mạch: IP ngoại vi, luồng AI
• Nguyễn Bính Khiêm — IC design engineer: IP design, AI flow / kỹ sư thiết kế vi mạch: thiết kế IP, luồng AI
• Lê Đại Quốc — AI flow engineer / kỹ sư luồng AI
• Đào Phước Tài — design verification engineer / kỹ sư kiểm chứng thiết kế
• Huỳnh Lê Anh Bảo — design verification engineer / kỹ sư kiểm chứng thiết kế
• Nguyễn Đắc Tâm — IC design engineer: system IPs / kỹ sư thiết kế vi mạch: IP hệ thống
• Lưu Sinh Nhật Sư — IC design engineer: NPU IP / kỹ sư thiết kế vi mạch: IP NPU

Reproducibility / Tái lập. Both repositories are public under Apache-2.0. The tool installs with uv and runs against the user’s own EDA tools, configured by role.
Cả hai kho đều công khai theo Apache-2.0. Công cụ cài bằng uv và chạy với bộ EDA của chính người dùng, cấu hình theo vai trò.

curl -fsSL https://raw.githubusercontent.com/nguyenquanicd/VLSIT_Q3TUI_ASIC_AI_FLOW/main/install.sh | bash
q3tui --version
q3tui tools init        # map tool roles to your site's tools
q3tui auto              # run the default chain unattended

Engine: VLSIT_Q3TUI_ASIC_AI_FLOW · Generated examples: VLSIT_Q3EX_ASIC_AI_FLOW

References — Tài liệu tham khảo

1. VLSI Technology, “Q3TUI — AI ASIC design flow: terminal UI and CLI,” GitHub repository, 2026. [Online]. Available: https://github.com/nguyenquanicd/VLSIT_Q3TUI_ASIC_AI_FLOW
2. VLSI Technology, “VLSIT_Q3EX_ASIC_AI_FLOW: example designs generated by the Q3TUI and Q3CORE flow,” GitHub repository, 2026. [Online]. Available: https://github.com/nguyenquanicd/VLSIT_Q3EX_ASIC_AI_FLOW
3. VLSI Technology, “Q3TUI Product Description — System Architecture and Main Flows,” Technical Report v1.0, Nov. 2026.
4. RISC-V International, “The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA” (RV32I, Zmmul, Zve32x), 2024.
5. IEEE Std 1800-2023, IEEE Standard for SystemVerilog — Unified Hardware Design, Specification, and Verification Language, IEEE, 2023.
6. Arm Ltd., “AMBA APB Protocol Specification,” ARM IHI 0024, 2021.
7. Chips Alliance and Antmicro, “Verible: SystemVerilog parsing, linting and formatting tools,” 2025. [Online]. Available: https://github.com/chipsalliance/verible
8. Verilator authors, “Verilator: open-source SystemVerilog simulator and lint tool,” 2025. [Online]. Available: https://verilator.org
9. Anthropic, “Claude Agent SDK documentation,” 2026. [Online]. Available: https://code.claude.com/docs/en/agent-sdk

Cite this article / Trích dẫn bài này: VLSI Technology, “From One Paragraph of Intent to a Checked RISC-V SoC: A Gated, Deterministic-First Flow Engine for ASIC Design,” technical article, Nov. 2026.

Đọc thêm

[Phần 1] ừ một đoạn ý tưởng đến SoC RISC-V đã kiểm chứng: flow engine thiết kế ASIC có review gate, ưu tiên xác định

VLSI Technology with AI

[Part 1] From One Paragraph of Intent to a Checked RISC-V SoC: A Gated, Deterministic-First Flow Engine for ASIC Design

Từ một đoạn ý tưởng đến SoC RISC-V đã kiểm chứng: flow engine thiết kế ASIC có review gate, ưu tiên xác định (deterministic-first)

VLSI Technology — Q3TUI ASIC AI Design Flow

Lương Triển Thắng · Lê Trường Thịnh · Nguyễn Bính Khiêm · Lê Đại Quốc
Đào Phước Tài · Huỳnh Lê Anh Bảo · Nguyễn Đắc Tâm · Lưu Sinh Nhật Sư

Technical report, November 2026 · Software described: Q3TUI 0.1.0 (Beta), Apache-2.0
Báo cáo kỹ thuật, tháng 11/2026 · Phần mềm: Q3TUI 0.1.0 (Beta), Apache-2.0

Abstract—Large language models can write register-transfer-level (RTL) code, but a free-running model is a poor design tool: its output is hard to audit, a single requirement change forces a rerun that discards approved work, and a testbench written by the same model that wrote the design does not verify it. Q3TUI answers with a flow engine rather than an agent swarm. Work is organised as flows defined in data files: each flow is a dependency graph of steps, each step is a pipeline of stages of three kinds — deterministic code (D), one bounded LLM call (L) and an EDA tool run (T) — and each decision point is a gate whose mode says who decides. Coordination is code, not conversation: no agent delegates to another agent, and the model never has the final word on compliance. Numbered requirements are the backbone of every artifact; verification is written from the specification without visibility of the RTL; and a change propagates as a scoped patch instead of a rerun. An end-to-end case study is dissected: from a 615-line intent document, the flow produced a 21-section specification with 87 requirements, a 38-module (7,306-line) RV32I processor with a 128-bit vector unit, 59 of 59 executed tests passing, and an Intel Arria 10 synthesis result of 8,690 ALMs, 10 DSP blocks and an estimated F_max of 218 MHz against a 200 MHz target. Ten figures document the method and the generated hardware. The conclusion states what the approach does well, where it fails today, and what must be improved before it is used on a production block.

Tóm tắt

Các mô hình ngôn ngữ lớn có thể viết code ở mức chuyển thanh ghi (RTL), nhưng một mô hình chạy tự do là công cụ thiết kế kém: đầu ra khó audit, chỉ một thay đổi yêu cầu là buộc phải chạy lại toàn bộ và loại bỏ phần đã được duyệt, và một testbench do chính mô hình viết ra thiết kế thì không kiểm chứng được thiết kế đó. Q3TUI giải quyết bằng một flow engine chứ không phải một swarm agent. Công việc được tổ chức thành các luồng khai báo trong tệp dữ liệu: mỗi luồng là một đồ thị phụ thuộc của các bước, mỗi bước là một chuỗi stage thuộc ba loại — code xác định (D), một lần gọi LLM có giới hạn (L) và một lần chạy công cụ EDA (T) — và mỗi điểm quyết định là một gate với mode nói rõ ai quyết. Điều phối là code, không phải hội thoại: không agent nào ủy quyền cho agent khác, và mô hình không bao giờ có quyền quyết định cuối cùng về việc tuân thủ. Các yêu cầu được đánh số là xương sống của mọi artifact; kiểm chứng được viết từ đặc tả mà không nhìn thấy RTL; và một thay đổi lan truyền dưới dạng patch có phạm vi thay vì chạy lại. Một nghiên cứu điển hình end-to-end được phân tích chi tiết: từ tài liệu ý tưởng 615 dòng, luồng đã sinh ra đặc tả 21 mục với 87 yêu cầu, một bộ xử lý RV32I 38 mô-đun (7.306 dòng) có khối vector 128-bit, 59/59 test được chạy đều pass, và kết quả tổng hợp trên Intel Arria 10: 8.690 ALM, 10 khối DSP, F_max ước tính 218 MHz so với mục tiêu 200 MHz. Mười hình minh hoạ phương pháp và phần cứng sinh ra. Phần kết luận nêu rõ cách tiếp cận làm tốt điều gì, đang thất bại ở đâu, và cần cải thiện gì trước khi dùng cho một khối ở mức sản xuất (production).

Index Terms—ASIC design flow, design automation, design verification, EDA tool integration, RISC-V, vector processing, design process, reproducibility.

Từ khoá—luồng thiết kế ASIC, tự động hoá thiết kế, kiểm chứng thiết kế, tích hợp công cụ EDA, RISC-V, xử lý vector, quy trình thiết kế, khả năng tái lập.

I. Introduction — Giới thiệu

Large language models now produce synthesizable SystemVerilog that compiles and, frequently, simulates correctly. What they do not do by themselves is behave like a design team. As soon as model-written RTL meets a real project, three failure modes appear.

The flow becomes a black box. A single prompt yields thousands of lines with no auditable boundary between what a model wrote, what a rule checker proved, and what a tool measured. When the block later fails lint, it is not obvious whether the code, the rule set, the tool invocation, or the model’s reading of the specification is at fault.

Every change costs a rerun. In a conventional generate-and-regenerate loop, editing one requirement invalidates the whole pipeline: reviewed text and approved decisions are thrown away and re-derived, at full token cost, with the risk that they differ.

Verification is not independent. A testbench derived from the same context as the RTL inherits the same misunderstanding. Correlated errors pass on both sides, which is the worst outcome a verification flow can produce.

Các mô hình ngôn ngữ lớn hiện đã sinh được SystemVerilog tổng hợp được, biên dịch được và thường mô phỏng đúng. Điều chúng không tự làm được là hành xử như một nhóm thiết kế. Ngay khi RTL do mô hình viết gặp một dự án thật, ba dạng lỗi (failure mode) xuất hiện.

Luồng trở thành hộp đen. Một prompt duy nhất sinh ra hàng nghìn dòng, không có ranh giới audit được giữa phần mô hình viết, phần rule checker chứng minh, và phần công cụ đo đạc. Khi khối đó fail lint, không rõ lỗi nằm ở code, ở bộ luật, ở cách gọi công cụ, hay ở cách mô hình đọc đặc tả.

Mỗi thay đổi đều tốn một lần chạy lại. Trong vòng lặp sinh-rồi-sinh-lại thông thường, sửa một yêu cầu làm mất hiệu lực toàn bộ pipeline: văn bản đã duyệt và các quyết định đã chốt bị bỏ đi và suy diễn lại, tốn đủ chi phí token, kèm rủi ro là chúng sẽ khác đi.

Kiểm chứng không độc lập. Một testbench suy ra từ cùng ngữ cảnh với RTL thừa hưởng đúng hiểu nhầm đó. Lỗi tương quan cùng pass ở cả hai phía, và đó là kết cục tệ nhất mà một luồng kiểm chứng có thể tạo ra.

A common answer is to add more autonomy: give the model tools, let it plan, let it spawn helpers and let it decide when the design is done. That answer makes all three problems worse, because autonomy enlarges the part of the process that no one can inspect. Q3TUI takes the opposite route. It keeps the model inside a structure that code already understands — flows, steps, stages, gates — and lets the model act only at the points where language is genuinely needed.

Một câu trả lời phổ biến là tăng mức tự chủ: cho mô hình công cụ, để nó tự lập kế hoạch, tự sinh các agent phụ, và tự quyết khi nào thiết kế xong. Câu trả lời đó làm cả ba vấn đề tệ hơn, vì tự chủ mở rộng đúng phần quy trình mà không ai kiểm tra được. Q3TUI đi hướng ngược lại. Nó giữ mô hình bên trong một cấu trúc mà code đã hiểu — luồng, bước, stage, gate — và chỉ cho mô hình hành động tại những điểm thật sự cần ngôn ngữ.

The design follows five commitments, each of which maps to a mechanism in the implementation:

1. Coordination is code. A flow is a data file, its steps run in a dependency order that the engine computes, and no model schedules the work.
2. Review gates at every decision. A step that needs a human decision stops at a gate whose mode is human, auto, auto_answer or none.
3. Deterministic first. Parsing, rule checks, formatting, simulation and synthesis are code and tools. The model receives their output as ground truth and never has the final word on compliance.
4. Update, not rerun. A changed requirement updates only the artifacts it touches; approved content survives byte-for-byte.
5. Independent verification. The RTL stage cannot read the testbench and the testbench stage cannot read the RTL, enforced by tool hooks rather than by instructions in a prompt.

Thiết kế theo năm cam kết, mỗi cam kết ánh xạ vào một cơ chế trong phần triển khai:

1. Điều phối là code. Một luồng là tệp dữ liệu; các bước chạy theo thứ tự phụ thuộc do engine tính; không mô hình nào lên lịch công việc.
2. Review gate tại mọi quyết định. Bước cần quyết định của người sẽ dừng tại gate có chế độ human, auto, auto_answer hoặc none.
3. Xác định (deterministic) trước. Parse, kiểm tra luật, định dạng, mô phỏng và tổng hợp đều là code và công cụ. Mô hình nhận đầu ra của chúng như ground truth và không bao giờ có quyền quyết định cuối cùng về tuân thủ.
4. Cập nhật, không chạy lại. Yêu cầu thay đổi chỉ cập nhật những artifact bị ảnh hưởng; phần đã duyệt giữ nguyên từng byte.
5. Kiểm chứng độc lập. Stage RTL không đọc được testbench và stage testbench không đọc được RTL, được hook công cụ thực thi (enforce) chứ không phải bằng chỉ dẫn trong prompt.

The contribution of this article is therefore not “an LLM writes RTL”. It is a description of how a flow engine keeps model-written RTL accountable — requirements as identifiers, tool results as evidence, gates as control points — together with a case study that dissects the generated hardware down to the instruction level and reports its own limits.

Đóng góp của bài này vì thế không phải “LLM viết RTL”. Đó là mô tả cách một flow engine giữ cho RTL do mô hình viết vẫn audit được — yêu cầu là định danh, kết quả công cụ là bằng chứng, gate là điểm kiểm soát — cùng một nghiên cứu điển hình phân tích chi tiết phần cứng sinh ra tới mức từng lệnh và tự báo cáo giới hạn của chính nó.

II. Architecture: Flows, Steps, Stages, Gates — Kiến trúc

Q3TUI is a terminal UI, a command line and an in-application assistant over one flow engine (Fig. 1). Every user action — run, approve, answer, change, reset — goes through a single operation layer (core/ops.py), so the three interfaces cannot drift apart. The engine (pipeline/engine.py) owns the step graph, content-hash staleness, gates, the fix loop, question routing and the pipeline.json state file; it never hardcodes the steps of a flow — it asks the flow for them.

Q3TUI gồm một giao diện terminal, một dòng lệnh và một trợ lý trong ứng dụng, tất cả trên một flow engine (Hình 1). Mọi thao tác của người dùng — chạy, duyệt, trả lời, yêu cầu sửa, đặt lại — đều đi qua một lớp thao tác duy nhất (core/ops.py), nên ba giao diện không thể lệch nhau. Engine (pipeline/engine.py) sở hữu đồ thị bước, phát hiện stale theo hash nội dung, gate, vòng sửa lỗi, định tuyến câu hỏi và tệp trạng thái pipeline.json; nó không bao giờ viết cứng các bước của một luồng — nó hỏi luồng.

Fig. 1. Layered architecture. Three interfaces share one operation layer; the engine executes the flows; every step draws on exactly three kinds of resource — deterministic code, a bounded LLM call, and an EDA tool called by role.
Hình 1. Kiến trúc phân tầng. Ba giao diện dùng chung một lớp thao tác; engine thực thi các luồng; mỗi bước chỉ dùng đúng ba loại tài nguyên — code xác định, một lần gọi LLM có giới hạn, và một công cụ EDA gọi theo vai trò.

A. Concepts — Các khái niệm

Most confusion about AI-assisted design comes from blurring the terms below. They are defined here once and used with the same meaning for the rest of the article.

Phần lớn nhầm lẫn về thiết kế có AI đến từ việc trộn lẫn các thuật ngữ dưới đây. Chúng được định nghĩa một lần tại đây và dùng với cùng nghĩa trong toàn bài.

Table I. Core concepts — Bảng I. Các khái niệm cốt lõi

Concept / Khái niệm	Definition / Định nghĩa	Lives in / Nằm ở
Flow Luồng	A declaration of a process: which steps run, in what dependency order, with which gate, options, tool roles, and which earlier decisions each step may receive. Khai báo một quy trình: bước nào chạy, thứ tự phụ thuộc nào, gate nào, tuỳ chọn nào, vai trò công cụ nào, và mỗi bước được nhận những quyết định trước đó nào.	FLOW.md, .yaml hoặc một thư mục
Step Bước	One unit of work with declared inputs, outputs, optional options, optional pass conditions, one optional gate, and a run() method. Một đơn vị công việc với đầu vào/đầu ra khai báo, tuỳ chọn, điều kiện pass, một gate tuỳ chọn, và phương thức run().	lớp Python StepDef (steps/<kind>/step.py)
Stage Giai đoạn	The unit inside a step; exactly three kinds (D, L, T, Table II). A step is a short ordered sequence of stages. Đơn vị bên trong một bước; đúng ba loại (D, L, T, Bảng II). Một bước là chuỗi stage ngắn, có thứ tự.	llm/runtime.py: Stage, StepContext.llm()
Gate Review gate	A pause after a step for a decision, with a mode that names who decides (Table IV). Điểm dừng sau một bước để ra quyết định, kèm chế độ nói rõ ai quyết (Bảng IV).	GateRecord trong pipeline.json
Question Câu hỏi	A structured gap found by a step: 2–4 options, a proposed default, and the design impact of each option; routed to the step that owns the artifact. Một khoảng trống có cấu trúc do bước phát hiện: 2–4 phương án, mặc định đề xuất, và tác động thiết kế của từng phương án; được định tuyến về bước sở hữu artifact.	schemas/questions/, gap_targets
Change request Yêu cầu thay đổi	A scoped instruction to regenerate one part of an earlier step’s output, written [step:unit]. Chỉ thị có phạm vi để sinh lại một phần đầu ra của bước trước, viết dạng [step:unit].	steps/common.py
Unit Đơn vị	The smallest regenerable piece of an artifact: one RTL module, one test case, one specification section. Phần nhỏ nhất có thể sinh lại của một artifact: một mô-đun RTL, một test case, một mục đặc tả.	do bước định nghĩa
Run Lần chạy	One execution of a flow: everything missing or stale, in dependency order. Một lần thực thi một luồng: mọi thứ còn thiếu hoặc stale, theo thứ tự phụ thuộc.	q3tui run
Chain Chuỗi	Several flows run in sequence, each taking over the previous one’s artifacts. Nhiều luồng chạy nối tiếp, mỗi luồng tiếp nhận artifact của luồng trước.	pipeline.chain, core/chain.py

B. Symbols and notation — Ký hiệu

Every symbol used later in this article is listed here. Where a symbol is also a configuration key, the key is the symbol.

Mọi ký hiệu dùng về sau đều được liệt kê tại đây. Khi một ký hiệu đồng thời là khoá cấu hình thì khoá chính là ký hiệu đó.

Table II. Symbols and notation — Bảng II. Ký hiệu

Symbol / Ký hiệu	Meaning / Ý nghĩa
D / L / T	Deterministic code / one bounded LLM call / one EDA tool run — the only three stage kinds. Code xác định / một lần gọi LLM có giới hạn / một lần chạy công cụ EDA — đúng ba loại stage.
human, auto, auto_answer, none	Gate modes (Table IV). Bốn chế độ gate (Bảng IV).
[step:unit]	Scoped change request, e.g. [rtl:m_alu]; without a unit it applies to every unit of the step. Yêu cầu thay đổi có phạm vi, vd [rtl:m_alu]; không nêu đơn vị thì áp cho mọi đơn vị của bước.
[decision]	The change request created when a gap question is answered; it lands on the step that owns the question. Yêu cầu thay đổi sinh ra khi một câu hỏi khoảng trống được trả lời; nó rơi vào bước sở hữu câu hỏi.
pass:	A pass condition checked by code after the step finishes: exists <glob>, contains <file> <regex>, run <cmd> (exit 0). Điều kiện pass do code kiểm tra sau khi bước xong: exists, contains, run (exit code 0).
{top} {filelist} {workdir} …	Placeholders a tool command template receives from the runner: {top} {filelist} {files} {incdirs} {workdir} {project} plus step-specific ones. Các placeholder mà command template của công cụ nhận từ runner, cộng thêm các biến riêng của bước.
Assumption:	How a step records, inside its own output, the default it used for an open question. Cách một bước ghi lại, ngay trong đầu ra của nó, giá trị mặc định đã dùng cho câu hỏi còn mở.
(recommended)	Marks the proposed default among a question’s options in the picker. Đánh dấu phương án mặc định được đề xuất trong bộ chọn (picker).
N/A	A check whose tool role or capability is missing — reported as not evaluated, never as a pass. Kiểm tra thiếu vai trò công cụ hoặc thiếu capability — báo là chưa đánh giá (not evaluated), không bao giờ là pass.
kind	Step-type id mapped to a Python class by the registry (steps/__init__.py: KINDS). ID loại bước, được registry ánh xạ sang một lớp Python.
sees: / gap_targets:	Flow-file maps: which steps’ settled decisions a step may receive; which step owns each question kind. Bản đồ trong tệp luồng: bước nào được nhận quyết định đã chốt của bước nào; loại câu hỏi nào thuộc bước nào.
checks_version	Bumping it makes previously finished results stale even when their inputs did not change. Tăng số này làm kết quả đã xong trở thành stale, dù đầu vào không đổi.

C. Who executes what — Ai thực thi việc gì

The division below is the whole architecture in one table. Read the last column first: it is the list of things each layer is not allowed to do.

Bảng dưới đây là toàn bộ kiến trúc trong một bảng. Hãy đọc cột cuối trước: đó là danh sách những việc mỗi tầng không được phép làm.

Table III. Division of responsibility — Bảng III. Phân chia trách nhiệm

Component / Thành phần	Is / Là	Executes / decides — Thực thi / quyết	Cannot — Không được
Flow file Tệp luồng	data dữ liệu	Declares steps, order, gates, options, tool roles, question ownership. Khai báo bước, thứ tự, gate, tuỳ chọn, vai trò công cụ, quyền sở hữu câu hỏi.	Contain code, conditions or loops — it is not a scripting layer. Chứa code, điều kiện hay vòng lặp — nó không phải lớp script.
Engine pipeline/engine.py	code	Topological order, staleness, gates, fix loop, question routing, state. Thứ tự tô-pô, stale, gate, vòng sửa, định tuyến câu hỏi, trạng thái.	Hardcode a flow’s step names; edit the design itself. Viết cứng tên bước của luồng; sửa chính thiết kế.
Step StepDef.run()	code	The order of its D/L/T stages, its pass checks, dispatching change requests. Thứ tự các stage D/L/T, kiểm tra điều kiện pass, phát yêu cầu thay đổi.	Declare itself passed without its checks. Tự tuyên bố pass mà không qua kiểm tra.
Stage D	code	Parsing, hashing, formatting, rule checks, report writing. Parse, hash, định dạng, kiểm tra luật, ghi báo cáo.	Call a model. Gọi mô hình.
Stage L	model mô hình	Write, repair and summarise text and code, only inside its declared directories, tools and output schema. Viết, sửa và tóm tắt văn bản và code, chỉ trong thư mục, công cụ và schema đầu ra đã khai báo.	Choose the next step; read denied directories; run arbitrary commands; approve a gate; mark a check passed. Chọn bước kế tiếp; đọc thư mục bị cấm; chạy lệnh tuỳ ý; tự duyệt gate; đánh dấu kiểm tra là pass.
Stage T	tool công cụ	One role command, its log parsed into normalised diagnostics. Một lệnh theo vai trò, log được parse thành diagnostic chuẩn hoá.	Be skipped silently: a missing role is N/A, not a pass. Bị bỏ qua im lặng: thiếu vai trò là N/A, không phải pass.
Gate Review gate	human or code người hoặc code	Approve, answer, edit, request a change, or defer. Duyệt, trả lời, sửa, yêu cầu thay đổi, hoặc hoãn.	Approve past an open blocking question (unless forced). Duyệt qua một câu hỏi chặn còn mở (trừ khi dùng --force).
Question Câu hỏi	step → human bước → người	Propose 2–4 options with a default and the impact of each. Đề xuất 2–4 phương án kèm mặc định và tác động của từng phương án.	Be decided silently in the step that raised it. Bị quyết im lặng ngay trong bước đã nêu ra nó.

D. The scope of the model — Phạm vi của mô hình

An L stage is one call through a single entry point, run_stage(stage, cfg, emit) in llm/runtime.py, with permission_mode="dontAsk". Its freedom is the six fields of the Stage object, and nothing beyond them: builtin_tools (default Read, Grep, Glob; code-writing stages add Write/Edit), deny_dirs (never readable, and .q3tui/ is always denied), write_dirs/write_files (where writing is allowed), output_model (the JSON schema the answer must satisfy), and the limits max_turns, effort, timeout_s and max_budget_usd. A path guard (check_tool_paths) applies these rules to every tool call, and a stage that tries to leave its directory is refused rather than corrected.

Một stage L là một lần gọi qua đúng một entry point, run_stage(stage, cfg, emit) trong llm/runtime.py, với permission_mode="dontAsk". Tự do của nó nằm trong sáu trường của đối tượng Stage, và không gì ngoài sáu trường đó: builtin_tools (mặc định Read, Grep, Glob; stage viết code thêm Write/Edit), deny_dirs (không bao giờ đọc được, và .q3tui/ luôn bị cấm), write_dirs/write_files (nơi được ghi), output_model (schema JSON mà câu trả lời phải thoả), và các giới hạn max_turns, effort, timeout_s, max_budget_usd. Một path guard (check_tool_paths) áp các luật này cho mọi lần gọi công cụ, và một stage cố ra khỏi thư mục của mình sẽ bị từ chối chứ không được "sửa lại".

What the model produces is data. Code validates it, writes the file, and decides what happens next. Compliance is never a sentence in a report: “lint-clean” is a tool exit status, “test passed” is a simulator verdict, and “the step is done” is a pass: condition or a check function. This is the boundary that makes the rest of the flow auditable.

Thứ mô hình tạo ra là dữ liệu. Code kiểm tra nó, ghi tệp, và quyết điều gì xảy ra tiếp. Việc tuân thủ không bao giờ là một câu trong báo cáo: “lint-clean” là exit status của công cụ, “test pass” là verdict của simulator, và “bước đã xong” là một điều kiện pass: hoặc một hàm kiểm tra. Đây chính là ranh giới khiến phần còn lại của luồng audit được.

Fig. 2. Contract of one LLM stage: a declared allow-list enforced by a hook, a schema-validated result, and a code path — not the model — that writes the artifact.
Hình 2. Contract của một stage LLM: allow-list được hook thực thi (enforce), kết quả được kiểm tra theo schema, và chính code — không phải mô hình — ghi artifact ra đĩa.

E. “A flow is data” — “Luồng là dữ liệu” nghĩa là gì

The sentence is easy to misread, because “flow” normally names a running process. Here the object is split in two: the description of the process is a data file, and the executor of the process is fixed code. The fragment below is a complete, valid flow fragment; it contains no instruction that a machine could execute on its own:

Câu này dễ hiểu sai, vì “luồng” thường để chỉ một quy trình đang chạy. Ở đây đối tượng được tách làm hai: bản mô tả quy trình là một tệp dữ liệu, còn bộ thực thi (executor) quy trình là code cố định. Đoạn dưới là một đoạn luồng hợp lệ và trọn vẹn; nó không chứa chỉ thị nào mà máy có thể tự thực thi:

name: spec
gap_targets: {spec_gap: spec, req_gap: parse}
sees: {smoke: [spec, parse, config]}
tools: [lint, synth, sim]
steps:
  - {id: spec,  kind: spec,        gate: human}
  - {id: parse, kind: vlsit_parse, gate: human, deps: [spec]}

The engine reads it, orders the steps by deps, looks up each kind in the registry (steps/__init__.py: KINDS maps a kind to "module:Class"), instantiates the StepDef, runs it, checks its pass: conditions and applies its gate. Change the file and the process changes; the engine does not.

Engine đọc tệp, sắp các bước theo deps, tra từng kind trong registry (steps/__init__.py: KINDS ánh xạ kind sang "module:Class"), khởi tạo StepDef, chạy nó, kiểm các điều kiện pass: và áp gate. Đổi tệp thì quy trình đổi; engine thì không.

Two consequences matter for engineering practice. A process definition is reviewable and versionable text, so a flow change goes through the same review as code. And the same engine runs every flow, which is why the TUI, the CLI and the assistant behave identically whatever the flow is.

Hai hệ quả quan trọng với thực tiễn kỹ thuật. Định nghĩa quy trình là văn bản có thể review và quản lý phiên bản, nên một thay đổi luồng đi qua đúng quy trình review như code. Và cùng một engine chạy mọi luồng, nên TUI, CLI và trợ lý hành xử giống nhau bất kể luồng là gì.

The limit is equally important: a flow file is not a scripting layer. It cannot add behaviour, only compose registered step kinds. A genuinely new kind of work is a Python StepDef registered with register_kind() — which is exactly where the model’s calls, the tool roles and the checks for that new kind of work are written.

Giới hạn cũng quan trọng ngang vậy: tệp luồng không phải lớp script. Nó không thêm được hành vi, chỉ tổ hợp các loại bước đã đăng ký. Một loại công việc thật sự mới là một lớp Python StepDef đăng ký bằng register_kind() — và đó chính là nơi viết các lần gọi mô hình, vai trò công cụ và kiểm tra cho loại công việc mới đó.

F. Gates and who reviews — Gate và ai review

Every step may declare a gate; the mode decides who closes it. The four modes are not a severity scale but four different operating regimes, and the same flow files can be run under any of them.

Mỗi bước có thể khai báo một gate; chế độ quyết ai đóng gate đó. Bốn chế độ không phải thang mức độ nghiêm trọng mà là bốn chế độ vận hành khác nhau, và cùng những tệp luồng có thể chạy dưới bất kỳ chế độ nào.

Table IV. Gate modes — Bảng IV. Chế độ gate

Mode / Chế độ	Decided by / Ai quyết	Behaviour / Hành vi
human	a person người	Stops for review; the reviewer approves, answers, edits, requests changes or defers. Reviewable items must be confirmed first. Dừng để review; người review duyệt, trả lời, sửa, yêu cầu thay đổi hoặc hoãn. Các mục cần xác nhận phải được xác nhận trước.
auto	code	Approves itself when the step is done; an open blocking question still stops the run. Tự duyệt khi bước xong; một câu hỏi chặn còn mở vẫn dừng lần chạy.
auto_answer	code	Unattended: approves and takes every default, blocking questions included, bounded by the iteration budget. Không người: tự duyệt và lấy mọi giá trị mặc định, kể cả câu hỏi chặn, trong giới hạn số vòng lặp.
none	nobody không ai	No gate at all; a blocking question still stops the pipeline. Không có gate; câu hỏi chặn vẫn dừng pipeline.

Three rules keep this honest. A blocking question cannot be approved away — the gate refuses until it is answered (--force overrides, and says so). Reviewable items flagged by a step (a suspect requirement, a parameter choice) must be confirmed before a human gate closes. And a gate mode can be changed at any time (q3tui gate STEP MODE, the TUI’s gate key, or Settings → Gates), all through one operation, so switching a project from review-heavy to unattended is a configuration change, not a code change.

Ba luật giữ cho việc này trung thực. Một câu hỏi chặn không thể bị duyệt cho qua — gate từ chối cho tới khi được trả lời (--force ghi đè và sẽ nói rõ). Các mục cần xác nhận do bước gắn cờ (một yêu cầu đáng ngờ, một lựa chọn tham số) phải được xác nhận trước khi gate người đóng. Và chế độ gate đổi được bất cứ lúc nào (q3tui gate STEP MODE, phím gate trong TUI, hoặc Settings → Gates), tất cả qua một thao tác, nên chuyển một dự án từ nhiều review sang chạy unattended chỉ là đổi cấu hình, không phải đổi code.

III. The Chain, Change Requests and Updates — Chuỗi, yêu cầu thay đổi và cập nhật

Flows can be run one at a time — q3tui --flow rtl run — or in a chain. The default chain is spec → rtl → dv → sanity → fpga, at most three passes, with asic available in place of, or after, the FPGA flow (Fig. 3). Each flow is self-contained: the rtl and dv flows list spec, parse and config among their own steps, so running one alone reuses the artifacts that are already up to date instead of regenerating them.

Các luồng có thể chạy từng cái một — q3tui --flow rtl run — hoặc chạy theo chuỗi. Chuỗi mặc định là spec → rtl → dv → sanity → fpga, tối đa ba lượt, với asic dùng thay cho hoặc sau luồng FPGA (Hình 3). Mỗi luồng tự chứa đủ (self-contained): luồng rtl và dv liệt kê spec, parse, config trong chính các bước của mình, nên chạy riêng một luồng sẽ tái dùng những artifact đã cập nhật thay vì sinh lại.

Fig. 3. The default chain. Gates sit where a decision is needed; a flow that changes RTL causes every checking flow that passed with the old RTL to run again, in chain order.
Hình 3. Chuỗi mặc định. Gate nằm ở nơi cần quyết định; luồng nào làm thay đổi RTL sẽ khiến mọi luồng kiểm tra đã pass với RTL cũ phải chạy lại, theo đúng thứ tự chuỗi.

Table V. Built-in flows and the steps they run — Bảng V. Các luồng có sẵn

Flow / Luồng	Steps / Các bước (theo thứ tự phụ thuộc)	Product / Sản phẩm
spec default / mặc định	spec → parse → config	Reviewed specification, REQ-NNN requirements, parameters, module map. Đặc tả đã review, yêu cầu REQ-NNN, tham số, sơ đồ mô-đun.
rtl	spec → parse → config → rules → csr → rtl → format → style_lint → smoke	Synthesizable RTL, generated CSR block, formatted and rule-clean code, passing smoke test. RTL tổng hợp được, khối CSR sinh tự động, code đã định dạng và đạt kiểm tra luật, smoke test pass.
dv	spec → parse → config → testplan → tb → prepare → simulate	Verification contract, testbench written from the specification alone, simulation evidence and triage. Verification contract, testbench viết chỉ từ đặc tả, bằng chứng mô phỏng và triage lỗi.
sanity	sdc → setup → cdc → cdc_waivers → cdc_check → rdc → rdc_waivers → rdc_check	Every CDC/RDC violation classified as waiver, RTL fix, specification request or question; re-checked until none remain open. Mọi violation CDC/RDC được phân loại thành waiver, sửa RTL, yêu cầu đặc tả hoặc câu hỏi; kiểm tra lại tới khi không còn violation mở.
fpga	fpga_port → sdc → fpga_synth → timing_util_report → ppa_optimize	Out-of-context synthesis, utilisation and timing report, PPA estimate. Tổng hợp out-of-context, báo cáo tài nguyên và timing, ước lượng PPA.
asic	asic_port → sdc → asic_synth → asic_lec	Standard-cell netlist with area, timing and power reports; logic equivalence against RTL. Netlist standard-cell kèm báo cáo diện tích, timing, công suất; kiểm tra tương đương logic (LEC) với RTL.
project	project → tools → libraries → fpga	Site settings: tool roles, standard-cell libraries, target FPGA. Cấu hình site: vai trò công cụ, thư viện standard-cell, FPGA đích.

The first two flows carry most of the method (Fig. 4). The specification is written into an editable template, split into numbered requirements, and reduced to a locked configuration whose legality is checked by code. The RTL flow then loads the coding rules, generates the register block with a CSR generator, writes the modules, formats them, runs the rule checks and a smoke simulation — and sends every failure back to the step that owns it.

Hai luồng đầu mang phần lớn phương pháp (Hình 4). Đặc tả được viết vào một mẫu có thể sửa, tách thành các yêu cầu đánh số, rồi rút về một cấu hình khoá cứng mà tính hợp lệ do code kiểm tra. Luồng RTL sau đó nạp bộ luật coding, sinh khối thanh ghi bằng CSR generator, viết các mô-đun, định dạng, chạy kiểm tra luật và mô phỏng smoke — và gửi mọi lỗi về đúng bước sở hữu.

Fig. 4. The spec and RTL flows. Requirements and configuration are produced once and reused; the RTL flow adds generation, formatting, rule checking and a smoke test around them.
Hình 4. Luồng spec và RTL. Yêu cầu và cấu hình được tạo một lần rồi tái dùng; luồng RTL bọc thêm bước sinh code, định dạng, kiểm tra luật và smoke test.

Questions carry an owner. When the specification does not decide something, the step emits a structured question with two to four options, a proposed default, and the design impact of each option (area, speed, power, complexity). The flow’s gap_targets map routes each kind to the step that owns the artifact — a spec_gap to spec, a req_gap to parse, an arch_gap to config — and a design_choice stays with the step that raised it. Answering a gap question creates a [decision] change request on the owner, which updates before the run continues, so a later step never patches an earlier step’s output behind its back.

Câu hỏi luôn có chủ. Khi đặc tả không quyết một điều gì đó, bước phát ra một câu hỏi có cấu trúc với hai đến bốn phương án, một mặc định đề xuất, và tác động thiết kế của từng phương án (diện tích, tốc độ, công suất, độ phức tạp). Bản đồ gap_targets của luồng định tuyến từng loại về bước sở hữu artifact — spec_gap về spec, req_gap về parse, arch_gap về config — còn design_choice ở lại với bước đã nêu. Trả lời một câu hỏi khoảng trống tạo ra yêu cầu thay đổi [decision] trên bước sở hữu; bước đó cập nhật trước khi lần chạy tiếp tục, nên bước sau không bao giờ vá ngầm đầu ra của bước trước.

Change propagates as an update (Fig. 5). After each run a step records a snapshot of what it was built from: hashes of specification sections, requirements, parameters and answers. On the next run, code compares inputs with the snapshot. If nothing relevant changed, no model is called and existing approvals stay valid; otherwise the model receives the current artifact plus only the changed inputs and returns only the changed parts, which code applies as a patch. Decisions settled earlier are passed downstream — but only to the steps listed in the flow’s sees map, so a testbench step still cannot see the RTL.

Thay đổi lan truyền dưới dạng cập nhật (Hình 5). Sau mỗi lần chạy, bước ghi lại snapshot những gì nó được dựng từ đó: hash của các mục đặc tả, yêu cầu, tham số và câu trả lời. Ở lần chạy sau, code so sánh đầu vào với snapshot. Nếu không có gì liên quan thay đổi, không mô hình nào bị gọi và các phê duyệt cũ vẫn hiệu lực; ngược lại, mô hình nhận artifact hiện tại cộng đúng phần đầu vào đã đổi và trả về đúng phần cần đổi, code áp thành patch. Những quyết định đã chốt được truyền xuống — nhưng chỉ tới các bước có tên trong bản đồ sees của luồng, nên bước testbench vẫn không thấy RTL.

Fig. 5. Update, not rerun: a snapshot of inputs, a code-side diff, a patch limited to the changed parts, and approvals that survive the change.
Hình 5. Cập nhật, không chạy lại: snapshot đầu vào, phép diff phía code, patch giới hạn ở phần đã đổi, và các phê duyệt được giữ nguyên qua thay đổi.

A failing check produces a change request, not a complaint (Fig. 6). Triage decides which step owns the defect and sends a scoped request — [rtl:m_alu] … — that regenerates only the named unit. The loop repeats until the check passes, a gate pauses, a blocking question appears, the iteration budget is exhausted, or the same finding recurs often enough to be escalated to the user as a question.

Một lần kiểm tra fail sinh ra yêu cầu thay đổi, không phải lời phàn nàn (Hình 6). Bước triage quyết định lỗi thuộc bước nào rồi gửi một yêu cầu có phạm vi — [rtl:m_alu] … — chỉ sinh lại đúng đơn vị được nêu. Vòng lặp tiếp diễn cho tới khi kiểm tra pass, một gate dừng lại, một câu hỏi chặn xuất hiện, hết ngân sách vòng lặp, hoặc cùng một phát hiện lặp lại đủ nhiều để được đẩy lên thành câu hỏi cho người dùng.

Fig. 6. The fix loop. Ownership is decided by triage, the fix is scoped to one unit, and the check then re-runs — with a bounded number of iterations and escalation when a finding repeats.
Hình 6. Vòng sửa lỗi. Quyền sở hữu do triage quyết, bản sửa chỉ trong một đơn vị, rồi kiểm tra chạy lại — với số vòng có giới hạn và cơ chế escalate khi một phát hiện lặp lại.

Continued in Part 2 — IV. Case Study; V. Inside the Vector CPU; VI. Discussion; VII. Conclusion; Authors and Roles; References.

Xem tiếp ở Phần 2 — IV. Nghiên cứu điển hình; V. Bên trong CPU vector; VI. Thảo luận; VII. Kết luận; Tác giả và vai trò; Tài liệu tham khảo.

Đọc thêm