|
From: Beat A. <bea...@gm...> - 2018-01-25 17:01:09
|
This is indeed an excellent starting point. Thank you very much, Beat > On Jan 22, 2018, at 16:10, Stephen Williams <st...@ic...> wrote: > > What you are describing (except for the speculative evaluation) is pretty much > exactly what simbus does. Look for "simbus" in github. Yes, it interfaces with > Icarus Verilog, I use it for my day job. > > >> On Sat, Jan 20, 2018 at 1:00 PM, Beat Arnet <bea...@gm...> 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...> 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 >>> >>> 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 >>> >>> Hope this helps some, or gives you some ideas? >>> >>> >>>> On Thu, Jan 18, 2018 at 6:55 PM, Kevin Cameron <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 >>>> >>>> - 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... >>>>> 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 >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > > > -- > Steve Williams "The woods are lovely, dark and deep. > st...@ic... But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep." |