Net classes in Eeschema (5.99)

[eelik]

Net classes can be defined in eeschema. Net classes are now in both pcbnew and eeschema, in the board settings and schematic settings respectively:

Jeff told about it:

@JeffYoung

Net Classes can now be assigned in Eeschema. They can also be used to color/style the wires & busses of a net. (And of course they feed through to PCBNew Net Classes.)

@JeffYoung

Net class assignments are what’s new. Net classes are normally applied to more than one net name.

We’ve talked about how to visually indicate net classes on the schematic.

1. The current way is to use the net class colors and line-styles. Negatives are that they might not work well for very large netclass sets; positives are that they appear in plots, print-outs, etc. and have historical precedent.
2. We could also support annotations (like the net names shown in PCBNew). Positives are that they’re easy to turn on/off en masse ; negatives are that they won’t appear in plots, print-outs, etc.).
3. We could have a mechanism similar to labels. Positives are that their placement, orientation, etc. is under the control of the author; negatives are that they’re harder to edit en masse and they can be visually noisy.

I’d love it if we could get by with just (1), with a slight preference for (1) + (2) if we can’t. I think Jon has a preference for (1) + (3).

[hildogjr]

To everyone follow, the propose of 3 can be understood in https://gitlab.com/kicad/code/kicad/-/issues/4613

[craftyjon]

Also for reference although I didn’t yet mention it in that issue: Jeff and I had talked about one option being to give labels their own “fields” (i.e. the same way a component has fields) that can be hidden or shown. Netclass would be one of these fields.

[SembazuruCDE]

I’m not testing the 5.99 nightlies, but I have a question about the colors. Is it free-form color chooser or just a list of colors? I hope free-form, but if it is a list of colors I hope the 10 standard resistor color codes are all represented. (Granted, printing yellow on a white page can be challenging…)

Also, I tend to use color coded test-points (which are available in the 10 standard resistor color code colors) for different signals. Does it make sense to allow some sort of hierarchical net classes? For my example, I would have a parent netclass for signal that defines the width and spacing and a default color. Each child would only change the color. That way if I decide that I want to thicken or thin all my signal routes I only have to change the parent net class instead of multiple differently colored signal net classes.

Is this a complicated enough suggestion/request to warrant its own github issue? Or am I just crazy?

[craigarno]

I would like to use eeschema net classes to communicate design requirements from the schematic to PCB layout. Even in a 1-man shop it is good to have your own design notes available to help constrain your layout design. In a 2-man shop (schematic → PCB layout) it is important/imperative to communicate design rules/requirements with the ability to easily (and consciously) override in PCB layout as necessary:

Power: needs more copper (thickness and/or trace width) to carry current, also where flood/fill is used
Low Noise: Clearance from noise generators like switching supplies, phase locked loops (jitterators), other digital logic (noise generators) for sensitive analog front-ends in both synchronous and asynchronous designs
High Speed Design: Can’t cross gaps in copper planes or reflections and signal degradation occur from impedance mismatches
Differential Pairs: must be routed together and length tuned to avoid signal degradation especially when routing around bends, vias, parts other obstructions (USB, HDMI, etc.)
HS Bus Groups: Where clock and data are running fast enough that edge timing and rise times are critical for signal edge alignment and noise management (think DDR memory designs, HDMI, etc.)

I spent this morning looking for information about how I might use KiCAD 5.1.6-1 release build Net Classes to communicate these necessary design rules from schematic generation to the PCB layout phase of a project to help me maintain my own sanity in non-trivial designs. Otherwise these things must be documented and check-lists prepared/maintained manually in LibreOffice type documentation. This is as much of an “option” these days as rubbing sticks together to make fire.

My sense of the current state of affairs is this is the direction KiCAD is headed, which is fantastic. Seems like there isn’t much clarity (some confusion) about what problems are being solved from this and other postings in the forums. I hope this short list helps provide clarity from a must have for engineering performance reasons as opposed to artistic esthetics (colors) which might enhance documentation clarity for error reduction, also important, but secondary to performance needs.

If what I described isn’t clear enough, I have three different books on the subject I can recommend.