Verilog - was: Re: [Gnucap-devel] Use of M as suffix for Mega

[al davis]

On Friday 18 August 2006 18:29, Svenn Are Bjerkem wrote:
> If the functionality in Verilog-AMS is the same, then other
> non-standard extensions should be switched off. If it is
> feasible, grant a period where an annoying message about
> future remove will make the user aware of what is coming.

That is the plan, sort of.  Keep the extensions until they get 
in the way.

I am considering using a translator to support Spice syntax.  
One big advantage of the translator approach is that several 
translators can be made, for exact translation of several 
variants.  I think most of these translators could be simple 
awk programs.  With a few to start with, some others like 
Spectre, Saber, and Touchstone could follow.

> Most simulators that I use do not have both analog and
> digital abilities but rely on probes to transport data from
> the analog simulator to the digital simulator and back again.
> If gnucap will handle both in one executable (like not
> relying on icarus verilog for the digital part) I would say
> it make no sense any longer to support spice syntax. You burn
> some bridges, but then you can focus on keeping up to date
> with the standard.

I do plan to eventually (probably fairly soon) have 
co-simulation with Icarus Verilog, but probably not quite the 
way the others do it.

The method of using two programs and passing probe data is 
ancient technology, over 20 years old.  Still, it makes sense 
in some ways.  For one, it can be done quickly and does not 
force a long term commitment.  Another .. it will probably run 
faster for large all digital blocks.

By having a digital-only program on call, it can be more easily 
optimized for the simpler task of digital simulation.

What the others are missing is that by adding digital capability 
to the analog engine, fully integrated, digital techniques can 
be applied to the analog portion, or even to pure analog 
circuits.  Gnucap already does some of this.

> Look at what Synopsys is doing to HSPICE: They cram it
> together with their VCS digital simulator and call it
> Discovery AMS. Cadence cram Spectre with their ncsim digital
> simulators to get Spectre-AMS and Mentor Graphics cram eldo
> with modelsim to get the ADMS.

Note .. Mentor's "ADMS" must not be confused with the model 
compiler called "ADMS" from Freescale Semiconductor that is 
available under GPL .

I have never used those programs.  I have not had access to 
them.  I think I understand the underlying technology, but I 
don't know anything about the user experience.  Can you give us 
some info?

Even with a possible gnucap - icarus verilog combo, I think the 
user experience might be a bit smoother.  The link to separate 
modules will become a key part of the way gnucap works.  As it 
stands now, the diode, bjt, and mosfet are almost external.  I 
have proof of concept working that will make them really 
external, with no impact on speed or user interface.  This will 
let you use the model compiler to make a ".so" of a new model, 
and link at at run time simply by referencing it in a netlist.  
The ability to link to arbitrary external executables, such as 
octave, is not far away.

> Will gnucap be able to replace all that? I must be missing
> something here.

Eventually, if I can get funding or help.  It is not as hard as 
they make it out to be, but does take time.  Gnucap is not 
Spice.  It does not have a lot of the baggage that makes Spice 
so big and hard to work on.  It does have a real mixed-mode 
engine that isn't being fully utilized.

> Future is Verilog-AMS or VHDL-AMS give or take what continent
> you live on. I prefer Verilog-AMS just because I hate writing
> all those port descriptions in VHDL.

There is also a difference in discipline.  I don't know any 
analog designers who like VHDL, but I know several who think 
Verilog is the best possible.  Digital designers seem to lean 
more to VHDL.

There is also a difference in accessability of the standard 
document.  The Verilog-AMS LRM can be downloaded from 
accellera's web site, with no hassles.  The VHDL-AMS LRM is 
handled by IEEE, and they want money for it.

There's also the issue of all those port descriptions in VHDL.  
Imagine trying to teach that to sophomores, in the Circuits-1 
class.