Power and multiple chips - Page 1
Forum section: electronics / projects

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 12, 2025, 06:48:46 pm
content: I have a project idea in mind which will use 64 RP2354's in parallel - it's not commercial, it's a "fun idea" and the parallelism is the point.However, assuming I get the MCU to run at full speed, and have the PIO's running messaging between them, I could be looking at 200mA per chip @ 3.3v or 12.8A, which seems ... excessive when scaled up to 64 CPUs (and I have ideas to scale it even further to 16x16 assuming this small-scale parallelism experiment works).In the past I've just put an LDO on the board, and specced it to the maximum power - I've had no real problems with that, but 12A is ... a lot. So I was thinking of putting an LDO per row, meaning each 8 MCU's would be getting their own 3.3v supply, with a shared GND.I don't *think* there's a problem with that - the pins will all be at 3.3v (even if "different" 3.3v across rows) and even assuming some tolerance mismatch, all the signals should be well above the minimum voltage for logical '1'... But I thought I'd avail myself of the collective wisdom of "people who know whart they're doing"So, any thoughts on whether there's a better way to do it ? Am I doomed to inevitable failure, or will this "work just fine, don't waste my time asking stupid questions!" ?

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2025, 07:44:24 pm
content: 12.8A multiplied by whatever your drop from Vin to 3.3V is a *LOT* of power. Also you still need that 12.8A at your Vin voltage. Discard the idea of linear regulators. This is really a job for buck regulators, one for each cluster of RP2354 MCUs. As to how many per cluster, well that depends on how many amps output current its good for. 8 MCUs for a max of 1.6A would fit the capabilities of a lot of dirt cheap buck converters. Vin would be 19V or 20V at under 2.5A from a secondhand laptop PSU or a 20V capable USB C PD power supply + a PD trigger set to 20V.However I would add 330 ohm series resistors in series with PIOs signalling between different power domains in case one supply fails, to limit the current that is being driven into PIOs of a powered down MCU!

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 13, 2025, 01:49:02 pm
content: 200mA is a lot of current for a uC. Somewhere between a few mA and 20mA is much more common. I did see a reference that a 200mA SMPS circuit was put on some rp2354 board, but that does not mean it actually uses so much current. Normally there is a quite big current reserve to be able to add external circuitry such as LED's to the board.And with a project like this, bandwidth of the interconnecting fabric is a huge bottleneck. The faster you can get it the better. It's probably also not a good idea to put them all on a single bus. For example if you have an 8 by 8 matrix, then each column can have a communication bus, and each row can have a separate communication bus. That would be 16 communication busses that can be used in parallel and independently of each other. Or you have 8 buses in total, where each bus both has a row and a column.Have you seen the project below:https://hackaday.com/2025/07/07/160-core-risc-v-board-is-the-m-2-coprocessor-you-didnt-know-you-needed/(I think it has both problems with interconnecting fabric bandwith and with powering the LED's.)And there is also at least one project around Raspi Pico's, but it's at a smaller scale:https://hackaday.com/2025/05/20/pentapico-a-pi-pico-cluster-for-image-convolution/

author: jwet
author_rank: Frequent Contributor
timestamp: July 13, 2025, 02:03:45 pm
content: I haven't seen mentioned that the Pico can run on anything between 1.8 and 5.5v (Vsys). It internally has a buck boost converter that makes 3.3v and a linear that makes core voltage. I would distribute 5v nominal with a low impedance bus. The data sheet doesn't show currents much over 80 mA. If you're making an array, I wouldn't overclock much. Overclocking is taking advantage of a random selection of one CPU. When you get into arrays with large numbers, you will likely find the weak sisters that can't run at 400 Mhz or whatever number people run these things at.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 13, 2025, 08:12:24 pm
content: Quote from: Ian.M on July 12, 2025, 07:44:24 pmThanksThe idea of putting resistors between the MCU's to isolate against a power-failure on one row/column is a good one, but I worry there'll be an effect on the rise/fall-time of the signals. I really want fast communications - maybe as high as 50MHz. Perhaps a similar thing could be done with auto-directional level-translators along the path - egSN74CB3T16211DGGR...

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 13, 2025, 09:01:02 pm
content: Quote from: Doctorandus_P on July 13, 2025, 01:49:02 pm200mA is very much the boundary condition, but I do intend to over-drive the RP2354's (hobby project, remember) up to ~399 MHz (chosen because that keeps the QSPI RAM/Flash interface at the max 133MHz, without jumping to 532MHz), which is well within the overdriven envelope (maxing out at about700 MHz) that others have seen. I still don't think the MCU will be drawing that much current - it doesn't even get warm at those frequencies, but with the GPIOs maxed out and both cores possibly maxed out running code, and all three PIO units maxed out running communications, I want to make sure there's sufficient margin, so ... top-end estimate it isQuote from: Doctorandus_P on July 13, 2025, 01:49:02 pmI have not seen the projects, but I will look them up, thank youThis is very muchnota shared bus system. Quite the opposite in fact. When I was young and doing my image-processing PhD at college, we had a Meiko computing surface full of transputers to play with. There's some massively parallel algorithms I want to play with againThe plan is to runNuttXon each MCU node via the built-in flash, and provide a message-bus device as part of the NuttX build. That message-bus device will know how to route messages from any node to any other, with all messaging being source-routed (ie: sender decides the route) and each node along the way "unwraps" one level of routing and sends it to the destination for that level.The idea is that there'll be a dedicated bus {req/ack/clk/data} for each of the available {N,S,E,W} directions in/out of every MCU, where req/ack are used to establish who is sending and who can currently receive, and clk/data are set up directionally to clock in/out data as needed. I'll be using an 8-bit data bus, and pushing it as fast as I can. There's not much travel-distance between nodes on the PCB, and I can make sure the signals are all straight-line. I can use edges (only 3 directions) and corners (only 2 directions) to flow data up and down and get a 3D compute volume.There are 3 PIO's on an RP2354 with me wanting 4 message-directions, so part of the message task (and this is usable because of the req/ack handshake) will be to configure and download the specific PIO program to a PIO to handle the message that is to be sent next. I'm thinking that most situations won't need to toggle the PIO directionality much, so we'll use an LRU cache to see if there's a need for the configuration for a given message or if we can use a previous (already extant) configuration. The message task for 'send message' also sets up the route for the message to take, eg:{N, N, W, N, W, destination}. I can gather congestion metrics for routing and re-route accordingly, since most nodes will have many paths between them.The RTOS provides a task to send messages, and there's a few message-tasks I'm interested in...The first one will be geometry-discovery on initial setup, and a write to OTP memory (because the PCB is ... unlikely ... to change) - even so I'll adopt a "config valid" checksum and use the last-valid configuration found in the OTPAnother use will be to download executable (NXFLAT format) programs/data into the memory-space of the RP2354 - and I'll be adding anAPS6404L-3SQR-ZRto each node on the PCB, giving it (slower) access to 8MB of RAM per node. I'm imagining there being tasks to load data into slow RAM in the background, processing in SRAM, and swapping from slow-RAM to SRAM on-demand to make best use of the QSPI interface.On top of that the tasks themselves can send messages with a call to the message-device provided by the OS-driver I'll write, making send-message basically just a function-call, and enormous bandwidth being available across the computing surface, at the expense of some code running on one of the ARM cores (as well as the PIOs doing the grunt-work) and the latencies of multiple-hop messaging.NuttX can make use of both CPUs in the MCU, but one of the MCUs will be running the messaging system as well, so there'll be a preferred CPU for most tasks, unless it's a really long-running heavily-CPU-dependent task. Using the PIOs to handle the actual transfer, and the NuttX environment producing an event when a transfer is complete and ready to be read makes this pretty similar to the old transputer link ideaI've been thinking about this for a while - I've pretty much mapped out the algorithm for getting this up and running efficiently, but I'm in the middle of moving house, so it's going to have to wait a while. I'm calling it the picoputer for the time being, in honour of the transputer from all that time ago..

author: Paradroid
author_rank: Contributor
timestamp: July 14, 2025, 11:52:15 am
content: Quote from: SpacedCowboy on July 13, 2025, 08:12:24 pmFor a design with 85-ish MHz digital signals at 3.3V level, I've used 100R series source termination, and that was no problem at all. 330R might work at 50MHz, especially if traces are short. Input capacitance if these MCUs is tiny, so trace capacitance will play a bigger role. Make sure to use thin signal traces and proper GND reference. With all that power you're planning, this calls for a 4-layer PCB anyway. Most services offer 0.125mm thin traces as standard these days - at least for a small increase in price. That's a day-and-night difference compared to 0.2mm traces on a 2-layer FR4 board...

author: Ian.M
author_rank: Super Contributor
timestamp: July 14, 2025, 01:10:27 pm
content: The alternative to higher value current limiting series resistors is a 'PWR_GOOD' circuit, with supervisor ICs for each power rail, that holds all the MCUs in Reset to tri-state their I/O pins if any of the power domain voltages are seriously out of spec.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 14, 2025, 03:36:02 pm
content: Quote from: SpacedCowboy on July 13, 2025, 09:01:02 pmI'm out.Getting a project to work like this at all is quite a challenge, it's never going to be faster then an off the shelf solution (such as a decent GPU). Adding overclocking just for shits and giggles just makes it a stupid exercise in my book.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 14, 2025, 04:22:46 pm
content: Quote from: Doctorandus_P on July 14, 2025, 03:36:02 pmI don’t know if I’ve unintentionally misled you here, but this isn’t anything to do with what is faster than an off-the-shelf GPU. This is for fun.Anyway, out or not, thanks for the help so farHave a nice life

author: Ian.M
author_rank: Super Contributor
timestamp: July 14, 2025, 04:41:34 pm
content: Nothing says you have to overclock it initially. I assume you (and anyone sane) will start at a conservative in-spec clock frequency, get the bugs out of the design, then test it at max. in-spec speed before seeing how high you can overclock it reliably, then back off a bit for stability.

author: mariush
author_rank: Super Contributor
timestamp: July 14, 2025, 05:10:05 pm
content: I'd use switching regulators to convert your input voltage to let's say 3.6v..4.0v , then use a fixed 3.3v LDO on the board , AP2112K, RT9080, RT9013, RT9167 ... lots of LDOs with dropout voltage under 0.3vA 3A switching regulator (ex AP62300, AP63300, AP64350 (3.5A), AP6450x (5A) , lots of TI chips ) ... for every 8 chips ... 8 x 300mA = 2.4A leaving 0.6A reserve ... , make 8 "tiles" with 8 microcontrollers...As for communication, you could probably have a master controller that passes messages between chips using SPI, quad spi, 8 bit parallel port (one clock per controller, shared 8 bit bus, poll periodically each chip to see if there's a reply or message to be passed to another ic etc etc ) etc

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 14, 2025, 05:37:42 pm
content: Quote from: Ian.M on July 14, 2025, 04:41:34 pmYes, I probably ought to have made that clear also. Building it, calibrating it, and using it are three separate stages, each of which will depend on the previous phaseThere’s also nothing to say that all the chips have to run at the same speed even - point-to-point messaging between them dissociates them from each other, after all.