upstream
It feels like many weeks have been leading up to this. We’ve got what feels like half of the actual schematic done, the half focused on power as opposed to data. These power connections will allow little cloud to power its own systems, as well as supply power to downstream USB-chargeable worker devices such as smartphones and tablets. It was incredibly satisfying to actually lay this out neatly, section by section.
The power’s journey starts on the upstream USB charging port. It connects to any USB-C charger annotated PD25W or more, which is roughly the wattage it will draw to cover both internal systems and downstream chargees. First up, power reaches the CH224A power delivery controller, whose purpose here is to ask the charger for a default contract of +9V. It’s the first standard USB-PD voltage above +5V, and we want to stay above +5V to be able to derive every rail with uniform step-down converters. The CH224A will later be controllable by the F133-A System-on-Chip once that wakes up. When the PD controller manages to negotiate its +9V default, it signals via its Power Good pin to the first buck converter that it can wake up.
sequence
The first two rails are ordered in accordance with the SoC’s required sequencing. The third and last is for miscellaneous other chips. The whole sequence is +3V3, +0V95, +5V. The SoC can derive its own +1V8, which it needs for the 64MB of DRAM packaged right inside. Each buck’s Power Good signal feeds into the next one’s Enable pin. The signal between the first and second gets a tiny delay to conform to the SoC’s sequencing needs. The final PG triggers the main power LED and lifts Reset on the SoC. The SY8388A bucks themselves have been picked based on their 8A output, comfortably above the ~4A drawn from the +5V one by the downstream workers. Plus they have the critical PG pins to enable chaining. And dirt-cheap at around $0.3@1K, lovely.
decoupling
This power schematic page got a chunk of the SoC and the on-board Ethernet switch, even if they’re data heavy. I was torn between placing them on the power or data page, because both aspects are involved for them. But apparently you can split a schematic symbol into multiple units that represent a single physical package in the actual PCB layout. So, I split off everything power related and put it on this power schematic. Each of the two chips needs an army of decoupling capacitors on their different power input pins. They’re generally consolidated here to avoid too many lines on the BoM during assembly, but I’ll probably do further consolidation passes later on. No split ground. The 5 Realtek NICs for connecting to laptops or desktops got the tame treatment.
downstream
The remaining non-trivial part of the board from a power point of view is the CH338X hub through which some downstream worker devices are charged. Again, I split the hub into a power and a data symbol, to keep things clean. Power doesn’t directly flow through the hub, but the hub has control over per-port fixed-function CH217A power switches. We need per-port control, to for instance refuse charging a particular device whose battery is not healthy enough to run. Plus this allows us to control battery level cycling per worker while keeping off 0% and 100% battery levels. The switches also block workers from drawing more than the 5V@0.5A USB Type-A standard.
review
Because it was my first time working with many of these patterns, such as buck chains and PD control, I repeatedly asked LLMs for design reviews, in the hope of screening for meaningful issues. Even if I set myself a usage standard that boils down to “AI is fine for learning & prototyping, but open weights only,” I found it hard to trust models not on the frontier for feedback on topics I’m not already familiar with. Accordingly, I found myself reaching out for whatever public model was best at the time, such as Opus 5.5, to come up with issues for each subcircuit. Not sure how to navigate this, maybe open weights only for prototyping, but not learning? It is appealing to reach out to the most advanced on-demand tutor sometimes.