Re: verilator

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.