Mail Archives: geda-user/2022/08/25/12:29:18
On Wed, 24 Aug 2022, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
> in what way does lepton break backwards compatibility ?
lepton-netlist doesn't really care to accurately reproduce the behavior of
gnetlist. This means that running it on an existing gEDA/gaf design
probably doesn't result in a netlist that is "correct", i.e., equivalent
to the one generated by the contemporary version of gnetlist.
Since the probability increases with the complexity of the design, and the
effort of manually checking the generated netlist also increases with the
complexity, this means lepton-netlist is essentially useless for making
small changes to a complex existing design.
> The problem with the "old" set is that it is not well defined.
> I don't say that we should remove the "old" set, I say we should
> create something that is well defined.
Well, actually it *is* well-defined. There may be bugs in the
documentation; if you come across one, please name it so it can be fixed.
IMHO, the problem is that the name "Master Attribute List" suggests all
attributes are documented in the list, while actually any backend can use
its own custom attributes, and there cannot be such a thing as a complete
list. That said, I believe it makes sense to include the attributes used
by common backends in the list.
> Also it shouldn't be redundant like the pinseq, that could just be
> implicit.
The pinseq= attribute isn't redundant. It's badly defined, though, since
it has two completely distinct meanings:
a) defining the order of pins in slot definitions, and
b) defining the pinnumber for use with SPICE backends.
IMHO, b) should be renamed to "spice:pinseq=", and a) should only be used
in slotted parts.
> I'm fine with prefixing, but instead of
> spice:device=...
> why not
> spice=xxxx
> end let the xxxx's be a black box for everything except the spice
> backend (btw. which spice) ?
What's the advantage?
The good thing about "spice:device=" is that is still makes semantic
sense. Having a black box would be even worse than missing documentation.
> Btw, why do we have T ... N, when we have
> the
> X ...
> {
> X specific stuff
> }
>
> syntax ?
Indentation in not actually present in this syntax, and there could be
lines with single closing braces in the text.
Sure, the current syntax could be replaced with a brace-delimited indented
block, but that would be breaking compatibility for no good reason.
Roland
- Raw text -