Multiple labels in schematic -- keeping the multiple labels in the layout?

Layout
1

If I do the following in the schematic:

image
image375Ă—523 3.05 KB

Then, each of those multiple labels (global or otherwise), the schematic respects the fact that there are all those labels, and they just happen to correspond to the same actual signal (same net).

The layout does not respect that, and it chooses one of them and everything connected to either one of those labels is now marked as the one and only label that pcbnew chose (looks like it chooses the first one alphabetically).

I looked into the files (with a text editor), both the schematic and the layout, but I saw nothing that suggested a “hack type” of workaround editing the files directly. This choice seems to happen in the “Import schematics / Update layout from schematics” process.

This can be quite aggravating: for example, if I want to create a filled zone for VCC_IO, turns out that I can’t!! KiCAD chose to assign that bunch as “VCCAUX(1.8V)” instead, and in the list of nets when creating the zone, there isn’t even a net named VCC_IO.

But it can get even more aggravating! I had my VCCINT, and I had forgotten to connect VCCBRAM to it. I had my VCCINT zone in the power plane layer… At some point I realized I needed to connect VCCBRAM to VCCINT, and I did (as shown in the pasted image above). Well, now when importing/updating from schematic, I get: Warning: Copper zone (VCCINT) has no pads connected., and the zone is actually unfilled, and all of the VCCINT pads are now unconnected. (I mean, sure, it’s not a puzzling or hard to fix problem… but it is truly irritating!)

One particularly ridiculous detail is: there are only two points in the entire board that are VCCBRAM, vs. maybe 10 or 20 that are VCCINT. KiCAD still decides to call that ground VCCBRAM And VCCINT was already there (which, assuming my observation/inference is correct, then yes, VCCBRAM is first alphabetically, so the whole net is now called VCCBRAM)

Any way to fix this? If no “official” way exist: any hacks to get around this limitation? Any plans to improve the bahaviour in this area?

2

Pcbnew doesn’t have the facility to associate multiple names with a single electrical net. Nets are identified by NETINFO_ITEM object, which has one netcode and one net name associated with it. Often, a net is identified by netcode only, so those must be unique (as far as I know). Even if the net list contained multiple labels for the same net, pcbnew wouldn’t be able to represent those nets with more than one name. I think the best you could do is to place a dummy device between the two nets, which would allow you to have two separate names for the net,. Note that this wouldn’t be as flexible because with three or more nets, it would matter exactly how you connect them in the schematic, which would have to match the layout.

3

Net-tie?

image
image868Ă—732 45.2 KB

3 Likes
4

I had thought about the Net-Ties, but it doesn’t really provide a good solution; precisely the example that I posted are the bunch of VCCs of a Zynq processor. They are separate for flexibility, but if one chooses to connect two or more of them (e.g., the VCCIO for the different I/O banks, or the core VCC for the processor and the core VCC for the FPGA fabric), well, they are power planes, so they must be laid out as big-bulky copper areas, without the connection between them happening through a narrow path (the net-tie).

I mean, one could certainly “short-circuit” the copper areas, and the rule checker will scream bloodymary because two different nets are “shorted”, which one would duly ignore … The thing is, this sounds like a pretty horrible hack. (plus, maybe not reliable; for all I know, some future version of KiCAD will no longer connect two zones of different nets just because they overlap and have the same priority — I always saw, and still see, that behaviour as a bug in pcbnew)

5

Disclaimer: I can not change the KiCad feature set so i give advice how to work with the current tool.

I think your problems might stem from your strange use of global labels. It’s really unexpected to see global labels named after pins connected to each other instead of connecting power symbols or cleartext signal names to the respective pins.

In a schematic that uses global labels I would always give nets the name of the provider side and I would use custom power symbols for power supplies.

It is also strange to see signal pins of two systems getting global labels and then having these connected at a third place. If one uses global labels then again use a cleartext name for every signal instead of using the pin name for it (For example if you have an LED to display a status then do not use PB13 for the label but LED_STATUS).

However, the section of your schematic looks like you might already think a bit like a hierarchical designer. So i suspect you might benefit from going all the way and use hierarchical sheets as abstract objects with hierarchical labels (pins) defining the interface.
Your VCC pins would then be hierarchical pins and in the root sheet you connect them to a global label which will define the global name for it.

Even better would be if you give your hierarchical interface names that avoid knowledge dependencies. VCC is not an ideal name as it requires the reader to check what chip it is connected inside the sheet and then check the chip datasheet to see what the voltage level should be. A better name would be to use for example 3v3 in the interface.

Similarly, with VCCPAUX, VCCAUX, VCC_MIO_501, VCC_IO. Reading this section of the schematic requires me to understand in detail other sections of the system (introduces knowledge dependencies). I can’t even really tell which one is the supply and which ones are the consumers.

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

2 Likes
6

What does this even mean if they are both the same net?
KiCad is not a magician’s tool to somehow get into your head and extract the information about what your intentions are.

1 Like
7

I think what @cal-linux is looking for would be net name aliases.
Their particular design style seems to be to connect global labels to pins and then have a separate place where all labels are connected. Possibly to allow easy large scale changes to the schematic from a single point.

I would argue hierarchical design might be the better option even if net aliases are introduced but can imagine that net aliases could be useful for certain tasks. One example could be simulation.

What might also help is if pads in the layout would not only display the pad number and net name but also the pin name (could be the reason why @cal-linux uses global labels here in the first place as they might want to misuse them to get the pin names displayed)

8

I understand that’s what they want, I don’t understand the mechanics of how they think this should work.

After thinking on this a bit what I think the request is about is to have aliases automatically be assigned to pins that are directly connected with a schematic wire so that creates a kind of virtual net island within a net.

I guess there is some value here but it will only work for displaying right alias on pins, not on tracks or zones because KiCad still doesn’t have any information on what is the right alias for those.

1 Like
9

How would you expect KiCad to handle this?
Suppose you have a VCCBRAM on the left side of the board, and a VCCINT on the right side, and you show the net labels in each track segment.
On which segment should Pcbnew switch labels?
If you do not tell Pcbnew where tho make the transition it can not guess your intentions.

Net ties are a dirty hack, mainly used for nets that have for example high current tracks, and also thin sense lines for feedback.
Net ties are however also very simple components. They are just 2 pads with a polygon on copper that connects those pads. You can easily make custom net ties of any size an shape you like for each of your connections, or even use multiple net ties and put them North, East, South & West of your IC.

And why use this weird naming scheme at all?
You have to go chasing Labels all over the schematic just to find out where the power for a certain IC is coming from.

Exactly. By just using a single net name there would have been no confusion at all. Also, if you accidentally delete such a net connection, for example when it gets accidentally selected in a block operation, you can easily oversee it and make faulty PCB’s while the schematic seems alright. Or if you’re lucky, the ERC catches it with “Pin connected to some other pins but not driven by any pin”

When (parts of) a zone is not connected to a pin it is left open on a purpose, and this is a very useful feature. Gaps in the zone filling are very easy to spot on your PCB. If Pcbnew filled those area’s it would have unconnected copper which useless, can even be harmful and is much harder to spot on the PCB then an open area.

Also: I read somewhere Pcbnew chooses net names in alphabetical order if a net has multiple labels, so I confirm your suspicion.

10

I would like to reiterate Rene’s point. This works effectively in both large schematic designs (100’s of schematics in a hierarchical design) and large software designs. It is essentially what is called “abstracting” (a term Rene also mentions), but I really like the term “knowledge dependencies” as that is a more functional definition. It also helps tremendously with re-using parts of the hierarchy in other designs.

Thank’s Rene! I had never heard that term before.

11

Yep, that is precisely where I was going with this.

Precisely!! I think you hit the exact core of the issue as I see it!! That is the actual issue, and yes, I’m using labels to compensate for that (arguable) deficiency.

I don’t think hierarchical sheets would help. As you comment:

Well, I don’t want a global name for it. (I mean, assuming, as I understand it, that then in the layout, all the pins ultimately connected to VCC will show the same label).

[[ Side note: I am not familiar with hierarchical sheets (I did read about them a while ago, but never used them). So, please do correct me if I’m wrong on my interpretation above ]]

I claim that I want to maintain the original names (VCCINT, VCCPINT, VCCIO, VCCBRAM, etc.) because they describe the role, and not the actual value they happen to have. With power signals, in particular, this is crucial. Being on the same net does not make them the same for layout purposes: decoupling issues/constraints or propagation time issues (when working with high-speed signals) make each pin or area a distinct element that has to be treated (and thus labeled) separately. With the Zynq, for example, they specify decoupling requirements, and for example, they say that VCCINT (9 pins) requires 4 decoupling capacitors. Well, when the layout shows all VCCINT, VCCPINT, and VCCBRAM pins labeled as 1.0V (because I chose to use the same 1.0V power supply for these three VCC’s, which is perfectly ok to do), then I get lost on which are the 9 VCCINT pins for which I needed the 4 decoupling caps.

A similar situation is the following: I have a signal that I want to “hardcode” to 0 or 1 — meaning, connect to GND or VCC (which will show in the schematic as +3.3V). Say, an ENABLE that I want to hardwire to VCC, or a CS for an SPI port that I want to permanently disable, so I tie it to VCC.

Then, when I need to place the decoupling capacitor on the VCC pin, pcbnew shows me several pins that are all labeled +3.3V, so I have to go back to the schematic or the datasheet to determine which of those pins is the one where I want to place the decoupling capacitor.

So far, I’ve compensated for that deficiency by manually assigning the REF to the caps using the pin number. For example, if my MCU chip has pins 3, 7, 14, and 22 as VCC pins, then I name the capacitors CM3, CM7, CM14, and CM22 (M for MCU, to distinguish them from the decoupling caps of other chips). But that can get tedious and difficult to handle.

This has been a problem especially now with the Zynq, which (1) is a BGA so the pin names are longer; and (2) it is not a 1:1 decoupling cap : pin mapping; so, if anything, I would want to name them CI1, CI2, CI3, and CI4 to know that those are the four VCCINT capacitors. But then, I would need pcbnew to show me the VCCINT pins labeled as VCCINT, and not as 1.0V (or VCCBRAM, as it is doing now in my design!)

Hopefully this clarifies a bit what I’m expecting / suggesting.

I guess there are two possibilities:

  • Netname aliases — with the ability to indicate which points in the schematic (pins, mainly) get which netname. @qu1ck suggested a rather clever way to accomplish this (and in retrospect, I think that’s what my brain was implicitly expecting to happen, without realizing that that would have to be explicitly coded in the software):
  • Maintaining the pin names. Possibly the way it should work could be: the pad shows the pin name, and if one hovers over the pad, then it changes to the netname to which it is connected. (example: I see the pin with name VCC or VDD, and when I hover the mouse, it changes to +3.3V).
    However, in some cases this may not work as nicely; many chips have really long pin names (case in point: the Zynq. Pin names can be VCCO_MIO0_500, or something like PS_MIO16_501/ETH0_TX_CLK). That certainly won’t play nice with this feature of showing pin names (maybe through the “tooltip text”, when hovering over the pad??)

As for traces and zones (as also pointed out by qu1ck); what’s the problem with showing all aliases to which they are connected? After all, there is (in principle / most of the time) room available, assuming the trace is long enough (and if it isn’t, probably wouldn’t matter not to show anything, since the pads to which it is connected are right there)

12

Are you aware that if you have the schematic and the PCB open in the same project, that Eeschema pans to a pin (and highlights it) when you select the pad in Pcbnew, and Pcbnew pans ( & highlits) when you select a pin in the schematic?

This works really nice with dual (or very big) monitors.

The number of decoupling capacitors is a poor measurement for the quality of the decoupling. It also does not suggest anything about the interaction with other power supply connections of the same voltage.
FPGA’s (at least used to) have weird power up sequences with multiple different voltages, which would make it different nets.

Also, if Zync suggests to put 4 decoupling caps on VCCINT (as an example) that does not mean that the other pins connecting to that net are not fed from the same continuous power plane.

How about this:
Your real issue is the decoupling, not the power net.
Refdes names are alpha numeric strings in KiCad. (Just the annotation prefers them to end in a number.

You can name your capacitors C_VCCINT1 through C_VCCINT4

Or you can name them C_VCCINT56 if you want the capacitor near pin 56 of your FPGA. (Add a text note to your schematic if you want to adopt such a system).

13

Some people prefer to have the decoupling caps close to the pins they connect to.

I prefer to use the hierarchical sheet approach, and put power supply related stuff together, so the rest of the schematic does not get cluttered with this.

With hierarchical sheets you can also assign a whole sheet (or more) to just decoupling caps. Extending on my previous post, you can make something similar to:

image
image822Ă—476 4.64 KB

Note: The blue text are just text notes. No fancy labels or anything.

With very high frequency stuff (such as FPGA’s) decoupling caps often have different values, even 1nf in 0402 size may be mandatory to extend decoupling to higher frequencies. With the scheme above you have an instant overview of which rails have which capacitors.

14

Interesting. I knew that worked for the symbols/footprints, but I had never noticed that it works at the level of a pin.

Still, that is just a marginal improvement; in fact, almost equivalent to the issue of having to go to the schematic or the datasheet. Sure, with dual monitors the situation is “de-aggravated”, but still.

Trying to avoid going off-topic (after all, that was just an example that illustrates the “problematic situation” I was describing). That’s what they specify. They actually do mention a few considerations when consolidating decoupling caps for two or more power sources (i.e., what can and cannot be done for certain combinations of power supplies that you decide to merge). At first, I was finding that a bit silly and confusing, so I was planning to just add the one decoupling cap to each pin… but with 0402s, that’s proving to be very challenging (and with the manufacturers that we’ve been dealing, going below 0402 is not an option — at least at the present time with the current budgets we’re working with)

No, I’m not sure that that’s the case. I mean, decoupling caps just happens to be the main (the one?) example that I can think of. But I’m sure there are other examples. The general principle is that the fact that two points of a circuit are electrically connected does not make them equivalent and interchangeable. Decoupling is one example of this very principle: you just cannot (well, should not) connect the decoupling capacitor 10cm away from the MCU VCC pin; even though as far as the schematic goes (and a DRC goes), it would be valid and equivalent.

The other, perhaps more specifically phrased, principle is: it is important that the layout carries/conveys information about the role of a signal / net / subset-of-a-net (which its name is supposed to denote), and not the actual value of it. I want to know that this pin is VCC, or ENABLE, or CS, and not that it is “+3.3V”. Similar to a program, or math expressions, where for example you want to see a variable called radius, and not the value 0.7 (just because the radius is 0.7).

[EDIT]. Just thinking of an additional example: I may want to know that this particular pin is the output of op-amp #1, and not the input of op-amp #2, so that I can choose to connect the impedance-matching resistor closer to the output, or do the length-tuning to match a differential pair close to the source of the signal. Again, all of these are things that one can do (just go to the schematic, or the datasheet, and by visual inspection figure it out). But again, I claim that it would be beneficial that I could label things individually and could figure it out in the layout at-a-glance.

15

Oh my!!! Poor Zynq, you just fried it big, connecting 3.3 times the allowed voltage in VCCINT!!! :‒)

(yeah, I’m one to talk: no-one seems to have noticed that in my original image, I short-circuited 1.8V and 3.3V!!! :‒) That was an actual bug in my schematic; I noticed it some 15 or 20 minutes after I posted … I mean, the ERC would have flagged it, of course :‒) )

16

Well, maybe you would have noticed it if you had put the power supply voltages near the pins :slight_smile:

But it’s completely irrelevant for this topic. I have never in my whole life looked closely at a datasheet of an FPGA. (I can manage with C and C++ on microcontrollers, and I’ve decided long a go to limit myself to that to avoid complete brain overflow).

17

As far as I can see, this is not a property of a net or a subnet, but a property of pin or pins. The relation of, say, a MCU VCC pin and a capacitor pin is that the capacitor is a decoupling capacitor for the MCU.

And as far as I know, “net” has traditionally meant all connected pins, regardless of different relations between any two of those pins and conscutively regardless of different layout requirements.

18

But that should not matter; KiCAD’s functionality includes the layout, so definitely, layout requirements should be considered!

That KiCAD has to work with standard formats and conventions to have compatibility with other tools, including the traditional convention of what a “net” is? Sure… But that should not mean that it cannot implement a functionality that goes beyond that “limited” notion that any set of points that are electrically connected (directly) are one net, and a net is nothing more than that.

19

You’re right. And see https://gitlab.com/kicad/code/kicad/-/issues/2018.

20

I prefere this. Then when placing the decoupling capacitor I see at schematic near what pin i should place it.