Thread by @AlexRBucknall

Someone says design a PCB, you'll think of an engineer opening up a datasheet, looking at the application notes, picking their components and starting the process of assembling a schematic, aka the behavioural arrangement of how all these components connect to each other [cont.]

Once behaviour has been grouped and assigned hierarchy (e.g. power, connectors, etc.) you have a schematic ready to be turned into a netlist. This netlist contains all the connections of the components, the wires between components as well as description of behaviour. [cont.]

Next comes layout, where the netlist is imported, physical footprints are associated with the netlist components, the physical shape of the PCB is defined and components are placed onto various layers of said PCB. This requires some thought given to it... [cont.]

You might place your connectors on the edges of the PCB, perhaps larger ICs like microcontrollers and FPGAs need to be given room to be routed and mixed signal domains should be isolated to reduce noise and cross talk. Generally once components are place routing can begin [cont.]

Routing is a looong process. One of the most complex too due to effects on other components. You wouldn't route sensitive ADC traces right under your power circuitry! But routing patterns can loosely be constrained to a set of general rules that a designer will follow [cont.]

So after a grueling and tedious process, we finally have a described, placed and routed PCB ready to manufacture. We hit send, off it goes to the manufacturer where they are kind enough to pick and place components for us, albeit we did pay for that [cont.]

We get a PCB back and just as we start to think about testing, we notice it's 2021 and our microcontroller now costs £££. Do we really have to rethink our PCB and start the whole process again? Can't we automate this and reduce iteration time? After all time == money... [cont.]

This is a problem we've run into numerous times in the past year at @balena_io. We design and we build hardware but most notably we build software too. We automate almost every aspect of our software, from testing to releasing, why can't this happen for hw? [cont.]

Recently we've been experiencing with a workflow using a couple of FOSS tools; we've been experimenting with SKiDL for parametrically generating netlists and building up subassemblies of modules that can dropped in like npm or pip packages [cont.] github.com/devbisme/skidl

This lets us rapidly change and modify the physical behaviour describes by our netlist and as these packages of subcircuits grow, the more powerful it becomes. Suddenly it's as simple as asking for a Python function for an filter circuit and passing in your cutoff freqs [cont.]

We can then take these assembled netlists and place them onto a defined PCB using tools like pcbflow that allow you to easily import a netlist or even SKiDL modules and physically place footprints onto a PCB. Give it some constraints & away you go [cont.] github.com/michaelgale/pc…

While both SKiDL and pcbflow are not yet perfect, they go a long way to enabling programmatic and parametric workflows PCB design. Obviously that leaves the elephant in the room, autorouting... Ask any PCB designer and be ready for their strong opinions [cont.]

Autorouting generally sucks, there's no hiding that fact. Historically it's been a cheap gimmick and overlooked due to its failures to match a humans ability to route traces. This doesn't mean open tools like Freerouting should be discounted... github.com/freerouting/fr… [cont.]

Freerouting, one of the few if only open source autorouters, is very basic. This doesn't mean that it's incapable however. Constraining and pushing an autorouter in the right direction can drastically help behaviour. One technique I've come across is river routing... [cont.]

River routing is a technique where traces are grouped together and flow like a river and branch off with grouped behaviours, e.g. you might group an SPI bus from an MCU. You can imagine this happening during the pcbflow stage of design to push... [cont.] tinyletter.com/jamesbowman/le…

... the autorouter into the right direction. While this might not solve for things like differential high speed traces, you can start to see how we can push tools like this to achieve automations that just currently don't exist for this traditional workflow [cont.]

Least to say if we can get this close to solving for an automated end-to-end PCB, we can turn this into an ML problem and start to think about how this could be fed into a neural network and run over and over again tweaking parameters as we go to optimise for X Y or Z [cont.]

Build in pre-manufacture simulation and testing for things like your analogue subcircuits using Pyspice, why can't we have a feedback loop where we run a design through a learning loop where we optimise for power, cost, component availability or even all three? [cont.]

Given that we're already doing the testing and releasing as part of our software workflow, why cant that be applied to hw? Attach a physical manufacturing step to your pull request workflow and get PCBs built and tested before you pass your CI checks and merge [cont.]

This is only beginning to scratch the surface for what this process could look like and how optimizations might work but it's something we're super excited about at balena and we want to have this discussion in a public forum. What other tools do you know about? [cont.]

We've also been thinking through the idea of isolating design and manufacturing dependencies with @alexandrosM with discussion of tools like the Voltera to supplement voltera.io/store. I'll continue to add to this thread as the discussion grows.

I wrote some of our discussion up for you @rahulthakoor 😛

This workflow extends beyond just the PCB; we can even generate physical cases for our newly generated PCBs. There a bunch of tools that let you programmatically manipulate 3D model. The Python framework CADQuery, github.com/CadQuery/cadqu…, is one of these tools [cont.]