kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I'm going to keep this brief, please respond in kind.  I'm going to
create a new entry in the version 5 road map over the weekend with the
pertinent requirements so this will be my last comments on this subject.
 The horse is dead.

On 10/12/2016 12:16 AM, Strontium wrote:
> 
> On 11/10/16 23:35, Wayne Stambaugh wrote:
>> 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.
> Yes, I agree too, which is why I was surprised by the rejection of the
> proposed patch.
> 
> Let me summarise the processing the DRC re-connectivity pass CURRENTLY
> does:
> 1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
> and sets them to "Unassigned".
> 2. It then iterates through pads, propagating the net of the pads to
> their connected entities.
> 3. It finishes.
> 
> The side effect of this processing is any and all Tracks/Vias that do
> not have connectivity to a pad have lost the net assigned to them.  It
> has been changed from "the net assigned during design" to "Unassigned". 
> Step 1 is irretrievable, all entities just have their Net forcibly set
> to Unassigned, regardless of what it is currently set to.
> 
> My patch adds two steps so the process becomes:
> 0. Locally Backup all entities Net assignments.
> 1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
> and sets them to "Unassigned".
> 2. It then iterates through pads, propagating the net of the pads to
> their connected entities.
> 3. Finally Iterate all entities, IF AND ONLY IF the entity has a net of
> Unassigned, then recover its Net from the backup stored in step 0.
> 4. End.
> 
> Steps 1 & 2 are unchanged from the original process.

Why the bypass?  Just change the connectivity algorithm to keep the
currently assigned nets.  Your patch creates a maintenance issue and is
confusing.

> 
> I did this because a side effect of the current processing is
> irretrievably lost net assignments.  The result of the patch is, after
> all re-connectivity is established, repair the damage done by step 1. 
> It does not do any Arbitrary assignment of Nets to Entities, an Entity
> can only have one of two nets after this, the net of a connected pad, or
> the net it had prior to the DRC pass.
> 
> I firmly agree that there could and should be more DRC errors issued out
> of the DRC processing, but its a separate issue, and really before we
> start issuing errors, we need to agree that we should be throwing net
> assignments out the window arbitrarily or not.  If not, then my patch
> corrects that in a very simple way with no change to global data
> structures.
> 
> You can make step 2 as complex as you like, add all sorts of logic to
> try and determine the "True" net for an entity, but at the end of that,
> it is my stance that any entity that failed to be "reconnected" by step
> 2, should not have its net left changed to Unassigned.  Because the Net
> was Assigned, it was the DRC pass in step 1 that Unassigned it.  Its
> cleanup, to correct the damage done by Step 1.  You can see the damage
> it causes in the pictures I posted, it is clear damage caused by the DRC
> process to the board layout and design as laid down by the designer.
> 
> I can easily add a DRC note/warning/error (and I think the level should
> be a preference) during the cleanup, that's not an issue and I think its
> worthwhile.  The only rationale I can see for turning the cleanup pass
> in step 3 off is for developers, and only if they are working on the
> re-conectivity algorithms of step 1.  And for developers, it really just
> needs to be a comment, "set this to false to disable net cleanup" or
> something like that.  I dont know what value exposing it to the end user
> has.
> 
> 
>>
>>>>    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.
> Agreed that it might not have much widespread utility and its a corner
> of a corner case, however I thought it wasn't safe to assume that single
> ended entities weren’t valid.
>>
>>> 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?
> Ok, all i am trying to say is if you refer to my steps above, you
> "could" in step 2, IF you knew what zone an entity was originally placed
> in, treat the zone like a pad.  You would need to KNOW the matching zone
> to via association, because as everyone points out and which I agree
> with, how do you deal with overlapping zones.  Any such change would
> need A great deal of consideration and thought and is not the subject of
> my patch.

The via net defines to which entity it is connected.  There are no
assumptions here nor would I ever be comfortable with making any such
assumptions.

> 
> I am also not saying that its a great idea, just that it "could" be
> done.  And the statement that Vias dont "belong" to a zone or other
> entity is actually not true, the existing reconnection pass in step 2
> makes the assumption that ALL entities, Vias/Tracks that connect to a
> pad "belong" to that pads net and otherwise they "belong" to no net
> (hence "Unassigned").  I agree with you in principle on this point its
> just not how the code works currently.
> 
> Step 2 make the assumption, and its a very sound assumption, that the
> net of a pad can be relied upon 100% to be correct.  So if we take that
> assumption, we can then propagate the net from the pad through all its
> connecting entities, just like an electric current would. Its a good
> idea and works beautifully for all entities that have a connection to a
> pad.
> 
> However, because there are other entities which are equally important
> for electrical connectivity, like fill zones, that assumption does not
> hold in the converse.  It is NOT true to say that Every entity that is
> not connected to a pad has no net or is "Unconnected".  That's a false
> assumption.  The current assumption of the reconnect pass is only valid
> for a large but limited set of connectivity and is not exhaustive.
> 
> It is correcting the negative side effect of this assumption that my
> patch seeks to address.
> 
>>
>>>> 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.
> Yes I don't want that either, nor does my patch allow it.  Net
> assignment of tracks and vias in the design phase should follow the
> primary entities (pads and fill zones) to which they are connected when
> placed, or later reconnected during DRC if it can be determined.  I
> don't see that as subjective, its design led. Setting any entity to the
> Net "Unassigned" when it used to have some other Net assigned to it is
> however, subjective.
>> 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.
> Well, ALL of kicad pcb works like this, you assign a net to a track or
> via based on the net you connect it to.  Its not subjective, its design
> directed.  There is no other way currently.  And as far as I am aware
> there is no real strong push to say that this is a bad design practice.
> 
> The only way to introduce nets into the design is with a net list
> import.  Tracks and Vias then obtain a net when laid, based on the pads
> or zone fills they connect to, when laid.  The only arbitrary net
> assignment is with Zones, where one can and must select the net of the
> zone.  There is no other way to assign nets to entities.  My patch is
> not about UI, its simply about keeping things consistent before and
> after the DRC pass.  It doesn't change, or propose to change how kicad
> currently assigns nets to entities.
> 
> But it does try to stop a "Giving with one hand and taking away with the
> other scenario".
> 
> The alternative to maintain consistency, is to prevent people from
> laying tracks and vias starting on fill zones, they can only start from
> a Pad; OR making sure that any time a track or via is started on a fill
> zone it has the net "Unassigned" from the get go regardless of the Net
> of the Zone its starting in.  I suspect Users would revolt at such a
> change.
> 
> But if we continue to allow users to lay vias and tracks, starting on
> fill zones, with appropriately set nets for those entities (the net of
> the zone) why would we then penalise them by ripping up all that work
> and setting it Unassigned.  Just because they havent managed to connect
> the net to a PAD yet. Its actually cruel.
> 
> This is a real design issue, if you have a complex board, you might
> start a track at a Zone, but you want to connect it to a Pad
> eventually.  You lay half the track, find things are in the way, or you
> want to see if the zone reflows properly or for any other reason, you
> haven't yet reached the pad.  So you press the DRC button.  OOPS all the
> work you just did is now set to the Unassigned net and need to be pulled
> up and restarted, there is no way to fix it.  Its hostile.  But that is
> exactly how it works now.
> 
>>>> 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.
> I am all for adding more DRC Errors/Warnings/Diagnostics.  But its not
> the issue I am trying to correct.  I want to correct the nets that have
> been assigned to valid entities, and placed using normal design
> techniques being irretrievably destroyed during a DRC.
> 
> I see it as Part 1.
> 
> Part 2, 3, etc might be all sorts of improvements to DRC, extra
> diagnostics, more checks, and so on, but to me this issue is the biggest
> problem of all.  DRC shouldnt break the layout.
> 
> Steven
> 
> _______________________________________________
> 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