I have a fully hierarchical design (essentially only blocks on the root page) with a D bus having 7 members (so the bus is named D[0…7]) and which goes around on the top level of my schematic and into several hierarchical blocks.
In one of the blocks, there is another net named D1, which is local to that block only. It should not conflict with the D1 net in the D bus.
Unfortunately, this is what I am seeing. A ratsnest is created between the local D1 net and the D1 net from the bus. KiCad shouldn’t do that, but I’m sure it’s because of something I did.
I believe hat because of the simple example project I made to check out this issue. And when I try that, I see a net /A1 at the top level and a different net /memory/A1 inside the block. This is what I expect, so surely it was me.
Originally, I had a hierarchical label on the local net which could have been a problem, but I since deleted that so the net is completely inside the block. And I’ve renamed the net inside the block to something else to try and clear out any artifacts in the netlist. I even removed the wires and set both pins to no connect and then added the connection later. But whenever I name the local net D1 (using a net label to show connection between the wires, the ratsnest appears between the local net and the bus once I synchronize the board to the schematic.
A few interesting observations:
If I create a net local to the block (such as /memory/A1 in the example design), assign that to the board pins, and then push changes from the board to the schematic, it works! However, if I make schematic changes and then go the other way the ratsnest between the bus and local net appears again. That suggests the issue is in the schematic or netlist logic, driven by something I’ve done when making the design.
If I manually edit the nets using a text editor, it also works. For some reason, I do not find the net name in the schematic file (either the root sheet or the block with the local net) so I must be overlooking something. But if I edit the net on the board to make its scope just the block, all is fine until I push changes from the schematic again.
If the net is named D1 or something else doesn’t matter in my example project because I always see a local net, so I don’t think it has anything to do with the net name being D1 or D*. Didn’t seem likely, but I tried it. And if the local net in the real design is named D2 or D5 it still connects to the bus, so it’s not the exact name being D1 but rather the confusion (somehow) of the net name losing focus.
If I connect the pins in the block with a wire and don’t use net labels, then of course things work. I get an auto-generated net names based on one pin of the net. That’s fine. If I then add the net label ‘D1’ onto the single net, I get a connection to the bus again. So the issue doesn’t seem to be related so having multiple nets connected with labels in the block.
It sure seems to me that I’ve done something wrong when creating my design that is causing the issue, but the example project I’ve attached behaves as I expect and I think it’s a proper representation of the issue. So I’ve surely done something to cause this, but I don’t know what it is or how to fix it. Any help is greatly appreciated!
Now, it would be fair to ask why I don’t choose another net name. It should work, but this can be easily avoided. I’m replicating an existing design which has these net names and schematic layout, which means that using wire stubs with net labels and having a pair of D1 nets is the best way to recreate the original design. So if possible, I’d really like to figure this out. And it seems possible if I could resolve whatever issue I am surely doing.
I hope that explains what I am looking for, and perhaps gives someone an idea how I could have broken things so that my design does not behave nicely and as I expect, which the example design does. Thank you!
You are using the old behavior.
In old KiCad versions, the bus itself was just graphical eye candy, and the “bus labels” were just local labels, and thus all local labels on a page connect together.
Since a few KiCad versions, it’s possible to use a busname, dot, signalname convention for bus names, and this greatly reduces the chance for duplicate names.
I’m not in the mood to check whether this is rock solid though (What happens if you have such a name as a local label without a bus connector, does it still connect to the bus?)
I recall when KiCad 6 was released by busses all broke and I had to re-implement. I skimmed through the documentation before posting this and I didn’t see why it wasn’t a valid approach, but I’m certainly able to change if there’s a better way that I didn’t understand yet.
All that being said, my example shows that the method I’m doing can work. Why doesn’t it with my bigger design? I can’t figure that out.
This is not really accurate, in that the way this type of bus connection is made hasn’t changed (even though new additional bus features have been added)
There is no “old behavior” – this is still the current behavior.
any labels with the same name on the same sheet connect together. It does not matter whether they are part of a bus or not.
This assumption is not correct – KiCad does this, by design.
Your example doesn’t have a problem because the sheet that has a local label D1 (which isn’t supposed to be connected to the bus) also doesn’t have any connection to the bus in question. If you moved the memory components to one of the other sheets, you would see the problem.
The reason the second one (using group bus syntax) is not connected is not really anything magical about the new bus features: it’s just that MEM.D0 is a different name than D0. The rule is really as simple as “every label with the same name on the same sheet is connected together”.
Edit: Oops.I made a bit of a &^%$#@! I used the Schultz.D[0..5] syntax, while I should have used Schultz{D[0..5]} similar to the example given by craftyjon. It still seemed to work (apart from the save and restart of the schematic editor that I had to do). I am a bit confused and am not sure how to interpret this behavior.
Yes, ok, Maybe I should have called it “historical behavior”. I expected this behavior but gave it a wrong name.
Yes, of course it does not show your issue.
On the “memory” sheet, your D1 label is a local label, and therefore it does not connect to labels on any other sheet.
Nothing wrong with verifying connections this way, but it’s quicker to use the net highlighting tool. It has the backtick hotkey (upper left corner of US keyboard between [Esc] and [Tab].
If I draw a wire and a label on: P2.6/XIN/TA1 with the D3 name, then highlighting shows it connects to the bus label on the same sheet:
Right click on the hierarchical sheet box, Import Sheet pin, and then replace the old D… pin with the **Schults…" pin.
Then your schematic still works. Do note that:
On sheet msp_1 the D3 label is now no longer connected to Schultz.D3 because they have different names. (Duh!)
Schultz.D3 on the msp_1 sheet is still connected to D3 on the msp_2 sheet, even though the names are different. This is because the bus got renamed though the hierarchy. This is by design.
I had to save the sheet, exit and restart the schematic editor a few times because net highlighting got confused by my net renaming. This seems like a bug in KiCad, I vaguely recall that it’s possibly already reported and fixed in the nightlies.
And last, to make it extra clear.
I go back to the msp_1 sheet.
Create a wire and a label with name Schultz.D3 on the P2.1/XOUT pin.
This wire now also connects to the the bus because it has the same name as the local label on the bus, even though there is no blue bus connected to the P2.1/XOUT pin. This is by design, although I can understand it’s confusing. It may make you wonder what the function of the bus connector is.
Even if I remove the local label from the Vref/A1-/P1.3 pin, then the P2.1/XOUT is still recognized as a bus label name, and connected through the hierarchy to the msp_2 sheet.
Here is your example project back with the modifications I made:
