Imported from old doc/plans (originally from an email)

<pre>
The "starpoint" problem
~~~~~~~~~~~~~~~~~~~~~~~

I have ideas how I'd solve the star grounding in this setup. It would 
obviously affect the PCB backend only. I don't like the idea of segmenting 
nets by using different attributes on different segments. I like the idea 
netname represents: any attribute attached to any segment of the net gets 
merged and there is only one set of attributes for the net at the end. 
It's because the schematics represents the logics, not the physical thing, 
especially not the geometry.

Instead I'd have an explicit object, sort of a hub. It really is a 
component with pins dynamically appearing whenever you draw a new net into 
it. Gemetrically (or "copperly", lol): all nets entering the hub is joined 
in one physicial point in pcb-rnd. Conceptually it's just a component 
with an unique ID and pins connecting separate nets.

Example #1:

Imagine you have the usual Vcc problem: some stuff needs more power,
others less, want to use two

The easiest way to use it is the hub is to partition a net into two nets, 
because you want one side be thicker in PCB. With the hub, you really 
have 2 nets, with different netname and differen attributes, both 
connected to the hub. I believe this makes everything much cleaner: you 
have a Vcc_l for low current and Vcc_h for high current (no, I won't keep 
the :1 thing in the non-compatibility mode).

With net segments, you wouldn't be able to use a power symbol to connect 
the Vcc pins of different components, as you had only one net in gschem 
with one name. You'd need to draw a net from the pin to the right segment 
that already has the low or high width property. You'd try to represent 
the PCB geometry in gschem.

With the hub, you get two net names so you can use the power symbols, 
still in pcb-rnd this will end up being the same galvanic network, 
connected in one point (which probably will be a hub "footprint", 
withexplicit refdes inherited from cschem). Still you'd see two nets on 
the netlist window in pcb-rnd and you'll know which one is the high 
current and which one is the low current.

Example #2:

star grounding; the same story goes, but you have many separate ground 
nets. They won't have different attributes (other than the different 
netname). They will connect a central "refdes=gnd_starpoint" to the gnd 
pin of a component on the schematics. There are three ways doing this:

- just draw the nets; it's not practical the same way as we don't draw 
normal vcc/gnd nets with lines but with symbols. But it works.

- like in example #1, make as many different gnd_whatever netnames and 
corresponding symbols as many arms your star has. This may be practical if 
you are connecting multiple stuff to the same arm of the star.

- I will keep the (with some amandments) "the same refdes is the same 
component" idea so just copy the hub and always give it a 
"refdes=gnd_starpoint". Plase the new instance (of the same) hub next to 
the component's gnd pin and connect it. At the end, each connection is 
still a new arm, and all these hubs are the same hub because of the same 
refdes. This way you can get the advantage of the other two methods.

Obviously it's possible to combine all the three methods in whatever 
mixture.

pcb-rnd and drc
~~~~~~~~~~~~~~~
I think the "netlist" backends will do much more than netlisting. I will 
stop pretending every flow is representable with a netlist. Instead, there 
will be a package of info or files, from which one may be the netlist. 
This concept of netlisting does not work with the pcb flow at all, this 
why we have gsch2pcb and pcb's import feature instead of just a plain 
gnetlist pcb backend. It's because we need to pass forth (and back!) some 
info which has nothing to do with netlists. Like the pin renaming hacks 
(the .cmd).

So I'd just admit the flow is a pack of different files. In case of the 
pcb-rnd flow, the pack would include a "drc script". It could add new 
rules in pcb-rnd's DRC, which could ensure things like:

- the location of the star hub; like if you make a star groudning you 
often want it to be close to the PSU. In the schematics you'd say 
soemthing like "pin 1 of the hub component is no farther than 5 mm from 
pin 4 of conn1". It'd be an attribute of a component or the design, I 
haven't decided yet. It'd obviosuly have a more formal syntax. The backend 
would take this instruction and convert it into a pcb-rnd drc rule.

- as the star point footprint will be a dynamic hack in pcb-rnd, there'd 
be some optional drc rule on how big it can be, e.g. how far two "pins" or 
"pads" hosting two arms (nets) can be

- you could also define that the minimal copper width or clearance for 
specific nets, as net attributes. With the same mechanism these would end 
up as DRC rules in pcb-rnd. This how you'd guarantee that Vcc_h is thick.

- these generic features could lead to better matched length, pair or bus 
support too.

</pre>