Hi fusesoc team,
I've been poking around fusesoc for a couple of small analog / mixed-signal projects I'm working on and I got curious about how to drive a flow from a schematic or a SPICE netlist rather than HDL. The data model takes a file_type so technically you can list a .kicad_sch or a .cir in a fileset, but I couldn't find a documented path that takes it the rest of the way. I also caught @olofk 's Latch-Up Waterloo talk where he touched on this kind of direction.
Locally I've got something working for the KiCad → SPICE → ngspice case:
- autotype filter learns .kicad_sch → kicadSchematic, .kicad_pcb → kicadPcb, .cir / .spice → spiceSource. .sch and .sp are intentionally not mapped (both ambiguous across tools — gschem / Cadence / OrCAD for .sch, HSPICE model libraries for .sp).
- A reference kicad_to_spice generator wrapping kicad-cli sch export netlist --format spice. It produces a spiceSource core and (optionally) splices ngspice_print / ngspice_control directives in so ngspice -b actually emits output.
- An Edalize ngspice backend consuming the spiceSource and running ngspice -b.
- Three worked end-to-end examples (rectifier, Sallen-Key low-pass, laser-diode driver) producing physically-correct waveforms / Bode plots.
The structure is deliberately narrow — same generate: → .core pattern fusesoc already uses for HDL, just with a non-HDL input. If the direction is interesting the same shape can be extended to gschem / lepton-eda, Allegro, OrCAD, Xyce, LTspice batch, etc. as separate generators.
I wanted to ask you:
- Is this a direction you want to encourage in-tree? Or would you rather the generator + examples live in fusesoc-cores and only the file_type vocabulary land in fusesoc itself?
- file_type schema: I tried a closed enum first and it rejected legitimate third-party spellings (LPF, QSF, eblif, …). Pulled back to pattern-only with the canonical names documented. Preference?
- Edalize ngspice backend is on the tool API today (that's what fusesoc's edalizer consumes). Worth porting to the flow API now, as a follow-up, or is a SPICE simulator a different layer entirely in your head?
- Naming gut-check on kicadSchematic / kicadPcb / spiceSource / spiceLib and on the ngspice_print / ngspice_control generator parameters.
Apologies for the lengthy issue, I'd be happy to share the branch if it'd be useful.
Cheers,
Polykarpos
Hi fusesoc team,
I've been poking around fusesoc for a couple of small analog / mixed-signal projects I'm working on and I got curious about how to drive a flow from a schematic or a SPICE netlist rather than HDL. The data model takes a file_type so technically you can list a .kicad_sch or a .cir in a fileset, but I couldn't find a documented path that takes it the rest of the way. I also caught @olofk 's Latch-Up Waterloo talk where he touched on this kind of direction.
Locally I've got something working for the KiCad → SPICE → ngspice case:
The structure is deliberately narrow — same generate: → .core pattern fusesoc already uses for HDL, just with a non-HDL input. If the direction is interesting the same shape can be extended to gschem / lepton-eda, Allegro, OrCAD, Xyce, LTspice batch, etc. as separate generators.
I wanted to ask you:
Apologies for the lengthy issue, I'd be happy to share the branch if it'd be useful.
Cheers,
Polykarpos