I’ve been using KiCad for a while now, but I’ve only recently needed to use the length and skew matching tools.
I’m using Kicad v8.0.4.
I’ve read the documentation and several forum threads about using these tools and avoiding common pitfalls. I enabled via distance and created a custom rule for the net class I intend to match:
These skew and target length values are not specific to any protocol; they are just for testing purposes. All nets in question are differential pairs.
After setting the custom rule, I used the “Update All Tuning Patterns” option in the Edit menu and proceeded to match the length and skew of the nets using the tools. The pop-up display indicated that the correct target length and skew were achieved when adding the geometries.
However, after running the DRC, I received length and skew errors for all nets.
For example:
"Error: Trace length out of range (...) max length: 45.1000mm; actual 46.2632 mm"
"Error: Skew between traces out of range (...) max skew: 0.1000mm; actual 0.3174 mm"
This is odd since the tools reported that the correct skew and length were achieved.
When checking the Net Inspector tool for this specific net, I can see that the total length is 46.2632 mm for both polarities.
I can’t understand what’s wrong here. Are the tools not reporting the correct values? Is the DRC not calculating the length properly?
Any insights on this issue would be greatly appreciated.
Note that the router removes track segments (or intersecting track segments) inside tracks from the length calculation
I went ahead and tried to put the pads, tracks and vias in sketch mode to see it there were any track segments inside the routed tracks. I couldnt see any but I also ùsed the cleaup tool.
Could you clarify what the “track segments (or intersecting track segments) inside tracks” are? I don’t see these occurring in my design.
Note also that the router removes track segments (or parts thereof) inside a pad, and then computes an electrically optimal path length from the pad entry point to the pad origin. The other length tools do not do this.
Key thing is my point above - this is a known issue; we’re just having discussions about which is “most correct”, and how to unify them in the codebase.
I understand. Essentially, the tracks within the pads and vias add length equally to both net polarities, so the Net Inspector will report a longer length for some nets (especially those with more vias).
My colleagues and I are transitioning from EagleCAD to KiCad. We often need to perform length and skew tuning for critical applications like DDR4 or PCIe, so it’s crucial that we can rely on KiCad’s tools for this purpose.
We are usually not inclined to ignore DRC errors, as this can make error tracing between board versions more challenging. However, since this is a known issue and a matter of determining the most accurate method, we can trust the tools if they generate correct results. We can confidently ignore these errors for now and wait for the issue to be addressed in future updates.
I might be misunderstanding you, but calculations are only run on connected tracks / footprints / vias. Nothing is added to a member of a differential pair from the other member.
I’m just saying the algorithms used to calculate each track length are slightly different between the router, the net inspector, and DRC.
My colleagues and I are primarily concerned about whether we can trust the tool’s output despite the DRC errors.
From what I understand, the main difference between the Net Inspector/DRC and the length tools is that the Net Inspector/DRC includes tracks inside pads/vias and other track segments (such as those inside other track segments).
In my particular case, I have a bus with various LVDS pairs, all inside the same net class. After setting the custom length and skew rule (as mentioned in my first post), all the tuning geometries are added to the nets, and in all cases, the tool correctly achieves the desired length and skew.
Since the calculations are made differently between the Net Inspector/DRC and the tool, the DRC throws length and skew errors for all nets. These errors could be ignored if the tools are producing accurate results.
I am trying to analyze further to understand the disparities between the reported lengths so I can determine if I can trust the tool for a good design and can safely sign off the project.
That’s a good question. For example the difference by following the centerline of a track from start to finish, will deviate from the “shortest path”, by regarding the track as a tube with a string in it and pulling the string tight. Especially with many corners such as length matching squiggles such differences will add up.
Is the routed length the best to use for length matching? It looks like that is the value the length tuning tool uses. Or is it unclear which gives the best results?
Yes the length matching value is probably the most accurate (which I think might be the same as the router length calculation, but I can’t quite remember).
I did some checks and the routed length includes the full length of the vias while the length matching value only includes the distance between layers. I just tried with regular vias, not sure how it works with blind vias. I would need to do some more experiments. I didn’t see the difference between the routed length and the tuning length listed in the link @gkeeth posted below.
But I can’t find a way to report those values or the routed length values, although it’s a least easy enough to click on the traces to get the routed length values.
James pointed out to me that the point in the docs about how the net inspector handles vias is not correct. In fact it uses the effective via length (i.e. the length between connected layers). In this regard the net inspector should actually be the same as the length tuner, I think.
I will update the documentation but I haven’t managed it yet.
When you say ‘routed length’, what do you mean by this, and where are you seeing it - in the message / status bar? (I can’t recall how that length calculation code works off hand).
I ran into this issue also. I’m working on a design with some matched length differential pairs. For example, on one net, the length matching tool gives me a length of 501.63 mils, which appears to include two complete via stackup heights. (There is a via at the source, the trace is on an inner layer, and there is another via at the end of the trace, which is at a connector. We are using via-in-pad.) Net inspector reports a total length for this trace of 439.09 mils, which seems to include just the portion of the vias that is within the electrical path. Yet, DRC is reporting an actual length for this trace of 529.03 mils. I am unsure how DRC is calculating that, but maybe it is including the connector pad length even though it is not the “shortest electrical path”. The 3 tools are giving me 3 different lengths for the same net. I have “include stackup height” enabled for length matching.
If I disable “include stackup height” for length matching, then the length matching and DRC lengths match each other, and the track length in Net Inspector also matches, but not the total length column, which still includes the partial via lengths. Although now I have a new issue in that the clock diff pair is routed on an outer layer, and so it only has a via on one end and now the length is different on that pair versus the other pairs. In theory, I need to shorten that clock pair now to match the new length of the other pairs. I believe this is the best approach for our design.
This is rather confusing, and it seems like it could get even more complicated with some designs, but maybe if you always have the same number of vias on all matched nets, then you can safely disable including the via height and then the DRC calculated lengths will match the tuned lengths.
