Menu
▾
▴
Re: [Iverilog-devel] Cosimulation with Icarus
|
From: Evan L. <sa2...@cy...> - 2018-01-21 16:19:42
|
Hi Beat - here's how I did this a few years ago (2013). I'm not suggesting that this is the best way to do this, and it has problems, but at least you can get going quickly without trying to find a way to plug into an analog sim. This works (notwithstanding the timestep issue, below), but was specific to ngspice, and was only tested with ModelSim. $spice_start runs in the main (ModelSim/Icarus/etc) thread, and creates a Spice thread, which starts up the ngspice shared lib. The threads communicate by signalling on condition vars; the spice thread sources a netlist (including a .tran command), and runs. When it has analog output data it suspends, waiting for new digital input data, and then repeats. The Verilog code calls $spice_read before a clock edge to get the analog data back, and calls $spice_write after the edge to drive new digital data. Two initialisation tasks have already been called to (a) associate Verilog reals with Spice node names (for $spice_read), and (b) associate Verilog reals or scalars with Spice parameters for $spice_write (I only supported gain and resistor). So, basically, the two threads run in lock-step around digital clock edges. Very simple, but it worked, and was robust (for charging circuits with inductors). However, it has a major flaw in that you can't tell how long ngspice will take to stabilise on a new set of inputs, ie. when it fires it's data callback. I was generally seeing Spice steps of up to about 4.5ns. You have to be careful that things don't get out of sync between the digits and the analog. I can't post the code, unfortunately. On 20/01/2018 21:00, Beat Arnet wrote: > Hello David, > > Thank you very much for your response. > > And thanks to all others who responded with great pointers! > > Here is my attempt to summarize a basic mode of co-simulation: > > First, Icarus is started on the Verilog top module, which via a VPI > "synchronization" call, to be developed, waits for the circuit-simulator > to provide a first set of input values to the top module. > > After the synchronization function returns, Icarus runs the HDL > simulation for one clock cycle, then calls the "synchronization" VPI > again to exchange top-module output and input values with the circuit > simulator. > > Now, this approach will force the circuit-simulator to run at the > fundamental step-size of the HDL simulation, which is not very efficient > (as the digital clock will likely be much faster than the time constants > of the analog circuit being co-simulated). > > I am therefore thinking that at each synchronization step, Icarus should > look (simulate) into the future to determine when the next change of > top-level output signals will occur, assuming no input signals change. > The circuit simulator can then compare this time to the next simulation > time it has scheduled, and instruct Icarus to (re-)run to whichever time > occurs first. > > Does this approach sound fundamentally reasonable? > > And is there a way to save all simulation states in Icarus in order to > revert a run back from the future? > > Also, can Icarus be instructed to simulate for a given number of cycles > before the next VPI "synchronization" call is made? > > Thanks again, > Beat > > > > > > > On Thu, Jan 18, 2018 at 11:48 PM, David Fang <fa...@go... > <mailto:fa...@go...>> wrote: > > Hi, long-time lurker here. I have some experience with VPI > co-simulation with a custom gate-level digital simulator (hacprsim), > tested against VCS and (minimally) Incisive, though I admit I've > never tried to connect it to iverilog. > > The following code includes calls to the VPI library that > synchronize events coming from the host simulator and registers > callbacks to the custom simulator, effectively keeping internal > simulator event queues in-sync, and transporting values between the > two simulators. > > https://github.com/fangism/hackt/blob/master/src/sim/prsim/vpi-prsim.cc > <https://github.com/fangism/hackt/blob/master/src/sim/prsim/vpi-prsim.cc> > > As dated as the code seems, it's been working stably for years. > > This test directory contains some expected outputs when co-simulated > with VCS: > https://github.com/fangism/hackt/tree/master/test/prsim/vpi > <https://github.com/fangism/hackt/tree/master/test/prsim/vpi> > > Hope this helps some, or gives you some ideas? > > > On Thu, Jan 18, 2018 at 6:55 PM, Kevin Cameron <iv...@gr... > <mailto:iv...@gr...>> wrote: > > > Hi Beat, > > I've done Icarus/Gnucap, and Icarus/Spice3 before, and there was > an "embedded-vvp" branch supporting that, but it's probably well > out of date by now. > > It was with VPI; I was intercepting driver updates on > non-blocking assigns in Icarus and going through PWL sources to > drive the analog, and (undriven) current PWL sources to pick up > Voltages from the analog simulator. > > I was trying to get the guys at Analog Rails to work on it, but > the Gnucap folk were clueless and it didn't go anywhere. AR have > since moved on to using Xyce, and might be interested in > revisiting the problem, likewise eFabless. The idea was to get > the AR guys to netlist out of their schematic environment in > some easy-to-use way as a starting point. > > The extensions to the analog simulator are minimal if it has PWL > sources - just hack it to go through a C/C++ API to pick up the > PWL waveform - instance path and signal name and some code > (library/function) to load dynamically. > > Generally you want to have the analog simulator as master and > digital as the slave (analog does event scheduling) if you can. > > If you can get this to work there's possibly money in it - > > http://www.v-ms.com/ICCAD-2014.pdf > <http://www.v-ms.com/ICCAD-2014.pdf> > > - digital simulators can't do power or CDC detection. Analog > simulators are only (really) slow if the models they use require > solving, and Xyce is designed for parallel processing. > > Kev. > > > > > On 01/16/2018 04:57 PM, Beat Arnet wrote: >> Hello experts, >> >> I am looking for some advice on how to implement a >> co-simulation between Icarus and a circuit simulator. >> >> The objective would be to couple both simulators and have the >> circuit simulator provide stimuli to Icarus and feed Verilog >> output variables from Icarus back into the circuit simulator. >> >> My hunch is that I will have to implement a VPI module that >> communicates with the circuit simulator to exchange simulation >> data. >> >> What I am unsure of is how to implement such a VPI function >> similar to the $monitor statement, in that it is automatically >> called when a signal changes. >> >> Any tips and suggestions would be much appreciated. >> >> Kind regards, >> Beat >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org!http://sdm.link/slashdot >> >> >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... <mailto:Ive...@li...> >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel <https://lists.sourceforge.net/lists/listinfo/iverilog-devel> > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > <mailto:Ive...@li...> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > <https://lists.sourceforge.net/lists/listinfo/iverilog-devel> > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
