A few months ago, there was a discussion thread about editing/creating netlists directly as input for PCBNEW. I’ve been working on a Python package called SKiDL for doing just that. You can read about it here. You can install it here. You can hack it here.
Here’s a short list of its features:
Has a powerful, flexible syntax (because it is Python).
Permits compact descriptions of electronic circuits (think about not tracing signals through a multi-page schematic).
Allows textual descriptions of electronic circuits (think about using diff and git for circuits).
Performs electrical rules checking (ERC) for common mistakes (e.g., unconnected device I/O pins).
Supports linear / hierarchical / mixed descriptions of electronic designs.
Fosters design reuse (think about using PyPi and Github to distribute electronic designs).
Makes possible the creation of smart circuit modules whose behavior / structure are changed parametrically (think about filters whose component values are automatically adjusted based on your desired cutoff frequency).
Can work with any ECAD tool (only two methods are needed: one for reading the part libraries and another for outputing the correct netlist format).
Takes advantage of all the benefits of the Python ecosystem (because it is Python).
A text-based, programming language philosophy eliminates many of the problems we deal with here on a daily basis: parts that don’t align with the grid, wires that look like they connect to pins but they don’t, buses that don’t really work, what the heck are the differences between global-local-named nets, how to re-use a subcircuit in more than one design, etc.
Wow, that’s looking cool.
Some minor suggestions -
Can generate_netlist have the NET format name included ?
I can see this being used across many NET formats, including of course, kiCad.
I find this harder to scan visually ERC WARNING: Unconnected pin: POWER-IN pin 2/VSS of PIC10F220-I/OT/IC1.
so maybe put the pin NumName first ?
ERC WARNING: Unconnected pin: 2/VSS POWER-IN of PIC10F220-I/OT/IC1.
Other comments -
Somewhat related to this, I have a small Python script that can export NET info from PCB-New.
Currently in test format, it exports in Mentor PADS Net format, in order to give an integrity pathway check for PADS -> KiCad translator
Yes. SKiDL has a master netlist generator and then sub-generators for each type of netlist it will support. (Reading part libraries works the same way so SKiDL could pull parts from several types of ECAD tools.)
Yeah, that’s easy.
Right now I’m working on a KiCad NET to SKiDL converter so you can design small blocks of circuitry with EESCHEMA and then turn those into Python files that can be used in larger SKiDL designs.
You could also add some simple naming rules to SKiDL, to allow Append Board type merge ?
(Mentor has a similar ASCII-In Superset feature)
Provided there are no collisions on RefDes, and local net names are unique, and common net names are agreed on (GND,+5V etc) this append/merge should work well.
I think that just needs a RefDes offset (eg R100+, rather than R1+) and some unique local-net-name seed ?
I was assuming the appended board would be in KiCad netlist format. If we wanted to merge arbitrary netlist formats then, yes, we would need some way to convert them into a canonical netlist format. But once in that format, just a simple program to insert the components and nets and SKiDL would probably handle it. You would probably want some control on when SKiDL keeps similar nets separate with a rename or when it merges them.
Now that I’mthinking about it, you could convert an arbitrary netlist into SKiDL code and then just execute it at the end of another SKiDL program. That would effectively merge the netlists.
Yes, that was what I was suggesting with the unique local-net-name seed suggestion above.
I’ve seen things like prefix $$$ or NN used to denote ‘local nets’, and anything else is considered global/common (GND etc)
This does vary by CAD tool, which is harder to manage.
I was thinking user offsets/seed would be simpler, and not require too much additional work in SKiDL, but be workable in most use cases I can imagine.
Yes, I see now. We could use either offsets or prepend a unique string onto refdes and net names to disambiguate. In any event, yes, appending one netlist to another with controllable merging is possible.
I’ve released SKiDL 0.0.3. The major change is the inclusion of the netlist_to_skidl command-line utility that converts a netlist output by KiCad’s EESCHEMA into a Python/SKiDL script. That’s useful when converting existing designs or crafting small building blocks for inclusion in a larger SKiDL-based design.
Once again, read about it here, install it here, hack it here.
I’ve released SKiDL 0.0.4. The major change is that the netlist can now be output in XML format. This allows external tools (like BOM generators) to work with SKiDL-based designs. I’ve tested it using KiCost to generate costing spreadsheets for some of my designs.
@devbisme I want to use skidl but I’m worried about possibility of refactoring. What happens when I change the script, create a new netlist which has different designators and import into pcbnew? I’m thinking that it will break the circuitry if I do that. Do you have any suggestions to prevent this from happening?
You’re right. SKiDL scripts don’t have a way to store a unique, unchanging code for each netlist component so it can always be associated to a component in the PCB layout. KiCad schematics assign a tstamp to each component for this purpose. I can’t do that with SKiDL because it generates the netlist anew each time the script runs. There’s no place to store tstamp-like objects in the script (particularly for iteratively-instantiated components). The only tentative solution I’ve come up with is to do graph-matching with the previous netlist and then relabel the new netlist to preserve the pseudo-tstamps from the old one.
The Xorn project by Roland Lutz is a python library designed to allow manipulation of schematics, netlists and other EDA data; it may be relevant/of use, since code exists in the wild to export gEDA data to eeschema netlist formats.
