Core concepts
How RTLBridge works
The path a specification takes from your sentence to a verified RTL module.
A run is not one call to a language model. It is a short pipeline where each step produces something the next step can check, and where the tools you switch on decide how much checking happens. This page explains what runs between pressing Generate and getting files back.
The seven steps
| Step | What it does |
|---|---|
| SPEC | Reads your request and settles the things you left open: port names, widths, reset behaviour, clocking. In project mode this is also where the agent explores your files. |
| RTL | Writes the module. This is the step your generator model choice affects most. |
| REVIEW | Re-reads the RTL looking for its own mistakes and rewrites what it finds. Only runs when Reflection is on. |
| TESTS | Produces a test plan and then a self-checking testbench from it, rather than writing tests directly and hoping they cover the spec. |
| SIM | Compiles the design and the testbench and runs them. A compile error here sends the run back to RTL rather than failing outright. |
| SYNTH | Pushes the design through synthesis for your chosen device family and reports a resource estimate. |
| FILES | Writes everything out and attaches it to the chat. |
Not every run touches every step. A question that does not need new code stops early, and a run with verification off skips TESTS and SIM entirely.
What happens when a step fails
Failures are expected and are usually recoverable inside the run. A module that does not compile is fed back with the compiler output; a testbench that fails is a signal to fix the RTL, not to accept the result. What you see is the state after those internal retries, not the first attempt.
When a run genuinely cannot finish, it stops on the step that broke, and the chat says which one. Partial files are still attached; a broken module you can read beats no module at all.
Why verification is a separate thing
Generated RTL that compiles is easy. Generated RTL that does what you asked is the hard part, and the only honest way to claim it is to run it. That is why the testbench is self-checking and why the verdict comes from a simulator rather than from a model saying the code looks correct.
# Test 1: reset clears the counter PASS
# Test 2: enable low holds the value PASS
# Test 3: counts 0 -> 255 and wraps PASS
# Test 4: enable re-asserted mid-count PASS
# ---------------------------------------------------------
# 4 tests, 0 failuresNote
A pass means the testbench that was written for your spec agreed with the module that was written for your spec. If the spec was ambiguous, both can be confidently wrong in the same direction; that is the one failure mode verification cannot catch for you.
Where the models sit
Three roles use a model, and you can set each one separately in Run setup: the planner that turns your text into a plan, the generator that writes the RTL, and the reviewer used by Reflection. Most people only ever change the generator.
What a run can see
By default a run sees your request, your saved coding style, and the earlier turns in the same chat. Everything beyond that is opt-in through the tool switches: the open web, Exa, the IP core catalog, the knowledge base. In project mode it also sees the files you uploaded, and nothing outside that workspace.