Electronic – SYNC Escape in SATA

fpgasatassdxilinx

I have a FPGA in which I have implemented SATA Host and a SSD as the device. The communication b/w them is occuring at SATA 3.0(6 Gbps).

I have a situation in which during write transaction I receive SYNCp from the device unexpectedly due to which the write transaction fails.
enter image description here

I have recorded the scenario in Chipscope. Here are description of the signal names:-

  1. align_insert -> I am inserting ALIGNp from my end as required by SATA protocol. Just added for info.
  2. tx_data_r0 -> TXDATA sent from the host link layer.
  3. prim_hold_det -> This records if any HOLDp is received from device.
  4. prim_cont_det -> This records if any CONTp is received from device.
  5. prim_align_det -> This records if any ALIGNp is received from device.
  6. prim_sync_det -> This records if any SYNCp is received from device.
  7. prim_r_err_det -> This records if any ERRp is received from device.

The present situation shows that the device is sending HOLDp and I(Host) is sending HOLDAp(x"9595AA7C"). Then, suddenly I receive, SYNCp from device. Usually, in normal scenarios the device sends R_IPp to host when the device has space available in it's link layer FIFO.

But here I am receiving SYNCp. So, I checked SATA 3.0 spec. On page 370, section 9.6.4, the state transition for Link Layer Receive has been provided, because I want to understand what the device could be doing. In that, I am checking the "LR4: L_Hold" state. In this state there are only two possible scenarios in which the device can send SYNCp, and those are "6th" and "7th" conditions.

My doubt is, is it possible to understand which of the conditions is triggering the SYNCp response. I have tried to analyse both the conditions.

  • "6th condition" – SYNCP received from Phy. As per this condition if the device receives SYNCp from host then it sends SYNCp in return. But you can check that in "tx_data_r0" no SYNCp have been sent by host. So, this is not my triggering condition. For now, I can speculate that this is not the condition.
  • "7th condition" – Transport layer indicates request to escape current
    frame. This may be the triggering condition. But the description is pretty vague. It doesn't provide any detail as to what could be the reason for Transport Layer demanding a SYNCEscape. I have checked the Device Transport Layer State Machine in the spec but there also no specific answers could be found.

If anyone has faced and debugged a similar scenario then it would be helpful. I am open to suggestions on debugging this scenario in SATA protocol.

Best Answer

You can interpret the SYNCp primitive from device as a hard link reset. Something failed and the device wanted to reset the link, but didn't request a very hard reset via COMINIT.

You should read the status register from the device after you received such a communication abort.

Related Topic