• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 1062 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.

DAC38J84: Difficulty Establishing JESD Link

Todd Rockoff
Intellectual 480 points
Part Number: DAC38J84
Other Parts Discussed in Thread: ADC16DX370

Dear Supporters,

I am working with a custom integration of Arria 10 SoC Dev Kit with Abaco FMC144.

Clock generation and A-to-D conversion are performing OK, but no luck yet with the JESD link to the DAC38J84.

SYSREF is a 2-pulse train at 1/32 the frequency of DACCLK, which is 148.5MHz.

K = 32 in our setup, LMF is 442.

SignalTap shows that the JESD link with the DAC chip is briefly established, but then this behavior repeats indefinitely: the DAC chip asserts SYNCb, then deasserts SYNCb after receiving a sequence of K28.5 symbols, but then reasserts SYNCb at varying points during the ILA sequence, usually in the 3rd multiframe. A snapshot of the lane alarms taken just after the SYSREF pulses shows only Frame Alignment error in 1 or 2 lanes, while the other error flags are clear.

Based on a prior thread, I have tried clearing 0x51[7:0], which should suppress any error from triggering SYNCb. However with this setup, SignalTap shows SYNCb to be illegally asserted for short durations.

Can you please provide some insight as to what causes this SYNCb behavior?

Hopeful thanks --todd

  • 0
    TI__Guru 65944 points

    Todd,

    we will get back to you within the next day or so.

  • 0
    TI__Guru 65944 points

    Hi Todd,

    If you can provide signal tap waveforms to demonstrate the errors that you are seeing, it will help with the debug process better.

    In the JESD204B standard, the link establishment goes through the following phases:

    1. SYNC event triggered by the JESD RX (DAC),

    2. CGS (JESD TX sends K28.5)

    3. SYNC de-asserted by JESD RX after recognizing 4x consecutive k28.5 char successfully.

    4. SYNC continue to be de-asserted after completion of ILAS

    ILAS sequence check include the specific LMFS identification code in the 2nd multi-frame of the ILAS sequence (it contains essential information for the link)

    see example below:

    4885.DAC3xJ8x ILA Sequence.xlsx

    The passing of ILAS requires the identification code from the JESD TX (FPGA) to send specific LMFS information as programmed on the DAC side. The identification codes from the JESD_TX must match the DAC programming. Otherwise the DAC will flag it and pull SYNC low again. The identification code is essentially the same among the lanes, except the lane ID should be unique

    For debugging purpose, we can essentially ask the DAC to "ignore" the ILAS sequence so it continues to go through ILAS even though the IDs are mismatched. 

    Note: we do have a mode where we skip ILAS completely. There is a difference between skip and ignore. Skip means the JESD_TX completely skips the ILAS stage. This was used to potentially be backwards compatible with 204A standard.

    We can do so through the following GUI configuration:

    (note: you can get the configuration register settings on the lower left corner of the GUI after you click on various buttons.)

    There is also another stage where the release buffer are set after all the lanes arrives. The release code comma character /R indicates the start of the buffering. Once all the lanes /R characters are received, the RBD will be released. It is possible that you have to adjust the RBD to allow optimization of delay due to various skews in your overall system.

    Lastly, you mentioned there are illegal assertion of the SYNC. There are two types of sync activities: one is sync request, another one is error reporting. SYNC request is at least 5 frames + 9 octets, and indicates a critical error to the JESD TX to indicate that re-link is necessary. Error reporting is basically a quick error message to the JESD_TX to be aware of the situation (2 frames maximum). They are set the same as the picture that you are seeing above. You can disable error reporting if you wish. 

    I have attached some slides to help you understand the difference.

    7230.DAC3xJ8x JESD204B Sync Request and Error Report.pptx

  • 0 in reply to Kang Hsia
    Intellectual 480 points

    Dear Kang,

    Thank you for this prompt and comprehensive reply, highlighting several potential reasons for the link establishment failure. The PPT is a valuable reference, and the XLS is a useful tool for checking the configuration parameters.

    One error in the JESD TX FSM communicating with DAC38J84 is immediately apparent: The JESD TX FSM should revert to CGS only if SYNCb is asserted for at least 5 frames.

    Another potential error is in the Lane ID values: All four lanes have LID = 0, for simplicity; DAC registers 0x46 and 0x47 are programmed accordingly. Is this setting of Lane IDs a severe error for DAC38J84? In that case, the JESD TX FSM can be adjusted such that each lane sends a unique LID.

    I also have a question regarding the match character /R/ (0x1C) as a release code for the RBD. What are the consequences of programming 0x4F to 0x1C41, to begin buffering immediately after the final /K/ character?

    The next time I request further help debugging the JESD link configuration, I will paste a SignalTap trace for your reference.

    Looking forward to your replies to my follow-up questions.

    Thanks again --todd

  • 0 in reply to Todd Rockoff
    TI__Guru 65944 points

    Hello Todd,

    The ILAS sequence failure (i.e. the failure to recognize the ID codes in 2nd Multi-frame) will be sufficient to trigger SYNC_REQUEST over SYNC line if the DAC is programmed in such fashion. Typically, we recommend the customers to simply ignore the ILAS. The function of ILAS is to simply provide redundancy check, in my opinion. I never quite understand the true nature of ILAS ID check. All I know is that it create more problems in bring-up than actual cross-check.

    Todd Rockoff said:
    I also have a question regarding the match character /R/ (0x1C) as a release code for the RBD. What are the consequences of programming 0x4F to 0x1C41, to begin buffering immediately after the final /K/ character?

    We recommend the user to keep at the default to allow /R/ code to be the release code of the buffer to comform with the standard. You are correct that this is the intend of the buffer.

    -Kang

  • 0 in reply to Kang Hsia
    TI__Guru 65944 points

    Hello Todd

    please allow me to close the post for now. You may always reply back to re-open the post. thanks.

    -Kang

  • 0 in reply to Kang Hsia
    Intellectual 480 points

    Dear Kang,

    Sorry for my long delay getting back to you. I have been trying different configurations of the JESD transmitter, based on observations of the output received from the ADC16DX370 JESD transmitter.

    It looks like the Arria 10 SerDes is normally "small-endian", sending the low-order byte first. However, the JESD specification seems to be "big-endian", expecting the high-order byte first. I assume that DAC38J84 is the same way.

    With 0x51 programmed to 0xFF, all four lanes report report Code Synchronization and 8b/10b Disparity errors, and no other errors.

    With 0x51 programmed to 0xFA to ignore those two errors, those errors are still reported, in addition to Elastic Buffer and Char mismatch.

    The repeating behaviour is that the DAC38J84 deasserts SYNCb, then reasserts SYNCb near the end of the 1st ILAS multiframe, as shown in this SignalTap capture:

    This SignalTap capture is a zoom in to one of the iterations of the repeated sequence shown above:

    I would be grateful for any further insight you might be able to offer.

    Hopeful thanks --todd

  • 0 in reply to Todd Rockoff
    TI__Guru 65944 points

    Hi Todd,

    the minimum required sync request error check is to have 8b/10b encoding disparity/not in table error and also the CGS error. Without these 3 checks, the JESD204B state machine will not run properly. These are the required JESD204 protocol.

    You may refer to the below firmware of our TSW14J56 EVM utilizing Altera Arria 5

    We also have Arri10 based TSW14J57 firmware you may refer to as well

  • 0 in reply to Kang Hsia
    Intellectual 480 points

    Dear Kang,

    Thank you for reinforcing the importance of the essential requirements and for providing the reference designs.

    Good news here: I am delighted to report that the DAC chip is now passing ILAS and producing data.

    For the benefit of others following this path: Even though Arria 10 PHY Byte Reversal is required on the FPGA receiver to accommodate ADC16DX370, and therefore on the FPGA transmitter for testing through an FMC Loopback connector, it appears that FPGA transmitter byte reversal should be *disabled* while sending to DAC38J84. Also, the ILAS symbols need to be organized in a "little-endian" manner sending to the DAC chip.

    With FPGA SerDes transmitter byte reversal disabled and the earlier byte of each pair placed in the low-order position of the pair, with DAC38J84 registers 0x51 and 0x52 programmed to 0xFF (allowing all lane errors to generate SYNCb and to count), the JESD link establishment process proceeds normally: DAC38J84 asserts SYNCb only once following the SYSREF pulse train and begins to produce data following the ILAS, and all of the alarm bits for all four lanes are clear following JESD link establishment.

    The data coming out of the DACs doesn't yet look as expected, but that must be a separate issue; this JESD link establishment issue is resolved.

    With gratitude for your candid and comprehensive support --todd

  • 0 in reply to Todd Rockoff
    Intellectual 480 points

    For completeness and in the hopes of not confusing anyone who may be seeking a similar solution, I am writing to rectify my previous comment regarding establishing the JESD link between Arria 10 and DAC38J84 on FMC144.

    What I wrote earlier is incorrect. Per the Frame Assembly diagram in Table 9 of the manual, is that the DAC38J84 JESD link is big-endian when F>1, expecting the high-order byte of a pair to arrive first. This organization is consistent with the ADC16DX370 and with all other JESD documentation that I have read.

    The Arria 10 8b/10b encoder for pairs of bytes is little-endian, encoding the low-order byte first. PHY TX Byte Reversal is not effective, because it is applied *after* the 8b/10b encoder, which results in 8b/10b disparity errors at the DAC38J84 SerDes receiver.

    The correct solution for this issue is not to apply Byte Reversal on either the TX or the RX. Instead, the correct solution is to swap high-order and low-order bytes by simple routing inside the FPGA. The "kbit" control symbol identifier should be routed along with the data byte to which it refers.

    Cheers --todd