CARME · RTL in the loop

Preview

Find the bug between the driver and the hardware before it is in silicon.

Most SoC bugs that escape are not in the RTL or in the firmware. They are in what one assumed about the other. CARME runs both together, from the first commit of either, and keeps running them on every commit after.

Become a test partner Talk to us

Firmware trace · RTL waves · one time axisrunning

41void dma_start(void) {
42  DMA0->SRC = (uint32_t)buf;
43  DMA0->LEN = 256;
44  DMA0->CTRL = DMA_EN | DMA_IRQ;
45  while (!done) __WFI();
46}

Four ways to put RTL in the loop

From one peripheral to the whole SoC.

One peripheral

A new UART, a DMA engine, a crypto core. The block is RTL; the CPU, memory and the other peripherals are emulated. The driver runs at almost full speed and only the block runs cycle by cycle.

An accelerator subsystem

An NPU, a video pipeline, a packet engine with its own memory. The subsystem is RTL with its interconnect; Linux and the user-space stack run on emulated Cortex-A or RISC-V cores.

The CPU

Your own core, in RTL, running real firmware against CARME's memory and peripheral models. Compare every retired instruction with CARME's reference model of the same ISA and stop at the first one that differs.

The whole SoC, a piece at a time

Start with every block emulated. Replace them with RTL as they are written. The same tests keep passing, or tell you exactly which block broke them.

What you test

The assumptions between hardware and software.

Drivers against new IP
HowThe vendor or in-house driver on the RTL, before any FPGA
Boot flow
HowROM, bootloader, secure boot and OS boot on the RTL boot path
Register maps
HowFirmware headers and the RTL register map checked against one .cmperiph
Interrupts and DMA
HowLatency, ordering and races between firmware and hardware
Low power
HowClock gating, power domains and wake-up, with the firmware that drives them
Error handling
HowFaults injected into the RTL or the bus; the firmware must recover
Performance
HowCycle counts of the RTL with the real software load
Security
HowKey handling, lifecycle and debug lock with the real boot code

Test	How
Drivers against new IP	The vendor or in-house driver on the RTL, before any FPGA
Boot flow	ROM, bootloader, secure boot and OS boot on the RTL boot path
Register maps	Firmware headers and the RTL register map checked against one .cmperiph
Interrupts and DMA	Latency, ordering and races between firmware and hardware
Low power	Clock gating, power domains and wake-up, with the firmware that drives them
Error handling	Faults injected into the RTL or the bus; the firmware must recover
Performance	Cycle counts of the RTL with the real software load
Security	Key handling, lifecycle and debug lock with the real boot code

Regressions that scale

Firmware against RTL, on every commit.

carme-test runs .cmtest files in parallel across cores and machines. Each test starts from a checkpoint, runs firmware against RTL, and checks UART output, registers, memory, bus traffic or signals. Results come out as JUnit XML; failures come with the trace, the waves and a command line that replays them exactly.

tests/dma_burst.cmtest

from carme import board
def test_dma_burst_to_ddr(rtl):
    b = board("boards/my_soc.cmboard", rtl={"dma0": "-f rtl/dma.f"})
    b.load("build/dma_selftest.elf")
    b.uart("uart0").expect("DMA: 64 bursts OK", timeout_ms=200)
    assert b.signal("dma0.u_ctrl.err_q") == 0

Both sides at once

Coverage, debug and tests that follow the project.

Coverage from firmware

Every firmware run adds to the RTL's coverage: code, toggle, FSM and functional. Every run also measures the firmware: which lines the tests reached. Two reports, one run, and the gap in each points at the test to write next.

One debugger for both

Stop the CPU at a line of C and see the RTL at that instant. Put a breakpoint on an RTL signal and land in the firmware that caused it. Traces and waves share one time axis in the Debug view.

From RTL to FPGA to silicon, the same tests

The .cmtest files that ran against RTL run unchanged against the FPGA prototype in the loop and, later, against the board. A test written on the first day of the project is still guarding it on the last.

Questions

Common questions.

Which HDLs can be in the loop?

SystemVerilog, Verilog and VHDL, mixed freely, through Lumina Sim. SystemC and C++ models connect as well.

Which buses connect the RTL to the system?

AXI4, AXI4-Lite, AXI-Stream, AHB, APB, Wishbone and TileLink, plus interrupts, resets, clocks and GPIO. Custom interfaces use a small adapter.

Does the RTL see real time or emulated time?

Emulated time, shared with the CPUs. Each RTL clock edge maps to a fixed point in that time line, so runs are repeatable.

Can I use my UVM environment too?

Yes. Keep the UVM agents on the interfaces CARME does not drive, and let the firmware drive the rest.

Full-system emulation for embedded and silicon teams

Your next tape-out, with the firmware already running on it.

Become a test partner Lumina integration