Re: making netlists 'work' gschem

Hi Al.

On Tue, Sep 18, 2012 at 04:47:20PM -0400, al davis wrote:
> I must have missed the original, but here goes ..
my fault. i was asking Savant in which way he is planning to make
something like this work
"""
load lang_geda.so
include some-models
geda
include device.sch
verilog
DUT #() device(0,1,2);
spice
Vtest 1 0 pulse ...
.print tran v(nodes)
.tran 1 2 3
.end
"""

i'm more puzzled about how to define a model/subcircuit in device.sch
than how to access a model from within a .sch.

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

this spice hacking obviously is bad. but anyway, spice-sdb is capable of
writing out a subckt declaration. are you proposing to drop that
feature?

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

this is quite obvious. i've also implemented a zero-resistance net to
get started. but still, the nodes are what connects to the outside
world, and they are named randomly....

> Actually, there could be the concept of commands in schematics.  

right i wasnt quite clear. to me a 'command' in .sch is a command
object. so more of an object that might do something in the end (or not).
but with the subckt 'object' its different: it cannot be processed at
the end (can it?). nor can it be a plugin (?!).

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

don't get it. :(

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

in which way 'encapsulated'? my understanding of gschem is, there is no
encapsulation at all. thats where i propose postprocessing after
parsing has completed...

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

so again, you're proposing to drop the gschem subckt object? what would
be the alternative?

could you provide an example of a use case of the parser and give an
idea on how the nodes could be referenced/connected\ to from outside the
.sch? (sorry if this is stupid.)

regards
felix

PS: im posting a secont time, sorry if the first mail reappears...