Re: [Gnucap-devel] verilator

[John Griessen]

On 10/04/2014 11:48 AM, Felix Salfelder wrote:
> On Sat, Oct 04, 2014 at 10:06:32AM -0500, wikitronic wrote:
> > >I need a plugin that I can use to interface Verilator compiled code to
> > >Gnucap. The plugin would output some set of values and then wait for input
> > >from the external program, then continue. This way I can use one plugin for
> > >many external programs.
> i understand that you would like to have a plugin that implements a
> component that will fork and run a program to which it then talks to
> using stdin/out. this might sound promising. but it's a dead-end. the
> communication between a component and the simulator is more involved,
> and you don't want to force it through a pipe.
>
> > >If nothing like this exists I would be willing to
> > >look look at developing it myself. I just need some helpful advice.
> 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.

So, when you say, "compile/link the verilator output against an interface to 
gnucap",
do you mean for each different chunk of verilator code?  That would not get
wikitronic's desired outcome of being usable for many different chunks of 
verilator code.

I can see wanting to use a verilator model of a signal processing chain running
some kind of digital filter and the output goes through an analog filter as
in sigma delta modulation.   Once you created a circuit model in gnucap for
the analog filter and the voltage to current strength part of the digital
output bitstream(s), the number of input signals and the clocking would all
be the same for any digital filter designed.  Isn't there a way to set
gnucap up to deal with that without recompiling for each new digital filter 
design?

The verilator code could model a machine with inputs for things like gain 
control.
Gnucap could be used as a testbench for a full system test of signal processing 
code
plus D2A by having the inputs to the verilator code stepped through ranges and
capture the output as it all runs.  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...