QSPI Clock Question

[hjups22]

Hi,

Is there a way to set the QSPI clock on the MP157 to be free running while also using the QSPI? The programming manual mentions that free running mode will prevent the QSPI from being usable.

I am working on a project to interface the MP157 to an FPGA via QSPI, however, having the clock start up only when the transaction is active prevents the QSPI clock from being able to drive an IO PLL. If it were free running when no transaction was active, then the FPGA could maintain a synchronous PLL lock on the MP157.

[PatrickF]

Hello,

I fear the Reference Manual is right, there is no way to keep QUADSPI clock running while the interface is working. Free running clock is only for test purposes.

To keep your FPGA PLL up and running, you should use a sideband clock.

For instance, FPGA could be sharing same external 24MHz oscillator clock which feed the STM32MP1 HSE in digital bypass,

or use an STM32MP1 MCO1/2 output (e.g. a division of PLL4_p or aclk, which are clocks available for QUADSPI too) .

This clock will be synchronous with QUADSPI clock (assuming same root clock is used), but phase relationship is not guaranteed. So, you might have to add some re-synchronization inside FPGA (if not already managed in your QUADSPI slave).

Regards.

[hjups22]

Thanks for the reply!

Using the same 24 MHz oscillator won't work since I am planning to use a SoM. However, the MCO1/2 pins are available.

Is the phase relationship with the QSPI and the MCO output guaranteed to be constant over time? i.e. if the FPGA IO is phase aligned on startup, will it need to be periodically readjusted / calibrated for each transaction, or will startup calibration be sufficient?

Thanks!

[PatrickF]

There will be no phase slip on a stable transaction, but the phase could change if there is low-power entry/exit or if any changes in the clocking (e,g, PLL relock, divider changes) or if QUADSPI is stopped/restarted. Linux is quite complex on clock/power management.

I think as this is not a standard use case, you have to do your own tests.

IMHO, best would be have a separate clock domain for your FPGA QSPI slave with a standard async bridge when going to your FPGA interconnect (obviously this might add few cycle latency).

[hjups22]

So assuming the QSPI block / PLLs are not turned off for power consumption, it should maintain the phase relationship?

It should be possible to remove the QSPI (and perhaps PLL / power management) from the Linux tree, and manage those states via bare metal firmware on the M4 core, correct? Then the linux side can access the QSPI for transactions via memory reads/writes.

The plan was to use a separate clock domain for the FPGA QSPI slave, and bridge over to the main logic via an asynchronous FIFO. However, I think I would still need a stable clock to drive the QSPI slave domain. To handle QSPI at 150 MHz for example, or QSPI-DDR at 90 MHz, a PLL will be needed to drive the FPGA IO in a stable way. And if the FPGA clock domain is driven directly by the QSPI clock, I'm not sure how the FPGA will respond to driving the clock high or low when not in a transaction... I suspect it will result it glitching.

My other thought was to super-sample the QSPI signals via a higher frequency asynchronous clock domain (like what is typically done for SPI), however, if the phase is maintained with the MCO, it sounds like that would be much easier.