DAC38RF82: SerDes Test Modes - PRBS31

Gil,

We are looking into this.

Regards,

Jim

Jim,

An update:

I have programmed/updated additional registers:

JESD_LN_EN = 0xFF03; Did that for both multi-DUC.

SRDS_PLL_CFG = 0x8051; Added CORRECT=1 and correct value for MPY according to MPY=5 in the latest datasheet (0x28).

When I measured the free running SERDES lanes 0-3 PLL clock/80 (DTEST=0001) I got ~70MHZ which leads to ~5.6GHz for the VCO. Probably the maximum for the VCO. Still, out of range (3125MHz max).

So, I updated SRDS_PLL_CFG = 0x8029 for MPY=5 according to the old MPY table (Feb 2017 datasheet) and got the correct 35MHz which gives VCO=2812.5MHz which is what I should get.

Then, I found the document "DAC38RF8x Test Modes" and, according to Table 1 programmed:

SRDS_CFG = 0x0109; Updated ALIGN=00

JESD_MATCH = 0x1CC0; Updated JESD_COMMAALIGN_ENA=0 for both multi-DUC.

Finally everything works ok (almost).

For lanes 0, 2, 5 and 7 I see constant Low for TESTPATT=100 and a high with negative pulses for other TESTPATT=011. CORRECT !

For lanes 1, 3, 4 and 6 I see constant High for TESTPATT=100 and a high with negative pulses for other TESTPATT=011. Almost Correct?!?!  What is this constant High?

Summary questions:

1. What is this constant High for lanes 1,3,4,6 ?

2. Using the MPY table from the old datasheet.
Using SERDES_REFCLK_DIV description from the new datasheet (August 2017) which states "The divide amount for the serdes REFCLK minus 1" (the old datasheet lack the "minus 1").

Both fields above prove correct.

So:

Which datasheet should we use?

Any relation to the version of build for my chip?

Thank you

Gil

TSW14J56revD SERDES Test Options.docxGil,

I received this document from the software development team but have not a chance to try it yet. Please feel free to give this a try as I will be doing this as well in the near future and let me how it works out.

Regards,

Jim

Jim,

I am able to generate a PRBS31 in my FPGA. No issues here.
I don't see how this document answers my 2nd post above.

Please let me know if you can clarify what I wrote, mainly in my second post (which is an update to the first).

thanks
Gil

Jim,

An update:

FPGA serdes pair P/N that is connected to DAC pair N/P (P to N, N to P) produces the Low state on the ALARM pin, while a pair that is connected P/N to P/N produces a High state.
So, changing polarity of the DAC lanes (SRDS_POL) to match the FPGA P/N produces a High on the ALARM for all lanes, while changing the polarity such that P/N connects to N/P on the DAC produces a Low on the ALARM for all lanes.
This is correct (since PRBS31 is generated in the FPGA and checked in the DAC), except:
If ALM_OUT_POL=1, why do we get a constant High when FPGA P/N connects to DAC P/N? Shouldn't that be a Low?

In addition, I require an answer for the second summary question in my second post (datasheet usage).

thanks
Gil

Gil,

I am waiting to hear back from one of engineers who has done PRBS testing with this part in the past. I hope to have some information for your on Monday. Are you having issues with your serdes lanes?

Regards,

Jim 

Hi Jim,

I wrote a very detailed description of the issue.

Now, the PRBS31 checker in the DAC responds correctly to the pattern sent from the FPGA (you can see the development of events above):

The open issues now are:

1. With ALM_OUT_POL=1 we should get a constant Low voltage when all checks ok (no errors). We get a constant High.

this happens when P/N from the FPGA connects correctly to the DAC lanes (P-P, N-N).

When we reverse the polarity, so FPGA P/N connects to N/P (P-N, N-P) , then we get a constant Low.

Why?

2. We are using the MPY table from the old datasheet (Table 4 SerDes PLL Modes Selection, February 2017 version).

And, we are using SERDES_REFCLK_DIV description from the new datasheet (August 2017) which states "The divide amount for the serdes REFCLK minus 1" (the old datasheet lack the "minus 1").

Both fields above prove correct.

So: Which datasheet should we use?

Any relation to the version of build for my chip?

thanks

Gil

Jim,

When changing the PRBS31 generator to generate a non-invert PRBS31 signal (although ITU O.150 states an inverted bit stream for PRBS31), and P-P and N-N connections, it behaves as expected (Low when no errors), except for lane 1 which gives a short high pulse every some time.

Perhaps the PRBS31 checker in the DAC implements a non-inverted PRBS31 (as opposed to the spec)?

thanks
Gil

Gil,

The latest data sheet is correct in regards to using a SERDES_REFCLK_DIV divide amount  minus1. The old data sheet should have mentioned this but did not.

Other signals besides TESTFAIL can be muxed onto the status output bit0 of the SerDes (then onto the alarm pad using DTEST), using RXDSEL in the

ws_tuning chain (see p.44 of the datasheet) Is there any chance you are using RXDSEL to mux a different signal out on lane 1? For instance, if you are muxing

out PATTVSYNC, this signal pulses once per complete pattern sequence.

I am still looking into the other issues you are seeing.

Regards,

Jim

Gil,

I was informed we have an app note related to PRBS testing with our EVM. I have not had time to look at this but plan on trying it in the near future. See if this document helps with any of your questions.

Regards,

Jim

 PRBS App Note.pdf

Jim,

You replied here to my first post, while other posts follow that.

Strange.

In any case, if you see the later posts, you will see I have this application note and already used it.

Remaining questions are still there.

See later posts for this thread... https://e2e.ti.com/support/data_converters/high_speed_data_converters/f/68/t/660334 

thanks

Gil

Gil,

Sorry for the delay on getting back on this. Regarding the MPY values and data sheet issues, it appears the value that needs to be entered into register 0x43B should be the Serdes reference clock divider -1. The EVM GUI enters the value this way but display's it without the minus -1. For example, with a MPY setting of 4 the register is loaded with a 3 but the GUI will display a 4. This may be confusing to users.

In the old data sheet, the value shown for a 5x setting for the MPY is correct. This table though had issues with other settings, thus was updated in the latest revision. For reasons unknown to me, the new table swapped out binary values with hex values in the MPY column. This column also shifted the value by 1 bit. So it is now displaying a hex word using bits 8:0 of register 0x43B, instead of bits 8:1. Since only bits 8:1 are used to set the MPY value, this table is adding more confusion again. I will look into changing this back to binary in the next revision.   

I am still looking into the PRBS issue.

Regards,

Jim

Jim,

Understood. So, I will use the new MPY table.

From the hex word, I will remove the lsb '0', add a msb '0', and use that for the MPY field.

Please get back to me on the PRBS.

BTW: Why isn't the reply on this thread?

e2e.ti.com/.../660334

thanks

Gil

Jim,

Section 5.8 talks specifically about an inverted version.

I have copied-pasted this section:

5.8

2 147 483 647-bit pseudo-random test sequence

This sequence may be used for special measurement tasks, e.g. delay measurements at higher bit rates. If error

performance measurements require longer sequences, future studies shall take into account this sequence.

The sequence may be generated in a twenty-nine-stage shift register whose 28th and 31st stage outputs are added in a

modulo-two addition stage, and the result is fed back to the input of the first stage.

– Number of shift register stages 31

– Length of pseudo-random sequence 231 – 1 = 2 147 483 647 bits

– Longest sequence of zeros 31 (inverted signal)

 

Please send the following (taken from my previous posts to this engineer):

(1)

With ALM_OUT_POL=1 we should get a constant Low voltage when all checks ok (no errors). We get a constant High.

this happens when P/N from the FPGA connects correctly to the DAC lanes (P-P, N-N).

When we reverse the polarity, so FPGA P/N connects to N/P (P-N, N-P) , then we get a constant Low.

Why?

(2)

When changing the PRBS31 generator to generate a non-invert PRBS31 signal (although ITU O.150 states an inverted bit stream for PRBS31), and P-P and N-N connections, it behaves as expected (Low when no errors), except for lane 1 which gives a short high pulse every some time.

Perhaps the PRBS31 checker in the DAC implements a non-inverted PRBS31 (as opposed to the spec)?

And if so, why is lane 1 different?

thanks

Gil

Correction:
Please send the following to this engineer (taken from my previous posts)...

Gil,

I have confirmed with our software development team that our pattern generator EVM does not send the PRBS-31 data inverted. Also, the designer confirmed we expect the data to be not inverted coming to the DAC. When I setup this test on our EVM, all lanes passed. I do not know why you are having this issue. Can you swap lanes the test pattern is coming out of your FPGA to see if the error moves to another lane?

Regards,

Jim

Jim,

To see why lane 1 is problematic, I thought of using OCTETPATHn_SEL (n=0,,,7) in JESD_CROSSBARn (n=0,1) to internally swap lanes.

I require few clarifications here for that.

I am using the PRBS test in 9GSPs/8bit mode on all 8 lanes:

1. Which of the two multi-DUC is operational in this test?

Which lanes in reg JESD_LN_EN (LANE_ENA field) should I turn on? Reg 0x4A in multi-DUC1? Reg 0x4A in multi-DUC2?

Which JESD_CROSSBAR register should I program: JESD_CROSSBAR1? JESD_CROSSBAR2? (program the OCTETPATHn_SEL bits)

2. What should I program to ONE_DAC_ONLY and ONE_LINK_ONLY (register RESET_CONFIG)?

3. Please confirm:

Writing OCTETPATH0_SEL=010 on JESD_CROSSBAR1 routes physical lane0 (rxp/n0) to internal lane2.

Or the opposite: treats internal lane0 as physical lane2.

thanks

Gil

Gil,

The OCTETPATH setting will not be very useful for checking PRBS. The crossbar mux is downstream from the SERDES and JESD, and re-orders the lane data for the remainder of the data path. Since the PRBS checking is internal to the SERDES, the crossbar settings won’t have any effect on the test. Can you swap the input data, which could help verify if the error is from the input source?

Have you tried adjusting the equalizer and or gain settings of the DAC?

Regards,

Jim

Jim,

So, JESD_LN_EN (LANE_ENA field) is also not relevant to the PRBS test.
Same with ONE_DAC_ONLY and ONE_LINK_ONLY settings.
Please confirm.

I will see how to swap the input data in the FPGA.

EQ field is set to 01 which is fully adaptive. Other settings for EQ are "No equalization" and Post/Precursor equalization analysis which can affect how the transmitter data can be modified. I did not use those.
Regarding EQ[2], I have tried with and without Boost. no effect.
EQHLD is default. CDR is also default.

Any suggestions for changing equalizer related settings?

thanks
Gil