Hi all… I have an idea for an alternative method of dealing with subcircuits (hierarchical sheets). I used to work at a startup for similar style software (though it focused on analog IC design), they had a rather nice way of dealing with hierarchy.
Simple explanation:
Design a circuit, add the hierarchy pins. Then create a symbol for the circuit, syncing the pins in the symbol with the ones in schematic. Add that to the library (project library or a global library?)
When you need the circuit in a new project, you can instantiate it, giving it a name starting with I (for “Instance”). Or whatever letter you wish. Then when netlisting you can use that name. Netlisting nets inside the subcircuit would have a name prefaced with the instance name. For example, if the subcircuit has a net named “BOB”, and there are two instances of the subcircuit, there would be two net, I1/BOB and I2/BOB. Also, for nets connected to pins, we’ll always use the shortest path name (because they really have two names for the same net. So if the main sch has ALICE as a net that connects to a pin (BOB) in the subcircuit, it would be referred to as ALICE in the netlisting (even though it could be referenced as I1/BOB). I suspect we’re already doing similar already with sheets. And you would do the same type if naming with the parts/circuits in the subcircuit. I2/I4/C7.
Any thoughts? If folks like it, I’ll add it as a feature request in Gitlab.
My experience is with system design, which is top down. You are advocating a bottom up scheme. I understand your experience building analog lib elements.
In a top down scheme a designer can insert a page for a power supply. Later in the lower level PS sheet he can insert a linear or smps, without regard for the top level design.
I, and I’m sure others, have a set of standard modules. This allows me to easily incorporate either a linear or smps, with fuse, monitors or whatever pre-built.
The problem with libs is everybody wants something different. How many types of 3 terminal regulators are there
Btw, adding it to gitlab doesn’t magically make it happen.
I see what you’re saying. I guess part of my issue is that I haven’t figure out ‘sheet management’.
And i was actually a programmer for said application. I’m not a circuit designer by any means. I’m just hobby playing with a Ben Eater CPU type design right now. I have a lot of repeating circuits, and I can never remember if I created a sheet for that particular circuit or not yet.
I get that adding a feature request doesn’t make it happen. As a software dev, I know it all too well
But at least the devs would be aware of it, and maybe discuss it.
This is the point of ‘instantiating it’. When you add it to your higher level schematic, it would get the name I?. Then everything in that instance would get the name I?/C4, I?/U9, etc. So even if you add it multiple times to your schematic, everything would have a unique name/path.
I dont think copy/paste is a reasonable/scalable solution.
I’m not trying to solve footprints, thats another whole topic (for me anyways)… I personally would love to attach multiple footprints to a symbol. Then during annotation, you would select which footprint you want. In turn, my solution for subcircuits, you could have multiple layouts/footprints. You wouldn’t have to use the footprint with the subcircuit, but it would be a cool option.
This seems to be the only difference from how KiCad currently works?
In V6 it should be possible to use the same hierarchical sheet in different projects. The sheet is however not added to a lib, you have to browse for it when adding it. But it doesn’t have to be located in the project library.
All the rest, with connecting pins, instance reference, net name and appending to references in the sheet seems to be described very similar to how it’s currently done in KiCad.
Design block also brings up some other threads on gitlab. For example in this issue, I already mentioned to add the ability to link a schematic sheet to a schematic symbol:
Paul - a good reference. I try to work similarly with standard modules (design blocks). It requires good design discipline.
I’ve intentionally chosen not to follow that exact path. Parts go obsolete or are difficult to purchase. Modules have to change. A change to 1 design block ripples to all other projects using that block. Which can become complex. That makes my aging mind hurt.
If you don’t mind my chiming in here, I can offer the method Mentor uses. Just about everything in there is done as text files. A “symbol” is a schematic symbol. What you’re calling a PCB footprint is called a “geometry”. You can work on schematics with symbols alone, but when you netlist and package en route to layout, you need another couple of files: The “map” file, which correlates the symbol with the geometry i.e. how many symbols (e.g. gates, connector pins, etc.) are in the device package and which symbol pins connect to which geometry pins. The map file also indicates which pins are swappable (e.g. the various inputs of a gate), and which symbols are swappable (e.g. the gates themselves) to ease layout. Finally, there’s the “catalog”, which is a one-line-per-part-number file that ties together the part number (i.e. your company’s internal, or DigiKey’s, or whatever) with the symbol, the map file, and the geometry. So if you’ve, say, laid down a through-hole DIP 7400 and want to change it to an SMT, you open up package, open the appropriate catalog, change the part number or geometry, then flow through packaging and back to layout.
I work regularly with design blocks in KiCad and I think the initial posters idea has potential to improve the workflow needed for it. As for now my workflow (with v5.x) is:
Copy the subsheet to the projects modules folder. This can be skipped if you directly link the file in your subsheet “library” but for me this was not really feasible as I use modules with trim components.
create a hierarchical sheet in kicad.
add the link to the submodule to the hierarchical sheet and a name.
import every hierarchical pin and place it where you want.
All of this could be skipped if there was a tool to place hierarchical sheets like symbols from a library. Of course its not really necessary but one could argue that the same steps are also skipped with the schematic symbol libraries. There are of course some open points which need a bit of thinking like:
should the hierarchical pins be freely movable for a library sheet? (I would argue yes)
how are modifications to the sheets handled? a local copy and link feature like for the v5 schematic symbols would work here.
I’ve played with Atanua - About a simple logic test and it has features that allow you to create new components from old. It is quite useful and worth looking at for ideas. On question though is about the footprint. If you created Subcircut do you create a footprint that goes with it?
It should behave like a primary symbol, i.e. can be associated with a suitable footprint. A wrinkle is what do you do about “internal” connections, do you expose them so that they can be routed normally or do you put tracks in the footprint?
