Difference between revisions of "KiCad without eeschema or cvpcb"
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
__NOEDITSECTION__ | __NOEDITSECTION__ | ||
− | [[category: | + | [[category:support]] |
− | |||
− | |||
Normally, KiCad netlist- and footprint-assignments files (<code>.net</code> respectively <code>.cmp</code>) are generated by the KiCad GUI-tools, and then serve as input for its layout-program, ''pcbnew''. | Normally, KiCad netlist- and footprint-assignments files (<code>.net</code> respectively <code>.cmp</code>) are generated by the KiCad GUI-tools, and then serve as input for its layout-program, ''pcbnew''. |
Latest revision as of 12:49, 6 December 2015
Normally, KiCad netlist- and footprint-assignments files (.net
respectively .cmp
) are generated by the KiCad GUI-tools, and then serve as input for its layout-program, pcbnew.
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.
Contents
Introduction
The normal workflow in KiCad is roughly as follows:
- make schematic
- generate netlist out of schematic
- assign footprints to netlist-components
- read netlist and module-assignments into layout-program
- place components and make layout
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.
Learn by example: a minimal schematic and layout
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!
Original schematic
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.)
Trimming the resulting netlist
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 'components
' 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 ('footprints
) 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 be omitted.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.)
Trimming the footprint-assignments file
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 netlist- and footprint-assignments files into pcbnew
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 (e.g. 'GND
'), this name would have been visible instead.