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