I would like to simulate some circuits with microcontrollers and analogue components, including simulated execution of the firmware. I imagined this would be a popular activity, so I was surprised when web searches did not find very much.
It seems to me that there are 3 plausible approaches to this:
Simulate the microcontroller internals, perhaps at gate level, or with additional MSI-level XSPICE models. Probably slow, and I found no pre-existing gate-level models, so heavy development needed. Perhaps some existing HDL processor descriptions can be compiled to XSPICE circuit descriptions.
Couple to an instruction-level microcontroller simulator using XSPICE. I found MCUsim and d_process software in the archive for this list and on Sourceforge. There is a problem with time, as without special coding an MCU simulator will only move forward, but the analogue simulator often makes time reverse itself. MCUsim and d_process seem to rely on generating the MCU clock in the SPICE circuit, so that timesteps are no more than a clock period. I have not really convinced myself that will work unless an analogue oscillator is used. It also seems likely to be slow, as the timesteps will still be small when the MCU is sleeping or in busy-wait. For many firmware programs that will be most of the time.
Execute high-level code for the firmware (with some conditional compilation) directly, inside an XSPICE model. Again, time reversal is a problem but it is possible to capture the execution state and replay it. I have a working example, but it seems unlikely to become a popular solution: there are two families of macros to use, restriction of coding style, conditional compilation, and the SPICE version of the firmware must emulate on-chip peripherals.
Are there other approaches or problems that I have missed?
Last edit: Giles Atkinson 2021-01-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Couple to an instruction-level microcontroller simulator using
XSPICE. I found MCUsim and d_process software in the archive for
this list and on Sourceforge.
There is a problem with time, as without special coding an MCU
simulator will only move forward, but the analogue simulator
often makes time reverse itself.
If you think about it, an analog simulator needs backstepping
because it made an prediction error that it wants to correct by
retrying. So backstepping is not necessary for the micro; it
suffices to 'freeze' after producing inputs while SPICE figures
out what the next analog timestep (and outputs) will be. Actually,
the micro should freeze for a number of analog timesteps, until
the analog time exactly matches the next sample rate edge
of the micro again. A simple handshake between the two
simulators should do.
MCUsim and d_process seem to rely
on generating the MCU clock in the SPICE circuit, so that
timesteps are no more than a clock period.
I have not really convinced myself that will work unless an
analogue oscillator is used.
It solves a practical problem in the simplest possible way:
the PULSE source in SPICE has internal breaks exactly at every
edge, while trying to run a .TRAN simulation for an exact
amount of time may not be guaranteed as precisely. So a PULSE
source used as the MCU clock (better: sample rate) will exactly
synchronize both simulators.
It also seems likely to be slow, as the timesteps will still be
small when the MCU is sleeping or in busy-wait. For many
firmware programs that will be most of the time.
You only need the synchronization at the sample rate (typically
1000x slower than CPU clock). In between sample rate pulses
the digital simulator is 'blind' and can run at topspeed.
In practice you don't really need a gatelevel simulation of the
digital part, behavioral (software emulator) will do. The
peripherals could need to be specified in SPICE, but then it
might be that the 'sample rate' becomes the CPU clock again.
So it should be carefully thought out if that is really
necessary.
Execute high-level code for the firmware (with some conditional
compilation) directly, inside an XSPICE model. Again, time
reversal is a problem but it is possible to capture the execution
state and replay it.
This is not a problem if you believe my suggestions above.
-marcel
Last edit: marcel hendrix 2022-09-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I read it and referred to it (as d_process) in my posting. Very nice, but am I wrong to think that the XSPICE model is synchronised by forcing the SPICE simulation step time to the MCU clock interval? And I think that the MCU simulator was in a separate process, which may cause a problem with simulation speed.
And Marcel Hendrix wrote:
It solves a practical problem in the simplest possible way:
the PULSE source in SPICE has internal breaks exactly at every
edge, while trying to run a .TRAN simulation for an exact
amount of time may not be guaranteed as precisely. So a PULSE
source used as the MCU clock (better: smaple rate) will exactly
synchronize both simulators.
Yes, it is simple, but there is a cost in simulation speed. It will not really be exact, but trying to be more exact than an instruction time is pointless. A PULSE source seems much better than an analogue oscillator for clock-cycle level synchronisation. But would an XSPICE digital clock generator work in the same way?
You only need the synchronization at the sample rate (typically
1000x lower than CPU clock). In between sample rate pulses
the digital simulator is 'blind' and can run at topspeed.
You need synchronisation whenever one simulator can see the other. So, input sampling by the MCU, MCU output change (timer or result of computation) ... Analogue comparator in the MCU is an interesting case, as it monitors the input continuously.
... but then it might be that the 'sample rate' becomes the CPU clock again.
So it should be carefully thought out if that is really necessary.
And that is why I think this is an interesting problem. Is it possible to make an XSPICE model that can be used without understanding how it works? One that a person can include in their circuit and then think only about circuit design and firmware.
Last edit: Giles Atkinson 2021-01-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it may be difficult to get per cycle arm "macro" models and it also makes no sense to simulate unneeded parts of the possibly complex mcu. So the d_process is not about simulating the cpu, but it rather provides an interface to a firmware that may run on host cpu within qemu, ... , and therefore simulation is very fast, the bottleneck is still the analog spice simulation. If you organize the code properly, then exactly the same code may run in this spice eco-system as in the final firmware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it may be difficult to get per cycle arm "macro" models
Indeed, a perfect example of a licensable trade secret. But instruction-level simulation is possible using only the data sheet, Likely already done. And anyone relying on tighter timing would be unwise to rely on readily-available simulation!
... within qemu, ...
My recollection of my previous visit to your site was entirely wrong. This time (a few minutes ago), I failed to find the XSPICE source.
If you organize the code properly, then exactly the same code may run in this spice eco-system as in the final firmware.
A very nice proposition. But any restrictions ?
Last edit: Giles Atkinson 2021-01-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Restriction is simple, simulation is limited to functional part and does not include per-cycle cpu timing simulation, which in turn means you should profile the code then separately on a MCU in the case your application is real-time control, streaming, ... and strict timings must be met, but this is then the problem of firmware architecture, ... and is not really something you would want to "debug" with spice. From functional point of view, hardware and analog interaction is limited only to the (yours) provided "macro" models of the peripherals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the link. This time I found it, and found that in fact my initial impression (from some months ago) was correct. If the time reversal problem is solved, it is because analogue time steps are not bigger than half the processor clock period. But since you used a digital oscillator that may not happen. Easily fixed if it is really a problem.
But with a message to another process on each clock cycle, I find it hard to imagine it is fast. You say that the analogue simulation dominates the run time, but in many cases the analogue simulation would be much faster if it was able to use more natural time steps.
I think it may be possible to synchronise only on circuit interactions with the MCU and simulate more quickly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am currently working on the same main goal. The Approach I chose is to use ngspice in its shared-library form and define the digital outputs as some form of piecewise-linear signals as "external" voltage sources. (https://sourceforge.net/p/ngspice/discussion/127605/thread/9939a5ed15/)
I am currently still struggling a bit with the synchronization, but the callback functions prepared should provide all the interface that is necessary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to simulate some circuits with microcontrollers and analogue components, including simulated execution of the firmware. I imagined this would be a popular activity, so I was surprised when web searches did not find very much.
It seems to me that there are 3 plausible approaches to this:
Simulate the microcontroller internals, perhaps at gate level, or with additional MSI-level XSPICE models. Probably slow, and I found no pre-existing gate-level models, so heavy development needed. Perhaps some existing HDL processor descriptions can be compiled to XSPICE circuit descriptions.
Couple to an instruction-level microcontroller simulator using XSPICE. I found MCUsim and d_process software in the archive for this list and on Sourceforge. There is a problem with time, as without special coding an MCU simulator will only move forward, but the analogue simulator often makes time reverse itself. MCUsim and d_process seem to rely on generating the MCU clock in the SPICE circuit, so that timesteps are no more than a clock period. I have not really convinced myself that will work unless an analogue oscillator is used. It also seems likely to be slow, as the timesteps will still be small when the MCU is sleeping or in busy-wait. For many firmware programs that will be most of the time.
Execute high-level code for the firmware (with some conditional compilation) directly, inside an XSPICE model. Again, time reversal is a problem but it is possible to capture the execution state and replay it. I have a working example, but it seems unlikely to become a popular solution: there are two families of macros to use, restriction of coding style, conditional compilation, and the SPICE version of the firmware must emulate on-chip peripherals.
Are there other approaches or problems that I have missed?
Last edit: Giles Atkinson 2021-01-10
On 2021-01-10 13:26, Giles Atkinson wrote:
[..]
If you think about it, an analog simulator needs backstepping
because it made an prediction error that it wants to correct by
retrying. So backstepping is not necessary for the micro; it
suffices to 'freeze' after producing inputs while SPICE figures
out what the next analog timestep (and outputs) will be. Actually,
the micro should freeze for a number of analog timesteps, until
the analog time exactly matches the next sample rate edge
of the micro again. A simple handshake between the two
simulators should do.
It solves a practical problem in the simplest possible way:
the PULSE source in SPICE has internal breaks exactly at every
edge, while trying to run a .TRAN simulation for an exact
amount of time may not be guaranteed as precisely. So a PULSE
source used as the MCU clock (better: sample rate) will exactly
synchronize both simulators.
You only need the synchronization at the sample rate (typically
1000x slower than CPU clock). In between sample rate pulses
the digital simulator is 'blind' and can run at topspeed.
In practice you don't really need a gatelevel simulation of the
digital part, behavioral (software emulator) will do. The
peripherals could need to be specified in SPICE, but then it
might be that the 'sample rate' becomes the CPU clock again.
So it should be carefully thought out if that is really
necessary.
This is not a problem if you believe my suggestions above.
-marcel
Last edit: marcel hendrix 2022-09-08
Here I wrote how I do it: https://www.isotel.org/mixedsim/embedded/motorforce/
Uros,
Yes, I read it and referred to it (as d_process) in my posting. Very nice, but am I wrong to think that the XSPICE model is synchronised by forcing the SPICE simulation step time to the MCU clock interval? And I think that the MCU simulator was in a separate process, which may cause a problem with simulation speed.
And Marcel Hendrix wrote:
Yes, it is simple, but there is a cost in simulation speed. It will not really be exact, but trying to be more exact than an instruction time is pointless. A PULSE source seems much better than an analogue oscillator for clock-cycle level synchronisation. But would an XSPICE digital clock generator work in the same way?
You need synchronisation whenever one simulator can see the other. So, input sampling by the MCU, MCU output change (timer or result of computation) ... Analogue comparator in the MCU is an interesting case, as it monitors the input continuously.
And that is why I think this is an interesting problem. Is it possible to make an XSPICE model that can be used without understanding how it works? One that a person can include in their circuit and then think only about circuit design and firmware.
Last edit: Giles Atkinson 2021-01-11
it may be difficult to get per cycle arm "macro" models and it also makes no sense to simulate unneeded parts of the possibly complex mcu. So the d_process is not about simulating the cpu, but it rather provides an interface to a firmware that may run on host cpu within qemu, ... , and therefore simulation is very fast, the bottleneck is still the analog spice simulation. If you organize the code properly, then exactly the same code may run in this spice eco-system as in the final firmware.
Indeed, a perfect example of a licensable trade secret. But instruction-level simulation is possible using only the data sheet, Likely already done. And anyone relying on tighter timing would be unwise to rely on readily-available simulation!
My recollection of my previous visit to your site was entirely wrong. This time (a few minutes ago), I failed to find the XSPICE source.
A very nice proposition. But any restrictions ?
Last edit: Giles Atkinson 2021-01-11
the fork link is provided on this page below https://www.isotel.org/mixedsim/index.html
Restriction is simple, simulation is limited to functional part and does not include per-cycle cpu timing simulation, which in turn means you should profile the code then separately on a MCU in the case your application is real-time control, streaming, ... and strict timings must be met, but this is then the problem of firmware architecture, ... and is not really something you would want to "debug" with spice. From functional point of view, hardware and analog interaction is limited only to the (yours) provided "macro" models of the peripherals.
Thank you for the link. This time I found it, and found that in fact my initial impression (from some months ago) was correct. If the time reversal problem is solved, it is because analogue time steps are not bigger than half the processor clock period. But since you used a digital oscillator that may not happen. Easily fixed if it is really a problem.
But with a message to another process on each clock cycle, I find it hard to imagine it is fast. You say that the analogue simulation dominates the run time, but in many cases the analogue simulation would be much faster if it was able to use more natural time steps.
I think it may be possible to synchronise only on circuit interactions with the MCU and simulate more quickly.
Hello to all,
I am currently working on the same main goal. The Approach I chose is to use ngspice in its shared-library form and define the digital outputs as some form of piecewise-linear signals as "external" voltage sources. (https://sourceforge.net/p/ngspice/discussion/127605/thread/9939a5ed15/)
I am currently still struggling a bit with the synchronization, but the callback functions prepared should provide all the interface that is necessary.