OK… as pointed out, my 1st attempt at a video is less than stellar! Sorry to those who suffered through it!
Never-the less, I did what to share my approach for implementing hierarchical symbols (symbols that are attached to schematics) in case it may be helpful to kicad developers working to implement this capability into a future release of Kicad. Perhaps it will provide a useful roadmap.
First, let me say, I did make an attempt at trying to do this within kicad code. Frankly, that is way beyond me. I am a chip designer, not a software expert. Also, everything I have done here is from the point of view of rf/analog chip design flow as it might look like using Cadence tools.
So here we go.
As truly excellent as Kicad is, a key shortcoming for my purposes is the capability to have hierarchical symbols with underlying schematics that can be kept in symbol libs for reuse across projects.
To solve this, I first reorganize the file structure for each kicad library, adding additional folders for schematics and spice circuit files as well as other folders for special purposes. These new folders hold schematics and spice netlists for the symbols that make up the particular library. This approach would look familiar to users of Mentor Dx Designer.
Here is an example for a symbol library folder for a set of spice simulatable behavioral cells within b_analog. Folder “sch” holds the schematics, “cir” holds the spice netlists, etc.
b_analog is the eeschema nickname for the symbol library b_analog.kicad_sym
Other library folders, say b_digital, b_pll are arranged in a similar way. In each case, the schematics for the hierarchical symbols are kept in the “sch” folder for the corresponding symbol library.
Here is an example of a behavioral rf library as it appears in the symbol editor. The shown symbol is a spice simulatable lc filter. The bandwith may be passed as a parameter into the schematic. The symbol as defined within it a “Typ” parameter that is set to “sch:” . This identifies the symbol as a hierarchical symbol and tells the spice netlister to look for and netlist the underlying schematic that is attached to it.
And here is the schematic that is associated with the filter symbol.
The above is a very brief description of how Ive organized the libraries for hierarchical design. Keep in mind that this does not work with standard kicad spice netlisting. I have had to write my own hierarchical spice netlister outside of Kicad to implement this capability. At some point Id like to make this available or perhaps Kicad will have something like this in the near future.
Continuing on a bit, here is the top level test bench schematic shown in the video.
This has a variety of symbol “typ” 's in it. "sch: type symbols have underlying schematics. “net:” type symbols point to text based spice netlists kept in various libraries that are accessed during simulation.
It is desirable to transverse the design hierarchy and open underlying schematics. I do this through the Confirma analog simulation cockpit via a hierarchy navigator. This is the left side panel with the “up” / “dwn” buttons. The “sch” button opens the schematic selected in the symbol list.
The re-netlist/Fast Netlist buttons to the right activates the hierarchical spice netlister. The resulting netlist is displayed within one of the tab windows in the middle. “Sim Netlist” sends the netlist together with any reference libraries, foundry libraries, etc to the chosen spice simulation engine. The spice engine may be topspice, ngspice, qspice, ltspice, smartspice, eldo and even spectre, whatever the user decides to plug into the framework.
The Confirma framework has been in use for a long time but with Mentor Dx as the schematic capture front end. Mentor has become difficult to work with and this is what has driven the effort to use Kicad. A big plus is that, with Kicad, you will never lose access to your schematic IP.
Finally, although the focus is on chip design, this flow also works well for system development. With enough spice simulatable behavioral components, it is fairly straightforward to put together systems as you would in matlab/simulink. Spice is actually a great simulator, especially that ngspice now that I have had a chance to use it a bit. Bravo to that Holger guy!
All for now… Kevin