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... _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
