Hello, we are a long time user of the NRF52840 and are consistently running out of spare CPU, so are looking at the NRF5340.
I see that the NRF5340 runs up to 128Mhz. Was the flash memory bus bandwidth doubled vs the NRF52? Also does the SRAM run up to 128Mhz?
Thanks,
Dave
Hi Dave
I would have to check if the flash bandwidth has increased, but the main advantage over the nRF52 is that the cache efficiency is increased significantly.
For this reason, if you look at the Coremark numbers the nRF53 application core is noticeably more powerful even at the same clock frequency, and you get more than double the performance when running at 128MHz.
And then you have the network core on the side, which alone provides comparable performance to the nRF52840.
For the application core half the RAM runs at full speed, but the upper 256kB of the RAM is slower. For this reason it is recommended to use the upper part of the RAM for peripheral buffers (SPI, UART, QSPI etc).
Best regards
Torbjørn
Hi, did you get a chance to check on whether the Flash memory bandwidth doubled? If not, this won't provide us much of a performance boost over the NRF52 Caching alone won't much with our application.
Hi Dave
Sorry about that, I forgot to follow up on this one.
I have forwarded your request to the experts and will let you know once I hear back from them.
Either way, how can you be so sure that high flash bandwidth is required for your particular application?
Are you running a large code base with extensive branching that is known to be inefficient when using cache?
The best way to know for sure would obviously be to acquire a nRF5340DK and do some benchmarking on your own, to verify the performance when running your particular algorithms.
Best regards
Torbjørn
Hi Torbjorn,
Caching of course will have some impact, but in general on most applications, doubling CPU speed and doubling power consumption is not worth it with a caching improvement of say 20%. This is a common mistake most controller companies make in their design. In our case, our main loops are not small enough to be fully cached. I can't say much more than that. And it's probably safe to assume that this same rule applies to most of your customers considering in the majority of the projects I have worked on, that is the case. ARM doesn't seem to understand this, and we may not be using an ARM much longer. Companies like Renesas seem to understand this problem, and properly scaled their memory bandwidth to run from flash at full speed. Admittedly, not everyone needs this performance, but most studies have shown that running as fast as possible and then going to sleep is the most power efficient way of operating. This makes the sole reliance on caching to balance the CPU speed increase contrary to good design practices.
Thanks,
Dave
Hi Dave
Every design choice has advantages and disadvantages. Like you indicate having faster flash throughput will increase power consumption, it won't help with wakeup times, and this drawback will affect you whether you need it or not.
If you go to sleep a lot then there is no need to use the the MCU at 128MHz, 64MHz provides better efficiency, and would probably reduce the overhead from going in and out of sleep since you would most likely do it less often (because of higher CPU utilization).
In the end the question is whether or not the nRF5340 will fit within your project requirements, in terms of performance and power consumption, and the only way to know that for sure is to test it out in practice.
One trick to reduce cache misses and improve performance is to put critical code (like frequently occurring interrupt handlers) in RAM so it can run without wait states and without having to use the cache. The RAM in the nRF5340 is divided in separate blocks, meaning you can put code in one block and data in another, to prevent interleaving code and data access which would otherwise slow this down.
Obviously this assumes you have some RAM to spare, again depending on your project requirements, but even just setting aside 10% of the RAM for code should increase performance considerably if you make sure to put the right part of the code into RAM
As for the flash speed the expert on this is still unavailable, but I will get back to you as soon as he's back in office. I don't think there is an increase in flash throughput in the nRF5340 (as you can probably read out of my answer), but I can't know for sure until I have gotten his input.
Best regards
Torbjørn
Hi Dave
Every design choice has advantages and disadvantages. Like you indicate having faster flash throughput will increase power consumption, it won't help with wakeup times, and this drawback will affect you whether you need it or not.
If you go to sleep a lot then there is no need to use the the MCU at 128MHz, 64MHz provides better efficiency, and would probably reduce the overhead from going in and out of sleep since you would most likely do it less often (because of higher CPU utilization).
In the end the question is whether or not the nRF5340 will fit within your project requirements, in terms of performance and power consumption, and the only way to know that for sure is to test it out in practice.
One trick to reduce cache misses and improve performance is to put critical code (like frequently occurring interrupt handlers) in RAM so it can run without wait states and without having to use the cache. The RAM in the nRF5340 is divided in separate blocks, meaning you can put code in one block and data in another, to prevent interleaving code and data access which would otherwise slow this down.
Obviously this assumes you have some RAM to spare, again depending on your project requirements, but even just setting aside 10% of the RAM for code should increase performance considerably if you make sure to put the right part of the code into RAM
As for the flash speed the expert on this is still unavailable, but I will get back to you as soon as he's back in office. I don't think there is an increase in flash throughput in the nRF5340 (as you can probably read out of my answer), but I can't know for sure until I have gotten his input.
Best regards
Torbjørn
