-
The advise I got for V6 was to open separate projects for each PCB in a design. Has this changed with V7? Or too early to tell?
-
No change.
-
The limitations in KiCad 7 (unchanged from 6) are:
- One schematic file per project -- which may be a set of multiple sheets, held together in a hierarchy.
- One PCB layout page per project -- which may contain milling contours to outline multiple separate, physical boards.
But if the multiple PCBs are more loosely coupled and can be "mixed and matched", e.g. a bus system with different optional plug-in boards and more to come later, I would keep them in separate projects. - One schematic file per project -- which may be a set of multiple sheets, held together in a hierarchy.
-
My present project is more like one PCB for the power supply and about 7 or 8 identical PCBs in addition to that for the works. So the numbers may or may not line up.
Perhaps a 3 x 3 layout with one power supply and 8 individual boards. That might even save money when purchasing the boards.
It would really be nice to have everything in one project.
If I decide to try this how does the process work? I understand you need a root drawing to show how all the pieces are connected. But how are the individual PCBs shown in that drawing? Custom part symbols perhaps with the INs and OUTs shown in a manner like pin numbers on ICs? And then individual drawings for each PCB? Do I start at the root drawing and then work down? Or with the individual PCB drawings and then work up?
Perhaps there is a video or written lesson on this? I will look. -
Quote
It would really be nice to have everything in one project.
I'm not sure. If you need to make a change to your PSU you will be changing your 'other' PCBs too, even though there is no real change to them and they are not affected. Further down the line it might be assumed that OtherPCB B is needed to work with PSU B, whereas in reality A will be fine with B (and vice versa). In software, this would be high cohesion and high coupling, which is not a desired trait.
Also, there is the implication that 'project' means Kicad file. If it's not in that Kicad file it can't be in the project. But in reality 'project' encompasses many files of various types (documentation, datasheets, PCB, 3D CAD, simulation, etc). If you want it all together, wouldn't it be better to have a folder in your file system called, perhaps, "The Project" and have sub-folders for the various types of sub-project? Easy to shove in source control, zip, delete, whatever. -
What could be nice and useful rather than just a single project holding actually several separate designs would be to add a project container, or something like that. Could be called a "workspace".
In which one could add several existing projects, which would be more easily accessible but would still be separate projects. That would give the functionality without fundamentally changing the architecture or risking screwing something up.
-
What could be nice and useful rather than just a single project holding actually several separate designs would be to add a project container, or something like that. Could be called a "workspace".
In which one could add several existing projects, which would be more easily accessible but would still be separate projects. That would give the functionality without fundamentally changing the architecture or risking screwing something up.
Good point. Grouping the files from multiple projects together can be done via a folder hierarchy, of course, with the current Kicad version. But then switching between projects still feels clumsy.
A multi-level file tree on the left would be nice (with a container, multiple projects within it, and the files for each project), and hopefully it would be relatively easy to implement. -
The one thing I think would be really important to capture in addition would be some sense of a "spanning" change -- eg changing a board to board connector -- where you need the same version of the connector on both boards, and would never want version 1 of board A with version 2 of board B.
Maybe version control is adequate to represent that... but I think the "container" UI would need to have some VC integration, at least, then. -
The one thing I think would be really important to capture in addition would be some sense of a "spanning" change -- eg changing a board to board connector -- where you need the same version of the connector on both boards, and would never want version 1 of board A with version 2 of board B.
There is a way to do this even now. With some limitations. In project A you can have a hierarchical sheet containing only a board to board connector symbol. In project B you place hierarchical sheet and use the same file (not a copy, but a link to the same file). So any change made to the connector in project B will show up in project A and vice-versa.
This works when connectors use the same footprint (e.g. IDC, Micromatch with flat cable connecting the boards). For designs where the footprints are different there are some issues. For PCB that are sandwiched with 100 mils pin headers and you are really designing a prototype this is not really an issue as you can use the same footprint but than solder different connector manually. For serious designs where you want to generate proper BOM for both projects, this is currently not a solution https://gitlab.com/kicad/code/kicad/-/issues/14764. -
Support for multiple PCBs is a deep rabbit hole. Of course, there is the trivial simple solution, like mentioned above that we basically have a collection of project, each of them with schematics and corresponding PCBs. But many designs are not that simple.
Let me give you an example.
There is one or more schematic drawing, but there is no 1:1 correspondence between a schematic sheet and a board. Instead one needs to divide the design up between separate PCBs, for example for packaging reasons. In this case, there is no logical partitioning of the schematic, but you may need to move components between PCBs to achieve the desired shape. Think about for example a camera. There would be board-to-board interconnects maybe in the shape of real connectors, or wires or flex pcbs. To have any meaningful automation, the design tool has to support treating these connectors as nets and of course it also need to have the ability to assign and reassign components to the different PCBs.
There is a similar situation if you have boards on a backplane etc.
I would love to see this supported in the future, but no idea how much fundamental architectural changes are needed for this in KiCAD. -
The one thing I think would be really important to capture in addition would be some sense of a "spanning" change -- eg changing a board to board connector -- where you need the same version of the connector on both boards, and would never want version 1 of board A with version 2 of board B.
There is a way to do this even now. With some limitations. In project A you can have a hierarchical sheet containing only a board to board connector symbol. In project B you place hierarchical sheet and use the same file (not a copy, but a link to the same file). So any change made to the connector in project B will show up in project A and vice-versa.
Yes, I also use this for multiple instances of the same schematic block on the same board. Very handy. Say no to copy-pasting and maintenance hell.
-
It's possible to have multiple .kicad_pro project files in the same folder. They all show up in the kicad file list, and double clicking one that is not the currently open project swaps over. Board and schematic files belonging to other .kicad_pro files can be double clicked and they are opened in stand-alone instances of pcbnew or eeschema, which is useful for cross referencing between different boards.
Each of my project folders is set up as a git repository for revision control. In those I keep the .pretty component folders as git submodules (eg. ${KIPRJMOD}/resistors.pretty). That way I can have different revisions of the same component libraries checked out per project. (If I use components from the kicad standard libraries I copy them into my own git modules first.) It's not perfect in the sense that different boards within the same project folder may get out of sync with the component libraries. But once a board layout is finalized with the current component revisions and committed to git it shouldn't change anyway. If that board's revision needs to be bumped it likely makes sense to update to the latest and greatest of component revisions anyway. -
One PCB layout page per project -- which may contain milling contours to outline multiple separate, physical boards.[/li][/list]
That's what I'm doing with Kicad 6. I have a stacked design with 4 boards connected using 104-pin mezzanine connectors as backplane. For each backplane signal, I have defined a global net.
For the PCB I've defined four rectangles in the "Edge Cuts" layer. Each rectangle defines one of the PCBs of the stack.
Routing is 95% done.
My problem is this: How do I tell KiCAD that the pins will physically connected when the boards are stacked together?
Help! I need this to be able to run DRC and to see an uncluttered rat's nest.
Right now KiCAD thinks there are missing connections between the pins of connectors on different boards.
I'm thinking of removing the edge cuts and making fake routes using fake inner 6th and 7th layers that would span the four boards, but it sounds messy.
-
Anything that you do will be a hack as Kicad does not support his workflow.
The options that I see are:
1. You could use WireIt plugin to split the nets connecting two PCB's. I don't know though if it works with V7 or V6. https://github.com/devbisme/WireIt. The significant downside to this is that PCB will not be in sync with schematics. So splitting nets should be the last step
2. As you've said, you can connect the PCB on additional layers which will not exist in real PCB. You should even be able to keep edge cuts, as you can suppress individual DRC errors. So you could suppress the errors regarding the tracks crossing the edge cuts.
3. Do nothing. Suppress your OCD desires and live on.
I think that #3 is the best one. -
Well, yes, use an extra dummy copper layer - problem is, it has to be a copper layer. So that will appear in your stackup. But if you really want to handle several PCBs and their interconnections like this, I don't see another way. A bit clunky, but largely doable.
-
Anything that you do will be a hack as Kicad does not support his workflow.
That's not feasible, how am I going to route all those nets without seeing what is missing? Not the mention the high likelihood of errors. As usual it's a "the client wants their board last week, but I got their specs yesterday" kind of scenario.
...
3. Do nothing. Suppress your OCD desires and live on.
I think that #3 is the best one.Quote from: MitjaN2. As you've said, you can connect the PCB on additional layers which will not exist in real PCB. You should even be able to keep edge cuts, as you can suppress individual DRC errors. So you could suppress the errors regarding the tracks crossing the edge cuts.
I just tried to do that going through pseudo layers 5 and 6.
I've defined rule areas around the boards that only allow tracks on the pseudo-layers, that's the easy part.Well, yes, use an extra dummy copper layer - problem is, it has to be a copper layer. So that will appear in your stackup. But if you really want to handle several PCBs and their interconnections like this, I don't see another way. A bit clunky, but largely doable.
But connecting layers needs vias, and it's a tight design I didn't leave space for vias in the bottom right card! Plus, existing vias also prevent the pseudo-layers from routing.Quote from: MitjaNThe options that I see are:
I guess I'll have to look into that plugin, and if not painfully route those pseudo layers.
1. You could use WireIt plugin to split the nets connecting two PCB's. I don't know though if it works with V7 or V6. https://github.com/devbisme/WireIt. The significant downside to this is that PCB will not be in sync with schematics. So splitting nets should be the last step
Thanks for your feedback!
-
My problem is this: How do I tell KiCAD that the pins will physically connected when the boards are stacked together?
Help! I need this to be able to run DRC and to see an uncluttered rat's nest.
Right now KiCAD thinks there are missing connections between the pins of connectors on different boards.
I'm thinking of removing the edge cuts and making fake routes using fake inner 6th and 7th layers that would span the four boards, but it sounds messy. (Attachment Link)
When I came across this in KiCad on a dual board design all I did was separate the parts in the Pcb and the Schematic thus separated nets.
Ian. -
But then you have to make the decision on which component goes to which board at the schematic level. If pcb had some kind of net-tie feature or a kind of "teleporting via", where one puts down a connector and its counterpart on the other board will becme part of the same net. I'm not familiar at all how the pcb editor works, but maybe this would not be so hard to implement. You could define coupled connectors, where each side is part of the same net, but you would be free to route any net to it, when it would connect its other side to the same net. This is so that you would not have to comit the pinout on the schematic.
-
Well, yes, use an extra dummy copper layer - problem is, it has to be a copper layer. So that will appear in your stackup. But if you really want to handle several PCBs and their interconnections like this, I don't see another way. A bit clunky, but largely doable.
But connecting layers needs vias, and it's a tight design I didn't leave space for vias in the bottom right card! Plus, existing vias also prevent the pseudo-layers from routing.
Well, yeah. it would work for throug-hole connectors (not needing extra vias), but otherwise not that well indeed.
-
Quote
But then you have to make the decision on which component goes to which board at the schematic level.
Isn't that why you have a schematic? It shows the human what the thing is, so they don't have to reverse engineer the gerbers. -
No. The schematic is the circuit. The boards are the packaging. If I have to fit the circuit into some funky shape using two boards, I don't care which component goes onto which board, as long as it implements the function of the circuit. I would like to be able to place the components onto any board at depending on how they fit best and not make that decision at the svhematic level.
-
Hmmm. Well I think I would do it differently. I would have (simplistically):
CAD showing how the PCBs fit (and in what they fit).
PCB overlay showing where components are on each PCB.
Schematic showing the circuit for each PCB.
Schematic showing how each PCB is connected to the others.
If appropriate, a block diagram showing the functional blocks and which PCB they are on.
The PCB schematic documents the PCB. It seems to me the reason you don't want that is because you prefer to make it up as you go along; you don't know where things are going to go until you place them. I think that's not the way to do design, and it's certainly not the way to document a design - when you or someone comes to fix them, how will they match something on the schematic to which PCB? Or vice versa: what the hell does this PCB do?
I think your approach would be like having the text of all man pages stuffed into one document without any of the command names. But, having said that, whatever floats your boat
-
When dealing with board-to-board connectors, my approach to limit errors and make things easier is just to create custom symbols for said connectors, with text for the pinout near each pin.
Make its incredibly easier to not screw up the schematics, and can be reused as many times as wanted without having to look at the pinout on a separate document everytime.
Simple and effective.
-
Here is how I ended up doing it.
I first further decomposed the schematic so that no sheet spans more than one board.
Note that due to lack of space I had to relocate components on separate boards until things fit in the available space.
There was no way to know ahead of time which component goes on which board beforehand, so there go any top-down "just decide where your stuff will be placed before you start" design fantasies.
I then replaced all the global nets with hierarchical labels. This applies especially to all power nets (3V3, 5V, GND, etc.). This was excruciatingly boring and took a long time to do manually, about half a day or 8 hours. (Maybe one day I'll write some code to parse the schematic S-expressions in a real language to be able to do that programmatically next time.)
Then I connected the connectors of each board to the subcircuits of that board only.
In the end you get for example four ground nets PCB0/GND, PCB1/GND, PCB2/GND, PCB3/GND, four 3V3 nets PCB0/3V3, PCB1/3V3 etc.
I made good use of the menu option that allows you to mass-convert labels from one type to the other (e.g. global to hierarchical.)
Once I did that I was able to finally see that needs to be routed in the PCB editor rat's nest.
One important thing that was useful is that I used local labels to connect connector pins to subcircuit pins.
I wasn't able to use a sheet for defining the connector pinouts, KiCAD was complaining about multiple labels per net, but maybe there is a way to do it using local labels.
A few improvements to KiCAD come to mind though:
- Power symbols that create local, not global nets. This way you can have ground symbols that look like ground and not just a square box with a "GND" sign as seen below.
- Selection filters in the schematic editor to select only local/global labels, only power symbols, etc. That will make the job of extracting subcircuits and making them into sheets not using global nets much easier.
- An option for automatically invoking and laying out the pins of a hierarchical sheet instance
- An option for sorting the above
- Another option for automatically updating the pin directions (in/out/bidirectional) even if it's just cosmetic