cospandesign / nysa-sata Goto Github PK

The stack is difficult to use, the interface needs to be simpler

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

After exercising this core on an FPGA we observed that the back pressure from the hard drives revealed some data loss on the link layer. A work around was implemented, it was a small buffer that would absorb the data transients. This is ugly and hacky and needs to be fixed correctly.

The area in the '/nysa-sata/rtl/link/sata_link_layer_read.v' can be found on line 228 and is related to these registers:

assign              d0_buf                    = bump_buffer[0];                                                                         |            if (data_scrambler_en) begin                                                                                                
assign              d1_buf                    = bump_buffer[1];                                                                         |              prev_data   <=  descr_dout;                                                                                               
assign              d2_buf                    = bump_buffer[2];                                                                         |            end                                                                                                                         
assign              d3_buf                    = bump_buffer[3]; 

The first milestone should be to expose the bugs in a consistent way.

My stimulate not right!
no problem......

I can't use iverilog, can you provide modelsim simulate script？

The synchronizer on this line and one farther below is on the wrong clock domain.

On wiki page no any information about configuration of Xilinx GTX-transceiver.
Please check your email. Thank you.

Cocotb is tool that allows users to write test benches for HDL in Python. It is much easier to write extensive tests with Python than with verilog.

The following tests should be written an exercise before the sata core is verified:

• Bootup: The system starts in a default state How is this defined?
• Single Word Write: Write a single piece of data to the SATA stack side: Expected Results: observe the correct address and data on the simulated hard drive
• Single Word Read: Read a single piece of data from the SATA stack: Expected Results: observe the correct address on the hard drive side and pass a piece of data through the simulated hard drive and read it from the SATA stack
• Large Write: how big? Send a stream of data from the SATA stack side to the simulated hard drive side: Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.
• Large Read: how big? Read a stream of data from the SATA stack side: Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.
• Large Write With Easy Back Pressure: how big? Send a stream of data from the SATA stack side to the simulated hard drive side with simulated stall commands to slow the transfer of data: Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.
• Large Read With Easy Back Pressure: how big? Read a stream of data from the SATA stack side with simulated stall commands to emulate back preassure: Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.
• Large Write With Hard Back Pressure: how big? Send a stream of data from the SATA stack side to the simulated hard drive side emulate the challenging back pressure (every other clock, ever two clock, etc..): Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.
• Large Read With Hard Back Breassure: how big? Read a stream of data from the SATA stack side emulate the challenging back pressure (every other clock, ever two clock, etc..): Expected Results: observe the correct address behavior (starting at every sector) and the correct data flowing through.

I found tx_comm_reset and tx_comm_wake signals valid only one clock cycle when I simulate the design,so is this correct?