Overlapping zones

Allow overlapping zones to have a clean way to make a single solid ground plane with two nets (like AGND and DGND) and different netclasses.

It is a general consensus that split ground planes are like inviting the devil to dinner, so to speak.

Maybe with a special priority like -1

Just wanted to note, this is not a formal feature request in the sense that craftyjon suggested you write in your previous thread. Though obviously sometimes there are developers on this user forum, a request here will not be considered by the development team. To make a feature request, you have to make an “issue” on the KiCad Gitlab. The easiest way to start is to open KiCad, go to About KiCad, and click Report Bug. The issue template will open with your version info already pasted, so all you have to do is fill in the template.

All that being said, this existing feature request may be related to what you want. https://gitlab.com/kicad/code/kicad/-/issues/5838 It is mostly focused on grouping nets for schematic/ERC purposes, but there are mentions of combined star grounds that seem relevant. There is a reference to another feature request related to net-ties that might also be relevant. https://gitlab.com/kicad/code/kicad/-/issues/2265 If either or both are close to what you want, I’d encourage you to add a “thumbs up” to show support for them.

Yes, I know about this forum, but the rest of your post is what I was looking for before putting a formal request in the right place.

The whole “signals” thread seems a bit overkill and needs more time to be implemented… maybe just a quick feature about zones will avoid a lot of headaches for people using the non-split ground plane.

Definitely worth writing up the combined-zones idea on its own! Small/coherent features do have a better chance of attracting the attention of an interested developer. Consider linking back to the earlier forum thread, especially for context on the possibility of using custom rules for this task. (I’m not a developer but) I suspect the initial idea of zone priority -1 meaning “allow combined zones” will not end up being a good way to implement this (overloads the concept of priority for a somewhat unrelated idea, IMO) so custom rules may be more applicable here.

1 Like

I do not understand what this is supposed to mean.

You can create multiple zones and connect them to the same net, and those zones will be merged into a bigger zone.

If your zones have different nets, then they should simply never be merged in my opinion. Net names are to separate nets from each other. Breaking this fundamental rule creates more confusion then it solves problems. Using separate “AGND” and a “DGND” nets is deprecated. It is almost never a good idea to do this, although it is a stubborn misconception that grew over the last 30+ years and is still printed in lots of literature (and around the 'net).

I think schematic-wise is very useful to have different ground symbols, and different colors to low noise analog or high speed digital nets (and also widths ecc…)

The split ground plane was a way to keep things separated, but with sharp edge signals it has become a big problem.

My original issue was in regard to netclasses, I want to have power nets with big tracks and vias and signal nets with smaller ones. I then want them to go to ground to the same plane, so that power nets get big vias and signal nets smaller ones automatically.

I also don’t like the “I guide you” approach to writing software… I want the freedom of doing things my way (maybe the software can give me warnings or ask me to go in “advanced mode”)… because there is a big difference between theory and practice (and this field is all about choosing compromises, it’s almost never like the textbook says).

I think you are going overboard with the AGND and DGND thing… in microcontrollers they put AGND and DGND pins (with separated internal circuits) and tell you to put them together just outside the package, because it gives them problems to do that inside.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.