3 ms·

I wonder why they did this, most SoCs have more than enough IOs and IPs for Ethernet MAC, USB PHY, etc. and I assume the BCM2712 is no exception (though there a

I wonder why they did this, most SoCs have more than enough IOs and IPs for Ethernet MAC, USB PHY, etc. and I assume the BCM2712 is no exception (though there are no public docs so it's hard to say). Is this meant to support low power applications where the main SoC is power gated and the RP1 acts as a sort of powerful, user programmable "BMC"?

SeasonalEnnui 3y ago
I got the impression the primary motivation to do this is so the BCM2712 (and future processors) can move to smaller process nodes (less power, more speed) but keep things like 5V tolerant IO, ADCs, analog features which work better on 40nm. Going forward they will be able to keep a consistent set of IO whilst iterating to new BCM variants without hitting constraints as a result of smaller process nodes.
GrilledChips 3y ago
Decoupling. The raspi pin header is a defacto standard. The raspi foundation have to maintain a very high degree of compatibility with it. Have a look: https://raw.githubusercontent.com/pinout-xyz/Pinout.xyz/master/resources/raspberry-pi-pinout.png https://raw.githubusercontent.com/pinout-xyz/Pinout.xyz/mast... See all those various overlapping functions? It's the combination of functions on every pin that has to be mimicked too. Even though the raspi foundation get a fair degree of customization from broadcom, putting peripherals on a chip gets harder for process reasons as you push for performance. This is the same reason why the M1/M2 implement the eUSB spec and have external eUSB repeaters, instead of putting it fully on-chip. The foundation clearly want to go in the direction of increased performance, so it makes sense to push all that messy GPIO stuff off onto a custom chip, get additional cost reduction from including ethernet and USB (fewer chips), and also continue to build their chip design acumen. I wouldn't be surprised if arduino go this way too. They're already severely limiting themselves in performance and ram by selecting a 5V ARM chip, and matching the exact peripheral combination of the atmega328 is just as much of a millstone around their neck too. They could go with a much cheaper and faster arm core communicating with an AVR chip to manage the IO pins and have a significantly more capable board. Lots of 3rd party AVR+ESP32 boards already do this.

SeasonalEnnui 3y ago

I got the impression the primary motivation to do this is so the BCM2712 (and future processors) can move to smaller process nodes (less power, more speed) but keep things like 5V tolerant IO, ADCs, analog features which work better on 40nm. Going forward they will be able to keep a consistent set of IO whilst iterating to new BCM variants without hitting constraints as a result of smaller process nodes.

GrilledChips 3y ago

Decoupling. The raspi pin header is a defacto standard. The raspi foundation have to maintain a very high degree of compatibility with it. Have a look: https://raw.githubusercontent.com/pinout-xyz/Pinout.xyz/master/resources/raspberry-pi-pinout.png https://raw.githubusercontent.com/pinout-xyz/Pinout.xyz/mast... See all those various overlapping functions? It's the combination of functions on every pin that has to be mimicked too. Even though the raspi foundation get a fair degree of customization from broadcom, putting peripherals on a chip gets harder for process reasons as you push for performance. This is the same reason why the M1/M2 implement the eUSB spec and have external eUSB repeaters, instead of putting it fully on-chip. The foundation clearly want to go in the direction of increased performance, so it makes sense to push all that messy GPIO stuff off onto a custom chip, get additional cost reduction from including ethernet and USB (fewer chips), and also continue to build their chip design acumen. I wouldn't be surprised if arduino go this way too. They're already severely limiting themselves in performance and ram by selecting a 5V ARM chip, and matching the exact peripheral combination of the atmega328 is just as much of a millstone around their neck too. They could go with a much cheaper and faster arm core communicating with an AVR chip to manage the IO pins and have a significantly more capable board. Lots of 3rd party AVR+ESP32 boards already do this.