Very interesting project! My understanding is that the circuits are human-validated hard coded modular blocks - is this correct? I didn't fully catch how PCB routing and placement is done. I haven't yet seen a credible from-scratch AI schematic design tool (though, admittedly, most of my projects are a mix of repeatable modules and custom circuitry... It would help to have a "known working" setup.)
Yep, exactly. I'll do another blog when I have a little more to show, but the concept is, everything is on a grid of 12.7mm squares, where there is a common bus running through north-south. The boards need to be 4 layer and feature size is pretty small, 0402 passives for example, maybe even 0201 if I'm really optimising for size.
SCH: https://github.com/MichaelAyles/heph/blob/main/blogs/0029-im...
3D bottomside: https://github.com/MichaelAyles/heph/blob/main/blogs/0029-im...
In the Phaestus workflow, it chooses modules, for example the main cpu block just has an ESP32C6-XIAO board on it, since it has massive compute, and radio with wifi6 and zigbee, which covers 90% of IOT. Since this is larger than 0.5" it sits in the middle of a 2x2, which bridges both sets of north-south buses, with all common pins.
Bidged pinouts: https://github.com/MichaelAyles/heph/blob/main/blogs/0029-im...
Early XIAO: https://github.com/MichaelAyles/heph/blob/main/blogs/0029-im...
It's been a pain in the butt to design for, since the vias need enough clearance, and we are almost maxed out on our bottom side, so on the 2x2's i've given it as much room as I can in the middle to allow for topside routing with a few vias.
Then, when assembling the board, it does a 0.1mm overlap n/s, which merges the nets, whilst the system keeps track of what signals are used, so I2C is all multiparticipant, spi1 gets the default CS line, otherwise it can use the aux pins via a resistor selector, the AUX5/AUX6 aren't connected to the XIAO, so if you wanted to do something like a USB power monitor, the power can run isolated at higher voltages, as long as they get fed through a current/voltage sensing block, which could be 1x1, 1x2 or 2x2.
As for component placing in the enclosure, buttons are sub-boards with a wire-to-board connector, and the 1x1 module is a block that contains a connector and an PCA9570, which allows the button to be placed anywhere with defined mounting features.
Similar for LCD's, the pre-designed block has a FFC connector, and comes with constraints, e.g. place at end of design, so the screen can fold back on itself, whereas if it was mounted in the middle, it wouldn't be able to go where it needs to be.
For AI designed schematics, you need to check out flux.ai (and quilter for layout), I don't have anything to do with this, i'm a little jealous tbh, but having used it, it's not for me (but i'm making fairly complex, FuSa, type approved stuff, for the sorts of boards that would go into phaestus, it would probably be adequate)
I'm pretty in the weeds when it comes to this stuff,
First of all, I made https://www.circuitsnips.com/ , which is like thingiverse for circuits, so users can get bits of designs and copy and paste them into their own designs, but the reception was lukewarm at best, it needed bootstrap data, for which I scraped GH, which could have been a mistake, either way, for the tens of people using it, I think it's pretty neat!
Circuitsnips Blog:https://www.mikeayles.com/#circuitsnips-com Circuitsnips GH:https://github.com/MichaelAyles/kicad-library
So, then I created a fork of TOON, called TOKN, which is token optimised KiCad notation, which successfully compresses kicad schematic s-expressions by 93%, and is able to regenerate schematics from it. With the intention of trying to generate schematics, one shot them using frontier models, or even post-train an OSS model to see if that works, however when I benchmarked it, I could get 100% syntax validity, but the models hallucinated the components, the pins etc, so they would need grounding.
TOKN Blog:https://www.mikeayles.com/#tokn TOKN GH:https://github.com/MichaelAyles/tokn
Which brings me onto my next, next, (next?) side project: An embedded documentation MCP server!, Load in your PDF's, it parses them and puts things into a sqlite db that the LLM can interact with more efficiently. I mainly use it for writing hardware abstraction layers for chips that have terrible vendor support (looking at you, NXP KEA128). Honestly, everything about this chip is awful, even the GPIO is laid out terribly, it's like the meme where everything gets put in the square hole. PORTB? nah, you need to do PORTA + 16. Anyway...
Bitwise-MCP Blog:https://www.mikeayles.com/#bitwise-mcp Bitwise-MCP GH:https://github.com/MichaelAyles/bitwise-mcp
And if you've read this far, here's a little treat:
https://www.mikeayles.com/#kidoom-featured