UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor wenorum
Visitor
117 Views
Registered: ‎07-05-2016

GTY eye scan stuck

Jump to solution

I've had no trouble with eye scans on GTX transceivers, but trying to do this on a GTY transceiver has yet to work for me.

  • Use DRP to write 0x0405 to register 3C (ES_ERRDET_ENABLE | ES_EYE_SCAN_ENABLE | ES_PRESCALE=5 to CONTROL register)
     
  • Reset transceiver by momentarily asserting the gtwiz_reset_all_in port of the wizard-generated IP block.
  • Use DRP to set up vertical and horizontal offsets.
  • Use DRP to write 0x0705 to register 3C (as above plus ES_RUN)
  • Register 253 (STATUS) reads back 0x6C00 forever (STATE=WAIT, DONE=0).  It's as if the transceiver reset didn't notice that the ES_EYE_SCAN_ENABLE bit was set.

Am I missing something?  The above procedure seemed to work for GTX transceivers. Is there a minimum width for the gtwiz_reset_all_in signal that I need to meet?

Thanks

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
42 Views
Registered: ‎08-07-2007

回复: GTY eye scan stuck

Jump to solution

hi @wenorum 

 

is it possible that you forgot to connect DRPADDR[9]?

You mentioned you have succeeded in GTX eyescan. GTX has only 9bits of DRPADDR, while GTY has 10bits on that.

You can check the DRPADDR[9] connection after migrating from GTX to GTY.

 

if this bit is unconnected, when you attempt to read 0x253, DRP will return the 0x053 registers value.

 

Thanks,

Boris

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
5 Replies
Xilinx Employee
Xilinx Employee
70 Views
Registered: ‎08-07-2007

回复: GTY eye scan stuck

Jump to solution

hi @wenorum 

 

please follow the steps in the following documents. it seems different than your operation.

 

US+ GTY

https://www.xilinx.com/support/answers/68785.html

 

US GTY

https://www.xilinx.com/support/answers/66517.html

 

Thanks,

Boris

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Visitor wenorum
Visitor
58 Views
Registered: ‎07-05-2016

回复: GTY eye scan stuck

Jump to solution

Those instructions seem to be at odds with the UB579 GTY documentation which describes the ES_EYE_SCAN_EN bit as:

This bit should always be 1 when using Eye Scan. Setting this bit to 0 powers down the Eye Scan circuitry in the PMA and forces the Eye Scan state to WAIT. Re-enabling Eye Scan functionality requires reasserting this bit and asserting/deasserting PMA reset.

But the AR#66517 presents the initial steps as follows -- the GT reset is done *before* setting ES_EYE_SCAN_EN:

Step 1: Set ES_HORZ_OFFSET[11] and USE_PCS_CLK_PHASE_SEL in accordance with Table 1 and Table 2

Step 2: Reset the GT: the GT should be up and running. Here for example, you configure the transmitter and receiver equalizers, run the reset sequences, wait for reset done, and check that buffers are not overflowing etc.. In this example the LPM mode is used.

Step 3: Be ready for the scan:

ES_CONTROL [5:0] = 6b000000

ES_EYE_SCAN_EN = 1b1 enables the Eye Scan

ES_ERRDET_EN = 1b1 enables the error detection: each bit of the Sdata bus is 1 if and only if the corresponding offset data sample does not agree with the recovered data sample.

ES_PRESCALE according to the BER target (we can set it to be very small initially: i.e. 5b00100)

 

 

And as far as I can tell the steps described in the answer records you mentioned are what I am doing.  What difference do you see?

Here's the code that I use to initialize the eye scan (here the reset is done after setting ES_EYE_SCAN_EN, but I get the same results when doing the reset first as described in AR#66517):

    for (lane = 0 ; lane < EYESCAN_LANECOUNT ; lane++) {
        /* Enable statistical eye scan */
        drp_write(lane, DRP_REG_ES_CONTROL, ES_CONTROL_ERRDET_ENABLE |
                                            ES_CONTROL_EYE_SCAN_ENABLE |
                                            PRESCALE_CODE);

        /* Set ES_SDATA_MASK to check configured N bit data */
        drp_write(lane, DRP_REG_ES_SDATA_MASK0, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK1, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK2, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK3, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK4, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK5, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK6, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK7, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK8, 0xFFFF);
        drp_write(lane, DRP_REG_ES_SDATA_MASK9, 0xFFFF);
        switch (drp_read(lane, DRP_REG_RX_WIDTH) >> 5 & 0x7) {
        case 3: // 20 bit
            drp_write(lane, DRP_REG_ES_SDATA_MASK3, 0x0FFF);
            drp_write(lane, DRP_REG_ES_SDATA_MASK4, 0x0000);
            break;

        case 5: // 40 bit
            drp_write(lane, DRP_REG_ES_SDATA_MASK2, 0x00FF);
            drp_write(lane, DRP_REG_ES_SDATA_MASK3, 0x0000);
            drp_write(lane, DRP_REG_ES_SDATA_MASK4, 0x0000);
            break;
        }

        /* Enable all bits in ES_QUAL_MASK (count all bits) */
        drp_write(lane, DRP_REG_ES_QUAL_MASK0, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK1, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK2, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK3, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK4, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK5, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK6, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK7, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK8, 0xFFFF);
        drp_write(lane, DRP_REG_ES_QUAL_MASK9, 0xFFFF);
    }

Then at each step of the scan I set the offsets and then start the run:

           drp_rmw(activeLane, DRP_REG_ES_VERT_CONTROL, 0x7FC,
                                                 (vOffset < 0 ? (1 << 10) : 0) |
                                                      (utFlag ?  (1 << 9) : 0) |
                                                                   (vAbs << 2));
            // Assume <= 10 Gb/s - Set MSB to 0
            drp_rmw(activeLane, DRP_REG_ES_HORZ_OFFSET, 0xFFF0,
                                                        (hOffset & 0x7FF) << 4);
            drp_set(activeLane, DRP_REG_ES_CONTROL, ES_CONTROL_RUN);

Here's a log of all the DRP operations during initialization (Lane:DRPaddress OP value -- where OP is <- for write and -> for read):

0:003c <- 0305
0:0049 <- FFFF
0:004a <- FFFF
0:004b <- FFFF
0:004c <- FFFF
0:004d <- FFFF
0:00f1 <- FFFF
0:00f2 <- FFFF
0:00f3 <- FFFF
0:00f4 <- FFFF
0:00f5 <- FFFF
0:0003 -> 1C61
0:004c <- 0FFF
0:004d <- 0000
0:0044 <- FFFF
0:0045 <- FFFF
0:0046 <- FFFF
0:0047 <- FFFF
0:0048 <- FFFF
0:00ec <- FFFF
0:00ed <- FFFF
0:00ee <- FFFF
0:00ef <- FFFF
0:00f0 <- FFFF

Then to start a scan:

0:0063 -> 80C1
0:0097 -> 0002
0:0097 <- 01FE
0:004f -> 000F
0:004f <- 7C0F
0:003c -> 0305
0:003c <- 0705
0:0253 -> 6C00
0:0253 -> 6C00
0:0253 -> 6C00
.
.
.

The eye scan state machine never leaves the WAIT (000) state.

 

 

 

 
0 Kudos
Xilinx Employee
Xilinx Employee
43 Views
Registered: ‎08-07-2007

回复: GTY eye scan stuck

Jump to solution

hi @wenorum 

 

is it possible that you forgot to connect DRPADDR[9]?

You mentioned you have succeeded in GTX eyescan. GTX has only 9bits of DRPADDR, while GTY has 10bits on that.

You can check the DRPADDR[9] connection after migrating from GTX to GTY.

 

if this bit is unconnected, when you attempt to read 0x253, DRP will return the 0x053 registers value.

 

Thanks,

Boris

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
Visitor wenorum
Visitor
33 Views
Registered: ‎07-05-2016

回复: GTY eye scan stuck

Jump to solution

Thanks very much (and do I ever feel dumb).

When I changed from a GTX to a GTY I added a DRP_ADDRESS_WIDTH parameter -- and changed my code -- in all places but one -- to use it.

My eyescan now completes.

I have some other error that I have to track down though since every point in the scan is returning a saturated error counter.  The GTY is receiving data properly so I know that the eye scan must be in error.

Thanks again for your assistance and my apoligies for a stupid error on my part.

I may be getting back in touch if I can't figure out why all points are showing a saturated error count.

0 Kudos
Visitor wenorum
Visitor
24 Views
Registered: ‎07-05-2016

回复: GTY eye scan stuck

Jump to solution

Added the synchronization step from AR#66517 and all is now working.

Many thanks!

 

0 Kudos