Is there any bugs in oob_controller?

[Jzone315]

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

[cospan]

I haven't looked at this in a while so it took me a little while why it's like this.

From what I remember, It depends on the platform that you use.

In the Xilinx Spartan 6 GTP The OOB controller takes in strobes. So, for example if you want to send a COMM RESET Pattern to the hard drive you strobe the 'tx_comm_reset ' signal for one clock cycle and the GTP will perform the long sequence of squelches in the appropriate pattern and then set the 'tx_oob_complete' high to say it's finished with the reset sequence.

[Jzone315]

You were right , I tried to make it working on kintex7 platform , so I keep these two signals up to 1.06us , for now linkup has been completed , however i have observed a others problem , when the platform startup,
signal sata_ready can't be asserted , because in the sata_link_layer_read.v module , signal idle always be low, what i known is when startup , the ssd will send the x_rdy signal ,which cause the state to fall into the READ_START , but without sof or even sync signal , this makes it as a dead state , i tried a lot of ways but with the same results , how can i settle this? why can't i receive the sof or other signals? is there any suggestions? Thanks a lot.

[cospan]

I'm glad to hear you saw linkup!

I'm looking at 'sata_link_layer_read.v'

I think this is what you are saying correct?

SSD -> FPGA

ALIGN
XRDY
! SOF && !SYNC??

That's strange, the sequence should be:

SSD/FPGA: SYNC (IDLE)
...
SSD: X_RDY (Transmit Ready)
FPGA: R_RDY (Read Ready)
SSD: SOF (Start of Frame)
SSD: DATA... (Data)
SSD: EOF (Endo of Frame)
SSD: WTRM (Write Terminate)
FPGA: R_OK (Response is Okay!)
SSD/FPGA: SYNC (IDLE)
...

It looks like the FPGA is not sending the 'Read Ready' signal. or the transmitter is not correctly configured to send the R_RDY correctly.

The value that is sent from the FPGA should be:

R_RDY: 0x4A4A957C
When it is scrambled it should be... (I think):
R_RDY (Scrambled): 0x8898E3F1

tx_dout = 32'h8898E3F1
tx_is_k' = 1

If this is true then the read state machine is correctly sending out 'R_RDY' and the transceiver may not be correctly sending data.

Dave

[cospan]

Also, you might have the tx pair polarity inverted. I ran into a similar issue and found that I could invert the polarity within the SERDES module.

[Jzone315]

I am hignly appreciated that you have totaly token what I meant.
But in my debug project , I have obseved the transmitter of R_RDY sequence in its primitive value 0x4A4A957C instead of the scrambled value 0x8898E3F1 , so did all the prim sequences(SYNC , X_RDY , SOF , EOF , R_RDY , WTRM , ...etc) need to be scrambled?
I found two singals prim_scrambler_en and data_scrambler_en in the top module , i did tied both of these two signals to 1 , but the transmitter of the prim sequences are still in thers primitive values , only the payload parts are in thers scrambled value , why did this happen?
And the receiver in my ILA core i observed are the primitive values too , did these primitive values caused the loss of the SOF and SYNC?
Thank you very much for my disturbance.

[Jzone315]

I have checked the schematic and XDC file again , both the tx pair and rx pair are normal , if the PN pairs does inverted , how could the linkup is asserted?

[cospan]

I am hignly appreciated that you have totaly token what I meant.

Your welcome!

But in my debug project , I have obseved the transmitter of R_RDY sequence in its primitive value 0x4A4A957C instead of the scrambled value 0x8898E3F1 , so did all the prim sequences(SYNC , X_RDY , SOF , EOF , R_RDY , WTRM , ...etc) need to be scrambled?

They should be scrambled before they are transmitted over the SATA link.

I found two singals prim_scrambler_en and data_scrambler_en in the top module , i did tied both of these two signals to 1 , but the transmitter of the prim sequences are still in thers primitive values , only the payload parts are in thers scrambled value , why did this happen?

You are correct the primitives should not be scrambled. I apologize, I forgot about that.

I have checked the schematic and XDC file again , both the tx pair and rx pair are normal , if the PN pairs does inverted , how could the linkup is asserted?

You are correct, I shouldn't have posted that at midnight.

I don't have an idea right now, but I think of something I'll let you know.

[Jzone315]

Hi Dave
Sorry to interrupt you again.
I have fixed the issues now , it had something to do with my gtx phy , now i could start the sata tests , but i still has a little confusion .
According to the wiki , when i start a DMA write operation , i need to fill up 2048 bytes data to the fifo , but for all i know is the single one of the hdd's sector is 512 bytes , so can i set the sector_count and sector_address?
In my tests , when i use sector_count = 1 and sector_address = 0 to do DMA write , while in DMA read , the user_dout_size is 0x000080(128bytes) , when i use sector_count = 4 and sector_address = 0 to do DMA write , while in DMA read , the user_dout_size is 0x000200(512bytes) , so how should i exactly use the two signals in DMA write and read ?
Thanks a lot!
Jzone Wang

[cospan]

Hi Jzone,

I have fixed the issues now , it had something to do with my gtx phy , now i could start the sata tests , but i still has a little confusion.

I'm happy to hear you fixed the issue!

According to the wiki , when i start a DMA write operation , i need to fill up 2048 bytes data to the fifo , but for all i know is the single one of the hdd's sector is 512 bytes , so can i set the sector_count and sector_address?

The minimum size you can write to the hard drive is 8192 bytes or 2048 32-bit values. You must write in the entire 2048 32-bit words in order to complete a transaction or else the hard drive will lock up.

When I first started I thought 512 bytes was the correct size too. This is correct for older hard drive communications but for the new hard drives the size of a sector is 8192 bytes. If you would like to write only 512 bytes you will need to read the 8192 byte sector into a local buffer, modify the 512 bytes and then write back an entire 8192 bytes.

1 sector_count = 8192 bytes (or 2048 32-bit values)

The reason why you must write 32-bit values is because the SATA stack operates at 1/4th the frequency of the byte clock for the gigabit transceiver.

SATA II = 2.5GHz frequency
Byte Frequency = 250MHz (8b10b)
SATA Stack = Byte Frequency / 4 = 75MHz

I hope this makes sense.

[morvaridS]

Hi,
@Jzone315 I think I have the same problem that you had. Linkup is 1 but but it seems like the read and write signals aren't sent out correctly from the fpga (Kintex 7). Since you said you fixed this issue and it had something to do with your gtx phy, I'd appreciate if you tell me what the problem was and how you fixed it.
Thanks
Mori