No subject

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 at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
>