Re: [Gnucap-devel] making netlists 'work' gschem

[al davis]

I must have missed the original, but here goes ..

> On Fri, Sep 07, 2012 at 06:01:52PM +0530, 
address@hidden wrote:
> > What I have in mind is to map components in schematics to
> > models (spice or verilog-ams)
> > Exactly, how it is done, I dont presently have nay idea.
> > I need to look at gnetlist to see how it is done in it.

It really must be done explicitly.  My original thought is that 
the "device" attribute does exactly that.  I still think that is 
the way.  Unfortunately, there is a lot of slop in gEDA symbols.  
I think the solution is to clean that up.

You should look at gnetlist to see how NOT to do it.  In the 
spice module (both spice and spice-sdb) there is code there to 
recognize the spice symbols and to emit spice code for those in 
a specific way.  That is a BAD way to do it.  The netlister, and 
the language plugins for gnucap, should not have any knowledge 
of any specific symbols or devices.

On Wednesday 12 September 2012, Felix Salfelder wrote:
> my understanding is as follows.
> 
> gnetlist uses the last (?) "netname" attribute it finds in a
> connected component as the nodename that represents it. this
> partially makes sense, but is difficult to do in gnucap. a
> net with a netname tag would have to rename the nodes it
> connects to (when it is parsed). this is not implemented in
> u_nodemap...

It was (and still is) my intent here that nets are first class 
objects.  This solves much of the problem.  Making nets first 
class objects opens up a lot of new possibilities.  Depending on 
what you want to do, you could use different models of nets.  

If you want a spice-type simulation, the net model could be a 
short.  For speed, it could be a collapse-the-nodes type of 
short, or for probe flexibility it could be a nullor model of a 
short, similar to the spice zero-volt-voltage-source.

This also provides the possibility of alternate ways to 
simulate, such as interconnect oriented where the nets are most 
important and the devices use something like IBIS models.

You also need to consider another language plugin for a PCB 
layout.  If it is done properly, gnucap plugins could be used as 
the path between schematic and layout.  This opens up post-
layout simulation and layout-vs-schematic checking.

> it looks as if netnames are better off where you have put
> them, but then, the subcircuit and port magic items need to
> be handled in order to do anything with the netlist. the
> difficulty with this is, that unlike gnetlist/spice-sdb,
> gnucap parses sequentially, and doesnt see the whole
> picture.
> what might work is this: lang_geda parses all CARDs into a
> private scope, which is postprocessed once it exits, and
> then dropped into CARDLIST::cardlist. since there is no
> concept of commands in schematics files, the user will have
> to switch to another language anyway (is that right?) -- and
> not even notice.

Actually, there could be the concept of commands in schematics.  
Look at Qucs as an example.  As you say, it is not sequential.  
The whole thing is gathered up, then the "commands" are 
executed.  Old versions of Spice work this way too, broken up by 
key cards like ".alter".

A lang plugin could do this.  I would not want it in general, 
but with plugins you can change things like this on the fly.

It seems to me ..  stuff done at "top level" probably should be 
mostly sequential, but anything that is encapsulated should be 
treated as a unit.  In spice and verilog, a "subckt" or "module" 
is such an encapsulation.

> such a private scope seems neccessary for subcircuits. at
> least i cannot think of anything else. the spice-sdb node
> naming scheme would then be trivial to implement. but i
> don't like it yet. any better ideas?

Again, please look at spice-sdb as an example of how NOT to do 
it.   Think of the language plugins as part of a general 
translation facility.  Read one, write another.  It translates.  
Read one, write back the same format, it should be "lossless" in 
the sense that it makes the same schematic, layout, circuit, or 
whatever.