Roadmap for pykicad

[dvc94ch]

What are you planning on using pykicad for? Adding schemas for the other file formats or the parts you are planning on using should be straight forward...

@wez @lukecyca

[dvc94ch]

I'm going to change the original scope of the project. If someone wants to only use the file format support we can discuss how to accommodate this.

New scope and goals:

• port footprint generators from kicad (since they are really high quality) and add a couple of missing ones
• autoplace routine and computing footprint boundary box
• full pcbnew file format support
• drc checking
• extend footprint generators to generate 3D models
• integration with autorouting engine, probably this one [0] (should be useful for at least estimating the board size)

[0] https://github.com/StefanSalewski/Ruby-PCB-Router

[wez]

Here's what I need:

• Load footprints and schematics with full fidelity of the information in the source file. There's a few things that you Suppress that it would be good to pass through in some way. I don't need them in my code, but "worry" that leaving them out of the final pcb file will cause problems with the end result. There's a rust kicad parser that has a generic way to do this sort of thing

• I'm doing things like rotating footprints for myself. I'm using the shapely library for the transformations. I don't think that you need to support this in pykicad, but you may need to consider this when thinking about my next point.

• I'm assembling the PCB design using the pcbnew python module. I want to remove this dependency because it is buggy and incomplete. So I'd like to be able to compose a fresh PCB file using pykicad; I want to add my (potentially rotated) footprint instances, and I want to emit the areas, tracks and vias that I'm computing in my tools.

• since I'm importing pcbnew, I have to run the system python 2.x for this to work, which means that I have some nasty local patches to work around some python 3 unicodeisms. It would be great to make pykicad work out of the box on both python 2 and 3.

• DRC would be awesome and save me some work!

re: auto-routing, I've been looking at that ruby router code and at the paper referenced there this past couple of weeks. I'm building something that works within the constraints of the keyboards that I'm hacking on, but a full featured router is a huge effort. When I've gotten a little further along, I'll put the code I have up on github. I'd recommend tackling that later; I don't want to see pykicad get bogged down by an auto-router until after the other stuff is done :-) In the meantime, for auto-routing, I'd suggest adding support for the .dsn (export) and .ses (import for the routed result) files used by https://github.com/Engidea/FreeRoutingNew (those files also work with other commercial auto routers). That router does work and is being maintained by someone.

[dvc94ch]

I don't need them in my code, but "worry" that leaving them out of the final pcb file will cause problems with the end result.

This shouldn't be the case anymore. Since version 0.0.2 this should have been fixed... If you find a case where this isn't true it's a bug.

Load schematics with full fidelity of the information in the source file.

Can you provide more information? Are you using skidl to generate the file? Or are you thinking along the lines of the pin mappings from the libraries? The problem with those is that they don't use the sexpr format yet, but I think this is on the kicad roadmap and going to change in the near future. I'm not too bothered with supporting what is soon to be a legacy file format... I think most of the code for the new format is already in place.

[wez]

re: schematics, yeah, I'm using skidl. I blurred the line between skidl and pykicad when writing the above. Part of what I'm doing is loading the symbol data (via skidl), then I compute which of the pins are available based on a combination of the symbol data and the footprint data (both the purpose and physical position). I don't care too much where that information comes from, so long as I can get it. I currently get the symbol info from skidl and that's fine.

[dvc94ch]

I don't yet understand how that mapping works, so I've postponed doing anything there. But I think that should be handled in a different project.

My understanding is that the part library provides a list of pins and a list of footprints that work with those pins. But that seems to me like in most cases that doesn't work very well and you need a 1:1 mapping from the part to the footprint. The same chip in a different package usually has the pins in completely different positions no? So that means an FPGA for example from the same manufacturer, same family and same model needs multiple parts for the different packages?

My thought on handling this is that one FPGA from one manufacturer and family is represented by a circuit parameterized over it's resources. Once I've designed the circuit I want to find the cheapest available FPGA from that family that has the amount of needed resources. So then we'd have an Lattice_HX_FPGA(io=50, bram=8k) to represent the circuit. This is compiled to or amended with a package say BGA(x=40, y=40, pitch=.1) and a mapping [[io_0, bga_43], [io_1, bga_44]....]

[dvc94ch]

Added initial Segment and Via support, not sure yet on how ergonomic the API is...

[dvc94ch]

@wez how's your keyboard project going?

Just released pycircuit 0.0.1. If you like skidl I think you might like it. It's still early and missing support for ERC checking and importing footprints from kicad but it has a nice way of specifiying them in python. It exports circuits to graphviz and layouts to kicad and svg. It also supports importing modules from kicad. There is also support for delunay triangulation and shortest path queries for routing and half perimeter length queries for placement algorithms.

Exporting to spice and fpga toolchain integration are on the todo list but there's currently more important things :)

[wez]

ooh, very interesting, I'll play around with it!