[Top][All Lists]

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

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

From: Thomas Sailer
Subject: [Gnucap-devel] Re: commands in verilog mode.
Date: Sat, 01 Dec 2007 13:43:04 +0100

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?

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?

IMO the biggest advantage would be to have a procedural language for
generating stimuli. 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.

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

For this to work well, U devices might need to be extended somewhat. The
predominant method to characterise standard cells these days seems to be
that propagation delay, output rise/fall times and power consumption is
computed from an interpolated two dimensional table indexed by the
output load capacitance and the input rise/fall time.


reply via email to

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