First of all, having used Mentor and Cadence tools before, kicad 9 is excellent. Congratulations to everybody involved.
When doing a bit of manual trace length tuning, I found an oddity. Reporting it here so others are aware.
If you look at the top trace in the picture, you can see the very last segment is completely in the pad.
The routed trace length reported here is ~3.2mm
If I delete that last little bit in the pad, the length doesn’t change.
In the bottom picture, I moved it so the first corner is now out of the pad, and then the length jumps to 3.75mm - and deleting the last segment now reduces it (3.04)mm
Using the distance to the center of the pad I think is correct, although I can see reasons why you would ignore segments within the pad. I changed the transparency so I can see what’s going on.
Replying to myself here… I had a quick look at the code, and this looks like a deliberate decision (if I 'm looking in the right place). Not sure its the correct choice in all cases, but at least I am aware of the behavior and can work around it.
“Like AssembleTrivialPath, but follows the track length algorithm, which discards segments
* that are fully inside pads, and truncates segments that cross into a pad (adding a straight-
* line segment from the intersection to the pad anchor).”
I’m a bit confused why you call it an “Oddity”. A track segment that is completely inside a pad does not modify the electrical length, no matter if the track segment is present or not. I would not expect any other behavior.
Same (similar) for overlapping track segments. Overlapping track segments do not increase the length the current travels. But do note that algorithms such as this are being optimized every now and then. Some time ago double sections may have been counted twice, and there were different length measurement tools that reported different lengths for the same net.
It’s not a section I use often, but as far as I know, the goal is to calculate the length of the current path, regardless of what features (pads, tracks, graphic items in a net) are being used. In the nightly this has been enhanced again. Now a start is made for calculating the actual time delays (depending on PCB stackup, track impedance) instead of only the length.
It’s an oddity as a slight move of the first segment corner from inside to outside the pad makes a relatively large jump in the trace length.
“Overlapping track segments do not increase the length the current travels”
This is not true in the case of the pad as you suddenly lose the distance from the pad edge to the center which is a good reference point.
The current will, in the case of the through hole pin, flow on the surface of the pin so the correct place to measure is to the hole edge. However, as the hole is the same size on both pins of the pair, the center works as well.
/Mike
I recently re-wrote the code that does this for v10, to ensure that the same electrical path optimisations were applied uniformly (e.g. for length / time matching, status bar reports, net inspector panel, etc).
I haven’t looked in detail to see if there is a bug in the example you’re showing, but happy to take a look if it’s confirmed with the latest builds. Therefore I’d be grateful if you could see if this behaviour exists in the latest testing build, and if not give a small example project showing the issue.
I can see how ignoring the pad segment might give an error if the pads are rectangular or different sizes, but would this be a likely case at very high speeds? A large pad on one track would add capacitance and mess the pair balance.
Sorry I don’t quite get what you’re saying. This is just about optimising for effective electrical length (for which we always use the shortest path betweeen entrance to a pad and the centre of a pad [1]). Nothing to do with capacitance or symmetry between diff pairs.
[1] For pads at the start or end of a track. We don’t current optimise for drive-by pads.
The top pad/via has the first segment within the pad, so the length calculated is shorter than the second pad where the first segment ends just outside the pad.
This is particular problem with the large through hole pads used for PCIe, but you also see it with vias.
If you take the general case at the bottom, the length ideally would be calculated by working out the intersection of the trace with the pad boundary and then a direct line to the pad center.
** Even better from the pad boundary to the nearest hole boundary but it’s safe to assume the hole sizes on pads where this matters would be the same.
/Mike
Might not be relevant . . . but, if you take your general case reasoning and apply it to your first two upper cases you should get different answers anyway.
This is exactly what the algorithm is meant to do. There might be an assumption that no trace element is entirely within the pad boundary though. Need to check with the nightlies.
Maybe… I do recall having something in the back of my mind that it might go wrong with a segment inside a pad - but I can’t quite remember! A bit busy at the moment so can’t take a look immediately, but will fix if it is still an issue.
