On Wed, 2011-04-13 at 22:26 +0100, Peter Clifton wrote:
> pin[pinnumber=1] {
> pinnumber="99";
> }
And regarding stuff like the above - where we key off one attribute and
change it in the rule, IF that is ever legal - we should do it like a
PLC executes its processing cycles.
Freeze a view of the attributes as exist "before", run the rules on
those frozen attributes, then bulk update. That would enable a pin-swap
with syntax such as:
pin[pinnumber=1] {pinnumber="2";}
pin[pinnumber=2] {pinnumber="1";}
I've long seen this to be the most sane way of managing back-annotation
into a hierarchy. I would go as far to say refdes should be
back-annotated as such:
#X1 > #X1 > #R1 {refdes = "R99";}
#X1 > #X2 > #R1 {refdes = "R123";}
#X1 > #X3 > #R1 {refdes = "R3";}
Could be included in some back-annotation file from the PCB which
operates live on the design data at net-list generation stage.
I'm not sure if the schematic hierarchy would use "id=R1", "id=X3" etc..
"refdes=R1", "refdes=X3" but to be honest, it doesn't really matter.
The only thing which is important is the processing order of each block
of attribute annotations.
Whether the attribute annotations should be a separate file, or reside
within an attribute (also over-ridable for extra CS recursive
elegance? ;)) is not something I've thougth about much yet. Either has
its charm - perhaps we could use both.
--
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!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user