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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user