Anatomy of a Fabric run

The Regex Accelerator’s repository was produced by a single run of Vosken Fabric, our IP development system. “Produced by a run” invites a misreading - that a model wrote some RTL and we kept it. What happens is narrower and more boring than that, which is exactly why it works.

The shape of a run

A run is a sequence of gated stages. Each stage produces reviewable artifacts; the next stage cannot start until those artifacts are validated and frozen.

Requirements. The brief becomes numbered, testable requirements - 73 of them for the regex engine. Numbered matters: from here on, everything downstream must justify itself against a requirement ID. Vague intent dies at this gate or not at all.

Architecture. Subsystem decomposition, external interfaces, protocols, clocking, register maps. For the regex engine this fixed five subsystems and one deliberately boring decision - a single 250 MHz clock domain, no CDC - that removed an entire class of bugs before any RTL existed.

Hierarchy. Each subsystem is decomposed into leaf blocks with allocated registers and defined boundaries: 33 leaves plus a top-level wrapper, 39 blocks in all.

Micro-architecture. Every block gets four artifacts: a port expansion, a datapath design, an FSM specification, and a component spec that serves as the single source of truth for integration. This is the stage that constrains generation - by the time RTL is written, the degrees of freedom are small.

RTL. SystemVerilog is generated per block, inside the frozen micro-architecture, and linted as it lands. Generation here is closer to transcription than invention; the design decisions were made, reviewed, and frozen upstream.

Verification. Static analysis, formal properties with prove and cover sessions per block, simulation, regression. Findings flow back as review records attached to the block, not as folklore.

Coherence. Independent validators check that the stages still agree with each other - that the architecture matches the hierarchy, the hierarchy matches the micro-architecture, the micro-architecture matches the RTL, the ports line up. Six validators run across the whole repository. Drift between stages is a defect, even when each stage looks fine alone.

Where the humans are

At every gate. Specialised agents draft each artifact, but freezing a stage is an engineering decision made by an engineer looking at reviewable output. The system’s job is to make that review tractable: small artifacts, explicit interfaces, requirement IDs everywhere, and validators that catch the cross-stage inconsistencies humans are worst at spotting.

Why this beats “generate and pray”

Unconstrained generation produces plausible RTL with unknowable properties. The pipeline inverts that: by the time code exists, its intended properties are already written down - in requirements, in the component spec, in the formal properties derived from both. Verification then checks the implementation against an explicit target instead of reverse-engineering intent from code.

One brief in. A repository out: requirements, architecture, 39 specified and implemented blocks, per-block verification collateral, and a traceability chain connecting all of it. That chain is the next post.