<@U01819B63HP>: Thank you for the webinar with Ma...
# xschem
@Stefan Schippers: Thank you for the webinar with Matt Venn! One point I'd like to make related to one of your last comments in the Q&A: It is possible to do co-simulation with iverilog, both in Xyce and in ngspice. Xyce has this written up here: https://xyce.sandia.gov/files/xyce/AppNote-MixedSignal.pdf (except this is a very technical and software-oriented application note, and I'm pretty sure there's one that is more user-oriented). The cosimulation between ngspice and iverilog is buried in an obscure branch and I need to bring it back out into the sunshine. Both are done in the same way, using one simulator as the primary one and setting up the other as a sub-process and communicating with it via a pipe. The ngspice version uses iverilog as the primary simulator, which then launches ngspice as a sub-process. Xyce does it the other way around, which makes more sense. At one time a few years ago, I started looking into the idea of writing a module for xspice which would read a compiled vvp file from iverilog and use it to generate xspice events. I never had the time to work on it but I think it is feasible and mainly involves ripping the vvp parser out of iverilog and rewriting it to use the xspice event queue.
🌍 1
Thank you for the question. Yes there are lot of interesting things that can be done. One thing to investigate is how synchronization works, and how to avoid interlocking/dead locks. One scenario for example is a digital block feeding some outputs fo the ngspice block and some ngspice outputs going as inputs to the digital block. ngspice does its time stepping calculation, so it needs inputs evaluated at a specific time. Event driven (digital) simulators on the other hand will jump to the next event, possibly skipping a huge time if nothing is changed. SO there must be some API for this, like the analog simulator generating an event in the future where the digital tool must stop at and dump the output values... I am not an expert in this area, however i have seen many cosimulations deadlocked for synhronization issues (analog waiting for digital to provide signals, digital blocked waiting for analog)...
In some cases the analog time step advance does not meet the required precision (error estimation) in this cases the analog simulator throws away the last point and advances with a smaller timestep. This happens for example if one signal is abruptly changing state, say from vss to vcc . So if there is a digital part cosimulating there must be some way to 'roll back' the digital engine.
I don't know how the ngspice transient analysis solver operates. If the analog simulator never throws away a time step (may be because it is smart enough to always estimate the correct time advance) then it will be much simpler...
This old 1996 paper does some investigation.
Usually much of the problems are avoided by intelligently splitting the circuits so there are synchronization devices (flops) at the domain boundaries.
🌍 1