1

I am using a Xilinx 7-Series GTXE2 Transceiver configured as SATA host PHY. This transceiver is interfacing with an SATA Host controller and an SATA Gen1 device.

During initialization, I am able to see COMRESET, COMINIT and COMWAKE from host and device. They have been captured on RXDATA/TXDATA. TX/RXELECIDLE are de-asserted correctly. The host controller is able to receive and response to complete OOB sequence.

After that, the host is sending D10.2 at 1.5 Gbps to start speed negotiation. The device is responding with \$ALIGN_p\$ primitives, which are send at 1.5 Gbps.

However, from RXDATA, I can only see D27.3 D10.2 D10.2 K28.5 symbols appearing for only one clock cycle, which is 20'haaaaa, follow by 20'h5f0e4. After that, I am seeing 20'h55555, follow by 20'h5f0e4. The D27.3 and K28.5 character appeared to be correct. D10.2 appeared to be either swapped or shifted. Because the GTXE2 transceiver is unable to decode \$ALIGN_p\$, the speed negotiation failed.

I have set RXCDR_CFG to (72'h0380008BFF40100008). The FPGA is connected to a Gen1 device.

I have implemented a control signal to release RXCDRHOLD when I find 20'haaaaa follow by 20'h5f0e4 in the data stream. After I release the hold signal, it becomes 20'h55555 and 20'h5f0e4. If I don't release RXCDRHOLD, I see garbage on RXDATA. So it seems that releasing RXCDRHOLD only improve part of the \$ALIGN_p\$ characters. K28.5 and D27.3 was right. D10.2 is bit swapped or shifted.

I have came across another post, wherein the author may have experienced similar problems. He modified RXCDR_CFG: Configuring a 7-Series GTXE2 transceiver for Serial-ATA (Gen1/2/3)

I was wondering, if anyone has experienced this problem with Xilinx 7-Series GTXE2 transceivers.

Community
  • 1
sunni
  • 19
  • 2
  • Could you please post a waveform containing `RDXDATA`, `RXELECIDLE`, `RXCDRHOLD`, and `RXCOMWAKEDET`. – Martin Zabel Jan 19 '16 at 12:16
  • What is the device? (HDD, SSD, vendor, fabrication year). Did you use the Xilinx Core Generator or Vivado equivalent to generate the GTXE2 instance? => the generated code has bugs and is partly not correct for the SATA protocol. What's your test board? How do you connect your FPGA to a SATA cable: SFP adapter, SMA adapter, ...? – Paebbels Jan 21 '16 at 22:04
  • When exactly do you release `RXCDRHOLD`? You must wait until the complete OOB handshake phase is over, because the OOB bursts are filled with \$ALIGN_p\$ symbols. I'm also waiting for at least 63 consecutive detected ALIGN symbols. So the ALIGN stream from device is stable. – Paebbels Jan 21 '16 at 22:19
  • we tried another SATA drive: Western Digital WD Green WD10EADS I am seeing the output of rxdata_out of instant gtwizard_0_GT are inverted. gtwizard_0_GT is the wrapper of GTXE2_CHANNEL, generated by vivado. I expected when GTX sending ALIGN primitive, it appear as burst of : 0011100100 | 1010101010 | 1010101010 | 0101111100 D27.3 D10.2 D10.2 K28.5 From chipscope, I see bit is inverted: 1100011011 | 0101010101 | 0101010101 | 1010000011 – sunni Jan 22 '16 at 02:28
  • I applied a little hack @ rxdata . assign rx_data_out_new = ~rxdata_out. I wonder if you have seen this before? it seems to me that I would get different result from different SATA drive. – sunni Jan 22 '16 at 02:29
  • I finally can link up the drive by using the hack. – sunni Jan 22 '16 at 02:29

1 Answers1

2

I thought again about your inversion problem. The problem is that you or your PCB or your device swapped the RX+ and RX- wires for the transceiver input.

Your GTXE2 is configured to a 20-bit bus and no 8B/10B encoding, so the direct inversion of each bit seen in your measurement is caused by the wrong polarity at the input pins. You can enable polarity inversion (RXPOLARITY) for RX in the transceiver. The option is used to swap the pins, because PCB designers might swap the wires to reduce hops and vias.

You should also look into your boards schematic if there is a hint for swapped wires.

Paebbels
  • 3,897
  • 2
  • 18
  • 43
  • I modified the xdc file for RXN/P by changing from set_property PACKAGE_PIN AN3 [get_ports MOCARXN] set_property PACKAGE_PIN AN4 [get_ports MOCARXP] To: set_property PACKAGE_PIN AN3 [get_ports MOCARXP] set_property PACKAGE_PIN AN4 [get_ports MOCARXN] The link up is failed. According to chipscope, I am seeing RXDATA as 20'hA0F1B follow by 20'h55555. It is the same result if I don't change the RXP/N location. – sunni Jan 25 '16 at 01:53
  • You can't change the pins via XDC. The XDC setting is needed by the mapping step to find the correct location, nothing more. Transceiver pins are fixed and thus can not be swapped by XDC. You need to 1) confirm if the PCB designer swapped the P and N wires and if so 2) you need to change/enable `RXPOLARITY`. It's a transceiver generic. – Paebbels Jan 25 '16 at 02:40
  • @sunni Did you look for the `RXPOLARITY` parameter and you schematic? Am, I guessing right? – Paebbels Jan 28 '16 at 16:37