On Sunday 12 October 2014, Felix Salfelder wrote: > > The timesteps of interest might be much slower than > > the sigma delta modulator clock speed once the model of the > > D2A is tested out. Then the verilator code output > > bitstream(s) could be mathematically dumped into a D2A_OUT > > variable used by gnucap to test the system for things like > > signal gain is in range and not too large or too small... > > you can inject signals into gnucap simulations easily. use > the PWL model and feed in a list of control points. this > often requires careful text preprocessing (awk, perl etc.). > it is probably a good idea to develop plugins that simplify > this issue. could be factored into reading in a waveform > from a file (already there, somehow) and having a COMPONENT > or just BM that replays them.
Better to use gnucap's digital interface and let the automatic conversion take care of it. On Saturday 04 October 2014, Felix Salfelder wrote: > what you want to do is compile/link the verilator output > against an interface to gnucap (instead of a main() > program). something very similar already exists for spice > components. spice-wrapper.cc implements the interface which > is then linked to spice object code. in your case, the > wrapper will have to take care of the signal conversion > and/or instanciate appropriate connectors, some work on the > verilator side might be neccessary... Yes .. Verilator is a compiler. The usual way to use it, you use it to compile your verilog code into C++. Then you add a "main", link it and run the executable. To interface to gnucap, a "verilator-wrapper" would substitute for that main, it would then generate a .so file that could be used as a plugin, similar to the spice models. You only need to write verilator-wrapper once, then it should be simple to use verilator to generate plugins. spice-wrapper is quite a mess, because of the messy job it has to do. I am hoping verilator-wrapper will be less messy. You can start by looking here: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:tech:plugins But the digital interface isn't described there. It's (sort of) in d_logic.h ... A new logic primitive would most likely be a plugin derived from COMMON_LOGIC. You need one for each output. I just realized (been away from it a while ...) that logic is now parsed by "obsolete_callback", not by a dispatcher. This needs to be fixed in order to make progress here. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
