Possible implementation for several PCBs per project

Community Feature Request Chat
1

Hmm. I was just casually observing this thread, though I have my own hopes and opinions. It was my understanding over the past weeks that a succinct statement of the topic would be:

Should KiCad be able to handle a network spanning multiple PCBs.

(e.g., a power supply, or a stack of boards)

And, if so, how to implement. Hidden wires, new uses of buses, etc.

Currently, depending on complexity, I:

  • Use separate sheets
  • Often with the above, ignore some ERC violations.
  • Create separate projects, in order to have multiple valid networks and 100% pass ERC and DRC, and not give up simulation.

If we’re discussing something totally different, I’d need to adjust.

1 Like
2

So, how could KiCad be improved to support several PCBs for one project? I would start with a basic premise: In any case each project should have only one master schematic and possibly several subsheets, as it is now. This opinion can be challenged, but IMO KiCad shouldn’t try to manage larger systems.

My basic idea for the new feature is this:

Boards would be tied to hierarchical sheets. With the current workflow logic each project has one schematic (one master and possibly subsheets). Each schematic is meant for one PCB file only. This could be enhanced so that in the sheet properties the user could add a new board file name. Then each sheet, with its subsheets, would be tied to one PCB file.

When the user connects an upper level sheet with wires to the attachement points of the hierarchical sheet, if the connection would be between two PCBs, it would not be an error, but the user is responsible for knowing that these connections must be made with external connector wires or by some other means. They wouldn’t require copper tracks in the PCBs.

This is just a wild idea after brainstorming. Please comment and give your opinions.

EDIT: updating PCB from schematic would introduce a new problem, and navigating between PCB and schematic. EDITEDIT: Or maybe not a big problem, because there would be only one PCB for each sheet, and each PCB would have unambiguous connections to some sheet(s). If updating happens from a PCB, it would be automatic like it is now. If it happens from the schematic, it happens from a certain sheet, and each sheet would know its PCB. So this would be mostly transparent.

3

This would create some restrictions to use of global labels. IMO it would be too confusing to allow connections between different sheets/PCBs using global labels. Global labels should work only inside on PCB, and a global label with the same name used in several PCBs should be an error. This would of course cause a small problem for power symbols: one “GND” is quite universally used between sheets in hierarchical designs. Now this would be prohibited for sheets representing different PCBs.

4

I still like my own idea to “nest” kicad projects. With this method, each PCB has it’s own KiCad project, wile the is a “master project” which has all the schematics of the sub-projects in a hierarchy.

But before discussing “possible implementation”, setting up a set of requirements would be a logical first step. With the “nested project” idea, it would also be quite easy to have several people working on the system at the same time, because the sub-projects provide logical barriers between the pcb’s.

Multi PCB projects can also have very different PCB requirements. For example one PCB can have very thick copper for high currents while a “control PCB” has a more conventional stackup.

I’ve also seen PCB’s where a relatively small high layer count PCB is used on top of a much bigger but lower layer count PCB to keep the cost down.

And this also overlaps with the use of sub-modules and integration of already existing designs (such as an uC breakout board) into another design. This would ease the transition from a rapid prototype to a more production oriented version.

And although there is nothing wrong with brainstorming about this topic, it does seem a bit premature. KiCad is doing very well and development has been accelerating for several years, but I do not know in what sort of timeline a feature like this may be implemented. It will come eventually, but I guess it’s still several years into the future. That can of course also change rapidly if either a company is willing to sponsor this feature, or if a (new?) KiCad developer develops a keen interest in this.

1 Like
5

I think this would be as easy with “several PCBs per schematic” idea because both the PCBs and the correspdonding schematic sheets would be in separate files.

That, too, would be automatically possible with “several PCBs per schematic” approach because each PCB would be one file and could have independent settings/requirements.

This would of course be possible, too, with my approach. Actually I have been thinking about a simple example where a project, one board, would be split into two boards but kept in one schematic hierarchy.

In the end I think your approach and mine would be pretty similar in many respects and in possibilities but would need different kind of implementations and UI details in KiCad.

One advantage which I can see in my approach would be that it would be easy to reuse design rules (net classes) between boards, and also text variables. They would be closer to the current implementation than in your nested approach.

On the other hand, this can also be a limitation: if the two boards are dissimilar, they would be need for two different net class sets which might be better served by two separate subprojects rather than just one project.

(By “implementation” I don’t necessarily mean code implementation or code architecture but how KiCad appears to work, the UI and workflow architecture and the file formats.)

6

I would start with the most basic, high level question “Why do people need or want to have several boards in one project (or metaproject)? What is their perceived need or the problem to be solved? What are the use cases, without referring to possible or current implementations in KiCad?” I mean, why it’s not enough to have just one project per PCB?

This way we would find functional requirements. Can for example @daemonburrito or @set answer this?

1 Like
7

I think that we want a mechanism to have one project for the whole system.
A recent work we did for a client needed to split the functionality between the processor and the power stuff, for space reasons. And we used an approach that is similar to “nested projects”. In this way you have one top-level where the client can see all the functionality.
You need some place to document the information for the all the parts of the system.

You could even want to add information about the connection components, like in the last proposed example here.

KiCost has a very special (bizarre?) mechanism to specify this. You can have multiple part numbers for a single symbol, so you put the cable, crimp terminals, crimp housing, etc. all in the connector. I think that using explicit symbols for them is much better, of course takes more work. These components belong to the system, but they aren’t for a particular board. Using some top-level project is a good way to host them.

In the example I mention above you clearly see how boards are connected, which is an important documentation.

Note that KiCad doesn’t need much changes in order to support nested projects the way I mention above. Perhaps something to avoid the need of adding explicit hierarchical ports, some mechanism to say “this connector must be exported as hierarchical ports”.

The solution used by KiKit looks too limited to me.

Also one interesting addition to KiCad could be some mechanism to define a cable for ERC. Otherwise you have to define each wire use, when in fact they are just connections. Some mechanism to say: pin 1 is connected to pin 3, and pin 2 is connected to pin 4. This will enable full system ERC check even for the top-level with cables:

Schematic

8

I think a mechanism to join them will be helpful

The association between sheet and PCB looks ok.

9

I agree. Each physical GND should have a different name and global connections crossing PCBs should be reported as errors.

But allowing to make explicit connections between boards could enable system level ERC checks.
One current problem is with the PWR_FLAG. If you have GND1 in board 1 and GND2 in board 2, and you connect them using hierarchical ports the ERC fails.

10

I hope that this topic is not consuming too much bandwidth.

A couple of things:

Not so important: The mailing list has decided that it does not like me; I had a managed pseudorandom password, etc., but had to use the Google SSO because I’ve been lost. If anyone stumbles across a “daemonburrito” post (could be lost somewhere during moves), that’s me, and may soon be me again.

On topic:

  • I had forgotten that I had heard of the “nested part” solution that works currently, but it is difficult to document and not part of a documented UI flow. It does have the advantage of working.
  • As the first message hints at, my primary interest is in having ERC/DRC and simulation all be possible with separate PCBs (maybe that distinction is important, with the modular design of Kicad, eeschema, and pcbnew.)
  • It’s not particularly important if this feature is not immediately discoverable at this time, however, so major chrome work is not top of mind for me (though it would be nice someday, as mentioned.)
  • The design of KiCad’s netlists presents some room for experimentation now that I might pursue, all plumbing for the most part.
    • The “global flag problem” doesn’t seem insurmountable, but it does seem troublesome to work through without disturbing a UI that’s working great for its purpose now (using nightly builds.)
    • One more implementation possibility is a systemnew (or whatever we want to call the executable module) that would take pcbnew products as parts. It would be in keeping with the design strengths of KiCad overall.
    • I did follow the scripting API, and while it’s extremely useful for some things, I can’t see it bent for this purpose.

And I do, of course, realize that this is just kibitzing unless someone or something steps up to the plate. It’s possible to do in a do-no-harm methodology with a new systemnew and the existing text products that already exist for nets.

I don’t mind formalizing “nested” approaches, btw. It’s just that it may require intrusive work for UI. The new module (calling it systemnew for now) has the advantage of being invisible until desired.

tldr; plumbing and discrete, non-intrusive work is possible now without stepping on toes. “Nested part” approach already works, but lacks UI and would require surgery; it does however, work right now (and could be documented, hint hint). KiCad nightly is in a pretty beautiful right state now; a modular approach is appealing to me, at least.

11

Circuit simulation and PCB design don’t work well together in KiCad. Usually it’s recommended to have separate schematic for simulation, and it’s not connected to a PCB.

What exacty would you want from ERC and DRC, or what they should do with a “several PCBs” project?

12

That is also true in a more general sense.
For a simulation, it does not make much sense to add things like connectors and footprints, while for a PCB, the voltage sources ans spice directives do not make sense.

But that does not mean that one would exclude the other.
I think the biggest limitation would be that spice simulations are quite often done on a small sub section of a schematic, such as a filter or an SMPS (for those there are specialized simulators and design software). If KiCad were able to limit a spice simulation to a single hierarchical sheet this would be a lot easier.

13

Obviously, schematic capture/circuit design and PCB design are different concerns in my workflow. I am not proposing ERC in the PCB stage, after the network is completed in eeschema, or DRC in schematic capture. I think I’ve been misunderstood, or I was not clear, sorry. It’s obvious to me that I meant that rules no longer apply once we go from eeschema to pcbnew, where routes that would be connections between PCBs in a system are errors/warnings in DRC.

@paulvdh understands my thoughts, I think. I didn’t want to get too mired in something that’s really, really greenfield; my first message was just a request for clarification that we were discussing a wish for system-level view. We’re all working around it, in at least three different ways:

I ignore some DRC warnings and errors, if the ERC is fine, but I lose some advantage of an EDA when I’m using my imagination in the last stage and trusting that my connections are correct. I send separate boards off to fabrication after I’ve worked things out, but obviously, this doesn’t scale with many connections (say, dozens of connections on a ribbon connector.) So far, it’s not a huge problem, and wasn’t in earlier versions where I used similar workarounds. But the fact that there are so many “workarounds” and misunderstandings show that there is a need, eventually. Trivial example: Phoenix connectors with validated electrical connections in the netlist.

I must disagree on semantics, though: there is one huge connection between eeschema and pcbnew, between circuit design and PCB design: the network. Sorry to state the obvious. And there are even features in pcbnew that affect cicruits, like track tuning, layers, etc.

Again, @eelik I don’t want to get too bogged down at this spitballing stage. But if it helps to directly answer questions as asked, I want something similar to what everyone wants but is approaching with different workarounds (I think?):

Exactly what I want from ERC and DRC

I’d like the network designed in the circuit design stage (eeschema) to span any number of PCBs in the PCB editor (pcbnew)

or what they should do with a “several PCBs” project?

The “or” is inclusive, yeah? Complex designs can naturally span multiple PCBs for the purpose of validation in KiCad, and then sending fabrication outputs with confidence of electrical correctness provided by such. Obviously I could create the designs on paper or in an art program, and create text files by hand to send to fabrication, but we’re using an EDA for a reason. I’d like the final outputs of pcbnew to have been verified.

Cases where multiple boards are needed are clear:

  • Power supply separation, for EMI or safety purposes, or even a power supply as a part.
  • Stacking and modular features like expansion boards, and their buses, for customers and repair (this is a really common desire.)
  • Electrical separation for avoidance of parasitic effects.

I probably don’t need to enumerate those, but I wanted to directly answer your questions as asked, in case it seemed like I was avoiding them. I think those are direct answers, and I don’t want to pollute the thread with repetition of thoughts and desires already stated; I’m already worried that I’ve said too much. Of course, if you want further description of what I wish from ERC/DRC and simulation, I will happily oblige. I just want to be a good forum member and not approach spamming levels of discourse.

I hope this has seemed friendly, as it is meant. I actually half-suspect that the features that we want are going to appear by surprise sooner than we think.

[EDIT] To quote the 6.0 docs and @set :

I think we all wish for this not to be the case:

KiCad currently supports one board file per project / schematic.

And all or nearly all features of KiCad to still apply.

1 Like
14

I’m violating the “not spamming” idea here, but I realize now that I may have misunderstood your last question, “what they should do with a “several PCBs” project?”; I understood it as “why would you want separate boards”, and maybe you meant “what should KiCad do with separate boards.”

I think that is the question itself. I think the simplest and least intrusive solution is one more tool, the systemnew which takes any number of pcbnew outputs and the netlist, with valid connections between connectors (maybe a new kind of wire or “route”, or just call it a “connector wire” in the UI.)

pcbnew fabrication outputs could still work as they exist.

Others here have proposed other solutions, like added functionality to the existing tools in the KiCad toolbox, making hierarchical sheets more powerful, nested parts, etc.

15

I have a sense of déjà lu over this but I think it’s a low-cost approach which is worth exploring as it will give experience for what’s useful. If nothing else this will allow system builders to document a set of interconnected boards. Or even things that are not boards, like power supplies, display modules, some of which might be off-the-shelf and not designed by the systemnew user.

2 Likes
16

would this really help tho? as far as I read it in the past most people who wants to have a “one schematic multiple boards” solution explicitly want to have multiple PCBs in one layout file for multiple reasons. the most often seen is probably production but also cross checking etc.

17

What more then is wanted from KiCad than what is there now? That’s the heart of the matter, what would you (they) want KiCad to do what it doesn’t do now?

@daemonburrito doesn’t have to be afraid of spamming or anything else. I blame myself for not being able to form the questions so that I would get the right kind of answer. All the time I just see that people try to do something with KiCad it’s not enough for (as far as we are talking about this “several PCBs under one project” question). I would like to know where are the limits of KiCad and what exactly it should be capable do to fulfill the need. And there seem to be different kinds of needs which go under the same name. Adding functionality for one use case wouldn’t necessarily help with another case.

18

Thank you, @eelik . The discussion, while it’s appeared frequently over the years, is just fine. And that reminds me, @Tojan , that I think we have the same goals. My main concerns, while I can’t rank them, definitely include cross checking; I hope semantics aren’t throwing anyone, I’m absolutely sure that we all want the same thing.

My spitball just comes from my “do no harm” experiences in programming with large codebases. KiCad already has, as a strength, a modular design which allows process utilities to be managed, while being separate entities as far as the OS is concerned (e.g., using the KiCad UI to start the project, do schematic capture with eeschema, click on the button that takes you to pcbnew when you’re satisfied which the ERC and any simulation you needed to do, then plugging in your fab’s limits and grabbing the outputs.)

The “do no harm” approach just takes the netlist along to one more process utility, which I’m referring to as systemnew for no particular reason than to have a name to discuss. It’ll have everything you’ve done in the previous steps, and its job will be to present a system-level view, maybe with special connections that don’t cause problems (the network is fine, pcbnew just rightly, with the “one board” limitation, lets you know when you have what it sees as connection problems.)

A new executable just seems like the safest path for experimentation, as it’s completely optional, and only becomes an official part of the process when/if it’s mature and useful to enough people to deserve a button on the toolbar in pcbnew and the KiCad manager.

It might make more “sense” to tear into pcbnew, but it’s an open-source project and there isn’t even a quorum on the feature. So systemnew is just my suggestion. Worst case, I learn a lot about KiCad internals. The wonderful thing about this project is its flexibility, modularity, and the ultimate parseability of the network description, which remains independent of this affordance that we want (features across multiple boards and components.) If it’s terrible, it’s terrible, and that will be okay because it won’t even be in the KiCad repository until our core maintainers believe its worth it. If it is liked, it will be an easy integration.

After that long spiel, and the previous messages, I think I’ve said everything I set out to say, unless there’s a question. It’s going to be in the oven for a long time, however it works out.

19

4 posts were split to a new topic: KiCad’s future as a single window MDI application

20

to be clarified, thats not my position I am completely fine with how KiCad does things now and manage my multi-board projects in a different way. I just saw that the discussion here did not picked up the imo most requested part of the multi-pcb design.

Many of these requests wanted to have an one schematic, multiple boards approach which is not currently working. Because if you use global labels or power symbols, you will end up having a number of unconnects between the boards which will irritate on routing because of the ratsnet as well as on checks because you have to check each unconnect manually. I can see why no one wants to do that for designs where you have dozens of shared signals between multiple boards.

Another point I saw often mentioned panalization in how they want it is not that great at this moment but I don’t remember the actual points they criticized there.

I think one idea to get rid of the ratsnets between boards would be to give a hierarchical sheet the option “do not connect interior signals to external ones” and the netlist calculator to check this option and well do exactly what the option says. But I don’t know how much bending of code this would need in regards on how global labels and power symbols are handled by the calculator creator right now.