nRF54L15-RISC V core use

[SubuMuthu]

Hi, 

SDK: 3.0., nRF54L15

The application is Matter + BLE dynamic multi-protocol + battery powered sleepy end device. Current Application(Matter/Thread + BLE + Firmware application) uses Cortex-M33 core, which has taken up almost 235KMB to 240KB of SRAM space and 1.1MB of flash space. 

We are releasing a  variation which involves RFID(125KHZ) and propriety implementation.  This involves specific and controlled timing for  generating 125KHZ RF signals and reading back the card contents. The Cortex-M33 core is already taxed with Matter and BLE and we are exploring the use of RISC-V core. 

The RFID application is not a large code base and it will require a) Timer/Counter, 2) ADC, 3) comparator, 4) capture compare and 5) core to manage  everything.  The RFID subsystem will periodically wake up,  generate a card detect signal, check if card is present, if present,  read the card, then go back to sleep, and wake up during the next one. The sleep - wake is every second.

There are critical timing to meet for successful card detection/reading.  It could be  possible to implement this in Cortex-M33 because the device is a sleepy(Thread) end device but we are concerned that the RFID application will not have any control on the priority(it could be allocated to Matter/Thread or BLE).  This is reason for us to look at the RISC-V core and use it exclusively.

The questions include:

1.  Does the RISC-V core have access to ADC, Timer/Counter, Capture compare and comparator? This link(https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/vpr_flpr.html) does not show that.

2. Can  the RISC-V core be put into sleep mode and be woken  up by peripherals (like when Card is detected? Or can it sleep and wake up periodically?

3)) Any sample examples other than this - https://github.com/nrfconnect/sdk-zephyr/tree/v3.7.99-ncs1/samples/subsys/ipc.

4) What about the SRAM requirements? we are running low but we are not expecting large SRAM use. We are thinking of  XIP(RRAM).So would it have any performance impacts due to Cortex-M33 and RISC-V contention? If SRAM is used,  how much of SRAM is needed?

5)) Is it possible to use external SRAM? this is not only for RISC-V core but also for Cortex-M33 core.

Thanks.

Subu

[Susheel Nuguru]

Hi Subu,

1.  Does the RISC-V core have access to ADC, Timer/Counter, Capture compare and comparator? This link(https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/vpr_flpr.html) does not show that.

No, it does not seem that you could use VPR only to run the RFID as ADC does not seem to be accessible through this core. I think you need to design some IPC mechanism where peripheral events are listened on the Cortex-M33 core and processed on the VPR through IPC. That way there is minimal overhead for M33 due to this and most of the info when passed to VPR can then process the data.

2. Can  the RISC-V core be put into sleep mode and be woken  up by peripherals (like when Card is detected? Or can it sleep and wake up periodically?

Yes, VPR can go to low power states and can be woken up with some limited wakeup sources like mapped GPIO, mailbox interrupt.

3)) Any sample examples other than this - https://github.com/nrfconnect/sdk-zephyr/tree/v3.7.99-ncs1/samples/subsys/ipc.

Unfortunately No, I have been using this sample also as template for some of my other hobby experiments. there is a sample in nrf/samples/ipc/ipc_service but this seems to have been tested only on nRF53 and nRF54H. But My best guess is that this should also work fine on nRF54L.

4) What about the SRAM requirements? we are running low but we are not expecting large SRAM use. We are thinking of  XIP(RRAM).So would it have any performance impacts due to Cortex-M33 and RISC-V contention? If SRAM is used,  how much of SRAM is needed?

RRAM is slow, and if you say that you are taking all this effort because you think there are some time critical nature for the RFID design, then maybe RRAM might not be the best choice. How much of SRAM is needed is difficult for me to say as this is varies for every application and there is no generic answer to that. Just compile your application and look at the .map file to get an idea. I am thinking that if your RFID is a bit more complex than a simplistic RFID then it should be needing around 40KB of SRAM.

5)) Is it possible to use external SRAM? this is not only for RISC-V core but also for Cortex-M33 core.

Yes, both cores can use external memory using QSPI but the execution of these XIP might have some performance issues depending on SPI clock speed, Memory latency Arbitration between cores and Bus congestion during BLE/Matter radio activity

[Susheel Nuguru]

Regarding my answer on point 1). I might be wrong I have got some info that the datasheet and SDK documentation will get more updates related to VPR soon. And there will be more information on the shared peripherals. Until then I do not have much info that I can share on that matter apart from what I have shared already.