[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Re: commands in verilog mode.

From: al davis
Subject: Re: [Gnucap-devel] Re: commands in verilog mode.
Date: Sun, 2 Dec 2007 22:38:51 -0500
User-agent: KMail/1.9.7

On Saturday 01 December 2007, Thomas Sailer wrote:
> The precedent in purely digital simulators is that the top
> module is a module (or entity/architecture in VHDL) that does
> not have any input / output signals. Then you specify the
> name of the top module (or entity and possibly architecture
> if there's more than one) to the simulator, and the command
> language is completely proprietary, and differs from
> simulator to simulator. Or don't even have one, such as ghdl,
> which just produces a binary. None of the digital simulators
> I know of allows one to modify the circuit from the command
> line.
> So your approach is even more comfortable.
> Regarding digital simulation engine integration: if the
> analog engine is in charge, doesn't that mean that the
> digital engine needs to be able to go back in time?


> That 
> seems to me inherently difficult to do efficiently. Do you
> have references to journal papers on that?

Just save some old values.  It is not hard.

Digital simulation is a lot easier than analog simulation.

> What would you gain by integrating with a digital engine like
> icarus? Say when you want to cosimulate analog blocks
> together with digital netlists consisting of instantiated
> standard cells?

I don't want to really integrate it.  I want to use it to 
generate plugins.

> IMO the biggest advantage would be to have a procedural
> language for generating stimuli.

One big advantage is to get the whole Verilog language without 
rewriting it.  A second advantage is that big blocks will be 
compiled, which will be faster than the interpreted version in 
the core.

> Even for purely analog 
> circuits, while it's easy to apply sinusiodal or square wave
> stimuli, its hellishly tedious to apply any other stimulus
> (say pseudorandom NRZ, for example). So having a procedural
> stimulus language for tran simulations would IMO benefit even
> purely analog simulations.

Purely analog modules can be compiled and attached as plugins 
too.  That was the original purpose of gnucap plugins.  It grew 
from there.

> Back to the structural verilog + standard cells case. Do you
> think that a digital engine would simulate this quicker than
> gnucap already simulates U devices? Right now I can't see any
> reason why a digital simulator would be inherently faster.

Compiled vs. interpreted.

The "U" devices are nonstandard and rarely used.  When there is 
a standard alternative, it should be used and the nonstandard 
one phased out.

> In 
> this case, wouldn't it be feasible to just implement a plugin
> that reads structural verilog, and a plugin that reads LIB
> files (as specified by synopsys) and generates subcircuits
> for standard cells that consist of U device calls? With some
> glue you could both read LIB and spice models and
> automatically have analog and digital models for that netlist
> with just the files provided by the standard cell library
> vendor and the structural netlist.

This strategy has plagued Spice for years.  Each layer makes a 
bigger mess.

> For this to work well, U devices might need to be extended
> somewhat. 

If U devices remain, and will be extended, there needs to be a 
portable way to do this.  There are two well known languages 
designed for this type of work .... Verilog and VHDL.  We 
should use them.

I don't do models!  Well  .....   The future gnucap will have no 
builtin models.  Not even a resistor.  All models will be 
plugins.  They can be plugins now.  There is a little more work 
needed to make it easy.

As it is now, you can omit any models from the build.  Just take 
it out of the makefile.  If you later decide you want it, 
compile it into a .so file and use it as a plugin.  If you want 
to use a hacked version of a model, just attach it as a plugin, 
and it will hide the builtin one.

The emphasis in gnucap is to provide development tools, for 
developing plugins, using standard languages.  I expect in the 
not-too-distant future, many models will be developed on 
gnucap, and therefore support gnucap first.  They won't tell 
you that.  They will just say "it is Verilog-A".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]