[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] making netlists 'work' gschem
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] making netlists 'work' gschem |
Date: |
Thu, 20 Sep 2012 19:22:26 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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...
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnucap-devel] making netlists 'work' gschem,
Felix Salfelder <=