[Wishlist] Multi-page hierarchical sheet instances (allow a hierarchical block to span multiple pages)
This is a continuation of #2063, which was closed as implemented but only addressed the root level. This issue requests the remaining and originally-intended part: allowing a hierarchical block instance at any level of the hierarchy to span multiple pages, with nets connecting across those pages by name — exactly as they would on a single large sheet. I am the original reporter of #2063, opened in 2017. I was directed to open a new issue by Ian McInerney in May 2025. First, I want to say: I am genuinely grateful for KiCad and the work the team puts into it. It is a powerful tool, available for free, and I want to see it replace the dinosaurs in the EDA space. This is one specific missing feature that prevents that from happening in professional contexts. I know experienced designers who do not take KiCad seriously specifically because of this limitation. I raise this not to criticize but because I want KiCad to succeed. --- **The request, stated precisely** ``` TOP.sch <- top level of hierarchy ADC.sch <- single-page hierarchical block PROCESSOR.1.sch <- page 1 of a multi-page hierarchical block PROCESSOR.2.sch <- page 2 PROCESSOR.3.sch <- page 3 LCD.sch <- single-page hierarchical block ``` All nets in `PROCESSOR.*.sch` are treated as if they existed on one sheet. The block appears as a single entry in the hierarchy navigator. If instantiated twice (complex hierarchy), each instance's nets are independent — exactly as with any single-page block today. --- **What this is not** * Not "flat schematics" (sheets connected by global labels with no hierarchy). The title of #2063 was changed to reference flat schematics without my agreement; I objected in the thread. This request is specifically about hierarchy with multi-page blocks at every level. * Not intersheet or off-page labels of any kind. I explicitly do not want a new label type that crosses page boundaries. Giving a net both a local and an off-page name makes no sense to me. I have direct experience with OrCAD designs where off-page labels caused silent netlist failures — a net that appeared connected was not. Approximately four decades after their invention, OrCAD still has bugs in this mechanism. That mechanism may even be an artifact of implementation than a feature requested by users. The solution is to have no cross-page boundary at all: pages within a block instance are one logical sheet, so no crossing mechanism is needed or wanted. * Not a change to how local, hierarchy or global labels work anywhere in the design. --- **Correct semantics** A net named `X` within a multi-page block instance connects to every other net named `X` within that same instance, on any of its pages. This is identical to current single-page behavior — it is simply the same rule applied uniformly, with page boundaries made electrically invisible. Hierarchical pins on any page of the instance behave as if on one logical sheet. Global labels still span everything as today. No new concepts are introduced. --- **Why global labels are not an acceptable substitute** This has been raised repeatedly in #2063 and I want to close it out definitively. Consider a CPU with 4 channels of DDR memory. If you make the data bus signals global nets, all 4 channels see the same bus — they are shorted together. The nets must be local to each block instance but must span that instance's pages. Global labels cannot do this. There is no workaround that scales. --- **History of this request and why it has not been resolved** This request has been open in some form since 2017 — nearly a decade. During that time: * The title of #2063 was changed twice to reference "flat schematics," which misrepresents the request and caused the implementer to solve a different problem * I objected to the title change in February 2025. Before any implementation work began, and I restated the request precisely * The feature was implemented at the root level only and the issue was closed * The cross-sheet local label behavior that appeared in 10.0.0–10.0.2 as a side effect was _closer to the correct behavior than anything intentionally shipped_ — and was then reverted as a bug in 10.0.3 Jon Evans (@craftyjon) noted in #24290 that "people saying 2063 is not fixed need to make a stronger and more detailed case." I hope this issue provides that. --- **Concrete impact — a real example** After #2063 landed in 10.0, I deliberately tested the new multi-sheet capability. I am a long-time KiCad user who understands the tool well; this was not accidental usage. I built a 2-page lab board design, separating the schematic across two top-level pages. The behavior in 10.0.1 was exactly what I had been requesting for years: nets connected by name across pages, no globals needed, no special labels. It worked correctly and was a welcome relief after nearly a decade of waiting. In 10.0.3, that behavior was reverted as a bug (#24290). My nets were renamed to `sheetname/netname`, the board lost its connections, and the design is no longer usable as-is. My recovery options are: 1. Copy everything onto one giant sheet — which is the manual implementation of this feature request 2. Add a global label to every net that crosses pages — the workaround I have always argued does not scale Neither is acceptable as a permanent answer to a problem this fundamental. --- **Suggested implementation path** I proposed the first approach in 2017 and again in 2019; Wayne Stambaugh acknowledged it. Jeff Gough (@jeffmakes, Oct 2019) and Jake Anderson (@grooveee, Apr 2024) described the same approach independently: **Option A:** Allow a schematic file to contain multiple title blocks / page frames on one large canvas. Print and plot generate one output page per frame. Page boundaries are a display and printing concept only — completely invisible to the netlist. This requires: * Single file per hierarchy level * No new label types * No new connectivity rules * No changes to hierarchical instantiation semantics * No changes to how local or global labels work It extends naturally to complex (multi-instance) hierarchies because the instance boundary is already well-defined by the existing hierarchy mechanism. The pages inside are just drawing space. **Option B:** The net namespace behavior present in 10.0.0–10.0.2 for top-level sheets was exactly the behavior I have been requesting — nets connecting by name within a shared hierarchy level, without globals, without special labels. I was excited when I saw it because it told me the underlying model was already capable of this. The only problem was that it was limited to the root level. Extending that same behavior to every level of the hierarchy — so that sibling pages within any hierarchical block instance share a net namespace — would also fully resolve this request. This path has the advantage of being demonstrably implementable, since it was working at root level already on 10.0.1. Either path arrives at the same correct behavior. I leave the choice of implementation to the developers. --- **Tested on KiCad Version:** ``` Application: KiCad x64 on x64 Version: 10.0.3, release build Libraries:       wxWidgets 3.3.2       FreeType 2.13.3       HarfBuzz 12.3.0       FontConfig 2.17.1       libcurl/8.18.0 Schannel zlib/1.3.1 Platform: Windows 11 (build 26200), 64-bit edition, 64 bit, Little endian, wxMSW Build Info:       Date: May 14 2026 13:33:37       wxWidgets: 3.3.2 (wchar_t,STL containers)       Boost: 1.90.0       OCC: 7.9.2       Curl: 8.18.0       ngspice: 46       Compiler: Visual C++ 1944 without C++ ABI       KICAD_IPC_API=ON       KICAD_USE_PCH=OFF Locale:       Lang: en_US       Enc: UTF-8       Num: 1,234.5       Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8) ```
issue