One flow, from the first line of RTL to the first boot.
Lumina checks and simulates the hardware. CARME runs the software on it. They share the file lists, the time line, the waves and the coverage, so moving a block from the testbench into the system is one option on the command line, not a project.
- 01Lintlumlint
- 02Formallumformal
- 03Simlumsim
- 04CARMEcarme
- 05Debugwaves + trace
- 06Coveragemerged
Six steps, one set of files.
- Write and check the RTL
ToolLumina Lint, Lumina CDC
What you getClean, synthesisable RTL with crossings checked
- Prove the hard parts
ToolLumina Formal
What you getProperties proved on the block
- Verify the block
ToolLumina Sim, UVM or cocotb
What you getBlock-level coverage closed
- Boot the firmware on it
ToolCARME with Lumina Sim
What you getThe real driver and OS on the real RTL
- Debug both sides
ToolDebug
What you getFirmware trace and RTL waves on one time axis
- Close coverage
ToolCoverage
What you getRTL coverage from firmware runs, merged with the block's
The file list Lumina reads is the one CARME reads.
Defines, include paths, libraries and the top name come with it.
# the DMA engine as its RTLdma0: rtl: files: -f rtl/dma.f top: lm_dma bus: { axi4: sysbus, at: 0x4002_0000, size: 0x1000 } irq: plic@23$ lumlint -f rtl/dma.f --top lm_dma$ lumsim -f rtl/dma.f -f tb/dma_tb.f --top dma_tb +UVM_TESTNAME=burst$ carme boards/my_soc.cmboard --firmware build/linux/Image --waves dma.fstExactly in step, from the bus to the coverage report.
Exactly in step
CARME and Lumina Sim share one clock. A bus transfer from the emulated CPU becomes AXI, AHB, APB, Wishbone or TileLink cycles on the RTL's ports; interrupts and DMA come back the other way at the cycle they happen. The RTL keeps Lumina Sim's 4-state values, so an X from an unreset register reaches the firmware as an error, not as a lucky zero.
Firmware as stimulus
Your boot code, your drivers and your OS are the most realistic testbench the block will ever meet. CARME runs them against the RTL and Lumina Coverage records what they reached, merged with the block's own regression. The holes that are left are the ones no firmware will drive, so you know where to aim the constrained-random tests.
One view to debug in
A stall on the bus shows as the instruction that issued it, the transaction on the bus, and the RTL signals that held it, at the same instant. Click from the firmware line to the waveform and back.
Checkpoint the boot, test the rest
Boot Linux once with the RTL in place, save the system to .cmsnap together with Lumina Sim's checkpoint, and start every test from there. A 30-second boot is paid once, not once per test.
Model first, RTL with one option.
Every Lumina Blocks IP ships with a register-exact CARME model and its RTL. Develop the driver on the model at full speed, then switch to the RTL with one option and run the same tests.
- LM-AES-GCM, LM-AES-XTS
In CARMEModel and RTL
- LM-SHA3, LM-DRBG, LM-TRNG
In CARMEModel and RTL
- LM-PQC-KEM, LM-PQC-DSA
In CARMEModel and RTL
- LM-LZS-E, LM-LZS-D
In CARMEModel and RTL
Common questions.
Do I need Lumina Sim to use CARME?
No. CARME runs on its own models. Lumina Sim comes in when a block should be its RTL.
Can the CPU itself be RTL?
Yes. Put your core in Lumina Sim and let CARME provide memory, peripherals and the rest of the system, or the other way round: an emulated CPU driving an RTL subsystem.
Can I run RTL from another simulator?
Yes, through CARME's DPI bridge, as a shared library or over a socket. Lumina Sim adds 4-state values, coverage, checkpoints and the shared debug view.
How fast is it with RTL in the loop?
As fast as the RTL simulates. Only the blocks in RTL run cycle by cycle; the rest of the system stays at emulation speed.
Full-system emulation for embedded and silicon teams
For embedded developers
Develop, debug and test without hardware
For silicon teams
Software ready when the silicon is
RTL in the loop
HDL and firmware, tested together
Testing and CI
Every test, every board, every commit
Boards and SoCs
250+ boards and SoCs, ready to boot
CPUs
Arm, RISC-V, SPARC, Power, x86, Xtensa, MSP430, TriCore
Peripherals
650+ register-exact models
Bring the block and the firmware that drives it.
We set up the co-simulation with you, on your RTL and your image.