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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp