kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/11/2016 12:18 AM, Strontium wrote:
> 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.

I agree with this.  We should not be changing the assigned nets in any
entity.  We should only be testing for connectivity and generating the
appropriate errors in the drc.

>>   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.

Hmm!  I'm not sure how effective a 3 sided Faraday shield would be.  I
would think that all four sides would have to be shielded for it to
effective.  The only case where this makes sense to me is if you are
using a housing to provide the shielding of the fourth side but even
that seems dubious.  In any event, I'm ok with changing the criteria to
one or more connections.  Maybe single ended connections can be drc
warnings rather than errors.

> 
> 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).

I don't understand what you mean by this.  If a zone and via have the
same net then they connect.  If not, they don't.  Vias don't belong to a
zone or any other entity.  They belong to a net.   Unless I'm not
understanding something, the only determining factor of entity
connectivity is the net.  How else would you determine connectivity?

>> 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.

I want to avoid subjective net assignment.  This is my primary issue.
The user should be in control of the net assignment.  KiCad can suggest
a default net based on the entities at the current location but I
strongly object to any notion of KiCad assigning or reassigning nets
based purely on entities at a given location.  IMO, this is even worse
than marking them as unassigned.  KiCad has no idea the intent of the
user.  This is why I would prefer that we have a via tool for this purpose.

>>
>> 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).

I would be more comfortable with this if our drc would detect orphaned
vias.  The single ended entities warnings I could live without in the
near term but that should added at some point.

> 
>> Cheers,
>>
>> Wayne
>>
>> On 10/10/2016 12:24 PM, Nox wrote:
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp