kicad-developers team mailing list archive

[Strontium <strntydog@xxxxxxxxx>]

On 10/10/16 19:59, Tomasz Wlostowski wrote:
> 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.
I disagree, I think the issue is portrayed to be far more difficult than 
the reality.

The problem is a designer can lay a Via using standard Kicad tools, and 
then Kicad will change that Via from the net it was assigned to, to 
Unassigned.

Thats the problem.

There is a solution, just make sure any Via (or track stub) that is 
Unassigned after a DRC pass is reverted back to the Net it had BEFORE 
the DRC pass.  It works, is simple, and does not require any changes to 
the way Kicad works in the face of the user.

There may be 100's of reasons why DRC is not great at the moment, and it 
should be re-written, etc, etc. But that just kicks this BUG down the 
road to a never never future, and meanwhile, designers using Kicad, 
maybe for the first time have a very jarring WTF moment when they lay a 
via, and suddenly at some seemingly random point, and without warning, 
it goes from being a GND Via, to being "Unassigned" and Oh, don't forget 
nothing highlights this to them, except a visual inspection.

> 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.
That's a different problem to the existing one.  The VIA has a GND Net, 
KiCad shouldn't (in my lonely opinion) change that to Unassigned, just 
because its not capable of dealing with it automatically.
> - Doesn't handle overlapping zones. The rightmost zone has the net GND,
> but it's not filled at all!
Again a different problem.  The problem is not anything about Kicads DRC 
not handling fills.  Even if it did, it would not be able to reassign 
the vias through some magic, because overlapping fill planes could be 
"ANY" or "None" of the intended net for the stitching Via.  Its why I 
say, once a via is placed, if KiCad can not UNAMBIGUOUSLY determine its 
connectivity it should leave the net assigned to it alone.

Changing it to "Unassigned" only makes the problem WORSE and doesn't in 
any way make it better.
> - It's difficult to extend. We'd like to have arcs/other shapes on
> copper layers with proper connectivity check sooner or later!
Again, different problem, the maintainability of the DRC code is not the 
issue at hand.
> - It's slow. Net propagation on Chris's motherboard takes ~6 seconds.
Again, different problem, the speed of the DRC code is not the issue at 
hand.
> Therefore, I've decided to rewrite the algorithm. My assumptions were:
Tom, rewriting the DRC code is probably a worthy goal, and I would be 
the last one to defend the existing code base,  but, unless someone can 
resolve the issue of backtracking a isolated Via to its intended Net 
based on connectivity ALONE, then the ONLY solution is not to change it 
to unassigned in the first place.

Which is EXACTLY what the patch I proposed oh so long ago achieves. You 
will need to do the same thing, otherwise you will have the same 
problem, you will rip up all the net assignments, like the existing DRC 
code, You will rebuild all the unambiguous connectivity, and then you 
will be left with a bunch of entities (lets say they are vias) and you 
will not be able to UNAMBIGUOUSLY decide what net they SHOULD be 
assigned to based on board connectivity alone, and you will end up with 
"Unassigned Vias".

So while rewriting the DRC code is probably a fantastic idea, what's 
actually preventing the application of the patch I proposed, strictly on 
its technical merits, and not on the basis that one day we might have 
different DRC code which somehow (How, no one can actually say) handles it.

More importantly, has anyone actually applied the patch I proposed to 
KiCad and given it a try, before declaring the problem as unsolvable, or 
much more complex than it really is.  Because I was never given a single 
instance of a technical problem that it introduces and I never came 
across any after extensive use.

Steven