Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing

[al davis]

On Monday 14 May 2012, address@hidden wrote:
> Hi,
> 
> I've gone through the schematic format, verilog netlist
> format and the notes on how to translate. I've updated the
> wiki page about that at [1].

good!

> > 'net' is not identified as an implicit model by gnucap. Does
> that mean a 'net' module is to be defined in each case?

Actually, you can't count on anything as an "implicit model" .. 
not even the resistor.  They are all designed as plugins or 
subcircuits.

> A simple ideal net module can be
> 
> module net(pin1,pin2);
> resistor #(.r(0)) rnet (.p(pin1),.n(pin2));
> endmodule

or eventually with the right model compiler:

module net(pin1,pin2);
  output pin1,pin2;
  electrical pin1,pin2;
  analog
    V(pin1,pin2) <+ 0;
endmodule

or it could be a transmission line, an RC network, an RLC 
network, or whatever fits today.

In Spice, nets are in effect collapsed out.  In the "signal 
integrity" simulators, nets are first class objects and the 
other stuff is diminished, likely represented as "IBIS" models.

That's part of the benefit of not having the models built-in.  
You choose the models depending on what is important.

> Yeah right.. I'll just pass on the parameters. What should
> they be named? For example in case of a resistance, how
> should the tolerance parameter be named in verilog? 

You can't know that.  It depends on the symbol and model.  The 
translator module can not have any knowledge of any symbols or 
models in particular.

There is a "standard library" of models.  There should be a 
"standard library" of symbols.  Hopefully, they be consistent, 
but if they are not, it is not your problem.  Whatever the names 
of the parameters are, pass them on.

> Same as
> what it is in other formats (eg: gschem)?
> resistor #(.r(),.tol()) r1 (.p(1),.n(2));
> or
> resistor #(.r(),.tolerance()) r1 (.p(1),.n(2));
> or some other way?
> How are these parameters incorporated into the models of
> components?

"tol" or "tolerance" .. whatever you put in the schematic gets 
passed on.

In gschem, it has been considered normal to use a different 
schematic for layout or simulation, and maybe even different for 
different simulators.  There really should be types for 
attributes, some attributes are for simulation, some for layout, 
etc.  Mark them some way, perhaps with a prefix character like 
"." or "_".  Or .. just pass them on and make the target ignore 
any parameters it doesn't like?

> > > After getting the model name, in order to use in the
> > > analysis, the parameters of models are needed.
> > > Does this mean that the models should be stored?  (loaded
> > > as plugins?)

Not sure ... but you might want to choose among several 
different models.


One nuisance point I just realized ......  A gschem sch file has 
no notion of connectivity.  It comes from the extraction.  To do 
it correctly, you need the actual symbols.  That's bad, but we 
need to deal with it.



al.