Menu
▾
▴
Re: [Iverilog-devel] Cosimulation with Icarus
|
From: Kevin C. <iv...@gr...> - 2018-01-21 10:32:45
|
Hi Beat, Digital models are a degenerate form, i.e. less accurate than SPICE, if you try to do mixed-signal simulation as co-simulation it generally doesn't go well. It's better to take the approach of using an analog simulator framework and plugging-in digital models. If you read through the Verilog-AMS LRM - http://www.accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf - you can familiarize yourself with the concept of "drivers", "receivers" and connect-modules. The easiest way to get an AMS simulation to work well with Verilog is to convert on the driver/receiver boundaries for individual modules. If the boundaries are converted to PWL sources the analog simulator will call to re-evaluate them as needed. Converting (D->A) on resolved signal values causes a bunch of problems. Digital (Verilog) simulator people are usually unfamiliar with the "receiver" concept, but it is very relevant if you want to do nettype conversion in SystemVerilog (without analog). Analog simulators usually compute a largest possible step, and then call all the models to see if it's acceptable (the "acceptance time"), some may shorten the step (e.g. the PWL sources). After all the analog models are happy you can step the digital models up to the same time or stop at any D->A interaction, pull in the acceptance time and ask for the analog to be redone. An A->D event (voltage crossing) doesn't require pulling in the acceptance time. After digital is done analog can commit to the acceptance time and do another step. If you do something which stops the analog for every active digital time, it will crawl. That problem got me my last simulator job. The last simulator I worked on it was also a bit tricky to back out of the D->A assignment into re-evaluating the analog. You may find it easier to run analog and digital on separate threads. I.e. if you see a D->A assignment you want to force acceptance in the analog simulator before you actually do it, just stopping the digital thread saves a lot of code. Kev. On 1/20/2018 1:00 PM, 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 |
