Hi,

As promised (when I authored a patch which broke spice-sdb in favour of
fixing pinnumber updates), I have done a bit of work to restore the
spice-sdb slotting functionality without any need to adjust pinseq
attributes.

The resulting patch series is here:
http://repo.or.cz/w/geda-gaf/pcjc2.git

It _needs_ looking at.. to verify:

  a) The idea is sound
  b) The implementation is sound
     (I especially need help checking how to ensure I don't leak SCM 
      objects, which I'm fairly sure I am at present).


The idea was this...

Move policy in the mapping of component attributes (refdes= / uref=)
into the "package uref" identifier in gnetlist, into a scheme procedure.

When traversing the schematic, for each component, the scheme procedure
(get-uref object) is called (where object is the OBJECT SMOB being
considered). This procedure uses normal libgeda scheme API for querying
attributes, and determines what uref the component should have.

The default implementation gnetlist:get-uref mimics the current
behaviour of testing for a refdes= attribute, then falling back to uref=
(with a warning if found), or returning #f.


I've had to alter the execution order in gnetlist.c somewhat, as we need
gnetlist.scm, and any netlist backend to load (and provide the get-uref
function) before the schematic is traversed, and I ended up having to
move some of gnetlist.scm into gnetlist-post.scm.

This was necessary as immediately upon loading gnetlist.scm, certain
expressions are evaluated - and we can't define a list of packages until
we've traversed the schematic.


The spice-sdb fix removes all previous code which iterated over slots
for a given package, replacing it with a custom (get-uref ...) procedure
which ensures each slot of a component is given a unique uref when
gnetlist traverses the schematic. This means each slot will appear as a
separate "package" in the gnetlist data-structures, even if each slot
uses the same refdes= attribute.
    
The format for the package uref is "(refdes/uref).(slot)", in keeping
with the existing spice-sdb slotting code.


All the gnetlist tests still pass with this code. I had to re-order the
lines in the spice-sdb golden file for slotted components, as slots are
now processed in whatever order the gnetlist data-structures list them
in.


Comments?

This isn't as ideal as I'd like.. I'd hope to see the netlist backends
work more directly with the libgeda data-structures in their SMOB
equivalent form (as this gives more sensible access to attributes etc..
for processing).

In that case, we might not need a custom uref-mapping function, as it
could be taken care of in a similar way to the existing refdes aliasing
code. (This wasn't suitable for this fix, as gnetlist looses information
about individual slots with the same refdes during schematic traversal,
and has no way for you to query a particular slot).


I've kept this fix short, in the hope it can be reviewed and tested for
possible inclusion in the 1.3.x series. I fully appreciate however, if
it is deemed too risky.

In any case, I'd like to hear comment as to whether the idea is sound,
and if anyone spots any bugs / ways to fix possible SCM leaks, please
let me know.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev

Reply via email to