shong0504

Yes you're absolutely right about that. We talked to a bunch of aerospace teams who tried to use Renode and QEMU in their CI, but ended up scrapping it because their timing mechanisms were terrible and very inaccurate.

We do try to make our simulations as timing-accurate as possible. We are going to publish a report soon, to outline every gap between silicon and simulation, so these teams know exactly what to expect.

We're also not trying to replace HIL testing. As a firmware engineer myself, I know that hardware is and will always be the source of truth, and we're not changing that. What we can do, is reduce the amount of testing that needs to be done on hardware, because HIL testing will always be slow and clunky. Things like application logic, and replicating garbage data on something like a CAN bus, is much better suited to be tested in simulation, and that's the gap we are focusing on.

Let us know if you have any other questions!

I would say that is true, that hardware vendors should and can provide simulation models with their hardware. We know they can because they rely entirely on simulation to test their chips before tapeout.

We even tried to work with chip vendors (won't name here but they are 2 out of the 10 biggest microcontroller designers), but in reality, them providing their own simulation is a little bit counterintuitive for them.

They make their money on selling chips, and their thought is that providing a simulator would make it so that people buy less chips. If they do provide a simulator, it would be hella expensive, like through the Synopsys Virtualizer, which costs $500k per seat.

For RISC-V and open-source MCUs, they are easy to simulate. Just run the RTL through something like Verilator, and you have a fully working simulation.

We do hope that chip companies eventually do exactly that. We are also firmware engineers, and our goal is to make the simulation software we needed while working in the field. Either we make it, or they make it. Win-win in my opinion.

Anyone can make their own emulator. The ISA is publicly documented, and MCU datasheets are also public. There are also open source emulators like Renode and QEMU, like we wrote in our post. I would say there are two main differences between us and you using Claude to make its own emulator:

1. Although the ISA and peripheral behavior for the MCUs are documented, there are hardware intricacies that can't be effectively done with just an LLM. Things like register transaction timings, and hardware bugs (yes chip designers make mistakes in designs that aren't shown in documentation) requires many weeks of constant bench testing to detect and fix.

2. Maintenance. Yes, Claude is incredibly good. But it still makes mistakes. We understand that, and we're always making updates to our simulation software whenever there is a bug. You however, as a firmware engineer whose job is to make products and ship code, I would assume you would rather work on that instead spending all day fixing and updating a simulator. We do the maintenance for you, so you can focus on building your things.

Hope that answers your question! We're not claiming that AI can't do it with enough time and resources. It's just that the people who find value in this would rather spend their time on other things.

Automotive manufacturers typically use NXP, TI, or Infineon MCUs. In fact, we do support them!

It’s currently not public on our simulation platform because they are still undergoing testing and development. We don’t want to ship a half baked model, especially for uses like automotive where they have to go through strict certification testing. Hope that answers your question.