Comment 3 for bug 804972

I poked a bit in the source of netlist. This seems to be a consequence of the general rule that all symbols with the same uref are regarded to be the same object. The hierarchy crawling code in s_hierarchy.c sees only one instance.

How would a proper fix work?
At the moment, I see two alternatives:

a) Do not unite i/o port symbols in the internal representation of gnetlist. But how would the paser know, that a symbol is a port symbol? Gnetlist relies heavily on the ability to go over all components. Would these loops all be fine with duplicate urefs?

b) This is a case of overloading the uref attribute with a meaning it is not designed to. There are more conflicts with potentially nasty side effects. Imagine a sub sheet pin called "R1". The hierarchy code might try to connect to the resistor rather than to the i/o symbol. Since duplicate urefs are explicitely allowed, DRC checks would not catch this.
An alternative way to mark-up an i/o symbol would do away with these traps. Say, an attribute "io_port=portname". But the symbol would still need a unique uref. What happens, if a symbol contains no uref attribute?

---<)kaimartin(>---