How to connect a heterogenous bus throughout a hierarchy?

In my design, I have a bus with heterogenous bus members. This seems like just the kind of thing I can’t do in 5.1.x but 6.0 will handle nicely. So I tried to test this out. And I’m not having luck.

I have read several posts about busses in 5.99 and 6.0 (like Do you have any idea of adding wiring harness to the schematic diagram? and Hierarchy - Bus NOT connecting and 5.99 Trying to understand ERC errors and A single bus group and ERC and How to connect busses across heirarchy levels (KiCAD 5.1.10) and…). So the answer might be right in front of my face and I’m too daft to grasp it. I apologize if I’m just being dense.

I created a test design in 5.1.x that shows what I want to accomplish (though I realize not in 5.1.x). I also added the traditional bus style that works fine in 5.1.x as a control. Of course, I have many ERC errors that I think are simply telling me that the heterogenous bus isn’t connecting through the hierarchy. (10.6 KB)

No surprise there. Time to convert to v6 RC1 and then try it again.

At first I had warnings and/or errors, but I wasn’t surprised. So I created a bus alias and added the member nets to the bus, but that didn’t fix things. You can look at the Bus Definitions dialog to see if I set that up correctly.

I currently show the bus name on the block pins at the top level and in the subsheets in curly brackets, but I tried with and without the brackets to no avail. And I also tried putting the bus name at the top level in curly brackets, but that didn’t work either. I believe I tried all permutations of curly brackets, both with and without defining a bus alias, but nothing worked. (67.0 KB)

I think what I want to achieve is clear, having a bus with a simple bus name and member nets with unrelated names, but I’ve not figured it out. I’m sure KiCad v6 is able to do this so that means the issue in me. But if I can’t figure it out from existing posts on the forum, hopefully an answer here will help others in the future. Once this is sorted out I’ll post screenshots to capture what does work for posterity.

Sorry again if I’m just overlooking something obvious.

look at the attached modified project.
I have included the different naming-variants I am aware of.
Look also into the two subsheets, there are two different variants of naming. (28.0 KB)

If i understood correctly your proposal, i noticed that this is not working 100% as expected, nets do get highlighted because of their labels attached but buses don’t:

My approach is something like this:

@Aris_Kimi: I noticed the inconsistent highlighting too. I have filed a gitlab-report (

I think it’s a very minor issue, it affects only the highlighting and only if one mixes the alias/non-alias version of the bus-names. The connection of the busses is ok, all pins are connected. This can be controlled with the airwires on the board.

The example-project should only show all bus-naming-possibilities which I know. I don’t recommend to mixup the two naming-variants, but I wanted to show all variants.

regarding your example LCD{RS E BL}:
Your approach with bus-name before the braces (LCD{RS E BL}) is fine on your example and I use this variant also sometimes, but it has the disadvantage of longer net-labels on the unfolded nets. If you unfold nets you get labels LCD.RS / LCD.E / LCD.BL and so on. It gets worse if I use longer descriptive bus names (SPI_BUS_TO_INTERNAL_LCD).
This is good for distinguishing between many busses, but on designs with few busses I prefer to have shorter net-labels and get rid of the bus-name itself. So my main-usage (may change in the future) is labelling the busses without name and only with the curly braces {RS E BL}.

IMO, to be honest, the only true benefit i notice is shorter names, while (yes) my way has probably a disadvantage over this one, i am afraid omitting bus names might cause problems in future software versions that need to manually get corrected. So i am trying to be consistent.

Also i try to keep a bus continuous over a design sheet, and so i mostly use the naming for the hierarchical label, this way i have less instanses of a bus name (that i might need to change) and i think i have found my workflow.

So i see a benefit of a more clear schematic with less “floating” busses here and there.

One great thing is that i can unfold from a bus connecting two sheets and the whole thing can get highlighted. (Without an extra label on the bus)

(Image from inside a sheet of my previous screenshot)

(unfoding between sheets)

From the minimum KiCad knowledge i have, i can assume (with your way) that KiCad creates two busses, and that situation is more like “a net is showing in more than one bus” so this might be the expected behavior.

Examine this:

  1. try to unfold from both of those busses and note net naming
  2. remove No1 texture and try to unfold again (note a new bus prefix)
  3. try to unfold again from bus No2 (no change here)
  4. remove texture No2
  5. try to unfold from both busses again, (now both places have changed (again))

This makes me wanting to avoid mixing things like that… and also gentle ping @craftyjon for a more valuable opinion since he was also assigned this issue…

I don’t quite follow what you are doing here… MIXED_BUS{FOO BAR HAM EGGS} is a different bus than {MIXED_BUS} or {FOO BAR HAM EGGS}. The first one generates nets like MIXED_BUS.FOO. The third one generates nets like FOO. The second one depends on what you have put in the bus definition MIXED_BUS.

Thanks all for the help and suggestions!

What I wanted to accomplish was a bus like @crafyjon showed in the last image at Do you have any idea of adding wiring harness to the schematic diagram?. A simple name for the bus instead of listing all bus members. But I wasn’t able to achieve that and, unless I missed it, none of the modified projects above use that style. So is it possible? I assume it is based on that post I linked, but the implementation still eludes me.

next try attached, to avoid confusion this time with only the bus-alias-naming variant.
first the bus-alias “MIXED_BUS” is created. Look at Tools–>Bus definitions (see picture).
Then all busses get the name/label {MIXED_BUS}.
Then all unfolded nets have to be renamed (or unfolded new) to FOO/BAR/HAM/EGGS without preceding bus-name.
You can run ERC, it will show no error.
You can highlight bus, it will higlight all members on all sheets+subsheets. (30.5 KB)

1 Like

Thanks all!

It was only a matter of defining the bus and then ensuring that there were curly brackets around that bus name everywhere it was present in the schematic: at the top level, in any subsheets, on hierarchical block pin names, etc. Everywhere.

Top level sheet:

One example subsheet:

And the bus definition (which, it should be noted, is done at the top level so it filters down to all subsheets):

Now I’m off-topic, but it came up when I was reviewing the design as the initial bus question has been resolved.

Here is an image where I added another bus that is local only to a subsheet. This bus doesn’t leave the sheet. You will notice there is a label of PC[0..1] on the bus, to give the bus a name.

If that label is removed, there is an ERC error. It appears a local bus (only within one sheet) cannot be ‘unnamed’.

@craftyjon is that right?

I would think that a bus, like a net, could be unlabeled. And if so, KiCad gives the bus some generic name. I can see that they are different objects and it’s OK with me if busses require a name, but it seems like a choice of how KiCad operates and not the way it must be. Again, I’m fine with manually naming all busses but I can also imagine that an unnamed bus should be acceptable and so I’d just like to confirm. While it doesn’t bother me, if someone else desires unnamed busses they’re welcome to submit an enhancement request should it turn out that I’m correct and busses, as of today, must be manually named.

Edit: Forgot to attach the example project (89.2 KB)

Unnamed buses result in an ERC warning, not an error. The warning is because KiCad cannot infer anything about an unnamed bus and do any checking about whether or not the nets that you graphically connect to that bus are in fact connected to it.

Unnamed buses on a single sheet are not a big deal – if you use them this way, and don’t care about features such as bus unfolding or highlighting working properly, you can probably just turn off that warning. Unnamed buses in a hierarchical design are a bigger problem, but if you don’t place an explicit net label on a bus connected to a hierarchical sheet, it will be named from the sheet pin.

My mistake. I typed ‘error’ but meant ‘warning’. Thanks for correcting me.

Then I’ll name local busses (those that stay within a sheet) to avoid any warnings, with the understanding that it isn’t a real problem. Thanks!

Note that you can also turn this warning off in Schematic Setup if you’d like to use unnamed buses and don’t care about the bus unfolding feature or bus ERC.