This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AFE58JD48: 23-bit PRBS Detail Request

Part Number: AFE58JD48
Other Parts Discussed in Thread: AFE5808A

Tool/software:

Hello E2E Support,

I am looking for more detail on the PRBS output pattern that can be specified for the AFE58JD48.  Specifically:

What is the seed (the initial value upon TX_TRIG)?

What are the transitional bit calculations (from sample to sample)?

Which bits of the 23 are output when the LVDS serializer is in 14-bit mode?

Thanks for your assistance,

Regards,

Steve C

  • Hi,

    Polynomial used is x23+x18+1

    When tx_trig is received all 23 bits set to 1 

    Output in 16x mode will be LSB 16 bits of this 23 bits

    When in 14x serializer mode LSB 2 bits  of 16bit output will be discarded . So it is prbs[15:2] of prbs[22:0]

       

  • Hi Sachin,

    I waited a couple of days to respond while I further examined the data I was seeing.  I have implemented an "expected data" circuit in my FPGA to test the incoming AFE channel data based on your response, but I am seeing anomalies in the pattern.  This occurs not only for the PRBS pattern, but also for the Ramp pattern when the device is in 14-bit mode.  In both cases, it seems to relate to a transition of bit[15] of the internal pattern (Ramp[15] or PRBS[15]).

    I am 99.9% certain that I don't have deserialization or data integrity issues.  If I select the actual AFE data instead of a test pattern, there is no indication of bit errors.  The data looks as expected.  Also, I am using a deserializer design that has worked flawlessly for over a decade using the AFE5808A.  That is why I'm initially using 14-bit data with the AFE58JD48.  I am also running at a relatively conservative sample rate of 40 MSPS.  I plan to increase the clock rate, so that is why I want to use the PRBS pattern.  In all cases, the pattern anomalies are consistent across all 16-channels of multiple AFE devices on multiple PCBs.

    Let's start with the Ramp pattern since it's the simplest case.  The ramp is 16-bits internal to the AFE, so in 14-bit mode I should see each code over 4 consecutive samples, repeating every 64K samples.  That holds true except for the 14-bit transition from 0x1FFE to 0x1FFF to 0x2000.  I consistently get the following:  0x1FFE (4 samples) followed by 0x1FFE (6 samples) followed by 0x2000 (2 samples).  It then correctly goes back to 4 samples per values until it again reaches 0x1FFE.  I have modified my "expected data" circuit to expect this anomaly and it can run all day without seeing a variation.

    For the PRBS-23 pattern, let me start by showing my interpretation of the LFSR structure:

    My VHDL is as follows:

    I have a spreadsheet of the expected and actual channel readings that I exported from an FPGA internal logic analyzer.  I can send that separately, rather than including it in the discussion forum.  It appears that there is far more data adjustment in the pattern data than just the simple LFSR feedback.

    Can you please validate my interpretation of the expected data structure for PRBS-23, and can you also verify that there is no additional data manipulation based on some determination of a "sign" bit.

    Thanks for your assistance,

    Steve Claffey

  • Steve,

    This ramp behavior is expected . This is because 16 bit (Data[15:0]) is in 2s complement format .  To make it 14 bit we drop LSB 2 bits (Data[1:0]) and add the 1st bit to 14 bit data (Data[15:2]+Data[1]) . In this case we need to make sure that when there is positive max value we should not add this bit and make it negative value .So that extra 2 samples are clamped to positive max value so you are seeing 0x1FFF (6 samples) followed by 0x2000 (2 samples).

    If we dont do this in the normal ADC data whenever it hits positive max value the rounded data will become negative mac value which is not correct.

    Same rounding procedure will happen in PRBS also .You need to add this rounding logic in your code to make the data from 16 bit to 14bit. Once this is done your results should match.

  • Thank you Sachin