Based on using PIO for a synchronous serial interface (SPI) I have realized (and measured) that the delay caused by a GPIO input is too large.
My tests and measurements results in:
A (PIO) GPIO input causes a delay greater then: [b]30ns[/b]
Assuming the GPIO outputs seem to have a delay in the range of 2..4 ns (below 10ns) - a total "round trip delay" (connect MOSI and MISO) has a delay of 32..38ns.
The "SPI feedback test" works only, if the the PIO SPI implementation does not generate SCLK faster as 25 MHz ("round trip delay" below 40ns)
So, due to the assumption, that GPIO inputs delay the signal "so much" - the sampling of the input signal (MISO as feedback from MOSI) gets "out of sync" with internally used clock (synchronous, on a master reading MISO, sampling a "way later", internally).
The limit to implement a SPI with PIO is: max. 25MHz(theoretically).
Bear in mind: any external circuit, e.g. a connected SPI chip with delayed response, or even using level shifters on SPI - will reduce the max. possible PIO SPI speed even more (I get just 17.857 MHz using an FPGA for bi-directional level shifting).
BTW:
Using a pull-up or pull-down does not improve anything (still a large input delay).
And I saw during testing: ANY input hangs on the 2.2V (E9 errata), even no pull-down enabled (any floating input, e.g. changing the direction to input, shows this E9 "effect", independent of any pull resistor).
The E9 errata (which tells me: a GPIO (I/O) cell library used causing "GPIO input issues") could be extended by a remark: the delay on GPIO inputs - used for synchronous interfaces (such as PIO SPI) is limited to the maximum possible speed as 25MHz.
BTW:
interestingly, a "native" SPI peripheral seems to be faster - technically, it could work up to SYSCLK/2, 75MHz (also PIO SPI could technically run up to 75MHz) - but I got also just 25 MHz SCLK (as working). Anything faster creates bit errors (due to the delayed arrival of MISO inside the chip in the same way?).
My tests and measurements results in:
A (PIO) GPIO input causes a delay greater then: [b]30ns[/b]
Assuming the GPIO outputs seem to have a delay in the range of 2..4 ns (below 10ns) - a total "round trip delay" (connect MOSI and MISO) has a delay of 32..38ns.
The "SPI feedback test" works only, if the the PIO SPI implementation does not generate SCLK faster as 25 MHz ("round trip delay" below 40ns)
So, due to the assumption, that GPIO inputs delay the signal "so much" - the sampling of the input signal (MISO as feedback from MOSI) gets "out of sync" with internally used clock (synchronous, on a master reading MISO, sampling a "way later", internally).
The limit to implement a SPI with PIO is: max. 25MHz(theoretically).
Bear in mind: any external circuit, e.g. a connected SPI chip with delayed response, or even using level shifters on SPI - will reduce the max. possible PIO SPI speed even more (I get just 17.857 MHz using an FPGA for bi-directional level shifting).
BTW:
Using a pull-up or pull-down does not improve anything (still a large input delay).
And I saw during testing: ANY input hangs on the 2.2V (E9 errata), even no pull-down enabled (any floating input, e.g. changing the direction to input, shows this E9 "effect", independent of any pull resistor).
The E9 errata (which tells me: a GPIO (I/O) cell library used causing "GPIO input issues") could be extended by a remark: the delay on GPIO inputs - used for synchronous interfaces (such as PIO SPI) is limited to the maximum possible speed as 25MHz.
BTW:
interestingly, a "native" SPI peripheral seems to be faster - technically, it could work up to SYSCLK/2, 75MHz (also PIO SPI could technically run up to 75MHz) - but I got also just 25 MHz SCLK (as working). Anything faster creates bit errors (due to the delayed arrival of MISO inside the chip in the same way?).
Statistics: Posted by tjaekel — Wed Oct 09, 2024 4:51 am