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.
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.
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.
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
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.
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.
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.
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.
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.
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!
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
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.
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.
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.