5 ms·

Author here. I’ve got a few more posts on VPR coming in the next couple of weeks. If you have any requests for deep dives into specific aspects of the architect

Author here. I’ve got a few more posts on VPR coming in the next couple of weeks. If you have any requests for deep dives into specific aspects of the architecture, feel free to drop them here!

SV_BubbleTime 2y ago
All of this wreaks of complexity crisis to me. That you need to know much and do do so much work - just in order to do the work you want to do. Explain why I’m wrong, please.
- AlotOfReading 2y ago
  The article goes into more detail than it strictly needs to because the purpose is educational. However, a lot of what it's presenting is simplified interfaces and relevant details rather than the true complexity of the whole. Modern hardware is just fundamentally complex, especially if you want to make full use of the particular features of each platform.
- fidotron 2y ago
  You are wrong. When more general purpose hardware (i.e. CPU cores) are added to chips like this it is to replace the need for single purpose devices. True nightmarish complexity comes from enormous numbers of highly specific single purpose devices which all have their own particular oddities. There was a chip a while back which took this to a crazy extreme but threw out the whole universe in the process https://www.greenarraychips.com/ https://www.greenarraychips.com/
  - awjlogan 2y ago
    Not wrong, especially for microcontrollers where micro/nanosecond determinism may be important - software running on general purpose cores is not suitable for that. They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. I’ve got a project that uses 4 hardware serial modules, timers, ADC, event system etc all dedicated function. Sure, they have their quirks but once you’ve learnt them you can reuse a lot of the drivers across multiple products, especially for a given vendor. Of course there is some cost, but it’s finding the balance for your product that is important.
    - fidotron 2y ago
      > They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. This used to be true, but as fabrication shrinks first you move to quasi FSMs (like the PIO blocks) and eventually mini processors since those are smaller than the dedicated units of the previous generation. When you get the design a bit wrong you end up with the esp32 where the lack of general computation in peripherals radically bumps memory requirements and so the power usage. This trend also occurs in GPUs where functionality eventually gets merged into more uniform blocks to make room for newly conceived specialist units that have become viable.
      - awjlogan 2y ago
        No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. E.g., just to enter an interrupt is 10-15 odd cycles, a memory access or two to set a pin, and then 10-15 cycles again to restore and exit. Additionally, micros have to be much robust electrically than a cutting edge (or even 14 nm) CPU/GPU and available for extended (decade) timespans so the economics driving the shrink are different. Small, fast cores have eaten the lunch of e.g. large dedicated DSP blocks for sure but those are niche cases where the volume is low so eventually the hardware cost and cost to develop on weird architectures costs more than running a general purpose core.
        fidotron 2y ago
        > No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.
- rcxdude 2y ago
  Making I/O properly programmable actually reduces complexity overall, because you can put more of the customizability on the other side if the interface, making things much simpler overall. I2C, for example, is a terrible interface in many ways, but one of the biggest is it creates a very complex and low-latency interface between the hardware and the software, and it's often easier to bitbang than use dedicated peripherals, especially the buggier ones. Running it on a small dedicated core means you can deal with it much more sensibly than trying to wrangle a hard peripheral which can't make enough assumptions about your use-case to give a good interface.
hn3er1q 2y ago
Thank you so much for asking, I have oh so many requests... Personally, I'm mostly interested in the ARM vs RISCV compare and contrast. - I'd be very interested in comparing static memory and ram memory requirements for programs that are as similar as you can make them at the c-level using whatever toolchain Nordic wants you to use. - Since you're looking to do deep dives I think looking into differences in the interrupt architecture and any implications on stack memory requirements and/or latency would be interesting, especially as VPR is a "peripheral processor" - It would be interesting to get cycle counts for similar programs between ARM and RISCV. This might not be very comparable though as it seems the ARM architectures are more complex thus we expect a lower CPI from them. Anyway I think CPI numbers would be interesting. I could go on but I don't want to be greedy. :)
- brucehoult 2y ago
  The Raspberry Pi Pico 2 of course also uses the Cortex M33, along with a self-developed (in his spare time!) RISC-V core that has very similar performance, other than not having an FPU. It's pretty easy to compare the same C code on both CPUs on a Pico 2, where you have equal RAM, equal peripherals etc.
rwmj 2y ago
Why did they go with the 64 bit Arm core instead of an RV64 core? (Or an alternative question: why go with the 32 bit RISC-V core instead of an Arm M0?) Does having mixed architectures cause any issues, for example in developer tools or build systems? (I guess not, since already having 32 vs 64 bit cores means you have effectively a "mixed architecture" even if they were both Arm or RISC-V) What's the RISC-V core derived from (eg. Rocket Chip? Pico?) or is it their own design?
- als0 2y ago
  > Why did they go with the 64 bit Arm core ARM Cortex-M33 is a 32-bit core, not 64-bit.
- crest 2y ago
  They haven't gone with a 64Bit ARM core. The ARMv8*M* isn't 64bit unlike ARMv8R and ARMv8A (the nomenclature can get confusing). The differences between ARMv7M (especially with the optional DSP and FPU extension) and ARMv8M mainline are fairly minor unless you go bigger with an M55 or M85 which (optionally) adds the Helium SIMD extension. At he low end ARMv8M baseline adds a few quality of life features over ARMv6M (e.g. the ability to reasonably efficiently load large immediate values without resorting to constant pool). Also the MPU got cleaned up to make it a little less annoying to configure.
  - rwmj 2y ago
    Thanks for the clarification. Confusing terminology!
  - pm215 2y ago
    ARMv8A and ARMv8R can both be pure 32 bit as well, incidentally -- e.g. Cortex-A32 and Cortex-R52. v8A added 64 bit, but it didn't take away 32 bit. It's not until v9A that 32 bit at the OS level was removed, and even there it's still allowed to implement 32 bit support for userspace.
- audunw 2y ago
  Not 64 bit, it’s 32-bit cortex m33. M33 has, among other things, TrustZone. So there’s some feature, along with developer familiarity and tools that make ARM desirable for an application processor. Mixed architecture doesn’t really cause any significant problems. The design is fully custom in-house design.
crest 2y ago
Will open-source developers unable or unwilling to sign an NDA get access to a toolchain to run their own code on the RISC-V co-processors? Is the bus matrix documented somewhere? Does the fast co-processor have access to DMA engines and interrupts?
- janice1999 2y ago
  FYI Nordic said on their YouTube channel that the RISC-V toolchain that already ships with Zephyr's SDK will support the cores. See around 00:56:32.520 [1] [1] https://www.youtube.com/watch?v=ef87Gym_D5c https://www.youtube.com/watch?v=ef87Gym_D5c
  - hasheddan 2y ago
    Indeed. It is used in this post to compile the Zephyr Hello World example for the PPR.

Author here. I’ve got a few more posts on VPR coming in the next couple of weeks. If you have any requests for deep dives into specific aspects of the architecture, feel free to drop them here!

SV_BubbleTime 2y ago

All of this wreaks of complexity crisis to me. That you need to know much and do do so much work - just in order to do the work you want to do. Explain why I’m wrong, please.

AlotOfReading 2y ago
The article goes into more detail than it strictly needs to because the purpose is educational. However, a lot of what it's presenting is simplified interfaces and relevant details rather than the true complexity of the whole. Modern hardware is just fundamentally complex, especially if you want to make full use of the particular features of each platform.
fidotron 2y ago
You are wrong. When more general purpose hardware (i.e. CPU cores) are added to chips like this it is to replace the need for single purpose devices. True nightmarish complexity comes from enormous numbers of highly specific single purpose devices which all have their own particular oddities. There was a chip a while back which took this to a crazy extreme but threw out the whole universe in the process https://www.greenarraychips.com/ https://www.greenarraychips.com/
- awjlogan 2y ago
  Not wrong, especially for microcontrollers where micro/nanosecond determinism may be important - software running on general purpose cores is not suitable for that. They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. I’ve got a project that uses 4 hardware serial modules, timers, ADC, event system etc all dedicated function. Sure, they have their quirks but once you’ve learnt them you can reuse a lot of the drivers across multiple products, especially for a given vendor. Of course there is some cost, but it’s finding the balance for your product that is important.
  - fidotron 2y ago
    > They can also be orders of magnitude more energy efficient than running a full core just to twiddle some pins. This used to be true, but as fabrication shrinks first you move to quasi FSMs (like the PIO blocks) and eventually mini processors since those are smaller than the dedicated units of the previous generation. When you get the design a bit wrong you end up with the esp32 where the lack of general computation in peripherals radically bumps memory requirements and so the power usage. This trend also occurs in GPUs where functionality eventually gets merged into more uniform blocks to make room for newly conceived specialist units that have become viable.
    - awjlogan 2y ago
      No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. E.g., just to enter an interrupt is 10-15 odd cycles, a memory access or two to set a pin, and then 10-15 cycles again to restore and exit. Additionally, micros have to be much robust electrically than a cutting edge (or even 14 nm) CPU/GPU and available for extended (decade) timespans so the economics driving the shrink are different. Small, fast cores have eaten the lunch of e.g. large dedicated DSP blocks for sure but those are niche cases where the volume is low so eventually the hardware cost and cost to develop on weird architectures costs more than running a general purpose core.
      - fidotron 2y ago
        > No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.
rcxdude 2y ago
Making I/O properly programmable actually reduces complexity overall, because you can put more of the customizability on the other side if the interface, making things much simpler overall. I2C, for example, is a terrible interface in many ways, but one of the biggest is it creates a very complex and low-latency interface between the hardware and the software, and it's often easier to bitbang than use dedicated peripherals, especially the buggier ones. Running it on a small dedicated core means you can deal with it much more sensibly than trying to wrangle a hard peripheral which can't make enough assumptions about your use-case to give a good interface.

hn3er1q 2y ago

Thank you so much for asking, I have oh so many requests... Personally, I'm mostly interested in the ARM vs RISCV compare and contrast. - I'd be very interested in comparing static memory and ram memory requirements for programs that are as similar as you can make them at the c-level using whatever toolchain Nordic wants you to use. - Since you're looking to do deep dives I think looking into differences in the interrupt architecture and any implications on stack memory requirements and/or latency would be interesting, especially as VPR is a "peripheral processor" - It would be interesting to get cycle counts for similar programs between ARM and RISCV. This might not be very comparable though as it seems the ARM architectures are more complex thus we expect a lower CPI from them. Anyway I think CPI numbers would be interesting. I could go on but I don't want to be greedy. :)

brucehoult 2y ago
The Raspberry Pi Pico 2 of course also uses the Cortex M33, along with a self-developed (in his spare time!) RISC-V core that has very similar performance, other than not having an FPU. It's pretty easy to compare the same C code on both CPUs on a Pico 2, where you have equal RAM, equal peripherals etc.

rwmj 2y ago

Why did they go with the 64 bit Arm core instead of an RV64 core? (Or an alternative question: why go with the 32 bit RISC-V core instead of an Arm M0?) Does having mixed architectures cause any issues, for example in developer tools or build systems? (I guess not, since already having 32 vs 64 bit cores means you have effectively a "mixed architecture" even if they were both Arm or RISC-V) What's the RISC-V core derived from (eg. Rocket Chip? Pico?) or is it their own design?

als0 2y ago
> Why did they go with the 64 bit Arm core ARM Cortex-M33 is a 32-bit core, not 64-bit.
crest 2y ago
They haven't gone with a 64Bit ARM core. The ARMv8*M* isn't 64bit unlike ARMv8R and ARMv8A (the nomenclature can get confusing). The differences between ARMv7M (especially with the optional DSP and FPU extension) and ARMv8M mainline are fairly minor unless you go bigger with an M55 or M85 which (optionally) adds the Helium SIMD extension. At he low end ARMv8M baseline adds a few quality of life features over ARMv6M (e.g. the ability to reasonably efficiently load large immediate values without resorting to constant pool). Also the MPU got cleaned up to make it a little less annoying to configure.
- rwmj 2y ago
  Thanks for the clarification. Confusing terminology!
- pm215 2y ago
  ARMv8A and ARMv8R can both be pure 32 bit as well, incidentally -- e.g. Cortex-A32 and Cortex-R52. v8A added 64 bit, but it didn't take away 32 bit. It's not until v9A that 32 bit at the OS level was removed, and even there it's still allowed to implement 32 bit support for userspace.
audunw 2y ago
Not 64 bit, it’s 32-bit cortex m33. M33 has, among other things, TrustZone. So there’s some feature, along with developer familiarity and tools that make ARM desirable for an application processor. Mixed architecture doesn’t really cause any significant problems. The design is fully custom in-house design.

crest 2y ago

Will open-source developers unable or unwilling to sign an NDA get access to a toolchain to run their own code on the RISC-V co-processors? Is the bus matrix documented somewhere? Does the fast co-processor have access to DMA engines and interrupts?

janice1999 2y ago
FYI Nordic said on their YouTube channel that the RISC-V toolchain that already ships with Zephyr's SDK will support the cores. See around 00:56:32.520 [1] [1] https://www.youtube.com/watch?v=ef87Gym_D5c https://www.youtube.com/watch?v=ef87Gym_D5c
- hasheddan 2y ago
  Indeed. It is used in this post to compile the Zephyr Hello World example for the PPR.