You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There appears to be a bug in cont_controller.v when the device sends HOLD. I have attached an ILA trace from that module that illustrates the issue.
This is the response to a COMMAND_DMA_READ_EX (8'h25) command for a single block. Near the end of the frame, the drive sends HOLD, HOLD, data_word, EOF. As you can see from the trace, detect_hold is asserted during the last data word. This causes link_layer_read to discard the last data word. (In sata_stack.v, user_dout_size reports 127 data words instead of 128.)
I have attached a diff against cont_controller.v that I believe fixes the issue: I have modified the assignment to hold_cont by ANDing it with cont_detect. (If HOLD had been followed by CONT, then it would be correct to keep detect_hold asserted during that cycle, but when HOLD is not followed by CONT, then detect_hold should no longer be asserted.) I have changed the other *_cont signals to match because I believe they are likely to behave the same way, although I have not observed a problem with them in practice with the devices I have available for testing.
The device that shows this behaviour is a Samsung 860 EVO SSD. We have also been testing with a Micron M500IT SSD, but we have not seen it issue this pattern of HOLDs. So far, only the Samsung drive has excited this problem.
There appears to be a bug in cont_controller.v when the device sends HOLD. I have attached an ILA trace from that module that illustrates the issue.
This is the response to a COMMAND_DMA_READ_EX (8'h25) command for a single block. Near the end of the frame, the drive sends HOLD, HOLD, data_word, EOF. As you can see from the trace, detect_hold is asserted during the last data word. This causes link_layer_read to discard the last data word. (In sata_stack.v, user_dout_size reports 127 data words instead of 128.)
I have attached a diff against cont_controller.v that I believe fixes the issue: I have modified the assignment to hold_cont by ANDing it with cont_detect. (If HOLD had been followed by CONT, then it would be correct to keep detect_hold asserted during that cycle, but when HOLD is not followed by CONT, then detect_hold should no longer be asserted.) I have changed the other *_cont signals to match because I believe they are likely to behave the same way, although I have not observed a problem with them in practice with the devices I have available for testing.
The device that shows this behaviour is a Samsung 860 EVO SSD. We have also been testing with a Micron M500IT SSD, but we have not seen it issue this pattern of HOLDs. So far, only the Samsung drive has excited this problem.
cont_controller.v.diff.log
The text was updated successfully, but these errors were encountered: