Feature request: Naming track widths and via sizes

[cal-linux]

It recently hit me, that having an actual number as the width of a trace is not a good idea. Same thing for via sizes and differential pairs parameters.

They should have a name/label. When I go to the Board Setup, Tracks & Vias, the entries in the “Pre-defined tack and via dimensions” should have:

• For tracks: Name, Width
• For vias: Name, Size, Drill
• For diff pairs: Name, Width, Gap, Via Gap

And then, the pull-down list in the “main” pcbnew work window to select track width should show the widths by their name. For example:

Track: Data-bus (0.15 mm / 5.9 mils)
Track: Control-line (0.2 mm / 7.87 mils)
etc.

Maybe the user could/should have the ability to omit the name, in which case it sort of falls back to the current functionality. The width is just a “hardcoded” numeric value)

An essential part of this feature is that if I go to the Board Setup dialog again and edit one of those, and for example change the Data-bus track width to 0.12 mm, all of the traces with Data-bus width will immediately change from 0.15 mm to 0.12 mm — yes, with the risk that if increasing, it can cause DRC violations; after all, this happens whenever one manually edits the width of a track or tracks the user can deal with that; and it’s not a critical problem: DRC violations do not stay there silently, assuming that one does run the DRC checker, either periodically, or at least before finalizing the board.

The feature also includes the aspect that the .kicad_pcb file should use the names. For example, the lines in the .kicad_pcb file would look like this:

  (segment (start 10.0 10.0) (end 20.0 20.0) (width Data-bus) (layer F.Cu) (net 0))
  (segment (start 30.0 30.0) (end 40.0 40.0) (width Control-line) (layer F.Cu) (net 1))
  (via (at 40.0 40.0) (size Control-line-via) (layers F.Cu B.Cu) (net 1))

While we’re at it, if you indulge me on a tangential rant / additional suggestion: it is also a horrible idea to put the net number in those lines; if net 1 is GND, that last line should be:

  (via (at 40.0 40.0) (size Control-line-via) (layers F.Cu B.Cu) (net GND))

[End tangential rant]

And of course, the user_trace_width and user_via lines in the setup section at the beginning of the .kicad_pcb file would be adjusted accordingly.

Notice that although this has some overlap with the functionality provided by net classes, it is not the same (I mean, putting aside the detail that net classes have such poor functionality that they are an almost-useless feature; I hope this will improve in KiCAD 6).

Who’s with me on this one? (I’m sure David Wheeler, if he was alive and cared about KiCAD at all, he would be with me on this one: “Every problem in computer science can be solved by an additional level of indirection” )

[Rene_Poschl]

Isn’t this exactly what net-classes are there for?

[craftyjon]

Yes, net classes will do this today.

This also relates to the request for custom pad stacks: vias will be able to have custom stacks just like pads once we implement that, so you can have a “library” of preset via stacks (including information about size/shape on different layers, etc)

[cal-linux]

@craftyjon

Yes, net classes will do this today.

No, not really. For one, net-classes have net granularity (that’s too coarse). If I connect point A to point B, I may need to run traces of different widths. For example, if I want to maintain characteristic impedance when jumping from outer layer to inner layer (outer layer is a microstrip, I may need width X to achieve impedance Z; on an inner layer, a stripline, may require width Y != X, to maintain impedance Z).

Notice that I still want the advantage of the “named width” for both the outer layer and the inner layer — I may want to change the geometry / dielectric characteristics, etc., and it may turn out that I need to change X to X’ and/or Y to Y’. With named widths, I could just set up my 50ohm-top-layer width and my 50ohm-inner-layer width. With net classes, the best I could do is just use a hard-coded width for one of the two widths.

Unless I’m not understanding net classes correctly?

Another thing is: they [net classes] do not work. Again, not sure whether in the daily v6 builds this has been improved.

I just ran a test; I assign GND to net class POWER, which has trace width 0.5 mm. I connect two GND points in the layout. It comes as 0.5 mm. I now change net class POWER to have 1 mm trace width. My layout is unaffected. I need to go one by one, each trace segment, edit it, and tick the box “Use net class widths” for the width to change. (again, I have to individually, one by one select each of the trace segments)

I do like some features in the net classes functionality — for example, having independent clearances for each net class, that’s a very neat feature, sure.

The point is: the user has the choice to forget about net classes and individually select widths and via sizes; my claim is: such selection should not be done through, or in any case should not be restricted to, hardcoded numeric values; such selection should be made through named widths and sizes.

Please do correct me if I’m wrong — I have never used net classes in an actual project.

[craftyjon]

@cal-linux

For example, if I want to maintain characteristic impedance when jumping from outer layer to inner layer (outer layer is a microstrip, I may need width X to achieve impedance Z; on an inner layer, a stripline, may require width Y != X, to maintain impedance Z).

You are right that this is not really possible in 5.x or earlier

The new design rule system is designed to allow more granularity by letting you specify things based on conditions like being on a certain layer, etc.

Another thing is: they [net classes] do not work.

This is by design, and I’ve never heard of another PCB layout tool that works the way you describe. We would never want to automatically change the geometry of tracks that have already been placed, because it could create DRC errors. There are tools to update groups of tracks together, but it still has to be an intentional operation by the user, not an automatic thing that happens when you change netclass settings.

[cal-linux]

@craftyjon

We would never want to automatically change the geometry of tracks that have already been placed, because it could create DRC errors. There are tools to update groups of tracks together, but it still has to be an intentional operation by the user, not an automatic thing that happens when you change netclass settings.

Hard disagree here — this makes them essentially useless, the way I see it.

The potential to cause DRC violations is really not a problem. On the one hand, it is the result of an explicit user action (granted, the changes are hidden behind a layer of indirection). But there are many other ways for the user to make a change that causes DRC violations.

But on the other hand, and more importantly: it’s really not a problem:

• DRC violations do not stay silent. The tool will tell you that there are DRC violations and will point you to them, one by one. (that is, assuming that one does run the DRC checker, which one should!)
• At the moment that the user changes a net class setting, the program could let the user know (two options: either refuse the action, with error message Applying this change will cause DRC violations; or just apply the change, but warn the user that there are now DRC violations as a result of the change, maybe asking Do you want to undo the change? … Or well, a third option, when the user executes the action, ask the user for confirmation: This change will cause DRC violations. Do you want to proceed?

As an analogy (since you are a developer, I assume you are perfectly familiar with C++), consider this fragment of a program:

const double min_trace_width = 0.1;

// ··· 

if (trace_width < min_trace_width)
{
    error_message ("Trace width below minimum allowed");
}

Now, the equivalent/analogy of the net class functionality would be that in the above program, if you change the declaration of min_trace_width to initialize it to a different constant, then all lines that use min_trace_width maintained the old 0.1 value, and that you needed to go and maybe right-click, line by line where min_trace_width is used, and ask it to change.

After all, the argument that “automatically changing could cause DRC violations” has its analogy in here: changing min_trace_width to some other value could introduce bugs in the program. For example, say that you change the line to:

const double min_trace_width = 0.05;

Well, there could have been a line in the program, buried inside an if that executes only in a rare condition:

trace_adjustment = something / (min_trace_width ‒ 0.05);

So, changing the constant (and automatically propagating the changes, as C++ or any programming language would do) is actually creating a divide-by-zero bug that in principle goes silently (unlike the DRC violations, which the program checks for!)

Really, to me, the current net classes functionality is as useless as named constants would be in a programming language where you needed to go and one by one at each use of that constant, ask the editor/IDE/compiler to reassign to the new value of the named constant after you changed the declaration/initialization of the constant.

[cal-linux]

@cal-linux

At the moment that the user changes a net class setting, the program could let the user know

BTW, in case someone is tempted to throw the argument that “well, that would be inefficient, since DRC checks are computationally expensive”… Two things:

• The program does not need to check every element against every other element; only the elements with the net class being changed against the others.
• Well, it’s not really expensive. A DRC check takes a few seconds on relatively complex designs (my current project is an 8-layer board, 100 lines BOM, .kicad_pcb file is 32 thousand lines; DRC check takes less than a second on a 7-year old computer). Compare this against the time it takes the user to manually adjust everything.

[chschlue]

I don’t get the code analogy at all.

That aside, “could create DRC errors” probably wasn’t strong enough.
Summarily widening tracks will create errors in most real-life cases.

[craftyjon]

I understand this perspective. You should open a feature request capturing the desire to automatically change all traces and vias to fit within the design rule min/max constraints when changing those constraints.

I’m not saying you are wrong, I’m just saying that this is generally not how most PCB layout software works, KiCad included, and departing from this norm would require careful thought about how best to do it.

While KiCad does have tools (and better ones in current master than in 5.1) for bulk-editing of objects, those tools are still designed with the philosophy of having basically no levels of indirection between making an intentional change and seeing the board updated.

The general idea with design rules (and netclasses fall under this umbrella) so far has been that they will never cause a modification of your existing design, they can just impact how new items are created and how errors/warnings are reported.

Again, I’m not saying your desire is wrong. It’s just a big leap conceptually from how KiCad works today. I do encourage opening an issue to get more developers in the conversation.

[cal-linux]

@chschlue

I don’t get the code analogy at all.

I’m not really sure what I can say about it… (are you familiar with C++ programming? or C, etc.?)

@chschlue

Summarily widening tracks will create errors in most real-life cases

Not really. With almost certainty I would say not in most. That is even putting aside the detail that perhaps 50% of the times you will be making the width smaller. Again, the issue is irrelevant, my claim is that the potential for DRC violations is not a problem.

[chschlue]

@cal-linux

I’m not really sure what I can say about it… (are you familiar with C++ programming? or C, etc.?)

I understand the examples, I just don’t find them particularly… analogous.

@cal-linux

Not really. With almost certainty I would say not in most . That is even putting aside the detail that perhaps 50% of the times you will be making the width smaller. Again, the issue is irrelevant, my claim is that the potential for DRC violations is not a problem .

Granted, making the width smaller generally won’t.
But I still can’t imagine why I would want to do that more or less on a whim. Won’t help against rising copper prices.

I’m just saying the proposed behavior would annoy me in most cases.

[craftyjon]

@cal-linux

With almost certainty I would say not in most .

I don’t know about your designs, but in mine, increasing netclass trace width would cause most traces to be in violation as I normally set my clearance rules such that I can butt traces against each other with the PNS router. You are right that decreasing width would generally not be an issue.

[cal-linux]

@craftyjon

I’m not saying you are wrong, I’m just saying that this is generally not how most PCB layout software works, KiCad included, and departing from this norm would require careful thought about how best to do it.

Although I can understand this (and completely agree with the second part of the statement), I’m baffled that EDA programs work like this (I exclusively have experience with gEDA and with KiCAD, and gEDA didn’t really have this feature — not that I knew, anyway).

This seems to go against common wisdom in computing:

• Defined/named constants in programs: the whole point is that if we change the value of that constant, every instance of usage will automatically get the new value.
• Parameters in spreadsheets (e.g., tax rate percentages in a tax calculation spreadsheet): the whole point is that we do not want a hardcoded number in formulas, but a reference to some parameter in a cell; if I change that parameter, every instance that refers to it gets updated.
• Configuration parameters (and net classes are a very close analogy here — they are, in a sense, configuration parameters): you set up sizes, colors, shapes, etc., in configuration settings. You now create instances that grab the values of those settings; if later you go and change those settings, the instances you placed earlier will be adjusted (update their color, their shape, size, etc.)

In general, the idea that, as with net classes functionality, you set up some “configuration parameters” to be used in a “read the value and save a copy of that value” manner, is just baffling.

[craftyjon]

Most EDA tools don’t historically directly take concepts from computing. They take concepts from mechanical drafting tools, which take concepts from pen and paper.

There are alternatives, like people working on projects to write schematics with code and things like that, but in terms of what the industry is used to, any kind of “automation” feature has to be careful to not stray too far from this paradigm without risking the consequences.

This is especially true in EDA tools because autorouters are historically pretty bad, and so many professional designers have a (perhaps healthy) skepticism of the program doing too much automatically.

[chschlue]

I think your original example about doubling power trace width and the loop examples is comparing apples and oranges.

Suddenly noticing you’re supposed to count to 511 instead of 255 and suddenly noticing power requirements are off by a factor of 2 is completely different.
In the latter case, adjusting trace widths probably is the least of your worries.

[cal-linux]

@craftyjon

I don’t know about your designs, but in mine, increasing netclass trace width would cause most traces to be in violation as I normally set my clearance rules such that I can butt traces against each other with the PNS router.

Ok, let’s take a step back; because I don’t see how this line of thought contradicts the proposal/desire to have net classes settings to automatically propagate.

If you set up a certain net class and use it in the tightest possible routing, then that means that probably / most-likely, that is not one net-class that you will ever change.

Again, that net class, you will not want to change. But this is not really an argument to claim that we should never be able/allowed to change net classes settings (in the way that I’m proposing, that is; with automatic propagation of changes).

Conversely: what happens if you do need to increase the width? As in, you just made a mistake; maybe you misread the PCB fab requirements; maybe your budget was reduced by your boss after you were 75% done with the layout, and you needed to switch to a less-fancy process, and for the new price, the PCB fab does not allow 0.12 mm traces, and the new required minimum is 0.15 mm, etc.

The point is: you already have the tightly routed 0.12mm traces that are as close as permitted. Yet, you must change them. Period, you must.

My claim is: why is it that not permitting to do it “the easy way” would be better in this case? For that matter, quite likely, an “automated update” of the traces widths will be painless despite the initial DRC violation: you now (after having the new widths and possibly new DRC constraints) just grab the innermost trace that is in violation, and push it a bit outwards. The push-and-shove routing will automatically push the other traces outwards, eliminating all DRC violations in the process!

Again: that that is not a feasible solution because doing that causes other problems? Well, again: you are in a situation where you will have to, one way or the other, make all of those changes/adjustments. Not really an argument against permitting the software to apply/propagate settings change automatically.

[craftyjon]

I am not disputing the need to make such changes, just disputing whether or not they should be so indirect and automatic.

The workflow I am used to for such a change (in commercial tools) would be:

1. Update the netclass settings to be correct
2. Use a properties search to select all tracks that belong to the netclass and have a width below the new minimum
3. Edit all the properties to increase the widths
4. Fixup any clearance issues caused by step 3

The key difference is that there is no automatic / silent change to a bunch of traces when I close the netclass setup in step 1. The change is not silent because you see all tracks that are selected before you update them en masse (and also have the opportunity to selectively de-select certain tracks if for some reason you don’t want to change all of them) I think this visibility into what you’re about to change is the important part missing from changing everything automatically.

KiCad currently isn’t great at this because it does not have a good properties-based search system (yet) so Step 2 is quite hard in KiCad. We’re working on fixing this!

[eelik]

@chschlue

I think your original example about doubling power trace width and the loop examples is comparing apples and oranges.

Changing track widths automatically could be compared to find&replace refactoring: it must be made on purpose. You would be negatively surprised if you would change a name of one variable and noticed the same word is replaced everywhere without asking you.

[craftyjon]

Exactly: what we need (and are working on) is better tools to do intentional refactoring. What will be a really hard sell is features that try to guess at what refactoring you want to do and do it automatically.

[cal-linux]

@craftyjon

Most EDA tools don’t historically directly take concepts from computing. They take concepts from mechanical drafting tools, which take concepts from pen and paper.

But you have to agree that things evolve, and definitely the wonders of computing take over (at least little by little). Computer generated/simulated stuff, or in general, computer exhaustively taking care of checking things, etc.

Still, I understand your point (even if not agreeing with the “conclusion”): after all, the people that started using EDA tools when they started to come out where the electrical/electronics engineers that were used to the “scotch tape” sort of way to create the layouts, and not the computer scientists that were used to writing programs.