OpenCores

SPI Master/Slave Interface

Issue List
SLAVE Continuous Tranfer #8
Closed jdoin opened this issue about 8 years ago— assigned to: jdoinBug
jdoin commented about 8 years ago

In SPI_SLAVE.VHD, if the user does not write a new word (strobing 'wren_i') and the master sends more clocks (i.e., continuous transfer), the slave goes from state 1 to 0, then to state N .. 1 .. 0 again. This causes an error in bit sync, and received data has a 'bit shift' error.

jdoin was assigned about 8 years ago
jdoin commented about 8 years ago

The bug is fixed in version v2.02.0122 of the SPI_SLAVE.VHD core. The fix consists in engaging continuous transfer regardless of the user strobing write enable, and sequencing from state 1 to N as long as the master clock is present. If the user does not write new data, the last data word is repeated. The SVN is updated with the bugfix.

jdoin commented about 8 years ago

This bug was discovered by Mateusz Starzycki, who is using the slave core in a project, in continuous transfer mode.

jdoin commented about 8 years ago

The code for v2.02.0122 show a small side effect: if slave data loads are skipped, i.e., if the data requests 'di_req' are ignored, the last data is retransmitted again, but the MSb is set to '1' even if it was '0'. This only happens for skipped load cycles. For normal load cycles, i.e., when data is loaded and 'wren_i' is strobed at each data request 'di_req', transmission is normal.

jdoin commented about 8 years ago

v2.02.0123: to avoid MSb cluttering when a di_req cycle is ignored by the user at the slave parallel input port, MISO will output zeros (others => '0'). The new version is uploaded to the SVN.

This code is tested for the 4 spi modes, and verified in hardware. See the scope screen shot:

<div class="line"> <div></div> <img src="usercontent,img,1312858125" alt="slave CT with default transfer" title="slave CT with default transfer" /> </div>
jdoin closed this about 8 years ago