SPI core mode 0 is racy

[bgamari]

Currently if one configures the Clash.Cores.SPI.spiMaster in Mode 0, the end of the transfer will race between CS and the capture clock. Specifically, the produced output will raise CS at the same moment as the last falling SPI clock edge (which the subordinate will sample on).

A similar race is avoided at the beginning of the transfer by the waitTime argument, where a few core clock cycles are inserted between CS being lowered and the SPI clock starting. Perhaps a similar delay should be inserted at the end of the transfer as well?

[bgamari]

Actually, I may have been a bit premature here. Closing until I have confirmed.

[bgamari]

I do believe that this is indeed a problem. While there is a cycle of delay between the sampling edge and the rise of CS, this violates the timing requirements for the DAC8734 (and I suspect most other subordinates).

[DigitalBrains1]

I think we can reuse waitTime for a delay at the end as well. I haven't looked at any datasheets, but differences in propagation delays might even make a slave observe S̅S̅ deassert before they see the clock edge. Surely there needs to be an appreciable delay before S̅S̅ is deasserted at the end.