← Back to team overview

kicad-developers team mailing list archive

Net propagation/connectivity calculation [was: pcbnew - enable editing of associated net for tracks&vias]

 

Hi all,

There's been another long thread on stitching vias/net propagation. Let
me add my 3 cents.

The whole subject is more complex, as Wayne and JP already mentioned
many times.

The root of the problem is the legacy's connectivity calculation/check
algorithm (class CONNECTIONS), which:
- propagates track/via net codes from the pads they're connected to,
- participates in finding isolated copper islands in zones,
- performs a connectivity check.

It has several drawbacks, though:
- Doesn't handle zones properly when checking board's connectivity. This
is the reason why allowing the user to select a net for a via/track is
*dangerous*. See the attached drawing - the top two zones are assigned
the net GND, same as the via that stitches them together. They are not
connected to any pad, though, but the board passes the DRC without any
error.
- Doesn't handle overlapping zones. The rightmost zone has the net GND,
but it's not filled at all!
- It's difficult to extend. We'd like to have arcs/other shapes on
copper layers with proper connectivity check sooner or later!
- It's slow. Net propagation on Chris's motherboard takes ~6 seconds.

Therefore, I've decided to rewrite the algorithm. My assumptions were:

1) Net propagation:
- Tracks and vias (and only tracks and vias, unless we add arc/curve
support in the future) take their nets from pads they are physically
connected to, just like in the legacy algo.
- Nets are never propagated from zones.
- Net propagation is triggered only during an update of the board's
netlist or when the user moves a part of the layout and places it on top
of different tracks/vias/pads.
- Tracks and vias that connect zones (which don't have a track/via-only
path to a pad) must have their nets manually assigned. Otherwise they'll
be reported as unconnected.

Let's take a look at the following chain of objects:
[Pad1] - [Track1] - [Via1] - [Zone1] - [Track2] - [Zone2]

Track1 and Via1 get their netcodes propagated from Pad1. Track2, which
connects the zones, must have its net assigned manually.

2) Connectivity check
- Take all object types into account (zones, tracks, vias and pads). The
example above will pass the connectivity check if Track2 is assigned to
the same net as Pad1. It will also correctly recognize overlapping zones
(with the same net assigned on the same layer) as connected.
- All subpolygons in zones are also checked, so we have insulated copper
island removal for free (and consistent with other connectivity
verification operations).


3) Design:
- No intrusiveness. The algorithm should not keep any private data in
BOARD_CONNECTED_ITEMs.
- No changes to Kicad storage model and core structures.
- Add/Remove/Update interface that can be later on abstracted through an
observer.

4) Integration in pcbnew.
- Leave an option (e.g. a checkbox in the preferences dialog) to fall
back to the legacy connectivity code, just as we did when testing the
new (de-Boost-ified) polygon filling code.

5) Status/TODO/missing stuff:
- I'm almost done with the code, I'll push it to my private branch as
soon as possible. Currently it's a separate class with a test program.
- Investigate interaction with the Board Cleanup function.
- We are missing track/via net assignment in the properties dialogs. I
like Nox's patch, but I'd prefer it to allow only to choose from the
nets that are in the netlist (no completely arbitrary names). How about
changing the textbox to a combobox with the list of legal net names?

Cheers,
Tom






Attachment: connections.png
Description: PNG image


Follow ups

References