From a plain-language spec to RTL that passes its checks, with Micius running the EDA tools

Turning a written spec into tested RTL usually passes through several hands: one engineer writes the spec, another writes, compiles and debugs the code, someone else draws a diagram for review. Here a digital design engineer hands the spec to Micius, Zhiman’s model, which writes the code and tests, runs the tools, works through the failures, and builds a schematic from the code that passes.

Take the smallest possible block: a 4-bit counter with an active-high asynchronous reset and an enable. The design might be under twenty lines; its self-checking testbench can run past a hundred. Real blocks are far bigger, but the chain is the same: write the spec, write the RTL (the hardware description code), compile, simulate and fix, then prepare a diagram and waveforms for review.

That work usually passes between people, and context leaks at every handoff. Whoever writes the tests has to reconstruct the design intent; whoever draws the diagram may not have the final code. The code that was verified and the diagram that gets reviewed can drift apart without anyone noticing.

Solution

A one-paragraph spec, handed to Micius

The engineer’s spec names the top module and its ports and says how reset and enable behave. Four behaviours need tests: asynchronous reset, holding while enable is off, counting, and wrapping from 15 to 0. It asks Micius to fix any failure from the tools’ diagnostics and rerun the checks; once everything passes, build the schematic from the same final code; return the full RTL, the testbench and the real results. And if it doesn’t pass, say so.

Micius, Zhiman’s model, set out its plan, wrote the RTL and a self-checking testbench, then ran the EDA tools itself: syntax and lint checks, compile, simulate. It chose which tool to run, and every command and every tool response went into the conversation verbatim, so the conversation is the run record.

The checks passed, but the first compile stopped: the testbench was driving one of the design’s outputs, which can be read but not written, a common testbench slip. Micius can fix errors like that straight from the message and compile again.

Diagnosis

Design bug or testbench bug?

The harder case is a simulation that runs but fails its self-checks, and the first question is whether the design or the testbench is wrong. Here the pattern pointed one way: reset and hold passed, while the three counting checks were each one count behind. Micius read that as the testbench sampling right on the clock edge, before the counter had updated, and expecting the wrong value on the first edge after reset. Its fix was to sample just after the edge, rewriting the testbench and leaving the RTL alone.

The first rewrite didn’t settle it; the count was still a cycle out. Micius narrowed the problem to the expected value on the first active clock edge after reset was released, rewrote the testbench again and reran. Each diagnosis and change is written into the conversation, so an engineer can see why it changed what it did.

Micius4-bit counter · failing self-checksSimulation · self-checks

1. Compile The testbench assigned to cnt, an output of the designFixed
2. Compile passed · Simulate finished · Self-checks failed3 failed

Self-check results

cnt as read by the testbench, against the expected value

Check	ExpectedExp.	Read	Result
Async reset clears at once	0	0
First edge after reset → 1	1	0
Counts up to 5	5	4
Holds with enable off	5	5
Wraps from 15 to 0	0	15

PatternOnly counting checks fail, and each is one count behind (15 where 0 was due).

AssessmentThe design counts as specified. The testbench reads cnt at the clock edge itself, before the counter updates.

clk cnt 3456

• Before: sampled at the edge, reads 4
• Fix: sample just after the edge, reads 5

RTL unchanged Rewrite the testbench to sample after the edge, and recheck every expected value. Next: compile and simulate again

Results

Seven checks pass, then the schematic

In a separate run on exactly the same RTL, lint reported no errors or warnings and all 7 self-checks passed, covering the four behaviours in the spec. Only then did Micius synthesise the code and generate the schematic, confirming it came from the RTL that passed. Synthesis produced a flip-flop with an asynchronous reset, as the spec asked.

The engineer got back a report listing what was done, the RTL and testbench that passed, and the self-check log, each checkable against the others. The report also states the limits: these simulation results support functional verification but are not sign-off, and key conclusions need an engineer’s review. Whether to adopt the code is the engineer’s call.

Schematic

Trying the reset by hand

Because the schematic is generated from the code that passed, nobody draws it separately. Engineers can toggle clock, reset and enable on the diagram and watch the count against the waveform. Micius suggests an order: raise reset and see 0; release it, enable, and clock up; disable and watch it hold; count past 15 and see it wrap. The telling test is to let the count reach a non-zero value, then raise reset between two clock edges. The count clears at once, which is what “asynchronous” looks like on a waveform.

Micius4-bit counter · schematic and waveformSchematic · waveform

cnt4 · generated from the synthesised netlist

Same RTL as the one that passed

clkrsten +1 D Q R en 4-bit register cnt

Inputs

clkrunning

rst 1 0

en1

cnt · decimal 0 7

clkrstencnt

01234567

0

Reset rises between clock edges; the count clears at once

The schematic helps you see the structure and try inputs by hand; functional correctness rests on the simulation self-checks.

The schematic helps engineers understand the structure; whether the function is right still rests on the self-checks, and Micius says so when it hands over. The design was also very small: multiple modules, bus protocols and coverage closure weren’t part of this run. Micius closed with a few options for the engineer to pick from, such as making the width a parameter, adding an output that flags when the count matches a value, or building a UVM test environment.