One-click workflow

When an architecture is accepted, the initial workflow attempts the configured design stages in order. It records what each stage consumed and produced, and passes usable artifacts forward.

The stages#

1. 1
   RTL lint

   • Verilator checks the design RTL in about a second before anything else runs.
   • Errors (syntax, unknown modules) go to the Architect to repair.
   • Warnings that usually mean a bug (bits lost in a width mismatch, latches, two drivers on one signal, undriven signals) mark the step for review. Style notes such as unused signals are listed only.
   • Problems are underlined on their lines in the code editor.
   • Testbenches and FPGA board wrappers are not linted, and the process pack's SRAM macros count as known modules. Lint checks structure, not behavior.
2. 2
   RTL simulation

   • Icarus Verilog compiles and runs the project's SystemVerilog/Verilog testbench, or its Python (cocotb) testbench. For a VHDL design, GHDL runs a VHDL testbench and Python tests, and converts the design for a Verilog testbench. The step shows which simulator the last run used.
   • The run can report pass/fail, named metrics, scenario coverage records, logs, and a waveform when emitted.
   • After a pass, Verilator runs the same testbench again to measure code coverage of the design (line, branch, and toggle), shown as its own result; lines the testbench never reached are marked. Coverage never changes pass or fail.
3. 3
   Structural checks and formal properties

   • Clock- and reset-domain crossings and state-machine states that cannot be reached from reset, from Yosys's netlist of the RTL. Findings are marked for review; a crossing protected by a handshake is still listed as multi-bit.
   • When the RTL states assert or cover properties (for example inside `ifdef FORMAL), SymbiYosys proves the asserts and checks every cover is reachable. Two methods prove the asserts side by side, k-induction and PDR, and a failure PDR finds deeper than the normal check is named by a longer one. A failing assert fails the run and saves its counterexample waveform; every failing assert is reported, not only the first. Each reached named cover saves an example waveform. Named asserts are reported one by one and can prove goals (see Goals proven for every input). Designs without properties skip this.
4. 4
   Synthesis and mapping

   Yosys checks and synthesizes the RTL. With a compatible Liberty standard-cell library it can create a mapped gate-level Verilog netlist, saved under generated/netlists/. RTL memories that an installed SRAM macro implements exactly are mapped to it after a formal proof; see Memories, macros, and blocks.
5. 5
   Hardened blocks

   Only when tapeo.json lists blocks: each block is placed and routed on its own (or reused when nothing it depends on changed), then placed as a macro by the top.
6. 6
   Static timing

   OpenSTA runs a project Tcl/SDC timing flow using the mapped netlist and Liberty data. Timing evidence is meaningful only for the constraints and libraries actually supplied; assumed constraints must be labeled exploratory. An AI-written SDC stays exploratory until you edit it or choose Confirm constraints in Signoff readiness.
7. 7
   Floorplan, placement, and routing

   OpenROAD runs the configured physical-design flow using the selected platform resources and project inputs. A successful export can produce routed layout artifacts and measurements reported by that flow.
8. 8
   Gate-level simulation

   The project testbench runs against the routed netlist with the process cell models (zero delay), then again with the routed design's delays annotated from signoff timing (experimental: delays apply, but setup and hold violations are reported by static timing, not by this simulation).
9. 9
   Signoff checks and handoff

   Where matching process data and integrated runners are available, the app can run checks such as KLayout DRC, Magic extraction, Netgen LVS, OpenROAD antenna checks, and optional CVC electrical-rule checks. It also creates an engineering handoff archive. Missing process files or tools remain explicit skipped or unavailable results.

Repairs and server runs#

• The Architect can use actual error output to propose repairs and retry supported stages, with a bounded number of attempts.
• It continues independent available work when a stage cannot run.
• Workflow runs are saved and executed by the server-side worker, so closing or refreshing the browser does not stop an active run. This does not guarantee every project completes every stage.

Following a run: the run bar#

While a workflow runs, a slim bar under the workspace tabs (at the bottom of the screen on a phone) says what is happening in plain words, on every tab, so you can keep working. It shows the step and, once the project has an earlier run of the same kind, about how long is left.

• Details opens the run's story: each step as it starts, its result, the files the Architect changed (open each one, or its history to see or undo the change), and notes. Each line says what happened and what it means in plain words, with the real term in brackets, such as “Your code passed the proof-read (lint)”. Show tool details adds the tools' exact words.
• What's happening now explains the current step for a beginner: what lint, simulation, synthesis, layout, or DRC is, and why it matters. When a step runs a while, Why this takes a while says what it is doing for a design your size and how long it took last time.
• When a step fails and the Architect repairs it, What went wrong says why in your design's own words, such as “Your counter stopped at 3 because rst is still high on the 4th clock tick”. Show me opens that line in Code and the waveform at that moment.
• Underlined words open a short explanation with a picture; once opened, they are no longer underlined. A word your project meets for the first time is marked New term.
• Your chip lights up each part of the build (code, simulate, prove, synthesize, layout, check) as the run reaches it, and shows its result.
• When the run ends, the bar shows a summary: how long it took, what failed or needs review, Since your last run (for example “Your design got 12% smaller (412 → 362 cells)” or “Timing went from failing to passing”), and buttons for the next step, such as opening the failed stage or checking your goals. Dismiss it with ×; – shrinks the bar to a small dot in the corner. To read a run's story again later, use Last run at the right of the tabs, or Story → next to any run in the Workflow tab's run history.
• The browser tab's title shows the step while a run goes and the outcome when it ends. In Details, Desktop notification when it finishes asks the browser for permission and notifies you when the run ends while the page is in the background; Email me when it finishes sends the summary once, for that run.

The story is written by the workflow itself from what each tool reported; the only AI-written line is What went wrong. Runs started before this feature have no story. tapeo run --watch and VS Code show the same story.

Stage states#

Workflow states say whether a step has run, is running, failed, is blocked by prerequisites, was skipped, has no generated file, or is not integrated.