Hierarchical sheets - need help

I made a schematic & layout using hierarchical sheets for the first time. The reason for doing so was to replicate part of the layout using the replicate layout plugin. I thought had a reasonable grasp of the software but now a whole new can of worms has opened up.

It is a basic circuit for testing grid synchronization of a very low power version of a grid tie inverter (full H bridge with gate drivers) to be used with a battery pack. The battery pack is simulated with a 40VDC bus and there are regulated 3.3V and 10V power supplies for the input and output sides of the gate drivers. The inputs will be generated by a µC and are delivered to the gate driver over the test point connections next to the input pins.

Would appreciate some help with the following:

  1. Many actions (for example, updating the layout from the schematic) give the same error message: the schematic is not fully annotated. I have looked for missing annotations, but can’t find any. It would appear that the error is related to the two replicated parts of the layout (two half bridges with largely the same layout). When I delete the replicated hierarchical sheet and re-copy the original one, the error is gone. But just once. Forever after that, the error returns and persists until I repeat the operation of deleting the replicated sheet and copying it afresh. What am I doing wrong here?

  2. There are three kinds of errors in the ERC: (i) duplicate items, (ii) pin not connected, and (iii) power output and power output are connected. The first one must be related to the problem described above (annotation missing, probably because of duplicate items). The other two I cannot figure out.

I know the ERC can be a pain and many recommend not using it. I like it because it allows me to check if I am using the software more or less correctly. Not so much this time it seems…

Your help is much appreciated. I upload my project for your perusal.

My software:

Application: KiCad arm64 on arm64

Version: 8.0.4, release build

Libraries:
wxWidgets 3.2.5
FreeType 2.13.2
HarfBuzz 8.3.0
FontConfig 2.15.0
libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.61.0

Platform: macOS Sonoma Version 14.6.1 (Build 23G93), 64 bit, Little endian, wxMac
OpenGL: Apple, Apple M1, 2.1 Metal - 88.1

Build Info:
Date: Jul 17 2024 00:34:47
wxWidgets: 3.2.5 (wchar_t,wx containers)
Boost: 1.84.0
OCC: 7.7.2
Curl: 7.87.0
ngspice: 42
Compiler: Clang 14.0.3 with C++ ABI 1002

Build settings:
Archive.zip (568.9 KB)

To me it looks like you have some trouble with organization.
For example, having a nearly empty sheet:

And then still stacking all kind of stuff on top of each other:
image

… does not make much sense to me.

Annotation is still a bit of a mess in KiCad itself. Ideally, KiCad should not bother about annotation at all, because it uses UUID’s internally, but for now it’s a thing we have to live with, and annotation has to be correct for KiCad to work properly.

Most of your problems are indeed related to the annotation, and tho the duplicate sheet. At the moment, you have a “Q3” on each of the instances of the sheet, that means you have two transistors with the same RefDes, and that does not work. You have to re-annotate at least one of those sheets, but there are more annotations. It’s easier to simply do a global re-annotate, and then add the page numbers too:

After this, the annotation problems (and the duplicates) have been solved. Do note this does not change the mapping between schematic symbols and PCB footprints, provided you keep the Re-link footprints to schematic symbols based on their reference designators checkbox OFF. This should only be turned on for some special occasions.

Then, running ERC:

[Little rant] A bit of a mess again: A nearly empty sheet with plenty of room and again you put texts over each other to make them unreadable. Why? [/Little rant]

I think KiCad is getting a bit confused here, because power symbols act as global labels, and they are not really connected to anything on your root sheet. I suggest you read about the function of the PWR_FLAG symbols, and then put them in an appropriate location, instead of just somewhere random. I usually put them near the power input connector or the on-board power supply. To get rid of the ERC messages, I simply deleted that section for now.

RKM

Use RKM_code both for resistors and capacitors, or do not use it at all, but do not mix it.

Power output and Power output are connected


This is a problem in the UCC21550ADWR symbol. Those VSSB pins should have been set to a power input. Also changed pins 4, 9 and power input. Power output is only used for things that deliver power, such as the outputs of voltage regulators. And even then their GND pins usually are set to “passive” (which is a “catch all” default) because a net (also the GND net) is only allowed to have one single power output pin. I also replaced the lines of your FET driver with a rectangle with background. This is more in line with the rest of KiCad.

UCC21550ADWR pin 5.

It should be a (logic) input according to the datasheet, so I changed that. It was defined as “unspecified”, and according to the ERC matrix, it’s not allowed to connect anything to unspecified pins.

Duplicate labels.

There are quite a lot of area’s where you have both a local and a global label on the same wire.
image

This is not useful, and can lead to extra maintenance, I deleted a bunch (but not all) of them.

Rearrange of voltage regulator schematic

I rearranged those schematics a bit, so they become actually readable. Normal conventions is to have signals go from left to right, and voltages from top to bottom. This makes it look like:

The End

There are some ERC violations left:


Two for the GND connections, because your schematic does not appear to have a recognizable place where GND enters your PCB. I think you still have to add a connector for that. The other is for an (apparently missing) library.
Because of these changes (I think something with the labels) net names (sheet names?) changed, See: report.txt (10.7 KB)

And then I lost interest. I also do not know how you want to fill in some of the details. Below are your files back. I changed them in KiCad V8, and apparently you are running KiCad V7 and can’t read those files. This is a long standing *&^%$#@! of KiCad.
2024-09-05_Archive.zip (247.9 KB)

Hi Paul,

Thank you for taking the time to help me out. This looks really excellent. Will try to replicate your results in my file and report back.

About the mess in my mostly empty sheets: apparently I owe you an explanation here. I started out with a single sheet where everything was a bit tight. Later I copied elements to the sub sheets. I then just didn’t bother laying out the symbols more sensibly. But point taken - a clean sheet is likely to result in a cleaner file…

Thanks again.

I already suspected you started with a single sheet where everything was cramped together. This is a regular beginners mistake. Also because you often see such schematics both on websites and on (paper) magazines. They often reformat schematics to fit in a compact rectangle for publishing. But there is no need to do so when working on your own project.

I think it’s good if you redo the schematic yourself. It gives you some practice in cleaning up.

It also looks like your LM317 sheets are both identical. They have a redicilous amount of capacitance (even though your gate drivers can do 6A, those are serious current pulses!), but average current is low.

For a better overview, also apply the left to right signal flow to your main sheet. I think I would pull the inputs to the LM317 regulators also to the main sheet, and put all the connectors on the main sheet too. This guides you into drawing a block diagram of the whole thing. Maintaining connections between schematic symbols and PCB footprints when moving symbols between sheets is a *&^%$#@! in KiCad. It’s one of those things that still have to be fixed someday. If you delete one of the LM317 sheets and reuse the other sheet, you have to fix the symbol to footprint mapping anyway. It’s not difficult, but it is a bit of a nuisance and easy to do wrong.

All your suggestions implemented now. (Well, almost. Consistent use of RKM is something for the next project. Also I kept the rectifiers/smoothing circuits in the same subsheet as the LM317 circuit, which could be more efficient by separating them.) I’m running zero errors and warnings in ERC, so all is good. Your post was not only helpful but improved my use and understanding of the software. Thanks again for taking the time to help out.

One more thing. I need to connect a resistor on the main sheet to a GND point in a sub sheet. Can I use a GND power symbol and a hierarchical label both named GND? Like this:

Or am I double labeling that node again? The only way to avoid that would be to delete the power symbol in that node. KiCAD yields no errors, so it’s not a problem. Just trying to improve my understanding.

Putting two or more labels on the same net is in itself not a problem. When the label names are the same, KiCad just accepts it. If the names are different, then KiCad chooses one of the names for the net, and issues a warning because it does not know whether it is intentional or an accident.

In KiCad, all GND and power symbols create global nets. I have seen some hierarchical schematics where GND and power was routed through the hierarchy and it created a big mess of wires, because GND is nearly everywhere. Routing power through the hierarchy only makes sense in some rare cases, for example when multiple isolated power supplies are used, and each creates it’s own local ground.

I think you can, but I don’t recommend that. It may be confusing later. It’s better to use either/or.

Actually using only the hierarchical label is more versatile. Then the sheet is self-contained and re-usable as it is and doesn’t depend on any power symbol outside it. As it is now, what happens if the sheet is re-used in another design and there’s another kind of GND symbol there used for the common ground? This of course depends on whether you want to create re-usable sheets at all, or will you create all your designs from scratch.

Note also that you shouldn’t need the power flag here. The most natural place for it is the main sheet, and because all the identical power net symbols are connected together anyway, the same flag is propagated everywhere. If you use only the hierarchical label, you have to import the label to the sheet box outside and connect it to the GND net there. Like here:
image

Duplicate naming isn’t a problem here. The hierarchical label is for the internal use of the sheet. The external name in the main sheet overrides it. In this case they are the same, but if you want maximum clarity, you can name the sheet’s hierarchical label differently, for example GND_REG.

Still one detail. Your hierarchical label GND is of type “output”. This doesn’t matter much, ERC doesn’t complain, but it would be more logical to use passive or input. There’s no “power input” type for hierarchical labels. To be honest I don’t know why the hierarchical label types are what they are, and why you can even have one type for it inside the sheet but change them to several different types when you import them into the sheet boxes – conflicting the internal type – and they don’t have any effect anywhere.

From what I have seen of this project, there is no power entry connector yet, and the main sheet is almost empty. As a result, there is no logical place yet to place the PWR_FLAGS yet.

As far as I know, the types for the hierarchical labels are only visual and it does not have any influence on ERC. I have never bothered to change any of these label types myself.

About those power flags. I have now redrawn the schematic to comply with eelik’s suggestion: hierarchical labels for GND and GNDD in all sub-sheets and connected them to GND and GNDD nets respectively on the main sheet. PWR_FLAGs are now also on the main sheet, so no more unnecessary replication. It is a cleaner and therefore nicer way of organizing things, thanks.

I added a BJT npn switch to the main sheet. It is driven in saturation mode by a 3.3V signal from the µC to drive open two relays on the grid side. The emitter is connected directly to the GND net like this:

Why is the ERC giving me this error? That is: I know why, because both the emitter and the PWR_FLAG pins are power outputs as is visible in the symbol editor. Should the emitter not be a power output but a power input? I used the standard npn symbol from the global library - I didn’t mess with it.

Adding an emitter resistor removes the error. But it looks to me that resistor is not necessary as it’s a straightforward switch in saturation mode. As I see it there is no need to pull up Vemitter or to limit current through the emitter.

Show us the pin properties of Q5. Generally BJTs have type Passive on all pins, not Open emitter as the ERC message says.

Right. So “Open Collector” and “Open Emitter” should both be set to passive. Looks like it chose the wrong symbol. It was a simulation only model from the SPICE section. Didn’t have proper pin numbering either. Changed it to the EBC-NPN symbol and the error is gone.

Thanks.

If you are also using this for simulation, just check that the pin assignments are correct with the new symbol.