Oof, while it's nice to see documentation, that pdf is clearly not done yet. A block diagram with one giant block labeled "Bus Fabric" is not so helpful, and all the I2C/SDIO/etc interfaces are just tacked on to the top right?
I assume that the final doc will have a full representation of all the APB/AHB/AXI buses and their topology, and also the control registers for those buses.
Still, nice to see an overview of the chip and peripherals. I could do a lot of fun things with the IO chip even if it wasn't connected to the SoC.
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"?
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.
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.
7 comments
[ 2.9 ms ] story [ 26.4 ms ] threadI assume that the final doc will have a full representation of all the APB/AHB/AXI buses and their topology, and also the control registers for those buses.
Still, nice to see an overview of the chip and peripherals. I could do a lot of fun things with the IO chip even if it wasn't connected to the SoC.
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.