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

[al davis]

On Friday 25 May 2012, address@hidden wrote:
> So, does this mean that the netlist parsed from gschem will
> contain VOLTAGE_SOURCE, RESISTOR etc ? And then we define a
> module(subckt) for that device which can be
> user-controlled?. But as a default shouldn't we map standard
> symbols to the standard models (modules?).

"default" should mean a standard include file .. like "stdio.h" 
is to C.  In fact, Verilog-AMS has a standard include file 
"disciplines.vams".  Without it, there is no notion of even what 
"voltage" is.  It's defined in that file.

In this case, the mapping is symbol dependent.  Ideally, the 
symbol's "device" attribute would always match the device type 
as Verilog wants it.  Practically, users get models from a 
variety of sources, and overall there is no consistency.  So, a 
means to do a file-defined mapping is essential.  A suitable 
means is defined by in the LRM (Language Reference Manual) so we 
should use it.

In case you don't have a copy of the LRM:
http://designers-guide.org/VerilogAMS/vams231.pdf

There is a lot of info here:
http://designers-guide.org/VerilogAMS/

Another good reference on Verilog-AMS is Ken Kundert's book.  
"The designers guide to Verilog-AMS".





> 
> > Use of "place" ...
> > 
> > You cannnot rely on names (device names or node names)
> > having any meaning.  They are just strings.  So (for
> > example) the relation between "placeR1" and "R1" cannot be
> > relied on.
> 
> Ok, that's right. So do I index a component and it's
> associated attributes(paramters) using associated
> arrays/lists?
> 
> > A "place" connects to a node, and has locations as
> > parameters. So, even if the names change it stays located.
> > 
> > I did not locate devices, only nodes.  The devices would
> > float and place themselves *reasonably* between the nodes,
> > which are explicitly located.
> 
> I thought placing devices would be straight forward and fine
> wrt parsing. But now I see the advantages of locating nodes
> instead of devices. Moving devices freely wouldn't change
> the netlist. That's fine.However, in this case of placing
> nodes rather than devices, the original placement of devices
> (which are placed between nodes) may not be reproduced from
> the netlist obtained by parsing the schematic (unless of
> course there is a definite way of defining nodes for a
> device and a definite way to place a device between those
> nodes). Although the placement of devices might not be
> important for simulation but will come to effect when
> looking at a layout schematic or may be when doing
> post-layout IBIS simulations .

Actually, the devices normally would be placed correctly.

If the nodes are placed explicitly, a symbol could be located, 
morrored, and rotated so the implied connections from its own 
pins to the located nodes are as short as possible.  If the same 
symbol is used again when the schematic is regenerated, it will 
fit exactly.

Stepping back a bit ..  the real goal here is to develop a 
system for mapping to and from a schematic in general, and to 
demonstrate it with geda/gschem.  If the system is well 
designed, it should be relatively easy to demonstrate it again 
with kicad.  Then, having both, we have a migration path between 
them.

A little more abstract ..  It is obvious that a mapping from one 
to another might require some intervention, because of names 
that don't match and issues like that.  Another use is to map to 
a different symbol set with the same program.  For example, you 
might want to change between American style resistors and 
European style resistors.  That is a simple change to the 
mapping include file, or perhaps selecting a different one.  
Like the C/POSIX "locale"?

The syntax  for include in Verilog is defined in the LRM.  I 
don't know about the include concept in geda/gschem or any other 
schematic format.  If it has one defined, use it.  Otherwise, we 
have tools like "m4" and "cpp" that can handle things like this.