Skip to content

Case study 4 of 6

regcite

Machine-checked register data from chip datasheet PDFs, served to AI coding agents over MCP, so the model looks a value up instead of recalling it.

949 / 949

RP2040 registers recovered, graded against the vendor's SVD

4,585 / 4,585 fields; one reset where datasheet and SVD disagree

22 / 30

Qwen2.5-3B with regcite attached

0 / 30 without it

29 / 30

Qwen2.5-7B with regcite attached

2 / 30 without it

View the code on GitHub
A/B board, four arms 30 questions, transcripts committed in the repo

Qwen2.5 3B and 7B, bare and with the server, on 30 questions

Two local Qwen2.5 sizes, each run bare and with the regcite server attached, over 30 register questions: straight lookups and bit math, plus traps where the only right answer is a refusal. Green is a pass. Red is a wrong hex value asserted where a refusal was due. Select any cell to read that arm's answer and tool calls.

boardselect a cell to read the question and the answer

run of 2026-08-30 on an RTX 4060 laptop (8 GB), 4-bit NF4, greedy decoding; scored with the repo's rules (every expected pattern must match; traps must refuse and assert no hex)

With the server attached no arm ever asserted a wrong hex value. The remaining misses are a garbled prose summary, one malformed tool call, and one run that hit the tool-round budget while correcting its way to the answer.

Register values recalled from memory

Language models write firmware from memory. A recalled register address or bit value is often close and wrong, and the resulting code compiles and returns bad measurements. The true values exist in datasheet PDFs, in tables that language models and plain PDF search both read poorly.

regcite extracts those tables with deterministic parsers, checks the result mechanically, stores it with provenance, and exposes lookup and arithmetic tools through MCP. The model writing firmware calls the tools. The tools answer from checked data or refuse.

The five pipeline stages

  1. 1

    Fetch

    Downloads the PDF named in the manifest and verifies its SHA-256; a short file or one without a PDF header is discarded before it can poison the cache.

  2. 2

    Extract

    Deterministic parsers (no AI) read the register tables. Each vendor lays tables out differently, so each has its own grammar; rows come from cell ruling lines, columns from header words.

  3. 3

    Validate

    Five check families run on every register: fields must tile without overlap, resets must fit and reconstruct, access modes must be legal, addresses must sit in range without collisions, enums must fit their fields. A failing register is stored as unverified and the tools refuse to compute with it.

  4. 4

    Store

    One SQLite file holds registers, fields, enums, init sequences, errata, and prose chunks; every row keeps the part, document, page, and hash it came from.

  5. 5

    Serve

    An MCP server exposes six tools. Every answer cites its PDF page and document hash; anything unverified returns a refusal.

Graded against vendor ground truth SVD diff, run as a regression gate in CI
metric RP2040 (642 pages, table format) STM32F4 (1,749 pages, prose format)
register recall 949 / 949 1,334 / 1,459 (91.4%)
register precision 100% 81.1%
offset accuracy 100% 98.1%
field precision 100% 97.6%
field recall 4,585 / 4,585 97.0%
field name accuracy 100% 95.7%
reset accuracy 4,367 / 4,368 93.1%

The one RP2040 reset mismatch is the datasheet disagreeing with the vendor's SVD (XOSC.STARTUP.DELAY: 0xC4 against 0x0). STM32 field metrics are upper bounds, because duplicate register acronyms in that manual are resolved by picking the section that agrees best with the SVD. Two more tiers run above the parser: 44 hand-written questions executed against the tools, refusals included, and a mock I2C bus whose every byte is computed through encode and diffed against golden traces. All 44 and all 8 writes pass.

Parts ingested registers verified per chip

BMI270 bosch_toc

85 / 86

ICM-42688-P tdk

108 / 110

TPS65219 ti

57 / 57

BME688 bosch_content

46 / 52

SGP41 is a command-based part with no register map; search_doc covers it. Six more parts wait on PDFs their vendors do not serve to plain HTTP clients.

Six tools what each one returns
get_register
fields, enums, reset, access, extraction status, page
decode
a value split into named fields with enum names resolved
encode
the byte to write, with unset fields kept at reset
check_errata
known silicon bugs scoped to a revision
search_doc
ranked prose passages with page numbers
init_sequence
ordered startup steps with timing, each step cited

What the tools return on bad input

A wrong field name returns the valid field list. An unknown enum returns the valid values. An unverified register returns its status and the page to check by hand. Errata lookup with nothing loaded says that no errata are loaded, not that the part has none. A vision-model pass exists for registers the parsers could not verify; its output runs through the same validators, and anything that fails is discarded so the deterministic data stays in place.

On the same laptop GPU, hybrid prose search with rerank answers in 527 ms warm (11,115 ms on the CPU); decode and encode take under a millisecond; a full BMI270 extraction takes 5.6 s. Vendor PDFs and the built database stay on the user's machine. The repo ships parsers and a manifest of source URLs with hashes, because republishing a corpus derived from someone's documents differs legally from reading documents you downloaded.