I’m currently working on length matching in KiCad, and I’ve run into some confusion when dealing with traces that include branches or stubs.
From what I understand, when there’s a branch in a trace, KiCad seems to treat each segment separately in terms of length. In such cases, it’s not clear how the total length is calculated or how to properly match two traces that share a common connection point but take different paths (e.g., a T-junction or a stub).
My question is:
How do you perform accurate length matching when traces are branched or when multiple connections are involved?
Is there a best practice or method in KiCad to handle such scenarios?
Unfortunately this is something that is not well-handled currently, but as people are using KiCad for more complex and professional designs, we are bumping in to more and more.
The length tuning tools will find a path from the start point up to any complex junction (such as a stub as you have found). The net inspector and DRC will include every element in their calculations. This is referenced in the documentation.
Until we have a way to define and tune signals (eg from Pad X to Pad Y) this will be tricky. The only way I can think currently is to tune first, then add stubs. Or do some maths to add up segment lengths and tune with manual length targets.
It’s not ideal, it’s on my list of things I’d like to fix, but currently I don’t have a timescale for it - it’s going to be a big piece of work.
What about the Idea to add the RefDes of the IC’s for which length matching is calculated. That way you can set up the length matching for all tracks between for example a microprocessor and DDR RAM in a single setting.
There are several open issues around the length (delay) matching. The one below seems to be one of the most comprehensive proposals, but my focus is wandering and I’m getting a bit lost.
