Menu
▾
▴
iverilog-devel
|
From: Beat A. <bea...@gm...> - 2018-01-17 00:57:35
|
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 |
|
From: Kevin C. <iv...@gr...> - 2018-01-19 03:07:25
|
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 |
|
From: David F. <fa...@go...> - 2018-01-19 05:12:01
|
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 lis...@li...://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 > > |
|
From: Cary R. <cy...@ya...> - 2018-01-19 05:49:59
|
Look in the vpi directory where all the system function Icarus supports are implemented. That directory and the standard to understand what the various VPI commands do should allow you to get the VPI interface to work.
Cary
On Thursday, January 18, 2018, 9:12:06 PM PST, David Fang via Iverilog-devel <ive...@li...> 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
Iverilog-devel@lists. sourceforge.net
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
Iverilog-devel@lists. sourceforge.net
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
|
|
From: Felix S. <fe...@sa...> - 2018-01-19 08:42:35
|
On Thu, Jan 18, 2018 at 06:55:03PM -0800, Kevin Cameron wrote: > 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. Hi there. at the time Kevin was experimenting with this, gnucap was in transition to plugins. presumably, only Al knew how it was supposed to work. The main idea is that contributions are plugins, and incomplete contributions can be immediably shared (and are workable) without needing either review or changes to the kernel. we are getting there. i have not used icarus or revisited icarus plugins since, but things are evolving. - there are more plugins available now. i see them as proof of concept of the idea. but some of them work quite well. - cosimulation related plugins exist [1,2]. this is analog only, but the idea is clear. with some tweaking, a similar approach could support connectmodules and a discrete event protocol. - the solver is now preloadable. with this it is possible to hook in domain specific calls. i use this for physics based models. in principle you could put vvp or a vpi interface here. > Generally you want to have the analog simulator as master and digital > as the slave (analog does event scheduling) if you can. yes. cheers felix [1] https://github.com/gnucap/gnucap-coupling/blob/master/README [2] https://github.com/gnucap/gnucap-jack |
|
From: Kevin C. <iv...@gr...> - 2018-01-21 09:29:33
|
Hi Felix, I handed over working code (still have it around somewhere), got it back converted to a "plugin" (unnecessarily), and not working. Given Xyce is a lot better and GPL'd, I'm considering Gnucap a dead project now. Kev. On 1/19/2018 12:16 AM, Felix Salfelder wrote: > On Thu, Jan 18, 2018 at 06:55:03PM -0800, Kevin Cameron wrote: >> 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. > Hi there. > > at the time Kevin was experimenting with this, gnucap was in transition > to plugins. presumably, only Al knew how it was supposed to work. The > main idea is that contributions are plugins, and incomplete > contributions can be immediably shared (and are workable) without > needing either review or changes to the kernel. > > we are getting there. i have not used icarus or revisited icarus plugins > since, but things are evolving. > > - there are more plugins available now. i see them as proof of concept > of the idea. but some of them work quite well. > > - cosimulation related plugins exist [1,2]. this is analog only, but the > idea is clear. with some tweaking, a similar approach could support > connectmodules and a discrete event protocol. > > - the solver is now preloadable. with this it is possible to hook in > domain specific calls. i use this for physics based models. in > principle you could put vvp or a vpi interface here. > >> Generally you want to have the analog simulator as master and digital >> as the slave (analog does event scheduling) if you can. > yes. > > cheers > felix > > [1] https://github.com/gnucap/gnucap-coupling/blob/master/README > [2] https://github.com/gnucap/gnucap-jack > > ------------------------------------------------------------------------------ > 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 > |
|
From: al d. <ad...@fr...> - 2018-01-19 20:16:09
|
On Tue, 16 Jan 2018 19:57:29 -0500 Beat Arnet <bea...@gm...> wrote: > I am looking for some advice on how to implement a co-simulation between > Icarus and a circuit simulator. The best way, with gnucap, is to make a target "tgt" for Icarus that generates a gnucap device plugin. If you want to do this, let me know, The D/A, A/D, and connectmodule code in gnucap is a bit stale. If I know somebody wants to use it, updating it can become a priority. |
|
From: Brian K. <bri...@so...> - 2018-01-19 21:03:21
|
I have extensive experience both with Verilog-spectre co-simulation (to design mixed-signal ICs) and with behavioral modeling of analog circuits such that they can be simulated directly in Verilog. I have found that the latter method is far superior both in terms of speed (of course) and ease in getting it to work. What kind of analog circuits do you want to model? Analog filters are especially amenable to behavioral modeling on Verilog but I have done RF synthesizers, PLLs, and most recently, a music synthesizer component about which I wrote a blog post here (which will be very elementary for Verilog experts but is more geared towards music synth enthusiasts): https://sonicsmith.com/glimpse-design-process/ On Jan 19, 2018 00:12, "Beat Arnet" <bea...@gm...> 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 > > |
|
From: Cary R. <cy...@ya...> - 2018-01-20 01:28:48
|
At my previous employer I used Icarus extensively for mixed signal modeling 100% in Verilog. You will notice that there is support, sometimes Icarus specific (e.g. wire real) or parts of Verilog-A, that make analog modeling much easier. A few years back before I started working at my current employer I started building a library of analog components that use adaptive time stepping to maintain accuracy without overloading the simulator with events. As can be noticed in the commit logs, I have not had much free time over the last few years so this is sitting in limbo right now. I still expect to finish it at some point and I do work on it from time to time.
Cary
On Friday, January 19, 2018, 1:03:27 PM PST, Brian Kaczynski <bri...@so...> wrote:
I have extensive experience both with Verilog-spectre co-simulation (to design mixed-signal ICs) and with behavioral modeling of analog circuits such that they can be simulated directly in Verilog.
I have found that the latter method is far superior both in terms of speed (of course) and ease in getting it to work.
What kind of analog circuits do you want to model? Analog filters are especially amenable to behavioral modeling on Verilog but I have done RF synthesizers, PLLs, and most recently, a music synthesizer component about which I wrote a blog post here (which will be very elementary for Verilog experts but is more geared towards music synth enthusiasts):https://sonicsmith.com/glimpse-design-process/
On Jan 19, 2018 00:12, "Beat Arnet" <bea...@gm...> 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
Iverilog-devel@lists. sourceforge.net
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
|
|
From: Beat A. <bea...@gm...> - 2018-01-20 21:00:50
|
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 lis...@li...://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 >> >> > |
|
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 |
|
From: Felix S. <fe...@sa...> - 2018-01-21 13:13:29
|
On Sun, Jan 21, 2018 at 01:29:14AM -0800, Kevin Cameron wrote: > I handed over working code (still have it around somewhere), got it back > converted to a "plugin" (unnecessarily), and not working. Hi Kevin. I have never seen the working (non-plugin?) version of this code. If you insist that it worked, and still have it around, then may I please ask you to share it? Beat, in particular could be interested. I presumably only know the code after you "got it back". I was not even around at earlier times. As the "conversion to plugin" usually does not affect functionality, your claim of having "working code" again pricks up my ears. and i must say, i am (naturally) skeptical. The code that I have seen tried to link (i.e. "cosimulate") two separate event queues. is that not the idea behind the "working code"? Now in reply to Beat, you write "simulation as co-simulation [it] generally doesn't go well"... if cosimulation does not go well (which i believe is true), it looks more promising to implement a tgt-$simulator for Icarus. this is off-topic in a cosimulation thread. but examples exist, these just dont fully work and need work. tgt-$simulator would turn a verilog module into a component the $simulator can pick up and run. there's no doubt that Icarus is the right tool, also gnucap-adms should be ported to Icarus, eventually. there should be just one that does all of ams. certainly, even tgt-xyce would be pretty neat, if somebody cares to do it. On Sat, Jan 20, 2018 at 04:00:42PM -0500, Beat Arnet wrote: > And is there a way to save all simulation states in Icarus in order to > revert a run back from the future? It is possible, but (was) pretty hard to do. i gave up on it, when it did not seem feasible without forking, either way. Or not worth it. best felix |
|
From: Kevin C. <iv...@gr...> - 2018-01-22 09:05:17
|
I think this is the old code - http://www.v-ms.com/download/ic-cap-i386-2009-06-03.tbz --- One of the problems with a Verilog/SPICE simulation is that it is at the two extremes of modeling circuits, it helps to consider various levels of modeling in between, and separating out concepts like strength and certainty from values (1/0) - also potential & flow on the analog side. ADMS is a bit of an abortion, if you want to do Verilog-A style modeling, it's probably better to translate to C++ and use something like GINAC - https://www.ginac.de/ [ as an aside I do believe in software patents, Verilog descriptions of ICs are software, algorithms are inventions. ] Simulators that don't do speculative stuff are "conservative" and don't back-track. However, back-tracking is not too hard if you are only dealing with FSMs (RTL/gate-level), although I've never been convinced it has much value. Kev. On 01/21/2018 05:13 AM, Felix Salfelder wrote: > On Sun, Jan 21, 2018 at 01:29:14AM -0800, Kevin Cameron wrote: >> I handed over working code (still have it around somewhere), got it back >> converted to a "plugin" (unnecessarily), and not working. > Hi Kevin. > > I have never seen the working (non-plugin?) version of this code. If you > insist that it worked, and still have it around, then may I please ask > you to share it? Beat, in particular could be interested. > > I presumably only know the code after you "got it back". I was not even > around at earlier times. As the "conversion to plugin" usually does not > affect functionality, your claim of having "working code" again pricks > up my ears. and i must say, i am (naturally) skeptical. > > The code that I have seen tried to link (i.e. "cosimulate") two separate > event queues. is that not the idea behind the "working code"? Now in > reply to Beat, you write "simulation as co-simulation [it] generally > doesn't go well"... > > if cosimulation does not go well (which i believe is true), it looks > more promising to implement a tgt-$simulator for Icarus. this is > off-topic in a cosimulation thread. but examples exist, these just dont > fully work and need work. tgt-$simulator would turn a verilog module > into a component the $simulator can pick up and run. > > there's no doubt that Icarus is the right tool, also gnucap-adms should > be ported to Icarus, eventually. there should be just one that does all > of ams. certainly, even tgt-xyce would be pretty neat, if somebody > cares to do it. > > On Sat, Jan 20, 2018 at 04:00:42PM -0500, Beat Arnet wrote: >> And is there a way to save all simulation states in Icarus in order to >> revert a run back from the future? > It is possible, but (was) pretty hard to do. i gave up on it, when it > did not seem feasible without forking, either way. Or not worth it. > > best > felix > > ------------------------------------------------------------------------------ > 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 > |
|
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 > |
|
From: Stephen W. <st...@ic...> - 2018-01-22 21:33:45
|
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 lis...@li...://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... <ste...@gm...> 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." |
|
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." |
Thanks for helping keep SourceForge clean.
X