P.S. If there is interest I will look to document my workflow.
It would be like suggesting that there is no point having LaTeX perform typesetting because the research takes so long anyway and you like typesetting your documents. I personally would rather spend that time doing something else and let the machine get on with it.
I'll coin a new term here to classify this kind of problem: NP-incomplete. A problem that's known to be NP-hard, and is actually now impossible because you the program doesn't have all the information it needs to solve the problem.
To properly route a board, the tool would need to know what kinds of loads are at each end of a net, how thick the trace needs to be, where the return path for the current loops involved are, the edge transition times of all signals on the board.
You have to know not to route delicate high-impedance signals next to high dV/dt power traces, how to properly split and combine ground planes, how to respect creepage/clearance requirements for voltage isolated systems, etc.
About the best we can do today is to use autorouting for not-so-critical traces after the work for everything else is done, and even then it only really works well when you have PCB area to spare. In the worst cases, like some 2-layer boards, an autorouter will inappropriately chop up your ground plane with the traces it needs to route and turn what was a good board with solid return paths into a poorly routed mess.
The reason autorouting sort of works in VLSI devices is because all of these requirements are baked into the tools themselves. Every signal has a timing requirement, an impedance requirement, fanout limits, etc. When you are only dealing with digital logic, it makes the job much easier.
It turns out that manually programming paths to account for those issues actually generate hundreds of saved production hours per year.
With 80% of my time being just the data sheets, application notes, and component selection.
It's really remarkable just how little time I put into the actual mechanics of building a PCB vs. everything prior to that.
The jitx folks used to talk a lot about making test jigs and adapters for people, which is a simple enough application that a text-based system could really shine at.
Boards with power circuits and micro-controllers. I'm not sure I would trust the routing software when it comes to a high-speed bus or radio just yet.
> There was no easy way to combine schematic and skidl-based circuits. This was a problem at a company environment where design reviews become impossible because nobody else could write their heads around a power converter circuit made in skidl.
You can output a schematic: https://devbisme.github.io/skidl/#svg-schematics
I haven't got a solution for half-and-half skidl and KiCad designs.
> I really like KiCad's backannotation feature for adjusting BGA fanouts and whatnot from the layout.
I've not tried this so can't comment on it.
It depends what your background is. For example, to wire up a header to an ATmega328, I wrote this:
micro = Part("MCU_Microchip_ATmega", "ATmega328-A")
micro.footprint = "TQFP-32_7x7mm_P0.8mm"
u_head = Part("Connector", "Conn_01x32_Male")
u_head.footprint = "PinHeader_1x32_P2.00mm_Vertical"
for x in range(32) :
micro[x + 1] += u_head[x + 1]
> [..] unless you already have a schematic (which seems redundant).
It can also output schematics. So you're just working on the skidl Python file.
> Freerouting seems like a good way to iterate quick solutions to routing approaches, but obviously has a lot of limitations.
Of course, I personally wouldn't use it for a high-speed bus or radio circuit, but otherwise it is quite reasonable.
There is a generate_pcb() function in SKiDL that will output a kicad_pcb file that can be directly opened using PCBNEW (no need to generate the intermediate netlist file). That function uses HierPlace to group the parts based on their hierarchical organization. That would be a good place to inject some autoplacement if you get it figured out.
As a software guy who occasionally does a test or automation fixture, I find the workflow of most EDAs a bit strange. It seems to actively discourage reuse.
Everyone seems to have their own stash of footprints and known good circuits.
I'd love a Footprint Club that looks at what people have been making for themselves, accepts submissions, and cleans them up the popular ones for upstreaming. Hmmmm.
Unfortunately even professional EEs struggle with using standardization to their advantage, I have found. Partly this is vendors' fault as they don't make things clear at all. Partly it's just a nice competitive advantage for me and my employer as we spend far less time on footprints and have far fewer footprint errors, so I guess I shouldn't squawk too loudly....
Is it documented and traceable now? It didn't seem to be last I looked, but I admittedly didn't look too hard (I've been using Altium for years). This is critical for a standard library: parts need to be compliant with standards (usually IPC-7351 plus the mechanical standard for that part), they probably need to be put on a grid (and it should be the same grid for all parts), and things need to be documented to the point that I can trace where that footprint came from, why it has the dimensions it does, and what it's good for. None of this is all that nasty, but it's the difference between "Footprint Club" and "Standard Library". Oh, and you probably need to record usage, since something that's been hand-assembled once is very different than something that's been used in production a couple million times.
> manufacturers just puke out special footprints for any random thing
Tell me about it! That said, familiarity with the standards will let you conclude that many things that look like they kinda-might-be standard but aren't obviously listed as such actually are standard things. This is key to saving time with a real standard library. (Diodes are the worst offenders here. The worst.)
> You've just got to make it, period.
Also known as "the refrain of the connector". Fuck connectors.
I'll see what I can do to write it up.
> As a software guy who occasionally does a test or automation fixture, I find the workflow of most EDAs a bit strange. It seems to actively discourage reuse.
Being able to re-use Python code sections is obviously quite cool.
I don't yet have a good solution to footprints, but slowly but surely getting there with the tooling.