Run your firmware before the board exists. Or before the silicon does.
CARME emulates whole boards and SoCs, from a Cortex-M0 sensor node to a 16-core Linux server, and runs the unmodified binary your build produces. Embedded teams develop, debug and test without waiting for hardware. Silicon teams put any block in RTL, and the driver, the OS and the hardware meet long before tape-out.
- 250+
- boards and SoCs: Arm, RISC-V, SPARC, Power, x86, Xtensa and MSP430
- 650+
- peripheral models, register-exact, from UARTs to PCIe and UFS
- 1 time line
- CPUs, peripherals, networks and RTL, the same on every run
- 0 boards
- needed on your desk or in your CI farm
# a Zephyr image on a NUCLEO-H753ZI, console on USART3$ carme boards/nucleo_h753zi.cmboard --firmware build/zephyr/zephyr.elf --uart usart3# the same board, with the crypto block as its SystemVerilog RTL$ carme boards/nucleo_h753zi.cmboard --firmware build/zephyr/zephyr.elf \ --rtl crypto0=-f rtl/aes_gcm.f --waves aes.fst --coverage cov/# every test, every board, on every commit$ carme-test tests/ -j 32 --junit results.xmlFrom the day the part is chosen to the day it ships.
- Start
Embedded developersThe day the board is chosen, not the day it arrives
Silicon teamsThe day the RTL starts, not the day silicon returns
- Run
Embedded developersYour Zephyr, FreeRTOS, Linux or bare-metal image on 250+ boards
Silicon teamsYour boot ROM, drivers and OS on your SoC, block by block in RTL
- Debug
Embedded developersGDB and your IDE on every core, no probe, time stopped when you want
Silicon teamsFirmware lines and RTL waves on one time axis
- Test
Embedded developersEvery commit on every board, no hardware rack
Silicon teamsFirmware as stimulus, RTL coverage from every run
- Ship
Embedded developersTested firmware on day one of hardware
Silicon teamsA virtual dev kit your customers use before samples exist
The binary you ship, on the whole system.
The binary you ship
ELF, raw binary, Intel HEX or S-record, exactly as your toolchain writes it. No special build, no stubs, no HAL swapped for a simulation one. Linux, Zephyr, FreeRTOS, NuttX, Tock, seL4, bare metal: if it boots on the board, it boots on CARME.
Whole systems, not one CPU
A machine is CPUs, buses, memory and every on-chip peripheral, wired as the datasheet says. Heterogeneous parts run together: the Cortex-A53 cluster running Linux, the Cortex-R5F running the RTOS, the M-core managing power.
Your RTL, in place of any model
Swap any peripheral, accelerator or CPU for its SystemVerilog, Verilog or VHDL. Lumina Sim runs it in 4-state, in step with the emulated system, and the firmware cannot tell the difference.
Many machines, one network
Connect boards over Ethernet, CAN, BLE, 802.15.4, LoRa and UART. A gateway, twenty sensor nodes and the cloud uplink run in one emulation with one clock, so a mesh or a vehicle network behaves the same on every run.
Deterministic, every time
The same inputs give the same instruction stream, the same interrupts at the same instants, the same output. A failure seen once in CI is a failure you can replay, step back through and fix.
Faster than the board, when you want it
Translated execution runs most microcontroller firmware faster than real time. Time can also be stopped, slowed, or run as fast as the host allows, and a checkpoint lets a hundred tests start from the end of one boot.
Any block, model or RTL. The firmware cannot tell.
Develop the driver on the model at full speed. When the block's RTL compiles, switch it in with one option and run the same tests. Lumina Sim runs only that block cycle by cycle; the rest of the system stays at emulation speed.
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()
A gateway and its nodes, in one emulation.
Every node runs its own firmware, and every run plays out the same way. Set packet loss, range and interference, and a timing bug in a mesh network becomes a bug you can replay and fix.
Debugging the board cannot give you.
Debugwith GDB or your IDE, on every core at once, without a probe. Breakpoints on code, data, peripheral registers and bus transactions.
Traceevery instruction, memory access, interrupt and bus transfer to .cmtrace, and open it next to the RTL waves.
Coverthe firmware: line coverage from the run, no instrumentation and no rebuild.
Profilewhere the cycles go, per function and per core.
Inject faults:flip bits, drop packets, glitch the clock, cut the power, and check that the firmware recovers.
Save and restorethe whole system to .cmsnap, and resume anywhere.
Every action has a command, a Python call and a socket API.
Scripts and tests are plain Python. Agents can boot a board, load an image, set a breakpoint, read registers and report what happened, with the same determinism a person gets.
Results come out as JUnit XML, coverage reports and traces your pipeline already reads.
- runtest_beacon_seen_by_gatewaynrf52840dk
- ···test_node_survives_brownoutnrf52840dk
- ···test_aes_gcm_vectorsnucleo_h753zi
- ···test_ota_power_cutnucleo_h753zi
- ···test_linux_boot_from_snapzcu102
- ···test_can_bus_off_recoveryramn
- ···test_watchdog_resethifive1
Plain YAML and Python, in your repository.
- .cmboard
What it holdsA board: its SoC, memory, external devices, pins, firmware
FormatYAML
- .cmsoc
What it holdsAn SoC: cores, buses, memory map, peripherals, interrupts
FormatYAML
- .cmperiph
What it holdsA peripheral: registers, fields, interrupts, and its model or RTL
FormatYAML
- .cmsystem
What it holdsSeveral machines and the links between them
FormatYAML
- .cmscript
What it holdsA run: what to load, where to stop, what to check
FormatPython
- .cmtest
What it holdsTests, pytest style
FormatPython
- .cmsnap
What it holdsA saved system state
FormatBinary, versioned
- .cmtrace
What it holdsAn execution or bus trace
FormatBinary, documented
What is in CARME.
- Arm Cortex-M, Cortex-R, Cortex-A (32 and 64-bit)Preview
- RISC-V RV32 and RV64, vector, custom instructionsPreview
- SPARC, Power, x86, x86-64, Xtensa, MSP430Preview
- RTL co-simulation with Lumina Sim (SystemVerilog, Verilog, VHDL)Preview
- Multi-node systems: Ethernet, CAN, BLE, 802.15.4, UARTPreview
- GDB server, tracing, coverage, profiling, fault injectionPreview
- Save and restore, checkpointsPreview
- Python scripting and tests, socket APIPreview
- Linux x86-64Preview
Common questions.
Do I need to change or rebuild my firmware?
No. CARME loads the same ELF you flash to the board. Peripherals are modelled at the register level, so vendor HALs, RTOS drivers and Linux drivers run as they are.
How accurate are the peripheral models?
Each model follows the register map and behaviour in the vendor's reference manual, and is tested against the real firmware that uses it: vendor SDK examples, Zephyr and Linux drivers. When you need more than a model, run the block's RTL instead.
Is it cycle-accurate?
CARME is instruction-accurate and deterministic, which is what firmware development and CI need, and it is fast. Where timing matters at the clock edge, put that block in RTL: Lumina Sim runs it cycle by cycle in the same emulation.
My board is not on the list. Can I still use CARME?
Yes. Most boards are a known SoC plus external parts: write a .cmboard of a few dozen lines. A new SoC is a .cmsoc built from the peripheral library. For a custom SoC, our services team builds and maintains it with you.
Can I model a peripheral myself?
Yes. Describe the registers in a .cmperiph and write the behaviour in Python, or point it at your RTL. Both load without rebuilding CARME.
Which platforms does it run on?
Linux x86-64.
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
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
Run your firmware on CARME first.
Bring a board you ship, an image you build, and a test that matters. We run it with you on CARME and on the hardware, side by side.