Core concepts
How SiliCode works
The path a specification takes from your sentence to a verified RTL module.
Pressing Generate does more than ask a model for some code. A run reads your request, writes the module, tests it, simulates it and checks that it synthesises, and it shows you where it has got to while it works. This page is about what you can expect between pressing the button and getting files back.
The steps you see
The strip on the active turn is the run telling you where it is. Each label is a piece of work with something to show for it at the end:
| Step | What you get out of it |
|---|---|
| SPEC | Your request turned into a concrete interface: port names, widths, reset behaviour, clocking. In project mode this is also where your files are read. |
| RTL | The module itself. This is the step your generator model choice affects most. |
| REVIEW | If the first simulation fails and Reflection is on, a second model reviews the RTL against the failure and repairs it before the run keeps iterating. A module that passes is never reviewed. |
| TESTS | A self-checking testbench, written against your specification rather than against the code that was just produced. |
| SIM | The design and the testbench actually executed, with the full log attached. |
| SYNTH | A synthesis pass for your chosen device family, and the resource estimate that comes with it. |
| FILES | Everything written out and attached to the chat. |
Not every run touches every step. A question that needs no new code stops early, and a run with verification switched off has no TESTS or SIM to do.
What happens when something goes wrong
Most problems are dealt with inside the run. A module that does not compile, or a testbench that fails, is something the run is expected to work through rather than hand straight to you, so what you see at the end is the state after those attempts.
When a run genuinely cannot finish, it stops on the step that broke and the chat says which one. Whatever was produced up to that point is 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.