Hi there, I’m new here, hope you can give me some pointers… Got a large project I am about to endeavour in and am considering making it a hierachical design. I got multiple stacked PCBs connected through a backplane. As this is a collaborative project I would prefer to have multiple projects in a folder structure that matches each PCB/module, then stitch it all together in a hierachical structure. Is this doable in KiCAD? I think it is important that each project functions completely independently from the rest of the design.
Keep in mind this should not hinder productivity, but allow a more structured approach where the interfaces between functions are defined through block.
How do I make the various hierachical ports ‘connect’ through the backplane, while having connectors in the PCB? Just add a bunch of ports and then connect each port to it’s appropriate connector?
I once did an experiment in this direction, and it did seem to work.
I first made a few projects in the same directory, each project with a schematic for one PCB.
After that I made the “root” project, and used the schematic files from the other projects as hierarchical sheets in the “root” design.
When working this way, then work on the schematic should always be done on the “root” project, to make sure annotation is unique for each component. Project specific libraries probably have to be added to both the root project and the sub projects in which it is used.
Back then I made a write up in a quite long forum post, and at the bottom of that post I also posted the zipped project:
Do note that the “official” KiCad standpoint is “one PCB per project” and this whole Idea was just an experiment, and I did not complete the project. But from what I did do it all seemed to work as expected.
You have to do component annotation in the root design to make sure that each component has a unique Refdes. If you make a mistake by for example doing annotation in a sub project and you have components with the same RefDes, it’s not a big problem because KiCad normally uses unique timestamp values as internal references between schematic symbols and footprints on the PCB in Pcbnew, and re-annotation in the root project should propagate to the final PCB’s when you work on those projects.
=========
Your “backplane” will be a PCB, and therefore a separate project. Do not make the mistake to put the backplane in the root project. The root project sees all components, and if you try to make a PCB from that, then all components will be placed on the PCB.
=========
The things you gain with the root project:
Block schematic with an overview of all sub projects.
ERC check over the whole design.
Easy switching between schematics with the hierarchy.
Copy & paste of connectors with wires and labels attached to another schematic (watch out for male and female footprints!) speeds up design and reduces errors.
Quick switching between projects by double clicking on a project file in the project manager.
You can make paper copies or a .pdf of all schematic sheets in one go.
================ [Edit]
Eelik (below) has a good point.
I have not tested this in V5.99. I just installed V5.99 very recently and have not done any serious work with it yet.
@paulvdh, have you tried this with 5.99? There have been quite many changes which may affect this workflow. References in hierarchical sheets are handled differently. Learning this workflow isn’t necessarily very useful if it can’t be used with the future v6.
What I would do is have one project for one PCB. But all of the projects would share the same hierarchical sheet where only the symbol for backplane connector would be. And the backplane PCB would also be separate project with multiple use of the said hirearchical sheet, but you would need to swap the connector footpirnt in the pcbnew (so that the footprint change is not shown in other projects)
I don’t understand exactly your needs but KiCad philosophy is one PCB = one project placed in one directory. How directories of several PCBs are relative to each other is ignored by KiCad so you can organize them according to your understanding of that project hierarchy. As I understand backplane is also PCB so for KiCad it is separate project. If you use there simply connectors to be placed at that backplane, or you define your other PCBs (I understood that each can have several connectors) as a footprints to be placed at backplane it is your choice.
Thank you, that sounds really promising!
It sounds like annotation duplicates is only a problem wrt. it being confusing from the root project? Because I could certainly accept that. Otherwise, I think you can prefix the annotations with a number for each subproject?
“Global” annotation is mostly important for “global” ERC check, and indeed, you can use the “page number” as a prefix during annotation.
Do you have any interest in experimenting with the next KiCad Version (V5.99, soon to become V6?) It is sort of interesting if this still works in KiCad V5.99 even though I do not expect any problems.
I do not know much details about the internals of KiCad V5.99. Just that the hexadeximal “timestamp” value chaned to an UUID, and is a much longer string. But the whole idea of those identifiers is that they do not change during the project. From that standpoint nothing has changed.
Maybe Eelik has some idea’s of possible problems.
I would prefer to use the stable release version as this is to be a collaborative university project. Otherwise it sounds promising, I just need to convince the ‘people in charge’ that the hierachical approach is worth the hassle.
The Hierarchical approach is not that much of a hassle, it’s just another project to stitch the others together, and if you don’t like it you can always simply abandon it and go further with the rest as separate projects.
The only problem I can see is with library management of custom libraries.
I have been using @paulvdh 's approach quite a long time now.
It works like a charm if you don’t mind annotation special handling.
(i kept personal-global libs and i don’t remember having an issue with symbols in any of those projects)
I was using that flow during v5 with stable releases. I do not think it was pretty convenient (lack of page numbering for example), but i found a functioning work flow and that kept me happy/bussy.
@eelik i will get back to move some projects too after rc is out and then i will report my findings.
I really hope this will somehow still be applicable. I found “browsing into a full multi board (and not only board) schematic” pretty neat.
Please spare a thought for your support folks. My boss once changed our product schematic to “hierarchical”, for no apparent reason. It made troubleshooting nearly impossible. I bought a dictation machine and created a personal “flat” schematic from the net list. It cost about a man - week but it was such a relief to be able to do my job once more.
Good use of hierarchical sheets can make troubleshooting easier, bad use can make it harder. Dividing according to functionality must be well thought and labels must be used wisely. It’s like in programming: it’s possible to write incomprehensible code using functions and classes. Writing code which works isn’t enough.