Major error in differential net tuning

Layout
1

With Version 7.0.10-7.0.10~ubuntu23.04.1, release build
wxWidgets 3.2.2 Unicode and bOOST 1.74.0

Using the differential tuning tool produced odd results. So I measured and summed all the segment lengths for two simple examples. First a diff pair that was a “perfect” match, and then a second case where I added a small difference.
As this is my first post I can only have one image. Perhaps more to follow.

Individual segment lengths top left to right 0.3339, 2.4330, 0.6449, 1.9451, 0.8791, 0.5449, 0.1769, 0.3807 = 7.3385 which is not equal to the Routed length of 8.8852 difference 1.5467 mm

The segment lengths of the bottom trace are 0.3339, 2.3594, 0.6449, 2.0924, 0.8791, 0.4712,

0.2888, 0.3016 = 7.3713 . Routed length 8.9160 difference 1.5447

skew between the sum segment lengths = 0.0328 an agreement.

Skew between routed lengths 0.0308

Now I want to match the length of two traces where the lower line has to reach 0.5 mm deeper in.

The tool is telling me that there is over 2mm of skew from going 0.5 mm additional trace length. Something isn’t making any sense here.

An expanded view of a typical 1 column deep fan out.

Starting with the top red trace we’ll sum the individual segment lengths. Routed length = 18.0629

Bottom Routed length = 14.3543

0.8845, 0.3420, 0.0492, 8.2606, 0.4526, 3.2627, 0.7228, 1.1000 = 15.0744 mm

0.2121, 0.4678, 0.2562, 7.9062, 0.4526, 3.3364, 0.7228, 1.1000 = 14.4541 mm

for a true difference of the individual summed segments of 0.6203 mm which seems exactly correct as the two traces are offset upward from the center line of pad M15 by about 0.1 mm.

However, the difference between the route lengths is 3.7086 mm

Now, running the length matching tool to tune out the real mismatch of 0.6203 mm we get

image

What a disaster looks like.

The segments for the bottom trace, left to right are now

0.2121 + 0.4678 + 0.2562 +0.1570 + 0.4271 + 0.1570 + 0.1571 + 0.4271 + 0.1571 +0.1570 + 0.4271 +

0.1570 + 0.1571 + 0.4271 + 0.1571 +7.1062 + 0.4526 + 3.3364 + 0.7228 +1.1000 = 16.6189

So, in an effort to match the lengths of a differential pair the tool added 16.6189 – 14.4541 = 2.1648 mm to the shorter length making it 1.5445 mm too long!

THIS NEEDS TO BE FIXED!!!

2

1.54mm sounds like the length of a via.
also you might want to fix the acute trace angle----see yellow circle below
If you are worrying about 1.5mm, this implies extremely high edge rates and so you wont want such an acute angle on the trace exiting the serpentine. And you wouldnt want that haphazard stub you have there and layer change without a stiching via/ plane return.
Your design defficiencies aside, can you please post the zipped PCB file and any relevant design rule DRU files necessary to load the project. We can take a look at this.
-glen. 35 years professional high speed design experience/ RF engineer.
image

3

My transceivers go to 12.5 GHz. No point in worrying about bad bends until the tool demonstrates that it can be trusted. So for now, no worrying about deck chairs! When the tool tells me that my skew is good to 4 decimal places, I’m going to check, especially when I can see that it is way off!

I have a ridiculously simple example that I’m happy to share when trust has been established. You might try two components, like this.

image
then add up up the segments.

In this example after the tool tells me that there is a perfect match the total segment length is 10.2669mm mm, when it should be 10.5911mm.

This is a trivial example, my reality is matching 28 diff pairs to the best that technology can provide. In practice, I find mismatches of many mm.

Thanks for the note about the ground vias. I haven’t forgotten them.

4

I get no delta… Exact same Length…

I Notice a bit of Extra Track in your image

Screen Shot 2024-01-29 at 09.28.42

5

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.

2 Likes
6

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.

1 Like
7

@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.

8

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.

9

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.

10

@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.

11

ahh , thanks. sorry flash_packets, my bad !

12

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.

13

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.

1 Like
14

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 :slight_smile:

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 :slight_smile: :frowning:

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 :slight_smile:

15

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.

16

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.

17

The OP has not replied yet. I hope its not another troll. We do seem to get trolls around new release time.

18

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.

19

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.

2 Likes
20

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.

  1. 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.

  2. 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.

  • In my previous job, I did a small modification of the peripherals of one board with DDR, I used an interactive router and unfortunately I moved one DDR signal, which changed its length. A subsequent DRC check alerted me that the signal was out of tolerance for its group. I think if something like this happened in KiCAD, I wouldn’t have noticed it at all and would have entered the production of the wrong board.