As noted in your other thread, part of the delay is down to the input synchronizers (2 clocks). There is also 1 clock delay between executing the PIO instruction that sets an output and that output appearing on a pin, and 1 clock delay between input on a pin and that value being read by PIO instructions.
So for a PIO program reading its own outputs, a changed output value becomes visible as an input 4 cycles later (2 cycles later if synchronizers disabled).
I don't like turning off the synchronizers as metastability problems are extremely hard to detect and/or debug, but SPI with RP2040 as the master is one of the rare cases where it may be safe to turn them off: so long as you know that the other end is fast and is generating timing directly from your clock then the setup/hold will always be met. With an FPGA at the far end (implementing the SPI slave) it's more complex, particularly if the FPGA is itself sampling the SPI signals to some faster clock - you will have to do some hard work with the datasheets to know if it is safe.
But whether the delay is 4 cycles or 2 cycles, for an SPI master that doesn't mean you have to slow down the clock by that factor - all the data is being read correctly at full speed, it just arrives a few cycles later and you have to take that into account in your PIO program.
If you were trying to implement an SPI slave in PIO then these delays would be more significant (and you can't turn off synchronizers in that case).
So for a PIO program reading its own outputs, a changed output value becomes visible as an input 4 cycles later (2 cycles later if synchronizers disabled).
I don't like turning off the synchronizers as metastability problems are extremely hard to detect and/or debug, but SPI with RP2040 as the master is one of the rare cases where it may be safe to turn them off: so long as you know that the other end is fast and is generating timing directly from your clock then the setup/hold will always be met. With an FPGA at the far end (implementing the SPI slave) it's more complex, particularly if the FPGA is itself sampling the SPI signals to some faster clock - you will have to do some hard work with the datasheets to know if it is safe.
But whether the delay is 4 cycles or 2 cycles, for an SPI master that doesn't mean you have to slow down the clock by that factor - all the data is being read correctly at full speed, it just arrives a few cycles later and you have to take that into account in your PIO program.
If you were trying to implement an SPI slave in PIO then these delays would be more significant (and you can't turn off synchronizers in that case).
Statistics: Posted by arg001 — Wed Oct 09, 2024 9:06 am