Can we share QSPI port with FPGA and nRF7002?

RE: Can we share QSPI port with FPGA and nRF7002?

Saxman58 — Sat, 13 Jul 2024 22:44:14 GMT

Hi Edvin,

I looked into this further and am now convinced that this isn't really possible, even if I wanted to modify the Nordic Wi-Fi library code myself. There is far more traffic on the QSPI bus than I expected, especially when we are trying to maximize the Wi-Fi throughput. And all the queues and threads further complicate the idea of trying to steal time from the QSPI usage.

At first I thought that the SPI would be too slow for the FPGA interface, even the 32 MHz SPIM4 on the nRF5340. But we found a way to make that work. So we are back to the using the dedicated QSPI connection to the nRF7002.

Thanks for your help!

Glen

RE: Can we share QSPI port with FPGA and nRF7002?

Edvin — Fri, 05 Jul 2024 13:58:02 GMT

Hello Glen,

I asked our WiFi team, and they said that it is not possible to share the QSPI peripheral with other devices, when it is used for the nRF7002, and it is not something that is planned to come soon either.

It is, however, possible to connect the nRF7002 via SPI instead of QSPI. It does slow it down, but if that is the only option, then perhaps you can look into it? Alternatively, you can investigate whether the FPGA is capable of running on SPI instead of QSPI as well?

Best regards,

Edvin

RE: Can we share QSPI port with FPGA and nRF7002?

Saxman58 — Tue, 02 Jul 2024 03:42:31 GMT

Hi Edvin,

1. We don't have hardware to test the QSPI with the FPGA, but will soon. But here is my reasoning. Xilinx has IP modules to implement QSPI in the FPGA, and they are highly configurable. But they only support master mode, and of course we want the FPGA to be the slave to the Nordic MCU, like the nRF7002 is. So we will design our own QSPI slave port (simpler than a master) and make sure that it matches the appropriate QSPI modes and operations that the nRF5340 supports and that we would use. The FPGA design will have addressable status and control registers, and memory read and write operations, all of which map very well to the commands for an external flash chip. Because we are creating the registers and memory interface, we can make sure they are compatible. (Memory will be RAM, not Flash, so the sector/block/chip erase instructions won't be used, but reads and writes still make sense.)
The QSPI port also supports custom instructions (see section 7.25.7 of the nRF5340_PS-v1.3.1) that might be useful to us to make some custom commands. However, I believe that as long as make the FPGA look like a memory chip (with the RAM as part of the address space, and the memory mapped status and control registers at different addresses) then the standard memory read and write operations (e.g.- READ4IO and PP4IO) should work.

2. On this point, I think the big question is whether the Wi-Fi drivers ever try to communicate with the nRF7002 without the application in the nRF5340 initiating it. Since the nRF7002 has an interrupt line to the MCU, I doubt that the driver would poll the nRF7002, but I can't say for sure. My hope is that the drivers talk to the nRF7002 a lot during the initialization and the establishment of communications to the Wi-Fi Access Point, but then after that the drivers only talk over the QSPI when the application asks for it (checking status or sending a new message) or when there is an interrupt. So if we have the FPGA mask the interrupt (pass it through an AND gate) for the few microseconds it takes to grab a new 512 byte block of data from the FPGA, and then allow the interrupt to pass through to the MCU once the QSPI is returned to the nRF7002, then that takes care of the interrupts. And the application would know not to initiate any Wi-Fi operations during the QSPI transfer from the FPGA.

If the driver doesn't talk to the nRF7002 unless the application asks it to, or if it gets an interrupt, then with this scheme there may not be a need to put the Wi-Fi driver on hold. But if it polls the nRF7002 periodically or something like that, then there could be a problem.

The other situation that would be a problem is if the Wi-Fi driver somehow gets exclusive control over the QSPI bus and prevents the application from accessing it directly. I don't know if this is possible for the driver to do.

Tusen takk,

Glen

RE: Can we share QSPI port with FPGA and nRF7002?

Edvin — Mon, 01 Jul 2024 22:18:12 GMT

Hello,

I have two questions:

1: Have you tried using the QSPI on the nRF5340 on your FPGA device? Does that work? The reason I ask is that the QSPI drivers on the nRF5340 are tailored to work with external flash chips, and of course the nRF70-series, because we can design these drivers as we like. However, you need to check that the QSPI drivers works with the FPGA device that you want to use.

2: I don't think the nRF7002 drivers will accept not being able to communicate with the nRF5340. At least not without disabling the WiFi protocol before doing so. So if that is an option, the answer is "maybe", but again, it depends on whether or not you are able to use the QSPI drivers with your FPGA devices.

I want to check this before diving more deeply into your questions. Then I know a bit more details before start asking our WiFi teams about details on how to set the WiFi on hold for a given amount of time.

Best regards,

Edvin