delivered

Two SoCs, each signed off in days

OpenTitan Earlgrey, a taped-out root-of-trust SoC, then Darjeeling, the next chip in its family. Same pipeline both times; the second started from everything the first one taught DV-FORGE.

OpenTitan Earlgrey

Full signoff in 30 days^*

A taped-out root-of-trust chip, started from its reference manual and nothing else. Every block, register, interrupt and crossing went into the map, each pointing back to its source.

~40IP blocks, all covered

33,000+RTL instances elaborated, zero errors

2,581registers and 6,015 fields, each checked

7bugs found

OpenTitan Earlgrey block diagram — OpenTitan Earlgreyclick to enlarge

OpenTitan Darjeeling

Signed off in 21 days^*

Different fabric, different memory system, bigger. DV-FORGE worked out what changed before writing anything, and started from everything the driver taught it.

35,000+RTL instances

21 days^*starting from what the driver taught DV-FORGE

+New blocks: collateral built for them
−Removed blocks: their tests retired, not left rotting in the regression
~Changed blocks: sequences and checkers extended, not rewritten
ΔRegisters, interrupts, address map: re-derived and re-checked

OpenTitan Darjeeling block diagram — OpenTitan Darjeelingclick to enlarge

* Most of these days were spent in regression.

Block diagrams: lowRISC/OpenTitan (github.com/lowRISC/opentitan), Apache 2.0. An independent open-source project; it does not endorse us.

how it works

One pipeline, from the reference manual to signoff

DV-FORGE reads the reference manual into a mental map of the SoC, with every fact tied to its page. The map and a deterministic generation model together make up the Forge engine, which writes the vPlan, the coverage model and the UVM. Every failure and every coverage hole from regression goes back to where it belongs, and what is learned becomes part of the engine, so it keeps improving over time.

Plays on a loop. Tap a stage, or step through with the arrows.

Then: why it scales

engine v43, regeneratev43

Reference manualSoC RM, rev B, PDF

p. 1

Forge engineSoC mental map + deterministic generation modelv41

vPlan0 testpoints

TP-INT-12 uart0 interrupt reaches the CPU table 5-2

Coverage model0 bins

cg_plic_route every source in table 5-2 42 covergroups

UVM0 sequences

soc_irq_route_vseq and 13 more, with agents, scoreboards and the register model

vPlan

Coverage model

UVM

Forge enginev411,284 behaviours0 map notes

Regression

Tests246

Coverage1,184 bins

learned into the enginegap in the RTLgap in the specwaived

Waiting for the regression

Every failure and coverage hole is traced against the map and sent where it belongs.

Learned into the engine0

Waived, with evidence0

Gap in the RTL0

Gap in the spec0

Learned into the enginegeneration model

Waive, with evidencemap

Gap in the RTLdesign

Gap in the specspec owner

Three stages, played on a loop.

1 of 3

why it scales

As the SoC grows, assistant answers get worse.DV-FORGE stays grounded, and gets cheaper.

One story in three steps. An assistant has to hold the chip in its context. The bigger the design, the more that context fills with unrelated and conflicting fragments. Answers are then not just guessed but wrong or of poor quality, a failure known as context poisoning, and every answer costs more. DV-FORGE keeps the chip in a cited map, gives an LLM only a bounded cone, and turns everything it learns into deterministic modelling.

Bigger contexts poison assistant answers. DV-FORGE stays grounded at any size.

Grow the design from one IP block to a full SoC and its derivatives, and ask both the same question at each size. The assistant’s context window stays the same size, so its prompt fills with unrelated and conflicting fragments. The facts it needs fall out, and what is left pulls the answer the wrong way: guesses, wrong facts borrowed from other blocks, and poor-quality advice. This is context poisoning.

Press play, or tap a design size on the chart.

Same question at every sizeWhich interrupt does uart0 raise when its TX FIFO empties, and how is it enabled?

Assistant prompt

30%

DV-FORGE prompt

100%

fact	Assistant	DV-FORGE

guessed or poor qualitywrong, from unrelated contextinvented

The same question, at every design size

Which interrupt does uart0 raise when its TX FIFO empties, and how do I enable it?

General-purpose LLM assistant

What goes into its prompt

about the questionunrelated fragmentsdid not fit

Its answer

correctguessed or poor qualitywrong, from unrelated contextinvented

DV-FORGEabout the question: 100%

What goes into the promptthe cone: 1.9k tokens

The rest of the map stays out by design, at every size.

the cone of influence for this question

Its answer

Asked twice: the same answer, from the same cone.

cited to the manual

Every change has a known impact. Every failure has a known cone.

Every component and sequence stays linked to the blocks it came from. A requested change already knows what it touches. A failing test already has a bounded cone of influence to backtrack through, and only that cone goes to the LLM, so nothing unrelated can poison its context.

Pick a change, or a failing test

AA change is requested. What has to change?

Or tap any block on the map.

BA test fails. What is its cone of influence?

Or tap blocks on the map to draw your own cone.

Every finding is learned once, so every iteration gets cheaper and faster.

The first iteration already needs 80% fewer tokens than an assistant, thanks to the SoC mental map and the deterministic generation model. The gains after that come from the deterministic model evolving: the first time a failure or coverage hole appears, it is a dynamic finding, and an LLM helps trace it inside its cone. Once understood, it becomes deterministic modelling and never needs an LLM again. Step through the driver SoC and then its derivative.

Findings in this iteration

0new, so dynamic: traced with an LLM, inside the cone

0already learned: handled by the deterministic generation model, no LLM

Forge enginev41

v42

1,284behaviours modelled deterministically

+0learned from this iteration

Starting point: built on open-source SoCs and improved through industry partnerships, before this project began.

share of findings that are still new, iteration by iteration

LLM cost per iteration

Debug turnaround per iteration

1 of 3

your flow

Your data and your style, learned once

Every team has its own spec templates, RTL conventions, UVM base classes and coding guidelines. DV-FORGE’s inbuilt parsers and generation model adapt to them once. After that, every new spec and RTL drop is read, and every file is generated, without spending tokens.

Inbuilt parsers adapt to your data spec templates, PDFs, register formats, RTL conventions

The parsers ship with DV-FORGE. When your specs or RTL do something they have not seen, an agentic loop adapts them once. Future specs and RTL in the same style are parsed deterministically, with no tokens.

your spec templateregister table row

CTRL  (+0x00)  RW  rst 0x0000_0000
  [0]  EN     enable the block

your RTL conventionin-house CSR macro

`ACME_CSR(CTRL, 8'h00, RW, 32'h0)
`ACME_FIELD(CTRL, EN, 0, 0)

parsed into the modelnext spec or RTL: 0 tokens

register  name=CTRL  offset=0x00  access=RW  reset=0x0
  field   name=EN  bits=[0]  desc="enable the block"

Generation follows your guidelines base classes, naming, file layout, coding rules

The generation model takes in your existing assets, so generated code reads as if your team wrote it.

default modeluart_smoke_vseq.sv

class uart_smoke_vseq extends uart_base_vseq;
  `uvm_object_utils(uart_smoke_vseq)

with your assetsacme_uart_smoke_seq.sv

class acme_uart_smoke_seq extends acme_seq_base #(uart_cfg);
  `acme_object_utils(acme_uart_smoke_seq)

vendor manuals

Proven on NXP, ST, Renesas, Infineon

Ten thousand pages of unstructured reference manuals, read end to end by the inbuilt parsers, adapted to each vendor’s conventions. Register models, vPlans and UVM out, from the same pipeline that ran Earlgrey.

4

vendors

14

reference manuals

10,000+

pages, none of them machine-readable

1

unchanged pipeline

Vendor RM, PDF onlythousands of pages, no structure
Register modelgraded vs the vendor’s own file
vPlan + UVMsame pipeline as Earlgrey

NXP

Kinetis K64 RM265 register tables
i.MX RT1060 RMregister model from the manual alone
MCX N94x RM
S32G2 RMautomotive
LPC55S6x UM

STMicroelectronics

STM32F4xx RMRM0090
STM32H742/743/753 RMRM0433
STM32N6 RMRM0486

Renesas

RZ/G2L and RZ/G2LC Hardware Manual
RZ/G2L SBC manual

Infineon

AURIX TC3xx User Manual, Parts 1 and 2
AURIX TC39x User Manual

Marked manuals are full runs, graded against the vendor’s own register file. Also in the corpus: AMD/Xilinx Zynq TRM, Silicon Labs EFR32xG24 RM. If your chip ships with a PDF manual, it is already the kind of input we run.

evidence

What it has already done

Not testimonials. These are runs.

3 chips, 1 command

One unchanged command, three SoCs end to end — two OpenTitan-class chips and Caliptra. Different fabrics, register formats and cores.

>99% match

Graded against a reference plan it had never seen. Over 99% of testpoints reproduced exactly.

30,000+ instances

Full-chip elaboration above thirty thousand instances, zero errors.

10,000+ pages

Registers pulled straight out of vendor manuals, 10,000+ pages in all, graded against each vendor’s own register file.

who we are

Developed in collaboration with academia and industry

Swadeza collaborates with professors at BIT Patna and with Signitude, a fabless semiconductor company.

academic collaborationBIT PatnaProfessors of the Birla Institute of Technology, Patna campus

industry collaborationSignitudeFabless semiconductor company

Also from Swadeza

The first company to deploy a fully automated system for in-production AI verification and validation for government recruitment, built for the Government of Bihar. It cut turnaround from several months to weeks, and created a credible, legally defensible ledger with transparency and accountability throughout the process.

Deploy DV-FORGE on-premises

Talk to us about a deployment, an engagement or a collaboration.

Talk to us info@swadeza.com

See DV-FORGE run live at SEMICON India, startup pod 6, in Yashobhoomi, New Delhi, from 17 to 19 September. Plan your visit

DV-FORGE is running live at SEMICON India right now, at startup pod 6 in Yashobhoomi until 19 September. Find the pod

Met us at SEMICON India? Pick up where we left off.