Peripheral timing is where I'd expect agent-written firmware to break most, like DMA and interrupt ordering. Does the simulation model that cycle-accurately, or is it functional only?
This simulates the chip but do I still have to write the simulation of my actual board which often has equally complex ICs on it and mixed analog and digital?
Unfortunately yes, we are limited in the mixed signal domain right now, that is by design. you would need to interact with ICs at a data level or pin level transactions. This would be digital levels nothing analog.
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.
one spot where pin-level leaks is the ADC. tons of "firmware bugs" are really a big divider that can't recharge the sample cap in time, so readings come out low or depend on the previous channel. even just modeling source resistance vs sampling time would catch a lot of that
This. And Claude writes my firmware and does a pretty damn good job, and it can even test with a bench setup. So honestly, I don't think this simulator has much viability. It's a bitter message but I think the earlier they recognize this the better.
Yes I totally agree claude can write some damn good firmware! but at an enterprise development team scale for testing needs simulation. It has and always will for any critical embedded system. I think its the other way around that the viability will only get greater. Only this year did people start trusting LLMs with firmware so the bet based on what we saw at industry, the better the AI the better you want the simulation it can use for your development.
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.
But what if (due to the availability of AI) it becomes more common that hardware vendors provide simulation models with their hardware? That's the direction I'm hoping we will move in. And if it doesn't happen, perhaps FOSS enthusiasts will provide these models ...
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.
Certainly a win if someone makes it, but I think that with the help of AI, soon anyone with a datasheet can make those simulation models. And even if it's not that simple, open source folks will do it.
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.
Thank you, and for sure market is very fragmented. Which is exactly why we are starting small and modelling deep with stm32 as our workhorse here. The quirks we are finding them everyday! I have seen mcu controller behaviour from neither errata nor datasheet and thats the beauty of field testing.
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.
The Renode wrapper story is a useful one, because the build-versus-wrap decision is where a lot of infrastructure startups get stuck. Wrapping gets you to a demo quickly, but you inherit the upstream roadmap and the bug surface without control over either. For safety-critical customers I'd guess the harder problem than speed is fidelity: how do you show a skeptical avionics team that your simulated peripheral timing matches real silicon? Published correlation data against hardware traces for a few common MCUs might do more for trust than any feature list.
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.
The simulation itself is deterministic. inputs in, same outputs out. But our data collection for the hardware behaviour does naturally have a few things that are probalistic, we don't do any ML based modelling. No really fast LLM under the hood unfortunately
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?
Thank you, yes validation is the new bottleneck anywhere we talk to people. However for us in hardware its pretty simple, The board is king! Our setups are simpler now than it will be in the next few months coming as we add in more and more components to a “scenario”.
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.
In my Python/Postgres work, unit tests don't catch lock behavior, so I run migrations against a disposable Postgres container in CI. Keeping the failing board trace with the exact firmware revision sounds like the same kind of evidence when a simulator and the board disagree. The board being the reference makes sense to me.
haha you just reminded me of a time when AI forgot about the python GIL when doing pytest wrapped around my custom USB endpoint C++ code to talk to my firmware and it completely broke all my host USB because I didn't know how locks would affect my code. this was opus 4.6 though so I forgive em.
As a firmware engineer, I had Claude and Qwen spend about two hours writing my own multi-chip emulator. I can connect multiple firmware images together with gpio, UART, SPI, etc. I didn't even prompt for this, they decided they needed this capability on their own and wrote the emulator.
What does your product offer that Claude hasn't already suggested and built on its own?
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.
One thing I'd want to know about a self-built emulator is who checks it. If the same model that writes the firmware also writes the peripheral models from the datasheet, a misreading of, say, an SPI FIFO flush or a timer prescaler gets baked into both sides, and the tests pass for the wrong reason. The errata-level quirks the founders mention are exactly what a datasheet-derived model won't contain. The practical test is differential: capture a few traces from a real board (logic analyzer on the bus), replay the same stimulus in the emulator, and diff the cycle timing and register state. Without that, I'd treat green results from a homemade sim as unverified.
This addresses a major bottleneck in AI-assisted hardware development. AI agents can generate firmware quickly, but reliable testing against hardware behavior is a completely different challenge. The focus on simulation accuracy and continuous validation against real silicon is particularly interesting. I can see this becoming an important part of the embedded development workflow as AI coding agents advance.
Will be putting this out later today. We have just been updating so much that it became a burden to try to keep our model coverage upto date. But our cloud-sim API itself shows what models it can run: STM32F042/F048, ESP32-C3, RP2040, STM32F072, STm32F446, STm32 F401. We will get this live soon!
We are both! The cloud service is for everyone to try right now. We have a paid local license version too.
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.
I'd be quite worried about your name being too similar to Symantec (now part of broadcom, but the brand is apparently being preserved to some degree): https://sep.securitycloud.symantec.com/v2/landing
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.
Thank you! We will have to look into that, but theres actually an even closer to our name that we get auto-corrected to. if you really want to see how crowded naming is... just google "simantic". Our SEO goals truly need to peak to get through
we have thought about it, but its a name we came up ourselves, fits the bill and we have the domain for it. Can't ask for much more. its pretty rare for google to be our inbound and when we get to that point we would probably overtake that in SEO anyway
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.
Peripheral timing is where I'd expect agent-written firmware to break most, like DMA and interrupt ordering. Does the simulation model that cycle-accurately, or is it functional only?
This simulates the chip but do I still have to write the simulation of my actual board which often has equally complex ICs on it and mixed analog and digital?
Unfortunately yes, we are limited in the mixed signal domain right now, that is by design. you would need to interact with ICs at a data level or pin level transactions. This would be digital levels nothing analog.
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.
one spot where pin-level leaks is the ADC. tons of "firmware bugs" are really a big divider that can't recharge the sample cap in time, so readings come out low or depend on the previous channel. even just modeling source resistance vs sampling time would catch a lot of that
This. And Claude writes my firmware and does a pretty damn good job, and it can even test with a bench setup. So honestly, I don't think this simulator has much viability. It's a bitter message but I think the earlier they recognize this the better.
Yes I totally agree claude can write some damn good firmware! but at an enterprise development team scale for testing needs simulation. It has and always will for any critical embedded system. I think its the other way around that the viability will only get greater. Only this year did people start trusting LLMs with firmware so the bet based on what we saw at industry, the better the AI the better you want the simulation it can use for your development.
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.
But what if (due to the availability of AI) it becomes more common that hardware vendors provide simulation models with their hardware? That's the direction I'm hoping we will move in. And if it doesn't happen, perhaps FOSS enthusiasts will provide these models ...
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.
Certainly a win if someone makes it, but I think that with the help of AI, soon anyone with a datasheet can make those simulation models. And even if it's not that simple, open source folks will do it.
Hi,
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.
Thank you, and for sure market is very fragmented. Which is exactly why we are starting small and modelling deep with stm32 as our workhorse here. The quirks we are finding them everyday! I have seen mcu controller behaviour from neither errata nor datasheet and thats the beauty of field testing.
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.
The Renode wrapper story is a useful one, because the build-versus-wrap decision is where a lot of infrastructure startups get stuck. Wrapping gets you to a demo quickly, but you inherit the upstream roadmap and the bug surface without control over either. For safety-critical customers I'd guess the harder problem than speed is fidelity: how do you show a skeptical avionics team that your simulated peripheral timing matches real silicon? Published correlation data against hardware traces for a few common MCUs might do more for trust than any feature list.
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!
LLM bot account.
Congrats on the launch! Seems like a great time this type of thing, with all the new robotics, chips, etc companies coming out
I don't know too much about hardware simulation. How much of the simulation is deterministic, versus probabilistic or ML based?
The simulation itself is deterministic. inputs in, same outputs out. But our data collection for the hardware behaviour does naturally have a few things that are probalistic, we don't do any ML based modelling. No really fast LLM under the hood unfortunately
Congrats on the launch, this is a great one!!
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!
Thank you, yes validation is the new bottleneck anywhere we talk to people. However for us in hardware its pretty simple, The board is king! Our setups are simpler now than it will be in the next few months coming as we add in more and more components to a “scenario”.
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.
In my Python/Postgres work, unit tests don't catch lock behavior, so I run migrations against a disposable Postgres container in CI. Keeping the failing board trace with the exact firmware revision sounds like the same kind of evidence when a simulator and the board disagree. The board being the reference makes sense to me.
haha you just reminded me of a time when AI forgot about the python GIL when doing pytest wrapped around my custom USB endpoint C++ code to talk to my firmware and it completely broke all my host USB because I didn't know how locks would affect my code. this was opus 4.6 though so I forgive em.
As a firmware engineer, I had Claude and Qwen spend about two hours writing my own multi-chip emulator. I can connect multiple firmware images together with gpio, UART, SPI, etc. I didn't even prompt for this, they decided they needed this capability on their own and wrote the emulator.
What does your product offer that Claude hasn't already suggested and built on its own?
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.
One thing I'd want to know about a self-built emulator is who checks it. If the same model that writes the firmware also writes the peripheral models from the datasheet, a misreading of, say, an SPI FIFO flush or a timer prescaler gets baked into both sides, and the tests pass for the wrong reason. The errata-level quirks the founders mention are exactly what a datasheet-derived model won't contain. The practical test is differential: capture a few traces from a real board (logic analyzer on the bus), replay the same stimulus in the emulator, and diff the cycle timing and register state. Without that, I'd treat green results from a homemade sim as unverified.
This addresses a major bottleneck in AI-assisted hardware development. AI agents can generate firmware quickly, but reliable testing against hardware behavior is a completely different challenge. The focus on simulation accuracy and continuous validation against real silicon is particularly interesting. I can see this becoming an important part of the embedded development workflow as AI coding agents advance.
dare I say it has already advanced!
Would it be confusing if Simantic added support the Siemens Simatic S7-1500 PLC?
haha, now wouldnt want the world to have yet another PLC simulation software would we...
Is the list of supported models in the docs? Thats the first thing I went looking for
Will be putting this out later today. We have just been updating so much that it became a burden to try to keep our model coverage upto date. But our cloud-sim API itself shows what models it can run: STM32F042/F048, ESP32-C3, RP2040, STM32F072, STm32F446, STm32 F401. We will get this live soon!
Why is this a cloud service instead of a local emulator? I don't get it
We are both! The cloud service is for everyone to try right now. We have a paid local license version too.
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.
I'd be quite worried about your name being too similar to Symantec (now part of broadcom, but the brand is apparently being preserved to some degree): https://sep.securitycloud.symantec.com/v2/landing
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)
Thank you! We will have to look into that, but theres actually an even closer to our name that we get auto-corrected to. if you really want to see how crowded naming is... just google "simantic". Our SEO goals truly need to peak to get through
Having the same issue. I have stopped Googling it, since i just start to wonder if its better to just rebrand.
we have thought about it, but its a name we came up ourselves, fits the bill and we have the domain for it. Can't ask for much more. its pretty rare for google to be our inbound and when we get to that point we would probably overtake that in SEO anyway
Odd choice of microcontrollers for a tool that targets professional developers. That's nothing e.g. the automotive industry would use.
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.