RFE: Remove KiCad limitation of single sheet at each hierarchy level

[Berk Akinci]

I think KiCad should start handling multiple-sheets at each hierarchy level.

An example of files for one approach could be:
TOP.sch <- Top level of hierarchy
ADC.sch <- Simple single-sheet hierarchical sub design.
PROCESSOR.1.sch <- Sheet 1 of a multi-page hierarchical sub design.
PROCESSOR.2.sch <- Sheet 2...
PROCESSOR.3.sch <- Sheet 3...
LCD.sch <- Another simple single-sheet sub design

In this example, all nets in the PROCESSOR.*.sch files would be treated as if they existed on the same sheet.

Background:
I've been unsuccessful in finding a good solution to making clean schematics on eeschema when number of connections increase. I haven't found this covered on the forums.
At work, I use schematics where a single component with 1000+ pins won't fit on a single page. (Large components span multiple schematic symbols.) On KiCad, I can't seem to fit even relatively simple designs.

On KiCad I use hierarchy, but I find that I often can't fit a level of hierarchy in one page. I've thought hard about how to partition a design into smaller chunks. I'm assuming I need to break myself of old habits formed from having used Cadence crap for too long; however, I can't figure it out. I could make enormous (size) pages, but I'd prefer not to.

For reference: I'm using US B size: 17"x11"
This is because B size is the biggest practically printable size in the office. Large format printers are not as widely available. Similar on screen too. Also, any more content on one page starts making it difficult to follow the true intent of what is happening. My view of schematics is like the programming rule of thumb of "any one function should fit in a screenful". Hierarchy covers some of this, but not all.

For more discussion on this topic, see:
https://forum.kicad.info/t/multiple-sheets-at-same-hierarchy-level

For a public example of types of complicated designs I deal with, see:
http://files.opencompute.org/oc/public.php?service=files&t=e5568c50e71fe52b851b2e386c4c7a27
(from http://www.opencompute.org/wiki/Server/SpecsAndDesigns)
This is just an example. I have not reviewed this design, and don't pretend that it is a good example. It's just a show of complexity that KiCad should aim to enable.

====== I know this is out of date -- i haven't been actively designing for a few months. ======
Application: kicad
Version: 4.0.2-stable release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 16.5.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=ON
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[David Rosky (drosky)]

This is a significant limitation.

Currently, eeschema forces the use of hierarchy simply because a schematic doesn't fit on the desired page size, rather than allowing a single schematic to be drawn on two (or multiple) pages.

Hierarchy is useful when there are logical, functional divisions between parts of your design. In these cases, the number of connections between the hierarchical levels are generally limited and have functional meaning.

OTOH, multiple pages per schematic are useful when you simply run out of space on your desired page size and would rather have two pages than use increasingly larger page size, for example, if being able to print the schematic at a reasonable scale is important.

Forcing hierarchy and hierarchical pins and connections in cases where a simple second sheet would be better can make schematic projects more complicated and less readable.

[Bob Cousins (bobcousins42)]

KiCad does not force the use of hierarchical pins for multi-sheet schematics.

I wonder how much of this feature request is based on a lack of knowledge of what can be done with KiCad currently.

[Karl (sunny247)]

Hello Bob,

I can say that as for myself the feature request is not based on a lack of knowledge.

I completely agree with David's point.
I would state my argument for it, but I would just be reiterating what David has already said.

[Bob Cousins (bobcousins42)]

Ok, David's statement "Forcing hierarchy and hierarchical pins and connections.." is simply incorrect. So if you agree with that, you are not fully familiar with KiCad.

I can see a use case for multiple pages of a sheet, however, many of the statements such as "KiCad forces you to use hierarchical sheets" are simply wrong. The fact is you can create multiple sheet, flat schematics with KiCad already, no changes are required.

[Berk Akinci (berka)]

Please see the linked forum thread for history on this issue. I am a 20-year user of various commercial schematic tools. My first reaction was that I had to break old/bad habits, so I posed the question to the community. I have not received a solution in the forum.

[Berk Akinci (berka)]

Another acceptable, and perhaps lighter-weight solution/workaround would be:
- Keep the eeschema single-sheet
- Allow adding more than one "title block" to the sheet.
  - this should probably be automated so that they can tile/snap reasonably.
- Have Print/Plot functions generate individual sheets for each title block.

If the impact to software design is an issue, this could be a reasonable compromise. However, as I understand, eeschema is currently up for a major rewrite. This is probably a good time to implement this enhancement.

[Maciej Suminski (orsonmmz)]

There is a much simpler workaround, though not so elegant. You can sacrifice the main schematic page to place subsheets there. In such case the hierarchy is root (the main page) with many leaves, effectively creating multiple sheets at the same level.

[Berk Akinci (berka)]

@orsonmmz,
I don't follow how your workaround would apply. That is the very problem I'm proposing be solved. On a large design, the number of connections that would have to go on and off the root page are too large to manage on a reasonable sized sheet. Also, global signals are not an option in many large designs.

[Maciej Suminski (orsonmmz)]

@berka,

With global signals you do not need any hierarchical pins. This is exactly what I have found in the schematic example you posted in #1 - flat hierarchy (unless I missed a nested sheet somewhere) connected with global signals.

I am not saying I do not like your idea, but it might be hard to squeeze it in the infinite queue of features requests, so it might take a long time to implement. I am just trying to show you how you can accomplish a similar thing in KiCad.

[Maciej Suminski (orsonmmz)]

Have a look at 'flat_hierarchy' demo delivered with KiCad [1], it shows what I meant.

1. https://git.launchpad.net/kicad/tree/demos/flat_hierarchy

[Berk Akinci (berka)]

I am hopeful. Has this been fixed in 5.0.0?

[NhatKhai (nhatkhai)]

Well, flat design with all global net name will work. Just use your first root page as a content summary of all the incoming schematic pages.... I see no issue at all! I think coding for the request require a lot of code hours with little gain here right?

[Berk Akinci (berka)]

Using global net names has been brought up before. It doesn't work in the cases I'm talking about. I'll pose the example again: 4 channels of DDR3 memory attached to a CPU: you can't use global net names in those blocks without shorting all 4 channels together.

[Rene Poeschl (poeschlr)]

I fully agree with @berka on this one. There are workarounds available for some of the use-cases where having multiple pages of the same hierarchical sheet would be useful. (Especially for the ones regarding flat design.)

However finding workaraounds is not the point of a feature request. It might lower the priority of the request if there are workarounds. The feature request is still a valid one even if the workarounds would be useable in all demonstrated use-cases (In this case there is a use-case where one really has no viable options available right now.)

---

How could such same level pages behave?
- Local labels apply to all pages on the same level. (Might be that they would need a new name in that case.)
- Hierarchical pins added to any of the pages behave as if they are part of the current single page.
- Global labels still affect all pages and hierarchies.

I doubt there is a need for a label that is only valid on the current page.

[Berk Akinci (berka)]

@poeschlr said: "Local labels apply to all pages on the same level. (Might be that they would need a new name in that case.)"

I am torn on these.

OrCAD calls them "offpage" labels and requires them to connect nets outside a page. I've inherited a design where this caused unconnected nets between pages. I've always been paranoid of forgetting them. I also find it awkward to have both an "offpage" label and a net name for nets that connect to multiple places on a page. (Admittedly, probably unnecessary, but makes it clear to expect another connection on the page.)

In Cadence ConceptHDL, any net with the same name is connected within the hierarchical block. This has the danger of naming some generic net like "PLL_VDD" and have it short to "PLL_VDD" on another page. I see the danger, but I didn't feel uncomfortable when using it. This could just be because I was accustomed to it.

[Jeff Gough (jeffmakes)]

A +1 for this. Any news on it?

I would suggest making no changes to the names of the label types, nor any additional types. I think pages should be structures _within_ a schematic file with only a graphical meaning - i.e. different "coordinate spaces" that render on different tabs in eeschema.

That way, schematic files are hierarchical objects as before, and pages are just graphical objects within them. Intuitive for the user (clear distinction between page and hierarchy object), and no changes to how the namespaces are currently managed. To avoid extending the coordinate system, pages could be implemented like a series of schematic files concatenated together into one file, with a "page name" field added to tell them apart.

As for the UI, the way Eagle handles it is quite acceptable - a bar with a clickable thumbnail of each sheet. It could be even more basic like Excel-style tabs. See the dumb example attached - a microcontroller that may be able to turn itself off once :D

[Wayne Stambaugh (stambaughw)]

If/when this does happen, it wont be until after the new schematic file format is implemented which is on the V6 road map. I seriously doubt this feature request will happen in V6. It's possible we could implement this in V7.

[Berk Akinci (berka)]

Hi Wayne,
That’s OK as long as you’re keeping an eye open for this while you rework the file format. I think changing the file format is a great time for this to be considered.
Some of the proposed implementation ideas to make sense: leave each schematic file as an item, and allow us to have multiple views within it. I personally don’t care if we made use of a giant schematic canvas. We have the commute and memory resources available. (The current file only allowed for a single title block IIRC.) I want to be able to navigate and print that canvas as a bunch of A3 or B-size sheets. I want to be able to navigate (warp) around that canvas as if flipping through pages.
BTW, did you intend to set a target release for this request?
I think this has been a significant limitation. I must admit I haven’t reassessed this request in light of bus harnesses being now available. One valid reaction I’ve heard from other designers is that the tool shouldn’t try to impose changes to the way we think about partitioning our designs. The way we think may be wrong, but no better solution has emerged.
Berk

[Wayne Stambaugh (stambaughw)]

@Berk, it's much more involved than the file format changes. There are some significant internal structural changes required to support this. Otherwise, we could probably get it done during V6 development.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2063