• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 192 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DP83822I: Question about BIST pattern details in 100FX

kawk
Prodigy 10 points
Part Number: DP83822I

Hi,

I'm successfully using a DP83822 in FX mode for optical communication to a "PHY" implemented in a FPGA. Now I'd like to utilize the BIST mode of the DP83822, in which it generates frames containing pseudo random sequence, to check for errors at the other end. I've been able to make the PHY emit such frames even in FX mode, but yet wasn't able to correlate the bits received in FPGA with any PRBS generation method.

Are there any details known about the PRBS generation and how the generated bits are packed into the frame? I can see J/K symbol and Ethernet preamble, followed by somewhat random bits.. But how are they generated? Using the common x^15 + x^14 + 1 PRBS15? Is there any bit/byte/nibble-reordering in effect? What methods can be used to synchronize to the pattern in a receiver?

Lower byte of register 0x1B according to documentation is 0x7D "equal to 500 bytes" (ie. effectively multiplied by 4?).

The packet length specified in register 0x1C doesn't exactly correspond to the actual number of symbols x 2 on line. There seems to be some overhead in addition to the Ethernet preamble, maybe synchronization info?

I'd appreciate if someone could help me with more details.

Thanks in advance!

Kolja

  • 0
    TI__Genius 17355 points

    Hi Kolja,

    • PRBS is internal implementation, we are not able to share it externally
    • Yes you are correct, 7D represent 500 bytes
    • the value in register 1C corresponding to the data payload size.

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Thanks for the quick, altough disappointing reply.

    The actual packet grows by more than 1 byte per increment in register 0x1C; the factor rather seems to be 3/2 ? Padding? Headers?

    Even if you may not provide me all details... am I correct to assume it is just based on common PRBS15 poly and LFSR, or does it do some extra processing, maybe some special, error-provoking bit patterns?

    Want to know just for internal, non-public testing functions.

    Thanks!

    Kolja

  • 0 in reply to kawk
    TI__Genius 17355 points

    Hi kawk,

    • PRBS generation is based on LFSR.
    • Did you mean by 1 byte increment in register 0x1C is actually 3/2 bytes incrementation? How did you measure it? What is the reason you are asking for this question?

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    > How did you measure it

    I count the symbols received in my "PHY" implemented in FPGA after J, K and preamble 5 5 5 D 5, emitted by PHY in FX and BIST mode configured for analog loopback. A protocol analyzer would show the same:

    •  0x10 in register 0x1C => 56 symbols after preamble (16 + 8 + 4 byte)
    •  0x20 in register 0x1C =>  96 symbols after preamble (32 + 12 + 4 byte)
    •  0x30 in register 0x1C =>  136 symbols after preamble (48 + 16 + 4 byte)

    It looks like I get 1,5 byte for each 1 byte set up in register 0x1C plus 4 extra byte, maybe FCS.

    I would like to understand if and how I could possibly build logic for validating the received bitstream, e.g. for bit error rate tests, or even generate a similar bit stream in FPGA that could be verified by the DP83822.

    The goal is to extensively test an optical link between a moving and a static part inside a device, which is implemented with CPU+DP83822 on one side and FPGA on the other.

    Thanks for your help,

    Kolja

  • 0 in reply to kawk
    Prodigy 10 points

    Found an error in my receiver; I recorded its MII output using a slightly wrong clock. That explains the 3/2 factor... some nibbles were counted twice.

  • +1 in reply to kawk
    TI__Genius 17355 points

    Hi kawk,

    Glad that works for you.

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Yes, now the number of bytes in received packet is consistent with the length configuration.

    However, I'm still unable to correlate any self-generated PRBS15 with the bits in the packet. I tried inverting bits, reversing bit order, nibble order, various generator polynoms, without success yet..

    My naive idea was (during experimenting) to build up a reference vector of bits using the probably most common PRBS15 with taps at 15 and 14, then build another vector from the nibbles received at MII rxd(3..0), and try to locate that received bit vector in the reference vector by correlation.

    Kolja

  • 0 in reply to kawk
    Prodigy 10 points

    Finally I made some *electrical* improvements (the output swing in my test setup wasn't sufficient for the FPGA input, although it first seemed so) and can now match the packet contents emitted by the DP83822 with sequence just as I described in my previous comment.

    Thanks for your input and keeping me on the LFSR track.

  • 0 in reply to kawk
    Prodigy 10 points

    One last observation: With register 0x1C set to 0x100 (256 Byte = 2048 Bit payload), the pointer into PRBS15 reference (where the packet content equals the reference  bits) advances by 2044 Bit per packet, not 2048..

  • 0 in reply to kawk
    TI__Genius 17355 points

    Hi kawk,

    Thank you for letting us know. We will double check on that. If possible, Could you let us know what is the procedure that you did to count the bit per packets?

    --

    Thank you,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 10 points

    Hi,

    my homebrew 100BASE-FX receiver in FPGA currently outputs received nibbles RX_D(3..0) and RX_EN, as in MII. I can record the output using embedded debug tools. The data received from a DP83822 in BIST mode appears as follows (each hex digit represents one received nibble, this example is taken from an actual received packet):

    • preamble: 55555555555D5
    • data: A5D9DCD4CAFABE1F...ADCDECAC6BE97877 (511 nibbles)

    Before and afterwards my receiver's RX_EN is deasserted. One could suspect that one nibble is simply lost in that custom logic, maybe RX_EN deasserted too early.. but a check of the data against PRBS15 reference confirms just 2044 bit (511 nibbles) per packet.

    An irritating nibble is the '5' following the 'D' at the end of preamble/SFD. It appears in every packet and definitely is not part of data (doesn't match anything in PRBS), but shouldn't preamble/SFD with the 'D' nibble? I do not have any grouping/reordering of nibbles into bytes in my receiver path...

    I used the following values to enable BIST in the DP83822 registers:

    1. [0x1B] = 0x0020
    2. [0x1C] = 0x0100
    3. [0x16] = 0x7108
    4. [0x1f] = 0x4000

    Regards,

    Kolja

  • 0 in reply to kawk
    TI__Genius 17355 points

    Hi Kolja,

    Thank you for letting us know the procedure information.

    --

    Thank you,

    Hillman Lin