Disclaimer: An unofficial colour scheme has been used to make the screenshots of this lecture. You can find it in GitHub - pointhi/kicad-color-schemes: Want to change the color scheme of KiCad? Look here for Inspiration. (blue-tone scheme)
Introduction
The official documentation for this topic: Eeschema | 5.1 | English | Documentation | KiCad
KiCad in general is more geared towards the use of hierarchical design. Small flat designs are easily possible as well but making complex systems as a flat design is not as easy.
What do we mean with flat design
This is how most schematics were made in the past especially before the age of computing.
A flat design is either a single page or multiple pages that simply hold your schematic. If there are multiple pages, then every page will probably hold things that are related to each other.
For a multi page design there also must be a way to make connections across these pages. Such cross-references are known as labels in KiCad. Another important tool are power symbols (also known as power ports in the past). These are your typical GND, VDD, etc. symbols.
What is a hierarchical design
A hierarchical design is a totally different design paradigm. It is in a sense comparable to object oriented programming. The main idea behind it is to introduce abstraction layers. This allows an easier understanding of complex systems.
A hierarchical sheet (when following this methodology) can not really be seen as the equivalent of a page of paper but more like an object with a defined interface.
In KiCad this interface is created with the help of hierarchical pins/labels. Global labels which includes power symbols reduce the power of this design methodology (See appendix for details).
Example designing a Battery Management System
In this example we look at the measurement and balancing board of a battery management system. This board has an interface for connecting every cell in the cell stack, a specialized chip that measures every cell voltage, temperatures and provides a way to discharge single cells for balancing. It further provides an interface to an external controller.
Single page flat design for a 3 cell battery
Single_page_3s.zip (220.7 KB)
Even with this simple circuit I needed to switch to A3 paper size to be able to fit everything in while still having some organization on the page.
Notice that we have duplicated the balancing part of the design for every cell. Just imagine you discover later on that something is not quite right with it. You now need to change every duplication.
Using graphical lines and text can be of great help to separate different sections that belong together. Such sections could already be a first indication of how to better abstract this system.
Multi page flat design for a 6 cell battery
Flat_multipage.zip (239.3 KB)
flat_multipage.pdf (196.5 KB)
In the previous section we discovered that having a single page becomes quite limiting fast. One can increase the page size but even that has limits. This means we might want to add additional pages. As mentioned in the introduction, this is not really one of KiCads strong points. We can misuse hierarchical sheets here and then work with global labels to achieve something similar.
The root page is then the index page of your design instantiating all other pages. If you are motivated you can even add some text or drawing to this page to make it clear where to find what.
Full hierarchical design of a 12s system
Full_hierarchical_design.zip (365.1 KB)
If we look at the previous systems we see that there is a lot of repetition that can be placed in a separate design block. Doing this will make our schematic easier to read and maintain while in KiCad at the trade-off that paper printouts no longer make much sense. (The orange bordered part is what is inside these sub sheets. Not a lot for a single page of paper.)
In this specific case we have instantiated the same sheet multiple times. This is done by either using block copy of a place sheet or by adding a new one and entering the existing file name as the target. (KiCad will ask if you are sure you want to do that.)
If you now want to change part of this subcircuit then it will be propagated to all other instances. As a test change the value of one of the resistors and check if it has changed in other instances. The only thing that is independent between instances are the reference designators and therefore also the selection of the unit in multi unit symbols. (You have free choice to select these independently in difference instances as long as they still stay unique over the full design)
Even in a hierarchical design workflow one can have sheets that are instantiated only once. See for example the system level (root sheet) of the same design. The host interface and daisy-chain filter sheets are instantiated only once.
Appendix
Label types and their priority
KiCad generally has 3 types of labels. The resulting net-name will be determined by their priority.
- Global labels always win.
- power symbols and hidden power pins are global labels.
- Hierarchical labels are second. The resulting net will indicate not only the label name but also the sheet reference.
- Local labels have the lowest priority. The resulting net will indicate not only the label name but also the sheet reference.
If there are labels of the same name in the same sheet then these are connected even if they are of different types.
Global and Hierarchical labels are available in different graphics types (input, output, bidirectional, tristate and passive) The graphic style only influences the look of the label it does not influence how it behaves for connecting nor is it used by ERC.
Why are global labels a bad idea for pure hierarchical design
Hierarchical design is there to allow for clean abstractions. Such an abstraction is done to separate what one needs to know to understand the current block from anything else in the system. Any form of global label needs knowledge about all other blocks in the system to ensure that one does not create a connection to the wrong net. Or at least the knowledge about the one block that defines the source of the label that one intents to connect to.
This does not only concern labels for signals. But also power connections. If one uses global labels for them then the designer of every subsystem needs to be aware of the power supply concept for the whole system instead of just being aware what the current part needs.
Choosing global lables also limits reusability. As soon as you for example use the GND symbol you can no longer use the same sheet somewhere where you want to use for example the AGND instead.
Why might you still choose to use some global labels in a hierarchical design?
Following a design methodology to the letter is not always a good idea. There are instances where it just adds unnecessary work or it can make circuits harder to read (especially for people who don’t have much expirience with this design methodology).
One typical example where one might want to deviate is for power symbols. A lot of designers are used to the distincitve shapes of power symbols. Seeing a text based label instead of such a symbol might therefore negatively impact readability.
Sadly there is currently no way to have power symbols limited to a sheet (there are many open question as to how such symbols would work especially how to differentiate between a global or local power symbol).
A further issue is related to ERC. Power symbols are implemented in a way that nodify ERC that there is a need for a power supply (they are invisible power input pins). If one uses hierarchical labels instead then this notification is not made. However in most circuits there will be some IC or similar part that will notify ERC about the need for a power supply. For designs that do not have an IC for this usecase one might need to introduce a special symbol for this notification (similar to the current PWR_FLAG symbol but with a visible power input pin instead of an output pin).
TlDr: It is up to the designer to choose how strictly to follow the pure hierarchical methodology.
Working with hierarchical sheets
Adding a new sheet
Creating a new sheet is done with the “Create hierarchical sheet” button in the right toolbar. This will spawn a dialog asking for a file and sheet name. The file will be created in the project directory with the given name and an instance is added to the current schematic sheet.
How to define the interface of a hierarchical sheet
The interface of a sheet is defined using hierarchical labels inside it and then adding them as hierarchical pins to the instantiation of the sheet.
Hierarchical labels are added with the “place hierarchical label” button found in the right toolbar. Pins are added to the sheets instance by right-click -> import sheet pins or via the button in the right toolbar followed by left clicking on the sheets instantiation.
Adding multiple instances of the same sheet
Additional instances of an existing sheet can be added by using the place sheet command and pointing to an existing file or by simply duplicating an existing instance using either crtl+c followed by crtl+v on a block selection or right-click->duplicate block
Using buses as hierarchical pins
Demo project: bus_pin.zip (1.9 KB)
Buses in KiCad version 5 are still quite limited. They only work for signals of the form common_prefix# (where # is an integer from a continuous sequence of integers between a lower L and upper U bound.) The bus must then be named common_prefix[L…U]. This name can be used for an hierarchical label to get a full bus out of a sheet with one pin. On the outside another bus must be connected to it with some label of the form outer_prefix[L..U] The outer prefix does not need to match the inner prefix. The connection is not made without that prefix!
On the inside of the sheet it could look like this (bus connection prefix1 has been highlighted in this screenshot to show that there is indeed a connection.)
On the outside it looks like this (prefix1 is still highlighted). The local label on the bus is required
