search

clash-lang / clash-compiler

Haskell to VHDL/Verilog/SystemVerilog compiler
https://clash-lang.org/
Other
1.4k stars 147 forks source link

SPI core mode 0 is racy #2644

Open bgamari opened 5 months ago

bgamari commented 5 months ago

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 commented 5 months ago

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

bgamari commented 5 months ago

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 commented 5 months ago

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.