Re: gEDA-user: analog/code co-simulation and schematics and netlists for silicon

[al davis <ad252@xxxxxxxxxxxxxxxx>]

On Tuesday 23 February 2010, John Griessen wrote:
> Al, are you saying that Icarus verilog would run along side
>  of gnucap once that interface is ready? 

Icarus has two key parts ..  A compiler, and a virtual machine.

In its normal use, the compiler generates code for the virtual 
machine, then you run the virtual machine on that code.

The icarus compiler has a provision for alternate "target" back 
ends.  There are several available. --  fpga, pal, vvp, .....

The plan is to make a new target back end that will generate a 
gnucap model plugin.  For gnucap, the Icarus virtual machine 
will not be used.

In gnucap (development version, not 0.35) ..  device models are 
not built-in, but can be loaded and unloaded at run time.  This 
makes it possible to have a lot more models without the bloat of 
all of the models you are not using.

(I'm not talking about the spice ".model" statement here .. This 
is the real code that implements the model.)

These model plugins are standard shared-object files native to 
whatever system you are running on.

As it stands now, some are hand coded in C++, some use the old 
"gnucap-modelgen", and some are spice models.  Gnucap can use 
unmodified Spice C model code as plugins, with a simple 
interface wrapper.

The work in progress is along two lines ..  One is an Icarus 
backend to generate a plugin.  The  other is to use another 
model compiler "ADMS" to generate gnucap code.

You can use ADMS now to generate NGspice code, which gnucap can 
use as a plugin, but this is not as efficient as it should be, 
because of the ancient Spice interface overhead and mapping 
overhead.

As another approach, it is possible to run the Icarus virtual 
machine "along side of gnucap", but efficiency is not good, and 
you need to hack some code.  It has been done.

> Would you still use gschem/gnetlist to schematically connect
> verilog modules?  That depends on having a good translator
>  first, right?

Anything that generates a netlist.

Gnucap uses "language plugins" to read whatever input format.  
Maybe someone could make a language plugin to read and write the 
gschem format directly.  Once this is done, it will also give us 
a stand-alone translator, both ways, between any of the 
supported formats.

> Could you just use a top level schematic as a guide for
>  connecting code modules to simulate with no netlist
>  generated from gschem?

Sure, but do you want to?


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user