Normally, KiCad netlist- and footprint-assignments files (
.cmp) are generated by the KiCad GUI-tools, and then serve as input for its
However, they can also be programmatically or manually generated, to avoid having to touch Eeschema and CvPcb in cases where a schematic doesn't make much sense (e.g. when generating the connectivity-info programmatically instead of interactively).
This whole page is mainly a reminder to myself.
The normal workflow in KiCad is roughly as follows:
However, by creating netlist- and footprint-assignments files yourself, you can effectively replace the first 3 of these steps. The fact that all KiCad interchange-files are plaintext makes this particularly easy.
To illustrate, a simple schematic is drawn in Eeschema, and the
resulting netlist and footprint-assignments (
.cmp) files are then
simplified and read into pcbnew to verify they can still serve
as input for the layout-phase.
The idea is that these simplified files could also be easily created by hand. (Actually doing this is not described here; only the possible simplifications are shown.)
DISCLAIMER: This is a very ad-hoc approach (trial and error). To be honest, I don't have enough confidence in current file-format docs.
DISCLAIMER #2: I think the KiCad version I use here (2013-may-18 stable) is severely outdated, so file-formats and workflow may have changed drastically since then.
...but now, back to happy thoughts!
The following schematic is used as starting-point:
Although not visible here, the junction between R1 / C1 / Q1 consists of R1 pin 2 (bottom-most pin of R1), C1 pin 1 (top-most pin of C1), and Q1 pin 1. These pin-numbers will occur in the netlist generated by Eeschema.
Although completely useless, this schematic happens to pass ERC. However, when creating netlists manually or programmatically, ERC does not apply - a netlist in this context is basically a graph without semantics - be warned. (It's easy to create connectivity-info that can serve as input for layout just fine, but violates ERC - e.g. a single net being driven by different outputs.)
Below follows a side-by-side comparison of the corresponding netlist generated by Eeschema (left) "the normal way", and one just like it, but stripped of unnecessary details (right).
(In the diff, '
<' indicates a line in the priginal files has been removed; '
indicates a line was left as-is, and a '
@' indicates a line was changed.)
Footnotes follow to describe each simplification.
1 (export (version D) 1 (export (version D) (A) 2 (design < 3 (source /tmp/kicad/test.sch) < 4 (date "Sun 25 Oct 2015 12:42:19 AM CEST") < 5 (tool "eeschema (2013-may-18)-stable")) < 6 (components = 2 (components 7 (comp (ref Q1) = 3 (comp (ref Q1) (B) 8 (value NPN_ALT) @ 4 (value NPN_ALT)) (C) 9 (libsource (lib michai) (part NPN_ALT)) < 10 (sheetpath (names /) (tstamps /)) < 11 (tstamp 562C083B)) < 12 (comp (ref R1) = 5 (comp (ref R1) 13 (value R) @ 6 (value R)) 14 (libsource (lib michai) (part R)) < 15 (sheetpath (names /) (tstamps /)) < 16 (tstamp 562C084A)) < 17 (comp (ref C1) = 7 (comp (ref C1) 18 (value C) @ 8 (value C))) 19 (libsource (lib michai) (part C)) < 20 (sheetpath (names /) (tstamps /)) < 21 (tstamp 562C0859))) < (D) 22 (libparts < 23 (libpart (lib michai) (part C) < 24 (footprints < 25 (fp SM*) < 26 (fp C?) < 27 (fp C1-1)) < 28 (fields < 29 (field (name Reference) C) < 30 (field (name Value) C) < 31 (field (name Footprint) ~) < 32 (field (name Datasheet) ~)) < 33 (pins < 34 (pin (num 1) (name ~) (type passive)) < 35 (pin (num 2) (name ~) (type passive)))) < 36 (libpart (lib michai) (part NPN_ALT) < 37 (fields < 38 (field (name Reference) Q) < 39 (field (name Value) NPN_ALT) < 40 (field (name Footprint) ~) < 41 (field (name Datasheet) ~)) < 42 (pins < 43 (pin (num 1) (name ~) (type input)) < 44 (pin (num 2) (name ~) (type passive)) < 45 (pin (num 3) (name ~) (type passive)))) < 46 (libpart (lib michai) (part R) < 47 (footprints < 48 (fp R?) < 49 (fp SM0603) < 50 (fp SM0805) < 51 (fp R?-*) < 52 (fp SM1206)) < 53 (fields < 54 (field (name Reference) R) < 55 (field (name Value) R) < 56 (field (name Footprint) ~) < 57 (field (name Datasheet) ~)) < 58 (pins < 59 (pin (num 1) (name ~) (type passive)) < 60 (pin (num 2) (name ~) (type passive))))) < (E) 61 (libraries < 62 (library (logical michai) < 63 (uri /home/michai/proj/046/lib/kicad/michai.lib))) < 64 (nets = 9 (nets (F) 65 (net (code 1) (name "") = 10 (net (code 1) (name "") 66 (node (ref Q1) (pin 1)) = 11 (node (ref Q1) (pin 1)) 67 (node (ref R1) (pin 2)) = 12 (node (ref R1) (pin 2)) 68 (node (ref C1) (pin 1))) = 13 (node (ref C1) (pin 1))) 69 (net (code 2) (name "") = 14 (net (code 2) (name "") 70 (node (ref Q1) (pin 3)) = 15 (node (ref Q1) (pin 3)) 71 (node (ref R1) (pin 1))) = 16 (node (ref R1) (pin 1))) 72 (net (code 3) (name "") = 17 (net (code 3) (name "") 73 (node (ref Q1) (pin 2)) = 18 (node (ref Q1) (pin 2)) 74 (node (ref C1) (pin 2))))) = 19 (node (ref C1) (pin 2)))))
A: the '
design' section seems to contain schematic properties like name,
date and creator-program, and can be removed entirely.
B: within each '
comp' (component) subsection within the '
section, the '
value' property is optional.
This property controls
the resulting component-value in the layout-phase. (The footprint-assignments
file has a similar '
ValeurCmp' property, but as far as I could see, its presence
has no effect on the component-value in the layout-phase.)
In this example, the '
value' property is left intact. It could be omitted from
the netlist-file, which would result in components not having a value in the
layout-phase, only a refdes.
C: the other properties in each '
comp' subsection contain a reference to
that component's entry in the symbol-library, location in schematic and
a timestamp. All of these properties can be safely omitted for our purposes.
D: the '
libparts' section contains for each component a footprint-mask ('
to allow CvPcb to filter likely footprints, additional symbol-fields
fields') and pin-semantics ('
pins') to allow for ERC. This whole section
can be omitted.
E: the '
libraries' section contains paths of used symbol-libraries, and can
F: within each net-description, the '
name' property is mandatory, but can
be set to the empty string as shown above, causing the numeric net-code to be
displayed in the layout-phase instead of a given name. (When supplying a name (e.g.
GND' for the ground-net), this given name takes precedence.)
Below follows a side-by-side comparison of the corresponding footprint-assignments file resulting from manually assigning footprints in CvPcb after reading in the above netlist (left), and a simplified version which can still be used as input for the layout-phase (right).
Again, footnotes follow describing each simplification.
(A) 1 Cmp-Mod V01 Created by CvPcb (2013-may-18)-stable date = Sun 25 Oct 2015 12:47:1 @ 1 Cmp-Mod V01 2 = 2 3 BeginCmp = 3 BeginCmp (B) 4 TimeStamp = /562C0859; < 5 Reference = C1; = 4 Reference = C1; (C) 6 ValeurCmp = C; < 7 IdModule = C_CER_4MM; = 5 IdModule = C_CER_4MM; 8 EndCmp = 6 EndCmp 9 = 7 10 BeginCmp = 8 BeginCmp 11 TimeStamp = /562C083B; < 12 Reference = Q1; = 9 Reference = Q1; 13 ValeurCmp = NPN_ALT; < 14 IdModule = SOT23EBC; = 10 IdModule = SOT23EBC; 15 EndCmp = 11 EndCmp 16 = 12 17 BeginCmp = 13 BeginCmp 18 TimeStamp = /562C084A; < 19 Reference = R1; = 14 Reference = R1; 20 ValeurCmp = R; < 21 IdModule = R_AXIAL_0W25; = 15 IdModule = R_AXIAL_0W25; 22 EndCmp = 16 EndCmp 23 = 17 24 EndListe = 18 EndListe
A: the header could be shortened to '
Cmp-Mod V01'. Omitting it altogether would result in
an error when reading in the netlist- and footprint-assignments files into pcbnew.
B: timestamps are hex
time_t seconds-since-epoch Unix timestamp-values, and
can be omitted altogether for our purpose.
C: as mentioned in the netlist-simplification above, the '
ValeurCmp' property serves no
purpose as far as I could see (but instead, the netlist-file's '
value' property does), so it
can be omitted.
Reading the above simplified netlist- and footprint-assignments files into pcbnew results in the following components and ratsnest:
(As can be seen, each component still has a value (although the transistor's value-field is marked 'invisible' in
the footprint itself - sorry, noticed this after making the snapshot :-). Omitting the '
value' property for each component
in the netlist-file will result in a blank value.)
Displayed component-pin numbers and numeric net-codes follow from the netlist-file. In case nets had been named
GND'), this name would have been visible instead.