6 ms·
VPR: Nordic's First RISC-V Processor
- bfrog 2y agoI kind of wonder why Nordic bothered sticking with arm cores at all. The competition isnt
- IshKebab 2y agoThey'll probably replace them but given they had no RISC-V expertise I imagine they made these small coprocessors first in order to gain experience. You can't magically do everything all at once.
- eschneider 2y agoOk, I'm on a project that just picked N54 processors for a set of new designs. W/O arm cores it wouldn't even be considered. The RISC-V cores are useful and will be put to work, but they aren't exactly a selling point. Why did we end up with N54s? Price, Performance, BLE6 support, PRICE.
- janice1999 2y agoA lot of software stacks are still only optimised for ARM. TrustZone is also far more mature and supported than the RISC-V equivalents.
- bfrog 2y agoIs TrustZone really all that useful? I haven't had a need for anything like it myself! esp-c6 module parts are like $2-3 and already have an fcc cert, low power, and support all the same protocols I believe. Are nrf54 modules really that cheap? Can I program them natively with Rust yet?
- explodingwaffle 2y agoWhat would you consider the “RISC-V equivalent” of TrustZone? Last time I was curious I didn’t find anything. (FWIW I agree with the other commenter that these ""security"" features are useless, and feel to me more like check-box compliance than anything else (Why does TrustZone work with function calls? What’s wrong with IPC! Also, what’s wrong with privileged mode?). Just seems like a bit of a waste of silicon really.)
- IshKebab 2y agoThere are some examples listed here: https://en.wikipedia.org/wiki/Trusted_execution_environment https://en.wikipedia.org/wiki/Trusted_execution_environment
- jdietrich 2y agoMultiZone, OpenMZ, Keystone, maybe Penglai or ProvenCore, I can't really keep up. That answer goes a long way to explaining the appeal of TrustZone.
- vardump 2y agoSo many different cores. Dual M33s, VPR, consisting of PPR (a low power 16 MHz RISC-V RV32E? for external I/O) and FLPR (a RISC-V RV32E running at 320 MHz, for software defined peripherals). I wonder what the max square wave GPIO toggle rate is with FLPR. Can it compete with for example RP2040/2350 PIO?
- crest 2y agoThey would have to fuck up massively for an I/O co-processor to lack single cycle GPIO access which would at least allow driving a 320/2 50% duty-cycle square wave, but sustaining that deterministically through priority access to memory and DMA is something else. At 150MHz the RP2350 is able to sustain that bandwidth with hard realtime guarantees allowing it to do things which are hard to impossible on other chips in the same price class e.g. glitchfree 720p video output "in software".
- petra 2y agoI wonder if that will be the effect of the rp2350, to push the whole market toward software defined peripherals?
- MisterTea 2y agoI would say not really as software defined peripherals have been around for some time. There is the Parallax Propeller and Greenarrays chips which have no hard IO blocks, everything is done in CPU cores. The Ti PRU is similar.
- hasheddan 2y agoAuthor 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 agoAll 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 agoThe 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 agoYou 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 agoNot 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.
- Scene_Cast2 2y agoI was looking into these recently. The current batch of the nRF54L15's was recalled, so I wonder when mass availability will happen. It looks like an interesting upgrade to the nRF52 though. The reason why I was looking at it is because I'm trying to hook up a 1kHz sampling ADC while streaming the data over BLE, and I need either a good DMA engine that can trigger on an external pin without a CPU interrupt, or a second core. I went down the dual core route, but I'd love to hear people's experience with DMA on the nRF52's and esp32-h2's and if it's finicky or not, and it's worth investing time into.
- dwnw 2y agoDMA will work fine. I remember a time when we were rewarded for making do with what we had rather than putting a handful of CPU cores on a sensor. These do not sound interesting to me, honestly. It sounds more like they can't figure out what they need to make.
- gonzo 2y agoThat was a time when gates were not as plentiful as they are now. Both the new Nordic SoCs are designed at 22nm. It can be a challenge as to what to use all the gates for.
- marsven_422 2y ago[dead]