The software is ready when the silicon is. Not a year after.
CARME models your SoC from its first memory map, runs the boot ROM, drivers and OS on it, and swaps in each block's RTL as it is written. The software team starts on day one, the verification team gets the most realistic stimulus there is, and your customers get a dev kit before the first wafer.
def on_write_CTRL(p, v): if p.CTRL.START: p.DATA = aes_gcm(p.KEY, p.IN) p.STATUS.DONE = 1 p.irq.done.pulse()
One model, from the first memory map to the customer's desk.
- Architecture
With CARMEBuild the SoC as a .cmsoc from the peripheral library. Run real workloads, try memory maps, cores and interrupt routing before any RTL
- RTL design
With CARMEEach block runs in Lumina Sim inside the full system as soon as it compiles. The driver team works against it the same day
- Verification
With CARMEBoot code, drivers and OS as stimulus. RTL coverage from firmware runs, merged with UVM regressions
- Pre-silicon software
With CARMEROM, bootloader, BSP, Linux and RTOS ports finished on the model and the RTL, not on first silicon
- Silicon bring-up
With CARMEThe same tests run on the board. A difference between silicon and model points at the block to look at
- Customer enablement
With CARMEShip a virtual dev kit with the SDK. Customers develop on it before samples, and on it alongside them after
Model, RTL and software, kept in step.
Model and RTL from one description
A .cmperiph describes a block's registers once. CARME's model, the C headers the firmware includes, and the checks against the RTL all come from it, so the register map in the driver and the register map in the silicon cannot drift apart.
Firmware-driven verification
UVM finds the bugs in a block. The firmware finds the bugs between blocks: the interrupt that arrives before the status is updated, the DMA that crosses a cache line, the clock gate the driver forgets. CARME runs the real boot and driver code against the RTL, and Lumina Coverage records what it reached.
Your own CPU
Put your core's RTL in the loop and run real software on it, with CARME providing memory and peripherals. Compare every retired instruction with CARME's reference model of the ISA, and stop at the first difference. Add custom instructions to CARME's model in a few lines so the compiler, the model and the RTL agree.
Design wins start before samples.
Your SoC, your evaluation board, your SDK and its examples, packaged as a CARME platform your customers install. They write and test firmware months before samples, your field engineers reproduce customer issues without shipping hardware, and design wins start earlier.
One register description, one time axis, one coverage database.
Common questions.
How early can we start?
As soon as there is a memory map. Most SoCs reuse known cores and peripherals from the library; the new blocks start as Python models and become RTL as it is written.
Who builds the SoC model?
Your team, with the peripheral library and the .cmsoc format, or our services team with you. We keep it in step with each RTL release.
Can our customers use the model without our RTL?
Yes. The virtual dev kit ships the model only. The RTL stays with you.
Does it replace FPGA prototyping?
It comes before it and alongside it. CARME runs from the first day of the project; the FPGA comes later and runs the same tests.
Full-system emulation for embedded and silicon teams
For embedded developers
Develop, debug and test without hardware
RTL in the loop
HDL and firmware, tested together
Lumina integration
One flow from RTL to running firmware
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