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