Before Simantic, we were ex-firmware engineers at companies like Neuralink and Tesla. We’ve worked on some of the coolest projects, like the Cybertruck and Roadster, back when they were still early prototypes.
We started working on firmware back when ChatGPT didn’t exist yet, but over the years, we saw how much of the engineering and development work has been automated as the frontier models improved to this point. In software, AI can run and test code inside your computer in a matter of seconds. But as firmware engineers, we didn’t have that luxury. An AI agent can write firmware in seconds, but in order to test it, we had to flash a physical board, then manually run tests using expensive and clunky tools with software made over a decade ago.
To speed up the validation loop, we built the simulation layer that lets AI agents test the firmware and make decisions based on evidence, instead of waiting for the engineer to run tests for them. We used to spend hours testing our firmware manually on devboards, but now we use our own simulation to validate firmware in seconds.
What we offer: - Virtual devboards you can program and run with a single API call, without leaving your terminal. - An AI code reviewer for firmware, that makes informed decisions based on evidence, using our simulation as a verification engine. - A CI/CD pipeline for your hardware projects that validates your firmware against a simulated version of the microcontroller on every commit.
Here is a demo of our simulation used in an AI code review session: https://www.youtube.com/watch?v=kBK1ZjGWWbQ
Our users are using Simantic for bare-metal and RTOS development for applications like flight controllers, electric vehicles, robotics, and satellites. For safety critical systems like avionics and automotives, a robust simulation system is incredibly important, because every change in the firmware puts a human life at stake, especially for machines that cost hundreds of thousands to millions of dollars.
We recently helped an early stage space startup building satellites, to test their firmware on hardware that they don't yet have. Even the development modules for those satellites costs over $100k, and we helped them do that at just a hundredth of the cost and time.
Early on in our journey, we established our idea to make better simulation but didn’t have a clear idea of how we would do it, we considered developing our software around open source emulation frameworks like Renode (https://github.com/renode/renode) and QEMU (https://www.qemu.org/), because they were tools already used within the firmware industry. We built our MVP that was essentially a wrapper around Renode, but we quickly realized there were a lot of limitations to doing this.
1. We were bottlenecked by the development speed of Renode themselves. We tried making contributions on Github to fix issues we came across, but the speed in which we could merge our features in was not fast enough for a startup like us trying to move fast.
2. Renode is built using Dotnet, and it was proving itself to be slower than we would have liked. Renode was released in 2017, which was when all code was still being written by hand, so I think it made sense looking back, but there were limitations because of the language itself.
3. The open source tools were bloated, with features that we would never use. Yes, there were a breadth of features, but we had a lot of things we had to work around just because we couldn’t remove or change them. Users were complaining about simulation accuracy. Renode is an emulator at the core, but our users, especially those who are building systems where timing accuracy is crucial did not find the accuracy good enough to validate their firmware.
Because of these issues, we made our own simulation engine from scratch, fully written in Rust.
- Our simulation is focused on accuracy. Open source frameworks often focus on expandability and developer experience, which means there were a lot of tradeoffs made to prioritize a breadth of models rather than going deep into a set of select models.
- We have our own hardware validation rigs running 24/7 to ensure our simulation models are as close to real world hardware as possible, and any gaps are detected and fixed as soon as we can. It currently looks like devboards connected to a Saleae Logic MSO and a SWD bus, controlled by a Linux PC, running Claude 24/7 just finding these gaps.
Our cloud-hosted simulator is available to use right now! We also provide a native binary with our developer plan licenses that let you run your firmware on your machines locally without any limitations.
Check it out at https://simantic.com/cloud-sim, and you can start using our AI firmware reviewer bot in your own Github repos here: https://simantic.com/dashboard/simantic-bot.
We currently have support for some models of the STM32F0, F4, H7 series MCUs, ESP32-S3/C3, and RP2040, but we’re constantly working to release new models every week, and improve our existing ones.
Thank you, and if you have any questions, feel free to send us an email at founders@simantic.dev
What does your product offer that Claude hasn't already suggested and built on its own?
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.
This was kind of part of our original offerings to have a firmware mixed signal co-simulation. Run firmware--> see Spice level simulations happen. But this was a case where the speed to fidelity trade off really didnt make sense... yet. We were spreading ourselves thin on a long horizon project with nothing to show for it during the YC term.
We will come to revisit this problem for sure as we have heard many of our customers ask similiar question for analog IC purposes. Just have to take it one step at a time.
The other contributing cause is the actual lack of silicon in supply and we are seeing it especially for the automotive industry, which is only spiking demand for better simulations to unblock teams.
If you want to ship with agents at scale you need a good testing pipeline now more than ever. We don't replace the bench setup test, we look to enhance what you bring to it.
But that doesn't take away from the fact that, yes you could just let your LLM continuously loop on some hardware setup, rinse and repeat for weeks. If you have the hardware and the time to spare.
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.
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!
First of all, congrats on the launch. I have worked with many such products and this is something that is required. There is no one solution fits all in this domain. Each vendor has their quirks that. So this is overall a great problem to tackle and kudos to you for taking this up.
Could you elaborate a bit more on how this is different from Renode?
Also you are entering into a market that has well established legacy players. Most of the firmware is developed in China. How do you intend to make a space for yourself in such a scenario.
I think our biggest difference to renode is the silicon validation and our commitment to keeping our simulation honest. I have struggled to find simulators that people actually put the measured differences and that is the direction we will go. We haven’t put our silicon validation benchmarks public yet but we will in the coming months!
As for legacy players, they don’t fill the niche enough. Thats why we exist and as a startup can fill this niche for the people that need it, whether its china, or anywhere else.
I don't know too much about hardware simulation. How much of the simulation is deterministic, versus probabilistic or ML based?
I work on agent tooling on the software side, and the pattern you describe is exactly what we see there too. Generation got fast and cheap. Validation stayed slow and human. In software the review queue became the bottleneck.
In firmware it sounds worse, because the queue was a physical board!
Curious how you triage the gaps your validation rigs find. When the sim and the board disagree on timing, how do you decide which one is wrong? And how often is it the board setup rather than the model?
Good luck today, rooting for you!
But, this is a great point because we do think about what is a bench artifact from the dev boards we are testing versus something that would not show up in production pcb.
But we started as local only however quickly learned thag cloud has a few advantages. we can have seamless github integration setup for people. And quite a few people prefer when things just work with a setup on every commit!
Convenience of the cloud or you can setup yourself with developer license.
Firmware validation isn't particularly close to symantec's products from my perspective, but I'm sure a lawyer would be happy to disagree for the right retainer.
(congrats on your launch in any case)
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.