Mail Archives: geda-user/2022/08/25/14:31:54
Roland Lutz:
> 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.
Instead of contemporary, wouldn't it be better to have e.g. 1.9.2
as a neutral ground for comparisions ?
> 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.
Have you extensibly used lepton so you are qualified to say so,
do you have a public design which I can use to compare things with ?
> > 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.
Ok, but that would be on separate threads.
> 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.
Perhaps one could use the backend names as headings.
> > 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.
Ok, I'll get back to that.
> > 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 upper (gschem,gnetlist) doesn't have to know about what it is,
it is up to the backend to handle the xxxx's and document its use,
and the backend might prefer some other syntax than var=value.
BTW, do you and the lepton team agrea on the prefix thing ?
Regards,
/Karl Hammar
- Raw text -