Note that Kicad calculates the lengths for tuning purposes properly, for example if your tracks makes corners inside of pads, these won’t be counted, Kicad always uses a straight line from the position where the track first touches the pad outline to the pad center. You can see this on your screenshot if you zoom in.
Therefore it is normal that you get a different result if you just add up segment lengths.
FWIW, there are many closed issues in 8.0 related to differential pairs and the tuning tool. You might look at the latest release candidate and see if the behavior is different from what you’re experiencing.
@Flash_Packets suggest you tone down your criticism of the tool. You wont make any friends here otherwise… We know you are frustrated. Why not try Altium?
So I tried a few diff pairs in Kicad . The tuning tool appears to provide the correct length matching. I tried a few messy routes and it is correct. again, why dont you post your PCB file ? Nobodys going to rip off your design, honestly. If you dont post it, or send it to the devs, well there’s no evidence from my POV.
Known Kicad defficiencies : Certainly diff pairs needs BACK key to work, but otherwise it is functional . You’ll probably need to hand route the fanouts to get what you what all the time.
Adding to @glenenglish post, if you do find examples which break length tuning, raise issues on the tracker with the example, for the developers to examine.You can make the issue confidential, so that only the core developers can see it.
I did some more diff pairs this morning, I tortured the tool. Seems to perform length calculation and length matching fine.
A diff pair primer :
They MUST stay on the same layer together, keep them tightly coupled , never more than a width/height product apart…and if they change layers, they must change together, and if changing layers, its a good idea to insert plane stitching vias or plane stitch with bypass caps because in theory the pairs if tightly coupled will be ‘ground independent’ but PCBs are never perfect so there is always some imbalance. Also, length match at the sender end not the receiver so the travelling wave along the trace pair is in phase as early as possible. Of course, never put a via in one side of a diff pair and expect anythign to work.
Suggest flash packet post a simple example PCB for others to see what the story is.
@Flash_Packets cannot post files until they reach “Basic” level in the forum. See New Member Information FAQ.
To see a forum user’s (any user’s) Trust Level, click on their avatar (or name), then again on the newly opened avatar (or name).
@Flash_Packets needs to open and read a couple of posts of another thread (their fifth thread to open) to self promote themselves to Trust Level one - Basic, to be able to post a file.
ahh , thanks. sorry flash_packets, my bad !
I understand it that if before being close to each other the tracks pair have some way separated then their length should be matched before they meet themselves to travel together.
But what “not the receiver” in this sentence means?
I think that at the receiver side they also should be matched and your sentence suggest that may be not.
I didn’t used differential tuning tool so have no experience.
Hi Piotr
Good comment, I will rephrase in more words. If a skew exists on a differential trace pair, that is to say between the transmitter and receiver, one of the pairs is longer than the other ; the skew should be removed close to where the skew occurred. I have seen situations where skew was introduced early in the trace route, in a U-shape, and then travelled 50mm to the receiver. The skew was not corrected until at the receiver pins. This is suboptimal.
If the skew exists on the pair over a large distance, the differential properties of the signal may be degraded if the length of the skew exceeds the one third of the edge rate of the waveform, approximately. Degradation will introduce loss of amplitude at the receiver, jitter and EMR (EMC problems) .
Sometimes skew is hard to avoid , such as a differential trace doing a U turn… In this case it’s ideal if the shape is varied, or the path is compensated (with another shape) as to reduce the skew.
Sometimes, it is not worth caring , because the distance the signals travel with skew is short compared to the distance in rise time terms. That is, for a 50mm distance (about 320pS) , and a rise time of the signal of 1nS, then the signal will not look (much) different anywhere along the trace when the signal is changing.
Fast signals with 100pS rise time, say, fast LVDS, MIPI, now we more easily experience problems. Length matching between pairs should always be better than 1/3 of the rise time . There’s a few exceptions to this, but that’s a good number. 33pS on FR4 is 10mm. so you see alot of length matching is is BS - however because these skew transitions happen thousands of times per second, and they are associated with noise, as all processes have noise (transmit and receiver, power supplies etc) , jitter will be produced, creating jitter in the acquisition of the signal at the receiver
Therefore we try ( need ) to route diff pairs to better than that, in practice routing within 1/10 of a rise time is no big deal. In practice the direction of the weave of the coarse glass mat in PCB prepreg can have a large effect on propagation velocity.
If the signal is multi level, not binary, constraints tighten proportionally.
That’s a real big rough take on it, made as simple as I can make it. For single ended traces on DDRRAM etc, length matching in groups there is a bit of a different game- the memory chips are fast and contain asynchronous paths that are timing flukes and very much rely on signals arriving at exact times relative to other signals. But no need to get carried away, (although we do) I’ve never had a simple DDR4 that did not work first go.
I was writing from home and during my way to work I thought I got what you wanted to say so get back here to correct what I have written but I see - I’m too late 
May be it is a problem with my English but at that moment I began to suspect that may be you all the time were speaking about two differential pairs (like Ethernet 10/100M) so sender and receiver would not be the ends of the same pair but sender connection to socket and receiver connection to socket (separate pairs). But text following it made me to abandon this assumption.
Ok. that is more probable reason than what I have written as “pair have some way separated”.
I have never reached such frequencies that I would have to worry about that and will never reach 
From time to time happens here (at forum) someone claiming that ‘autorouter’ is must have. I write then that it happened us (previous century) that our employee used autorouter and got 100% routing done so he ordered PCB and it didn’t worked. Data line was 1cm length while its clock line was around the whole PCB - so about 25 cm length. Even it was not very fast signalling it didn’t worked. It was first and last time we used autorouter
I suppose that you are using V8 while OP is using V7.0.10 as he written in first post.
I don’t know if between V7 and V8 differential pair tool was changed in any way but it is very likely.
So have in mind that results you get from V8 can be different than OP gest from V7.
Hi Piotr
Yes am using latest nightly K8rc2.
Professional users rarely use autorouters. I do not know of anyone who does. I am sure there are some users, and it could do a could job of wiring up old style TSSOP RAM and memory , for sure.
Really effective interactive routing tools I think are preferable. Altium’s push and shove of multiple traces with equal spacing glossing is an example, or being able to shove a track on the other side of a via.
On sender and receiver. Or generator/source and load/sink. Yes, there are some bidirectional diff pairs, (that is to say, source may be at each end, switched) so that requires more care.
The OP has not replied yet. I hope its not another troll. We do seem to get trolls around new release time.
doing the math of the complaint, it would equate to the OP not taking into account the 2 via distances + the BGA pitch which is 0.65mm not 0.5mm as claimed.
I know the op talked about 12.5 GHz transceivers, I am not sure how that relates to the design question, because I use those FPGAs in that package and the MIPI on them is only 1.5 Gbps per lane (750 MHz DDR clock) … and they’re not true ‘tranceivers’ since they need companion clock.
The above discussion about keeping differential signals in phase throughout the route was addressed nicely (I thought) in an AppNote I was just reading for Microchip’s USB hubs. Pages 17 and 18 have a nice discussion and some very illustrative graphics, with both good and bad examples.
Hello,
First of all, I want to say that the KiCAD developers are doing an excellent job considering the limited resources that flow to the FOS.
But I also have to agree with Flash_Packets that length tunner is not reliable.
I am currently struggling with a board design where there is a CPU and one DDR3 chip. I use version 7.0.10 on a desktop PC and more often version 7.0.6 on a laptop (7.0.6 because 7.0.10 works worse on a weaker machine). I don’t want to use KiCAD 8.x on the production version yet because I don’t want to do a one-way V7 → V8 conversion until V8 is stable.
For coarse tunning I use the Total Length value of the Net Inspector which works well.
I then do fine tuning with the Length Tuner tool. Mostly the differences between the Length Tuner and Net Inspector values are small, less than 1mm, this can be simply explained by the difference between mechanical and electrical length. In several cases, the difference between Tuner and Inspector is large, for example 5mm or even 14mm out of the total 29mm. I found that the tuner for some reason splits the connection into several parts, although the router evaluated this connection as connected. In one case it is divided into vias in others at the end of some segment.
At one point I needed to move the DDR along with the tuned paths 2mm further to gain more space, on the other hand I needed to keep the fanout around the CPU still. I used the lock function on the CPU and surrounding paths. After pushing it, it was enough to add 2mm in each way and it could be done. For some reason, the deviations between Tuner and Inspector have increased. Finally, I found out that the Tuner does not count the lengths of the locked segments, which is definitely a bug.
In conclusion, I have two things that I would like in a future version.
I would like it if Net Inspector added a column electrical length (the value with which the Tuner works) I understand that the calculation of the electrical length is quite difficult and for some 80% of the connections on my board it does not make sense, so the calculation of this value could be initiated button for the filtered signal set.
It would be great if sometime in the future it would be possible to add attributes or classes for impedance and signal length relationships in the schematic editor. Based on these values, it would be possible to create rules in DRC to control the width of the joints and their length bond.
There were a couple of thoughts in your message that reminded me of issues I’ve seen gone by, so I collected a number of them below. If an issue affects you, consider giving it a “thumbs up”. While a large show of support for an issue doesn’t guarantee that a developer will volunteer to work on it, the support can’t hurt.
For the length matching DRC, you should already be able to do something of the sort in the custom DRC rules if you name your related nets in a clever way (or group them with a netclass). I’m not sure which length calculator is used for the DRC check, so you’d definitely have to play with it first.
Thank you for your overview.
I had a netclass defined in the schematic for the Ethernet MDI interface, but a few days ago, I scrapped it and switched to assigning netclasses in PCB New using regular expressions. This goes against my initial desire to have everything defined in the schematic. However, the method of defining netclasses by attaching a rectangle with the definition to each individual signal is only practical for a limited number of signals. For instance, DDR3 involves around 50 signals that must adhere to specific length and impedance requirements. In my schematic, the connection between DDR3 and the CPU occupies only one side of an A4 sheet, leaving no room for 50 rectangles. Some EDAs will allow for the netclass to be defined en masse using a single rectangle that intersects the respective signals.
I must also mention that for effective work with high-speed signals, net classes based on layer are essential due to varying widths on different layers depending on the stackup. Fortunately, this feature is set to be introduced in V8, as discussed on the KiCad forum (Net classes based on layer - #6 by glenenglish).
I experimented with a plugin for handling length matching in V6, which, to my knowledge, isn’t available for V7 yet. I haven’t fully tested its capabilities, but it appears to source lengths from the Net Inspector.
Ultimately, I believe having the electrical length displayed in the Net Inspector is crucial. With net classes based on layer expected in V8, and if a way to graphically save netclass definitions directly in the schematic and everything could somehow be connected on its own rules, it would fully meet my needs.
I’ve also observed in numerous bug reports etc that ops do not know the correct electrical methods of generating delay lines, let alone differential delay lines. In many cases, what ops are complaining about - I beleive it is unreasonable for the tool to deal with the space and segment placement.
like this one.
Mark, I think the problem of simplicity comes when it’s pad to pad segments that need attention, especially in multi drop routing. IE where the Altium Xsignals is a good example of the user identifying pad to pad dleay constraint (and indeed, pad to pad length panel readouts) - I addressed how we might go about this thoroughly in my post and how I think we can acheive functionality without alot of expensive GUI programming time.- acceptable for the user to put it in a text file or flag sch jns etc and about how I think we can simplify the implementation because alot of corner cases are irrelevant to delay calcs.
as for effective net displays : here’s an Altium example. note the list of segments once I have highlighted the net : A0.DC_P_PP1
This is a misunderstanding. There’s no way to specify different netclasses by layer in V8 (nor should there be IMO, that feature does not make sense to me).
What is possible in V8 (and V7, and V6) is to define design rules for a net class that assign different trace widths/clearances per-layer.
