Major error in differential net tuning

Layout
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.
21

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.

22

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.

23

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

image
image706×802 39.8 KB

24

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.

25

Hi think "NetClasses by layer " was just a bad mix of words.

K8 provides for “Rules for a netclass specific to a layer”
and meets all the ops requirements IMO

and FWIW, I have been evaluating the diff pair tuner and I do not see any issue where there is plenty of room to get the job done and that I do not have any locked segments and I clean up delete any nearby serpentine tuning region.

26

Regarding easily adding many nets to a netclass visually in schematic, I’ll mention the netclass directive by area feature request: Specificy netclass / group / room by area in schematic (#4613) · Issues · KiCad / KiCad Source Code / kicad · GitLab

27

That makes more sense. This is possible in V8, but it’s equally possible in earlier versions.

28

Yeah, the blanketing directive.
image

That’s good for assigning netclasses and defining constraints like widths, etc, but does not deal with multi drop segment timing, where timing needs to be defined pad to pad, or more usually, driver pad to destination pad1, driver pad to destination pad 2. etc
Like pad CPU-D0 on U1-D0 1st in the chain, then next segment CPU-D0 to U2-D0 2nd in the chain.

In Altium,Xsignals - that was a huge advance. And it was simple to implement…
The user defines the pad to pad timings as groups. and the tuner displays the group…and thus driver pad to 1st chip in a chain is GROUPA, and driver pad to the 2nd chip in the chain is GROUPB

This has to be done at PCB editor level, that sort of physical connectivity is not visible or present at SCH level.

29

I expressed it imprecisely, this is what I meant.

My Net Classes table looks like this

obrazek
obrazek1245×691 29.4 KB

There are some Single Ended Non coplanar, Single Ended Coplanar, differential pairs, etc.
It is usually there twice, once for the outer L12 layer and then for the inner L32(4). The stackup is symmetrical, so I don’t have to distinguish TOP / BOT, 2nd / 3rd internal. But I can’t create an assignment rule conditional on the layer. So I can’t use this thing.

That’s exactly what I meant…

30

I routed some display Mipi routes last summer for Raspberry IOboard, and it was a bit worrying and confusing when there was more than one length value on the bottom of the screen, and all of them were not always visible.
Edit: And:
I matched the pairs manually, and the board seems to work. So I have not tried any newer versions of KiCad.

31

You cannot assign a net class rule conditional on a layer, even in V8 (and though I am in no way responsible for KiCad’s future roadmap, I don’t see this happening in the future - net classes are a property of an entire net).

What I am trying to say, though, is that you can create DRC rules that are conditional on layer and net class. So your DRAM_DATA net class can have one width/spacing on outer layers, another on 2nd/3rd internal, etc. You don’t need different net classes for each layer. As Glen says, that should meet your requirements, but if not please explain why.

32

Hi Mark, I use only custom rules, so I dont have the netclass constraint table in use, it is empty. I find that this helps sorting rules… The file based custom rule editor is OK except for I’d probably split it up into different files for different rule categories - as my rule files are getting long and painful.
IE (mechanical (clearances, widths ) , electrical (electrical net rules ) , manufacturing (minimum annular ring, hole to hole clearance etc) )

I’d probably write a basic python wx helper gui for dealing with the rule file. since 10 pages is getting a bit much

33

Ok, having one class for the whole network makes sense. But then there cannot be a direct connection between the width of the connection and the net class, there must be a certain transformation mechanism.
For example, I will create a class SEN50, which means Single Ended Non coplanar with a characteristic impedance of 50 Ohm. I cannot have a single value for the width, but it must be definable for the entire stackup, otherwise it may not be true that the entire net has an impedance of 50 Ohm. For current loads it is similar, the Curr1A class generally needs to be transformed to different thicknesses as the inner layers tend to have a different copper height than the outer.

34

yeah… but cant you do this ?
Still, the problem is that the router does not observe the rules in real time. If the rule is as below, you can still place a 0.2mm trace, when a 0.1 on layer 3 is all that is permitted. That’s no good. and it doesnt show the resolved rule clearance, either. so that needs to be a feature that goes in. Post DRC alert is no good because if the tool permits you to route a thousand tracks wrongly, that’s rework.

(rule "trace width by layer2"
(layer In1.Cu)
(condition " A.NetClass == 'HV' ")
(constraint track_width (min 0.3mm) (opt 0.3mm) (max 0.3mm))
(constraint clearance (min 0.15mm) (opt 0.15mm) (max 0.15mm)))

(rule "trace width by layer3"
(layer In2.Cu)
(condition " A.NetClass == 'HV' ")
(constraint track_width (min 0.1mm) (opt 0.1mm) (max 0.1mm))
(constraint clearance (min 0.1mm) (opt 0.1mm) (max 0.1mm)))

or

(rule "trace width by layer2"
(condition " A.NetClass == 'HV' &&   A.existsOnLayer('In1.Cu')")
(constraint track_width (min 0.3mm) (opt 0.3mm) (max 0.3mm))
(constraint clearance (min 0.15mm) (opt 0.15mm) (max 0.15mm)))

(rule "trace width by layer3"
(condition " A.NetClass == 'HV' &&   A.existsOnLayer('In2.Cu')")
(constraint track_width (min 0.1mm) (opt 0.1mm) (max 0.1mm))
(constraint clearance (min 0.1mm) (opt 0.1mm) (max 0.1mm)))
35

Yeah, so you write a DRC rule that says nets in net class XYZ have width A and clearance B when they’re on layer top or layer bottom. Then you write a rule that says when those nets are on layer 2 and layer 3, they have width C and clearance D.

The rules quoted by Glen are basically what you want.

36

The router does observe the rules in real time, but it will let you override them if you want (and then report it as a DRC error). One way that people often override the rules is with the “when routing from an existing track use its width instead of the current width setting” option, which would get you an undesired result in this case. If you turn it off, the router will use the opt trace width from rules on a per-layer basis.