Re: [Gnucap-devel] verilator

[Felix Salfelder]

Hi John.

On Sun, Oct 12, 2014 at 09:00:03AM -0500, John Griessen wrote:
> 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.

yes. but effectively, this is the same thing. if there was a way to
-- say -- run ELF executables as a part of a gnucap circuit (using some
plugin the OP asked about), then you would have to compile many
different chunks of verilator code and link to ELF executables,
respectively.

(also, once any of this is working, it will be easy to hide the code
generation, compilation/linking and loading from the user.)

> 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?

redesigning the digital filter will require a recompilation (of the
filter). changing instance parameters will not require recompilation.
but i guess i do not fully understand your question (?).

> 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.

this is the hard part.

> 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.

hth
felix