A while back I worked out what the minimum extensions to C++ would be for making it easy to model hardware, you can find that at http://parallel.cc. In a similar vein I wondered what the minimum extension to an analog simulator would be to support mixed-signal simulation, and that one turns out to be programmable PWL sources. Having previously implemented it in SPICE3 and GnuCap, it didn’t take long to add it into Xyce –
https://github.com/kev-cam/xyce-top
In the Xyce input that looks like this to add an inverter –
.SUBCKT INV VDD OUT IN
VPWL1 DRV 0 PWL FILE "code:./gates.so:AttachInv:output,Vtol=1e-3,Ttol=1e-13,Delay=2e-9,RiseT=1e-9,FallT=1e-9"
IPWL2 IN 0 PWL FILE "code:./gates.so:AttachInv:input"
IPWL3 VDD 0 PWL FILE "code:./gates.so:AttachInv:vdd"
ROUT DRV OUT 100
COUT OUT 0 1e-14
.ENDS
I use current sources with zero current as Voltage probes, so the inverter model, which is C++ code compiled into the dynamically loadable shared library gates.so, has two of those for the input and Vdd, and a V-PWL for output.
Here’s the Xyce output for a string of them –
The complete code can be found here –
I’ll be grateful if you please explain a step-by-step guide from scratch for how to build any Mixed-Signal simulator.
To boil it down: there are a few key differences between a digital simulator and an analog one –
1. Analog simulators understand potential and flow (Voltage & current) on a wire, digital simulators only do one those.
2. Analog simulators have signals that are discrete, but in the derivatives.
3. Analog models, like those of transistors, need to be considered together (requiring matrix solvers for partial differential equations) . Digital models work independently.
Digital models require less support; you can view them as a degenerate case of analog modeling, with only potential as inputs and outputs, and no need for matrix solving. Digital models are also finite state machines, where all outputs can be calculated on any input change.
So the above mechanism supports simulation where you translate your logic circuit into a C++ FSM that communicates through the PWLs. You can do that by repurposing pieces of Icarus Verilog, Verilator, or use my code generator (https://github.com/kev-cam/v2k-top, but needs more work).
Different analog simulators handle PWL sources differently, Xyce has two lists per PWL – one for values, one for breakpoints (where analog should be evaluated). Rather than using a global scheduler as one has in (say) Icarus scheduling is local through the PWL breaks.
Analog schedulers have more precision than Verilog simulators, it’s usually not a good idea to try to replicate digital timing in mixed signal environment – use the extra precision to get more reliable results.
For handling Xs & Zs see – http://cameron-eda.com/2020/06/16/unnecessary-problems-x-propagation/
X data (uncertainty) can be handled orthogonally in analog and passed-through.
If you want to use a full digital simulator (like Icarus), it can be run on a separate thread, with your analog simulator as the master control. Generally analog simulators have an acceptance phase where they work out how big a step to take, you let the digital simulator run in that slot until it interacts with the analog world (causing analog evaluation).
Why did you choose a PWL source as the input/output for the analog part? The analog simulator can’t do much with the extra events (before and after the current one), and I guess the digital simulator also has
a problem when it is running a real program instead of set of test vectors. Doesn’t a simple array of digital levels suffice?
The signals in an analog simulator are mostly PWL, and hacking the code in the simulator that implements the PWL sources is an easy way to hook in external code. An analog simulator works out the derivatives at a given point that will get it to another point in time, abrupt changes (infinite dV/dt) make the math unstable.
Changing the analog simulator might be an idea. By converting the circuit to a Digital Wave Filter, differential equations turn into a (digital) filter with fixed coefficients and fixed sample-rate. The conversion is lossless, and one might think of it a “Z-transforming a circuit.” Because the sample rate is fixed, synchronization with a digital simulator becomes very easy, and a digital filter can be almost trivially parallelized. No sparse matrices, because the structure of the netlist is reflected into the code. A problem is to get the data of intermediate nodes and branches out. A serial bus with a network protocol might be sufficient.
@Marcel, yes, the idea is to integrate discrete simulation techniques in with the analog, there are a slew of AI matrix-math processors that could be used, as well as FPGAs.
Low-latency SERDES is something in the Cameron EDA portfolio, particularly because parallel simulation needs it.