| Thread Previous • Date Previous • Date Next • Thread Next |
On 11/10/16 23:35, Wayne Stambaugh wrote:
Yes, I agree too, which is why I was surprised by the rejection of the proposed patch.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.
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.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.
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.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.
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.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?
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.
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.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.
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 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 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.
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.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 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
| Thread Previous • Date Previous • Date Next • Thread Next |
