Ehh, more than 90% of my time making a board is in reading data sheets & Application notes, making a schematic, component selection, component library building, and part placement. Routing is the easy part and relaxing enough that I like doing it myself.

Sure, some parts are obviously a manual process and hard to automate. But this is about automating the parts than can be automated.

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.

No, that's a bad analogy. A circuit board is not something that gets re-built every time you make a change. You can't just arbitrarily run traces around a board and expect a working design that meets EMI/EMC requirements.

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.

Interesting. I used to program CNCs (lasers and punching machines) for automotive parts. We couldn't rely on the path planner either. If the punching machine's turret ran too close to the clamps, it would crash and put it all out of alignment. There goes a day of production. The planner assumed all material was rigid, but when perforating thin material that wasn't the case. You'd end up with corners bouncing up into the turret that get caught and crumple the sheet metal like paper. The third issue happened when the auto path wanted to change tools multiple times.

It turns out that manually programming paths to account for those issues actually generate hundreds of saved production hours per year.

I agree. PCB layout itself is pretty fun and easy to do manually for any hobby sized projects. Making components is the tedious part. I wish there was some kind of standard component format that could be embedded into datasheet PDFs or something. Maybe as a QR code.

> Ehh, more than 90% of my time making a board is in reading data sheets & Application notes, making a schematic, component selection, component library building, and part placement.

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.

What kind of boards are you making? I used skidl a lot but I ran into two challanges, wondering if you have run into these also: 1) 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. Ideally I would have wanted to be able to drop in a "skidl-block" that would just have a fabric of a bunch of digital connections, and let analog circuits remain as graphical schematics. 2) I really like KiCad's backannotation feature for adjusting BGA fanouts and whatnot from the layout. It is really fast and makes doing layout much more pleasurable (that is a standard feature also in all the big name commercial ECAD suites). Using skidl broke my backannotation flow, at least that was the case ~6 months ago which is the last time I used skidl.

> What kind of boards are you making?

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.

> You can output a schematic I've been working on a branch of SKiDL that outputs schematics that can be directly opened using KiCad's EESCHEMA. That will allow some capabilities SVG figures don't allow.

I'm not really sure who the target market for things like skidl and jitx is: people who think schematic capture is a laborious, tedious, and error-prone technique for entering data before you can get started on a layout, instead of a useful documentation step that will yield dividends over the lifecycle of your design?

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.

I genuinely applaud any file format that can be diffed, but skidl seems like an absolutely painful way to develop a circuit - unless you already have a schematic (which seems redundant). Freerouting seems like a good way to iterate quick solutions to routing approaches, but obviously has a lot of limitations.

> I genuinely applaud any file format that can be diffed, but skidl seems like an absolutely painful way to develop a circuit - [..]

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]

Suddenly you see how powerful it can be when you programmatically hook things up together.

> [..] 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.

Yikes at those strings. Would be much better as enums; would enforce it's a valid selection, your IDE could help etc.

kicad schematic has a repeat/increment mechanism (insert key by default. I map mine to "."). Making this task surprisingly quick and painless.

I'd like to see documentation on your workflow. You can also post it on https://github.com/devbisme/skidl/discussions.

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.

I'm definitely curious.

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.

Yeah, because making a good footprint suitable for upstreaming is so laborious, and categorizing it is just as important as making it in the first place, most folks who find themselves needing a footprint just whip one out for the job at hand and it's "good enough" and they reuse it forever, even though they'd be ashamed to share it.

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.

No, there needs to be a footprint standard library. Three dozen or so standard footprints, drawn rigorously to standards, will cover tens of thousands of parts. (I'm talking things like EIA/IEC standard chip parts, JEDEC and JEITA transistors, diodes, and ICs, etc. Connectors not included!) Make that, rigorously and with documentation and traceability, and you can design boards fast and with great confidence in their manufacturability.

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....

There is a standard library and it's quite good, but manufacturers just puke out special footprints for any random thing. Often for good reasons, but often not, and it really doesn't matter if you need one in your design. You've just got to make it, period.

> There is a standard library and it's quite good

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.

There are parts libraries if you work in a company (there would be a whole division devoted to building components) so that internally there is a ton of (mandatory) reuse.

> I'm definitely curious.

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.