SPI Slave HIL IO Updates

[xmos-jmccarthy]

Thank you for submitting an SDK feature request. Please provide as much information you can.

Describe the feature
The original SPI slave hil IO had the design goal of consolidation as the primary goal. Now that it is being used in ways beyond the legacy unit tests we have identified shortcomings and nonidealities.
#63 Shall be addressed
#64 Shall be addressed
#65 Shall be addressed
#66 May be addressed

The most strict software design requirement came from the CPHA == 0 modes. In these modes, slave output has to be on MISO before the first SCLK, meaning that there is a very short amount of time between CS assertion and first SCLK. In the CPHA == 1 modes, the app has almost half an SCLK period more time to set the data to the device. To account for CPHA == 0 modes, and use of strobed ports meant that the device had to be architectured in a thread + ISR setup. The reason for this is because the slave has to OUT to MISO before the SCLK. If the master stopped a transaction, the XCORE would be stuck at an OUT which may never be clocked out. By using CS as an ISR for both assert and deassert, the deassert case is able to clear MISO's buffer, thus allowing the thread to continue on ISR return, back to the blocking IN on MOSI.

Two solutions are being investigated:

1. Split SPI slave HIL IO into 2 implementations, CPHA == 0, and CPHA == 1.
2. Keep current spi slave as general purpose, but add a single mode highly optimized for XCORE ports slave peripheral. This would most likely be mode 1 or 3 only.

[xmos-jmccarthy]

#66 will not be addressed at this time.

CS is heavily needed for the software IO implementation to reset and error recover from extra clocks. In the event that a spi slave byte transferred callback exceeds an sclk period, or the master started to clock before the spi_slave was fully initialized, the data in MOSI could be off by any number of bits. In the prior implementations, the transaction would "fail" due to sending invalid data, and the CS deassertion would clear MISO and MOSI, resetting to a clean state to try again. In the case where CS is set there is no definitive hardware level time to reset MISO and MOSI, so any missed bits will accumulate error. Adding an application API to clear the buffers could alleviate the issue but is not guaranteed to fix it, as it would have to be a request by the app to the HIL IO thread to avoid a resource exception. Additionally, since this implementation uses strobed slave ports, clearing the buffer could still occur at an undesirable time, clearing valid bits that have been clocked in. Turning off the clockblock while clearing the buffer also doesn't help, because bits have still been missed, so once it is re-enabled sampling can still begin mid-transaction. The decoupling between the RTOS and HIL IO library prevent a buffer clearing method from ever working due to the unknown latency between the RTOS app requesting the buffer being cleared and it actually happening in the HIL IO library.

To make an implementation to provide #66 would most likely require a free running clock that periodically samples SCLK and "guesses" whether a transaction is complete or not to clear the buffer to thus handle non port width size transactions. Alternatively, not relying on the transfer width and instead doing an unbuffered 1b port for MISO and MOSI, would allow catching this issue to be more obvious, but in this architecture maximum throughput would be significantly impacted.

[xmos-jmccarthy]

Closed by xmos/xcore_iot#537