Will a bus go between sheets on a Global Label? How?

[CCANDREWS]

to get a bus from sheet to sheet throughout a multi-sheet project, does it need to use hierarchical labels and wire directly or can i just use a global label? I have tried using a global label every which way and i can’t get it to work.

Actually, i am not having a great deal of luck using hierarchical labels either and wiring accordingly. the problem is on the sub pages i am getting sporadic ERC errors that a pin is not being driven. no error on the label (either if using global or hierarchical) and the net is highlighting correctly out to the edge of the sheet, but ERC is not liking the results no matter what i do.
thanks
craig

[Rene_Poschl]

• Hierarchical or flat schematic design, what is best for me? (How to deal with multi page schematics?)

@CCANDREWS

the problem is on the sub pages i am getting sporadic ERC errors that a pin is not being driven

The reason might be that the pin types of the pins you connect do not have all their requirements met. But we can not really help without the full error message

[CCANDREWS]

Thank you for the reply René. If kicad can use global labels for buses then I will keep digging. Do you happen to have a tutorial on carrying a bus through a global variable?

Since it is on the label, does the label (this is what the documentation calls a vector label I think, e.g., Data[0…7]) need to be manually attached to the bus on each page?

Members taking off of this bus work perfectly fine on the main page so I presume it is not a problem with the inputs. The problem only occurs when I connect to the bus on a sub sheet. The strangest part is this bus connects (all 0 to 7 elements) to a number of chips and the error is showing up only as one or two on each connection. E.g., Data0 gives an error on one, Data5 and Data7 on another, some other combination on all the others.

I will play more with it today. Update post too.

Thanks

Craig

[craftyjon]

Can you post a screenshot of what you are trying to do and explain more about what isn’t working?
One potential pitfall is that the current documentation actually includes some things about buses that don’t apply to the latest released version of KiCad (they will apply to future revisions) – we need to clarify that in the documentation.

[CCANDREWS]

I really like the way this forum lets screenshots be pasted into the text!!

On the parent sheet, everything works as expected and any labeled connection to this bus is fine. Netlist highlights any signal correctly. No “pin not driven” or “pin not connected” errors.

on a sub-sheet, everything is connected to that signal properly and the net highlights as expected

however, on this sub sheet for this component it decided that bA7 has a “Pin connected to other pins, but not driven by any pin”. the same signal worked fine on the main page. note that on this component, it thinks bA2-bA6 are fine.

Another component on the same page and here it gives an error for 10-14 but 8 and 9 are OK

on another component on this sheet it says 7 is OK (which it flags with a “not driven” error elsewhere on this sheet) but throws up “Pin not connected (use a no connection flag to suppress this error)” on bA0-bA1 and a “pin connected to other pins, but not driven by any pin” on bA2-bA6

while it does not give an error on each signal at each component, ultimately it gives a total of one error for each of the signals (e.g., bA0-bA15) spread among all the components.

Ah, i figured that little bit out. While probably not important, it looks like it fills the errors starting from the top of the page. for example the first instance of bA0 starting at the top of the page gets the error. all bA0 below that do not get errors. The first instance of bA1 from the top gets the error. All bA1s that are below that on the page do not get flagged, and so on. That explains why the errors seem randomly spread among the components. if a signal shows up for the first time (referenced from the top of the sheet) on two components but one is slightly higher than the other, the error is placed on the top one.

executive summary:
everything works fine on the first sheet. i think i have the bus going into the global label OK and i have the bus labeled correctly on the main sheet.

i have the bus labeled the same on the sub-sheet, have the global label the same on the sub sheet, but the error checker thinks none of the pins are being driven from the parent sheet.

thanks

craig

[Rene_Poschl]

Your global label uses the wrong syntax (unless i am misinformed)

It also must have the syntax common_prefix[x…y] (with x and y defining the range of the numbered suffixes)

The first page works because you have the local label there.

[craftyjon]

I think the main problem is that your global labels are not in bus format.
They also need to have the [0..15] format at the end to mark them as carrying buses from one sheet to another.
If you change those labels to be Buffered_Address[0..15] does it fix the issues?

In KiCad V6 there will be an ERC warning that will make this more clear, because it will warn you if you attempt to connect buses and nets together in a way that doesn’t actually work.

[Rene_Poschl]

@craftyjon

your hierarchical labels

I assume you mean global labels (the screenshots do not show any hierarchical labels)

[CCANDREWS]

Rene & Craftyjon

fantastic, you nailed it. i changed the global label shown here and that did it !!

it would be good if the manual showed this little example. The bus global label and the bus contents both need to be in that format.

note that the global label does NOT need identical names as the bus content label. the following works just fine where the global label name and the bus content label is not the same.

very helpful,

thanks

[craftyjon]

It is also worth mentioning that you do not need two labels here, unless it is visually helpful for you.
In the case that you connect a bus to a global label, the name in the global label will take priority, even on the local sheet. So, you don’t also need the local label.

[CCANDREWS]

Good information. i hadn’t tried that. when you referred to the label attached to the bus as a local label the lightbulb started to flicker here.

so you are saying that…
on the main sheet the local label needs to be attached to the bus but the global label brings all of those local labels to the same bus on a new sheet, so the local labels do not need to be redefined. the global label is connecting the bus on a different page just as if it were a continuous line (as expected).

thanks

[craftyjon]

There are two types of nets in KiCad, global ones and local ones.
Local ones always include what is called a “sheet path” which is formed from the location in the hierarchy (if you use hierarchical sheets).

Let’s say you create a local label called SIGNAL and place it on a wire.

So for example, on the top-level sheet, the net created by that wire will be called /SIGNAL, because / is the sheet path of the top-level sheet. If you instead had that label on a subsheet called SUBSHEET, the net created would be called /SUBSHEET/SIGNAL. These net names are visible if you inspect the netlist generated by Eeschema for import into PcbNew.

Now let’s say instead you attach a global label to that same wire instead of a local label. Global labels don’t have sheet paths. So, the net generated would be simply SIGNAL without the leading path. No matter what sheet you are on, that net will always be SIGNAL, and that means that when you export a netlist, all those labels will be joined together.

There is a priority of how nets will be named depending on what kind of labels are attached to them, and what pins are attached (for example, a wire that is attached to a component, but doesn’t have any explicit label, will have a name auto-generated from the component’s name and the name of the pin it’s attached to).

Global labels have the highest priority. That means, if a global label is attached to a wire, it “wins” over every other possible name that wire could take on. This means that attaching both a global and a local label to a wire is redundant, because the global label will always win.

Now, when you start talking about buses, the same rules all apply. If both a global label BUS[7..0] and a local label LOCALBUS[7..0] are attached to the same bus wire, the global label will win, and the bus members will be called BUS0, BUS1 etc on the PCB instead of LOCALBUS0, LOCALBUS1, etc.

This means that if you already are going to make your bus global by connecting it to a global label, you don’t also need a local label (on any sheet). You just need to use the same global label name everywhere you want to use that bus.

(I haven’t gotten in to hierarchical labels and sheet pins here, because that would be a longer explanation, but the very short version is that they are treated like local labels but with a higher priority. They still have lower priority than global labels, though)

[craftyjon]

By the way, I know the documentation is not very clear on this right now. I am planning to propose some changes to a lot of the documentation around schematic labels and connectivity (and how nets are named) for V6, because there are some changes in this area from V5 and I want to make it more clear.

[CCANDREWS]

thanks for the explanation. great information.

[SembazuruCDE]

@CCANDREWS

note that the global label does NOT need identical names as the bus content label. the following works just fine where the global label name and the bus content label is not the same.

very helpful,

But because any one net must have a single unique name by the time it gets to the PCB, finding the correct net name to assign a netclass can be difficult. With your example, if you try to find bAD3 in the list of netnames in PCBNew you won’t find it. It will only show up as “AD3” (because as @craftyjon states the global net takes precedence).

If for another net you used two different local net names (for simplicity lets call it on the top level sheet) for one net because coming out of the IC you label it as “RedLED” but near the red LED you label it as “DataSend” because you plan on using the red LED as an RX data send indicator in your programming. Once you send to the PCB it will show in the list of net names as either “/RedLED” or “/DataSend” and you have no really good way of knowing which it will be. Try to make a habit of only using one netname per net or you may cause yourself confusion down the line.

[craftyjon]

@SembazuruCDE

no really good way of knowing which it will be

This will also be fixed in V6:

1. There’s an ERC warning that reminds you if you put multiple labels on a net (on a single sheet) that only one of them will be used on the board
2. The logic for choosing which name “wins” is cleaned up and will be better documented
3. You can select wires and see what net they have in real-time

[Rene_Poschl]

@craftyjon

There’s an ERC warning that reminds you if you put multiple labels on a net that only one of them will be used on the board

How does this play with deep hierarchies? Do i now get a mass of error warnings on every hierarchical boundary? (If so then i hope this warning can be turned off somewhere central)

Example i have label /X/Y1/a connected to /X/a and also /X/Y2/a to /X/b (sheets Y1 and Y2 are pointing to the same schematic file).

What then happens if i connect /X/a in the root sheet to a power symbol?

hierarchy_craftyjon.zip (3.2 KB)

[craftyjon]

@Rene_Poschl

How does this play with deep hierarchies? Do i now get a mass of error warnings on every hierarchical boundary? (If so then i hope this warning can be turned off somewhere central)

No. The new code understands the hierachy and structure of the schematic in a way that current KiCad does not (until the moment when netlists are generated).

In your example,

1. Sheets that are higher in the hierarchy have priority for determining net names. So, the wire connected to J1 pin 2 is called /a because it takes its name from the sheet pin a on the top-level sheet. This is visible in the message panel now, so you can inspect the wire on the subsheet /X/Y1 and confirm it has the same name /a (the other information shown in the message panel here is debug information because I’m running a debug build, you can ignore it)
   
   
2. Power connections win over everything (including global labels). In the demo project you made, you connected the net that would be called /b to GND, so it’s called GND. Then, on the subsheet /X/Y2 you can see the wire is GND here too:
   
   

This demo project has no ERC warnings. The warning I mentioned would only be triggered if you had more than one conflicting label on the same sheet.

Also, in V6 ERC settings will be much better (I haven’t started on that project yet but it’s gotten some planning work already) and you will be able to turn off any ERC warning.

Edit: here’s an example of the warning I was talking about. It does not trigger right now if you have labels of a different type (for example, local vs. global or local vs. hierarchical) since it’s assumed that if people are renaming nets locally, it’s because they want to have some specific meaning on a certain sheet, but a different meaning globally.

[SembazuruCDE]

@craftyjon

Also, in V6 ERC settings will be much better (I haven’t started on that project yet but it’s gotten some planning work already) and you will be able to turn off any ERC warning.

At the risk of hijacking the thread I have a couple questions about your plans for ERC:

1. Are you planning on some way of differentiating in the Error List which are errors vs. warnings?
2. I understand the value of only having one report line per net per error, this avoids spamming the error list with duplications of the error. But sometimes that can be confusing if the actual error should be fixed at a node different than where the error is reported. Is there some way planned to help finding the error? Maybe a tree format that can be expanded to give links to potentially relavent places in the schematic? With your example above, maybe the expanded list would show all locations of the label test and all the locations of the label test2? (For pin-type errors/warnings the expanded list would provide links to all the pins on the net relevant to the error/warning sorted by pintype, etc.)

If you aren’t planning either of the above, should I submit my first GitLab issues for those ideas so you can track them?

[craftyjon]

@SembazuruCDE

Are you planning on some way of differentiating in the Error List which are errors vs. warnings?

Yes

@SembazuruCDE

Is there some way planned to help finding the error? Maybe a tree format that can be expanded to give links to potentially relavent places in the schematic?

Yes, this problem is on my mind. First of all, the new system should do a much better job of pointing the error marker at the actual place where there is a problem (this is possible because of the new real-time connectivity code that understands what net will be assigned to each wire/pin/etc even before the netlist is generated). Second of all, I have some ideas for improving the UI of the actual error list and error markers. I don’t have any prototypes to share yet but it is something I’m thinking about.

@SembazuruCDE

With your example above, maybe the expanded list would show all locations of the label test and all the locations of the label test2? (For pin-type errors/warnings the expanded list would provide links to all the pins on the net relevant to the error/warning sorted by pintype, etc.)

I’m not as sure about this. In the case of this specific warning, it only applies to the locations that are attached to the same wires graphically (meaning they are on the same sheet and joined together). I’m not sure the added value of showing other places where those labels appear, because the warning is localized to this particular part of the schematic where both labels are attached to the same connected net wires.

But the general concept of associating more information with ERC warnings and errors is planned. What specific information there will be depends on the specific ERC checks.