Re: gEDA-dev: RFC: gnetlist uref mangling (WAS: Re: Broken slotting)

[Steve Meier <smeier-at-NOSPAMalchemyresearch_dot_com>]

From my perspective, what we want is a flexable architecture that
provides net lists that meet the requirements of a number applications.
We can not expect the applications to conform to our needs we have to
conform to theirs. So, the front end has to not loose information and
the interface to the back end has to be highly flexible. This is one
thing that geda, libgeda and gnetlist got right! Does a page care if two
devices have the same reference designator? The page doesn't but PCB at
the netlist does, here it pays to have a flexable drc system so pcb's
requirements can be evaluated. Does spice care? maybe not I am not a
spice expert but if it doesnt and just wants to know which pins are
hooked to the ins and outs of an instance of a model then so be it.

From my perspective (all to often from the muck) it is an understanding
of each applications requirements and how they impact the API (especialy
the back end) that is needed.  And uhm yes Stuart your example is
starting to give me a clue.
Steve Meier


Peter Clifton wrote:
> On Thu, 2007-09-13 at 06:40 -0400, Stuart Brorson wrote:
>   
>>> Can you post an example of how a complex component's pins and their pin
>>> numbers would be arranged to satisfy spice?
>>>       
>> Steve --
>>
>> There is an example in the regression test suite which might answer
>> your question.  Look at the source under:
>>
>> Input schematic:
>> ${SOURCE}/gnetlist/tests/spice-sdb/outputs/SlottedOpamps.sch
>>
>> Output netlist:
>> ${SOURCE}/gnetlist/tests/spice-sdb/outputs/SlottedOpamps-output.net
>>
>> Does this clarify the intended behavior?
>>
>> Stuart
>>     
>
> I think we're looking at a different problem here - that is; we have 4
> symbols instantiated, all with refdes=U1, and the spice-sdb backend
> wants to treat them as individual entities.
>
> gnetlist (whilst keeping them separate in its NETLIST structure), refers
> to them by a common refdes U1 - and its not possible to separate them.
>
> A similar problem exists when using the gschem->PCB workflow, where
> sometimes people (like I used to) like to name slotted parts IC1a IC1b
> IC1c etc...  PCB doesn't care about the lower-case suffix, treating all
> the above as if they were "IC1". gnetlist treats them separately of
> course, and gsch2pcb outputs multiple footprints with the wrong refdes
> in this case.
>
> Do we want to allow both of the above behaviours?
>
> If so, it seems that we might want some per netlist-backend control of
> how gnetlist processes refdes.
>
> I think this mapping could be implemented as guile a callback function
> to the gnetlist backend to allow it to return a refdes for each
> component parsed in the schematic - to place in the NETLIST structure
> for that component.
>
> It would do this with full access to that component's attributes, and a
> default implementation should just copy the refdes= attribute (to get
> the current behaviour).
>
> The gsch2pcb backend might introduce the mapping from IC1[a-z]* to IC1.
> Any refdes which exit this mapping with the same string would be emitted
> as a unique package thanks to g_get_packages() not repeating duplicate
> refdes'.
>
> The spice-sdb backend mapping may wish to consider any slot= attributes
> (and other attributes which indicate the presence of slotting), to
> transform refdes=IC1; slot=n -> IC1.n (and so on). This would give each
> slot of a component a unique uref with which to identify pins and
> connected nets.
>
> I'm not 100% sure how this fits with hierarchical uref mangling, however
> this isn't likely to be an insurmountable problem 
>
>
> Any comments?
>
> Regards,
>
> Peter C.
>
>
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
>   



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev