Hierarchical Design for Complex Schematics
A schematic that fits on one sheet is easy to read and easy to review. A schematic that describes a system with a processor, two interfaces, a power supply and a dozen connectors does not, and the point at which a flat drawing stops working arrives sooner than most designers expect.
Hierarchical design is the answer that the tools provide: the drawing is divided into blocks, each block is drawn on its own sheet, and the blocks are connected on a top sheet that shows the architecture of the system rather than its details.
Why Flat Schematics Stop Scaling
The problem with a large flat schematic is not the number of components. It is the number of connections that cross the sheet, because every one of them has to be found and followed by eye when the design is reviewed or debugged. A designer looking for the return path of an analogue signal in a flat drawing of a mixed system is reading a map with no roads.
Splitting the design into modules restores the structure. The reader sees one function at a time, the connections between functions are explicit, and the drawing begins to resemble the block diagram that the design was specified with.
The Structure: Top Sheet and Sub-Sheets
The top sheet carries no components. It carries one symbol for each block, with the ports that connect to the rest of the system, and the wiring between those symbols. Below it, each block is drawn in full on its own sheet, with the same ports appearing at its edges.
A hierarchical design is therefore a tree. A block may itself be composed of further blocks, and the structure can nest as far as the design requires. The convention that keeps it readable is that each sheet should represent one function, at one level of abstraction, with a name that says what it does.
Sheet Symbols and Hierarchical Ports
The symbol that represents a block on the parent sheet is created from the child sheet rather than drawn by hand. In most tools the command takes the sheet as its input and produces a symbol whose pins correspond to the ports defined on that sheet, which keeps the two views consistent automatically.
A port is the interface of the block: the signals that cross its boundary. Anything internal to the block stays internal, and that is the point of the structure. Where the symbol has to be regenerated after a port is added or renamed, the tool updates the parent sheet rather than requiring the change to be mirrored by hand.
Net Names, Buses and Scope
Nets inside a block are local to that block, so the same name can be used in two different blocks without connecting them. That is a benefit for readability and a hazard for review, because a designer who assumes that a name is global will draw conclusions the netlist does not support.
Connections between blocks exist only through ports and the wiring on the parent sheet. Buses that cross a sheet boundary have to be declared and named at both ends, because the connection is made by name rather than by position, and the rules that the design will be checked against are written around those names. A bus that is declared on one sheet and not on the other produces a design that compiles with the connection missing. The same naming discipline is what makes a conversion between tools possible, as the notes on migrating design data between platforms describe.

Reusing a Block Across a Design
The practical advantage of a hierarchy is repetition. A power supply module, an input filter or a standard interface can be drawn once and instantiated several times, and an improvement to the block propagates to every instance when the sheet is edited.
Where a design uses the same block with different values, the tool may support channels, in which the components inside an instance are numbered independently and the annotations stay consistent. Even without that feature, the drawing benefit is real: four identical interfaces drawn on four sheets are four sheets to review instead of one.
Compiling the Hierarchy
The hierarchy is not resolved until the project is compiled. Before that step, the boundary between a sheet symbol and its child sheet exists as a drawing rather than as connectivity, and the design will appear to have nets that go nowhere.
Compiling builds the netlist from the whole tree, matches ports to sheet symbols, and reports the mismatches: a port on a sheet with no equivalent on the parent, a symbol whose pins no longer agree with the child sheet, or a bus whose members are inconsistent between the two views. Reading that list is the first check of the design, and it belongs before the layout begins rather than after it, exactly as the sequence from rules to DRC assumes.
Reviewing a Hierarchical Design
Reviewing a hierarchy is done level by level. Each block is checked against its specification as if it were the whole design, because within that sheet it is. The parent sheet is then checked as a block diagram: whether the interfaces match, whether the direction of each port makes sense, and whether anything is connected twice or not at all.
The blocks that carry risk are the ones that deserve a second reader. Power conversion, high-voltage sections, interfaces that leave the board and anything with a safety or regulatory requirement are the places where a structural review finds what a detailed one misses. The characteristics that mark a carefully made design are usually visible at this level rather than in individual components.
From Schematic Hierarchy to Layout
The hierarchy can be carried into the layout as well. Placement and routing can be organised by block, which groups the parts of one function together on the board and makes the layout match the drawing that describes it. The rules that keep a layout efficient are easier to apply to a design that has already been divided into functional groups.
Where the blocks are repeated, the layout can be repeated too, and the arrangement of the repeats on the board becomes a decision of its own. When a channel is later found to be at fault, having the copies laid out identically makes the comparison between them meaningful. Keeping the same block in the same orientation at each instance makes the board easier to inspect and easier to debug when one channel behaves differently from the others.

FAQ
How many sheets should a design have? One per function rather than one per page size. The test is whether a reader can understand the sheet without knowing the rest of the design, and that depends on how much context the sheet has to carry.
Do local net names ever cause problems? They cause assumptions. Two sheets may use the same name for different signals, so the connection has to be traced through the ports rather than inferred from the label.
Is a hierarchy necessary for a small design? No. It becomes worthwhile when a flat drawing can no longer be reviewed, which for most mixed designs is earlier than the component count alone would suggest.



