kicad-developers team mailing list archive

[Strontium <strntydog@xxxxxxxxx>]

On 11/10/16 09:27, Wayne Stambaugh wrote:
> I've thought about this for a while and I'm going to try a different
> approach.  Please bear with me, this is going to be lengthy but in the
> interest of resolving the via stitching issue properly, I think it needs
> to be done.  I'm going to expand on JP's idea that we first define the
> problem we are trying to solve before we can arrive at a sound solution.
For my part the problem i would like to see solved is stated as:

"Do not assign the net of any pcb entity as Unassigned unnecessarily."

That's it.  This behaviour hits on all kinds of use cases, but most 
noticeably via stitching, but at its core it is the behaviour of 
unsolicited changing of net assignments to Unassigned I object to most 
strongly, for any reason.

My opinion is, if there is a pre-existing net assignment there is no 
reason to prefer the "unassigned net" to it over the "pre-existing" 
one.  The "Unassigned" net is guaranteed to be wrong 100% of the time, 
the other choice may or may not be wrong, but its probably correct.  So 
"most" of the time you have done the right thing, and for all other 
cases you are no worse off than now.
>   It may turn out that there may be a reasonable solution that isn't
> terribly difficult to implement without completely rewriting the drc
> code or ignoring net connections which have undesirable side effects.
>
> First and foremost is the definition of a via.  A via is a feature that
> electrically connects two or more copper features (not just tracks) on
> different board layers having the same net.
I disagree on the "Two or more" A stitching via acting as a RF shield 
along a RF trace might exist where it is only connected at one point to 
a fill plane, the purpose is the vertical copper inside the via creating 
a shield, not necessarily the connection to a plane above it.  And while 
it is ideal to connect to a plane above, in a situation where only the 
via + fill will fit on one side of the board, and no room for fill zone 
on the other, the via is still preferable, from a theoretical RF 
standpoint than no via at all. There are also stitching tracks, which 
don't get much attention but exist, and they could easily be single ended.

I also prefer to think of this problem as an "entity problem" rather 
than a via problem as it also impacts on track stubs.

>   If we are in agreement with
> that, then we should be able to agree that any via that has less than
> two connections on different planes to the same net or that connect
> copper features on different layers with different nets are design rule
> errors.  Have I missed anything here?
Yes, single ended entities are valid in my opinion, see above.

>    I can't think of any valid case
> where you would want unconnected (floating) or partially connected (1
> connection) vias or vias that short different nets together.  If you can
> think of one, please elaborate.
No a via floating or otherwise should never validly short different 
nets. 100% agree.
Single ended vias and traces, yes i believe there is a reason they 
should be able to exist.
> Once this is established, we should fix both the connection algorithm
> and the drc to reflect this criteria.  How much work would this be?  I
> didn't write either of these pieces of code so I'm going to have to rely
> on some feedback here.  I'm not asking for a full rewrite of the drc
> code even though that is a noble long term goal.  I'm asking for what it
> would take to accommodate the criteria above with the existing code.
Difficult, because the fill zones are not currently considered for 
connectivity.  There is feedback between the shape and size of the fill 
zone and the result of DRC net reconnection, you cant fill until you 
have your net connectivity sorted out (so the fill can flow around it or 
onto it as the case may be), and you cant sort out your net connectivity 
for stitching vias, until you fill (if you do it based on the zone shape 
and size).
Catch 22.  Also, in order to properly calculate the fill, the isolated 
vias on it need the appropriate net so the fill can flow into them or 
around them as required.  One would also need to work out what zone the 
via belonged to, which is also non-trivial and would almost certainly 
require the via to hold a reference to the zone it was placed upon 
(which may or may not be more important than the net it has).
> If this can be resolved with a reasonable amount of effort, the only
> thing that would be left would be implementing the board editor features
> to place the vias.  I'm guessing most of the proposed patches address
> that issue or a reasonably close facsimile thereof.  At a minimum I
> would think a via placement tool with associated hotkey and a dialog to
> select the via properties from the list of netclass or global via
> settings and select the net name from the netlist.  I don't believe any
> board file changes would be required.  Once again, if I missed something
> please elaborate.
Via placement options would be cool.  My patch does not propose that.  
It would also be cool to "remember" the zone a via was placed on, 
associating the zone to the via.  Then the via options would let one 
reassign the via to another zone.  But again my patch doesn’t do that, 
or need it. It sounds complicated to implement.  My patch however, could 
use that kind of information to make a subjectively better choice for 
the net assignment of the via. (Assign to zones net first, if zone not 
found assign to pre DRC net, kind of processing.)  But this is 
subjective, for example, in an edit, you could have a GND stitching via, 
you drag it to a new zone, which is also GND, then change the old zone 
to VCC, one wouldn't necessarily want the moved via becoming a VCC via.
> The only drawback I can see doing it this way would be if someone
> inadvertently opened the board with a stable 4 version of kicad the vias
> would automatically get rip up.  Please remember, new features don't get
> back ported to stable releases.
>
> I think the crucial element is the drc and connection algrithm code.  If
> this is too much effort, we could try Nox's suggestion of a user option
> to enable or disable Strontium's ignore orphaned via code.  I would
> prefer if that we investigate my suggestion before we fallback to this.
> If anyone has any useful feedback or has any objections with this, feel
> free to comment.
I think creating a DRC Error/Warning for a fully unconnected entity 
(regardless of its net) after the DRC reconnection pass has done its 
work is a worthwhile addition to DRC.  Because they are not easy to find 
now except on trivial boards.  But i also dont think the existing 
behaviour of making wholesale changes to the assigned nets to 
"Unassigned" is desirable or useful either.

An additional single ended entity Error/Warning would be fine also (not 
sure how difficult that would be, probably not too hard).

> Cheers,
>
> Wayne
>
> On 10/10/2016 12:24 PM, Nox wrote: