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.
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 postand 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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
but IMO ! and it should not permit you to override them without prompting you unless you explicitly say so.
At DRC time, that’s too late for 100 traces you routed with the wrong width.
In Altium if you try and place a trace outside the rules, a model dialog box pops up and asks you ’ do you really want to violate the rules for this object ’ ? Usually, you will say no
In the case of custom rules in Kicad, the tool should choose the opt constraint by itself if it knows. IE if I start placing a trace from say, a via with netclass xyzm then the opt trace should be chosen unless it picks up the trace width (per option) AND it satisfues the rules . This does not happen.
This brings up some bad memories. A program I used 20+ years ago had this approach. In some situations I had to repair some 30+ track segments, and it asked for confirmation on each and every track segment, and that did get quite annoying after a while. (similar situations popped up several times).
