Hierarchical Sheets Questions

Hi All, I’m a KiCAD newbie still trying to figure out the ins and outs of the software, but I do have experience with other CAD software.

I have some questions about best practices when using a hierarchical schematic.

  1. I’m planning on using the sub-sheets to organize the logical schematic blocks. Would it be bad practice to have some components on the top sheet? Specifically some components that don’t logically make sense to put in the sub-sheet.
  2. Do people draw icons or anything within the sheet icon on the top level to show what the sheet does? Icons like op-amps or power symbols.

Thanks,
Seth

I use components all the time in top sheet, personally I prefer (not always practical) to have anything which will “interfere” with the user in top sheet. So buttons, leds, connectors etc. This way I find it much easier to see what goes in and what comes out without too much digging.

Typically I also have the stuff going between the blocks. Could be filters, jumpers or resistors

1 Like

I often add text notes to explain what is going on in the block

For grins, I took a screen-shot of the hierarchical sheet, resized it smaller, and then inserted it as an image in the top sheet. I don’t know if this is something I would recommend, it was just something that I did once.

That’s a pretty good rule to me! I might also include glue logic possibly, but I guess that depends on the individual cases.

@davidsrsb Good to know. I might do the same.

@Sprig I can see the value of that. I might do that with logos, such as Arduino or RasPi.

Is there a way to link or merge those? As in, make the sheet icon and the text or image act as one entity?

That sounds like a nifty feature request!

Being curious, what is glue logic?

I doubt that there is any formal definition of “glue logic”. It’s a kind of short-hand term that circuit designers throw around, and the exact meaning not only evolves over time, but also depends on where you are working.

I’ll suggest that “glue logic” is the (usually) trivial but essential circuitry necessary to interface one IC or functional block to another. Examples include:

  • Level translators or drivers, needed because one section of a product uses a different logic family than another. In the “good old days” this typically meant interfacing among subsystems implemented with TTL, CMOS, and ECL logic families. Now it could mean interfacing between subsystems using 1.8V, 3.3V, and 5V devices.

  • Inverters between a functional unit that implements a signal as active-HI and another unit that defines the signal as active-LO.

  • Decoding an address to drive an “enable” or “select” pin.

  • Buffering, deglitching, or latching data passed from one functional unit to another.

  • Circuitry to debounce mechanical contacts.

  • Drivers for front panel indicators, small motors, solenoids, etc.

Dale

3 Likes

Dale has pretty much gotten the gist of it.

I’d say my definition of glue logic is any component that isn’t a logical part of either circuit it’s interfacing with. Level shifters and inverters are good examples, as Dale’s listed. I’d also include other logic gates (AND/OR/XOR) to join signals. For example, if you had one enable pin on a power supply, and you needed to outputs to control it, the gate you use would be considered glue logic.

From my experience (and admittedly, the definition is fluid), I wouldn’t consider the rest of the list as glue logic when talking about it. My rationale is that those have dedicated uses that are linked to the thing they’re interfacing with.

Hope that helps,
Seth

From the icezum project:

icezum-sch

3 Likes

Makes sense :slight_smile: that was what I meant with “Typically I also have the stuff going between the blocks. Could be filters, jumpers or resistors”

Thanks for the explanation

Wow. That is a brilliantly done top/cover sheet. I think it would be a great addition to the distributed KiCad demo folder. I see the design is CC BY-SA 4.0 (found the version on their github wiki) so the KiCad project could just grab it, but the polite thing would be to contact that project to let them know first.

1 Like

Wow indeed. That looks like some very slick documentation (and I’m a big fan of well-made documentation). I’ll have to check out their project for some tips and tricks.

@pedro Thanks for linking.

1 Like

Maybe the CERN people want to contact them for politeness.
They will be proud to have a project included in the KiCad documentation. In fact, they were at the Kicad dinner at Fosdem and participated with 2 lectures at the hardware devroom.

1 Like

One more question about hierarchical sheets. Should they be visible in the project window?

I made a schematic with 3 subsheets (each with it’s own file). I can navigate them just fine within Eeschema. However, they seem to be completely invisible to the project view, while I would expect them to be visible there.

What am I missing from the Modus Operandi of KiCad?

You are missing nothing. Sheets that are correctly added to the hierarchy are hidden in the project window.
I guess one reason for this is that one can have the same sheet added multiple times. How should kicad then know which of the instances to show?

If that’s the case, then that begs some follow up questions:

The main one that comes to mind is: What’s the intended use of the project window? I ask this because it looks like a file manager with the ability to add directories, but if I can’t see the files that are actually in there, then that use-case is not possible.

Regarding the instances (as I actually have two instances of the same sheet in my current design), I envisioned that the project would show the file, then that file would have a way to expand it to show each instance. Inspecting the .sch file for the subsheet, that information is actually contained within that file, so it should be easy to read how many instances there are.

For my own education: How can I force a schematic sheet to be incorrectly added to the project to then be unhidden? I’m asking so that I can learn this software better and understand the design decisions made when it was developed.

1 Like

Delete the sheet instance inside of eeschema. (Not sure if this will lead to the sheet being shown in version 5 to be honest. It was that case in v4 and i just assume it is still the same.)

That behavior is changed in version 5. The project window only shows the top-level schematic.

2 Likes