Verification evidence for the SEC module

Four levels of testing

The verification flow is organized bottom-up. Individual modules are checked first, then the interfaces between modules, then the full SEC module at the APB boundary, and finally the FPGA implementation. This makes many failures local to the level where they are introduced.

Self-checking testbench results

Each testbench prints an explicit verdict by comparing against a reference model or expected sequence and counting PASS/FAIL checks. These are the latest local results.

Several older bring-up testbenches (the 4-word-protocol encrypt chains) are kept in the tree for historical reference and are explicitly marked deprecated — the rows above are the authoritative regression set.

Security-relevant RTL assertions

In addition to the testbenches, key invariants are encoded in the design as SystemVerilog assertions (`ifndef SYNTHESIS, simulation only). They are evaluated on every relevant cycle and stop the simulation if the invariant is violated.

Role of assertions: a testbench checks selected scenarios, while an assertion checks an invariant across all scenarios that reach the relevant signal condition. The fuzzy-extractor UVM suite runs its six groups with 0 assertion failures.

Behavioral flash model

w25q64jv_model.sv is a behavioral model of the Winbond W25Q64JV used by the Quad-SPI testbenches. It implements the opcodes, Mode-0 timing, and status registers used by the design.

• Status Register 1 (BUSY, WEL) and Register 2 (QE) modelled bit-for-bit.
• The five commands the design uses: WREN, RDSR1, WRSR2, Quad Page Program and Fast Read Quad Output.
• After every page program, BUSY is set so the master's poll loop is actually exercised, then cleared.
• A memory array so written bytes can be read back and compared.

Model implementation note: an early version split the flash logic across four event-driven blocks (on SCLK edges, on CS edges, and on the clock). Simulator event scheduling caused the read-status decoder to fire one clock late, so the master waited indefinitely for BUSY to clear. The model now runs from a single clocked process and decodes each command on the edge that receives it.

On-chip observability

The SEC module exposes internal status through APB-readable registers. The same observability points are used in simulation and on FPGA hardware:

FPGA bring-up

Passing simulation is necessary, not sufficient. The design was synthesised to an FPGA and driven by real RISC-V firmware against a physical W25Q64JV over the PMOD connector — the first environment that includes board wiring, I/O timing, and the physical flash device.

• Firmware test programs drive the full sequence over APB and read the status, error and observability registers back over UART.
• The multi-page stress test (sec_multipage_test) writes and reads 24 records across two sectors and checks in-order & reverse reads, cross-sector isolation, a fresh nonce per encryption and no dropped requests — 11/11 on hardware.
• The first SoC synthesis surfaced a name collision between an internal counter instance and a library cell; the instance was renamed and the relevant simulations were re-run.

Hardware debug example

FPGA bring-up exposed a quad-SPI read issue that was not visible in the purely digital flash model. Helper-data read-back returned a small number of incorrect words, with different counts across bitstreams.

Root cause. During a quad read, the eight dummy cycles are a bus turnaround: the master must release the DQ lines so the flash can start driving them. The dummy state was running in the driving branch and held all four DQ lines low until the data phase. At the dummy→data handover, the master's low drive conflicted with the flash driving DQ3/DQ0 high, matching the observed data dependence.

Fix: switch the dummy state into receive mode so the master tri-states the DQ lines during the turnaround. Single-line reads and quad writes are unchanged. The digital simulator cannot reproduce analog bus contention, but it confirmed no regression; the hardware [S] self-test confirmed the fix on FPGA.

Performance & silicon cost

Two questions beyond "is it correct": how fast does an operation run, and how much hardware does the module cost. The first is measured on the FPGA prototype; the second comes from a first ASIC synthesis of the SEC subsystem.

Operation timing (FPGA prototype — measurement pending)

A dedicated firmware test (sec_perf_test, on the live-demo branch) brackets each operation with Ibex's free-running mcycle counter, so the cycle delta is the exact wall-clock cost (cycles ÷ f_clk = seconds). The measured window is kept UART-silent — the result line is printed only after the timer is stopped — so the 9600-baud log cannot inflate the figure. Covered operations: one-time boot enrollment, page write with and without the 4 KB sector erase, authenticated read, and an N-page burst; the optional PCU supplies dropped-request and flash-stall counts for the same run.

No board numbers yet. The instrumentation and the GUI-side plotting are implemented, but the measurement run on the FPGA board is still pending, so no cycle figures are published here. What the hardware tests have already shown qualitatively: the 4 KB flash erase dominates a write into a fresh sector, and the multipage stress test sustained 24 page operations with 0 dropped requests.

Silicon cost (ASIC synthesis bring-up)

The SEC subsystem (tum_ss) is being taken through its first standard-cell synthesis with Synopsys tooling against a GF 22 nm library, within the subsystem's 350 × 350 µm² floorplan budget. The first runs were used to clean up RTL constructs that simulation and FPGA synthesis tolerate but the ASIC elaborator rejects — an oversized function-local lookup table and a cross-generate reference in the BCH chain (details).

In progress — no numbers yet. The elaboration blockers are fixed in the RTL, but a complete synthesis run (with the SRAM-PUF macro library linked) has not finished yet. Cell counts, area, and timing will be published here once a full run exists; until then the only committed figure is the floorplan budget above.

Live-demo GUI

For demos and bring-up, the FPGA tests are also driven from a small browser GUI. It builds, loads and runs a chosen fpga/sw test at the press of a button, streams the UART log live, and — the centrepiece — paints the external flash as a colour-coded sector/page map as the module writes, reads and authenticates records in real time.

Page colours: ■ written · ■ read + auth OK · ■ rejected (ERR_AUTH) · ■ erased · ■ empty · ■ reserved (helper / counter)

The GUI lives on the demo/live-gui branch. Its optional raw-flash-byte view depends on a read-only RTL path that is `ifdef-gated and never compiled into the ASIC build.

Toolchain

House rules. Reset is async, active-low throughout. Addresses and sizes come from one source of truth — sec_pkg.sv — never hard-coded in a test. After any change that touches the RTL, the relevant testbenches are re-run and the x/y PASS result is logged before the work is considered done.