• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 1220 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.

Why do I need to run SYSREF continuously with DAC38j84?

Scott Watson43
Prodigy 70 points
Other Parts Discussed in Thread: DAC38J84

I had an FPGA design which drives a periodic SYSREF only when SYNCB was asserted low and then only one period more when SINCB was deasserted.  In this configuration I would always get "FIFO is empty" flag alarms in each of the lane(s) i was using.  Furthermore, SINCB would never be asserted low again after the DAC was released from reset, even if I used register config74(0x4A) to request a JESD reset.  And no signal would make it through the DAC output.

I made only one change to my FPGA design to allow SYSREF to run continuously as soon as the FPGA PLLs were locked and my DAC signal output started working.

Why do I need to run SYSREF continuously in my DAC38j84 design to get JESD204B running and signals flowing?  I was not getting alarm_sysref_err bits firing in config108(0x6C).  Is it necessary to have SYSREF running as a prerequisite to get a SYNC request from the DAC?

I cleared the SYSREF masks in config5(0x5).  I opted to use all SYSREF pulses to sync clock dividers in config36(0x24). I have only one link configured and I tried 0b001 and 0b010 in config92(0x5C).

Thanks for your advice!  I am concerned that I am missing something critical that will impact the reliability of my design.

  • 0
    TI__Genius 17290 points

    Hi Scott,

    I am interested in the interface you have between the FPGA and the DAC SYSREF input. Note that the SYSREF input has a 0.5-V common mode, so it cannot be tied directly to an LVDS output.

    I believe that the DAC does need to get a SYSREF pulse before it will request SYNC. I'm fairly confident, but I'll need to double check. It sounds like you may have already confirmed this though.

    Regards,
    Matt Guibord

  • 0 in reply to Matt Guibord
    Prodigy 70 points

    Matt,

    We are using the 0.01uF in-series capacitors recommended by the DAC38j84 datasheet for SYSREF and DACCLK.  I verified the 0.5V common mode voltage using a scope probe on the DAC side of these capacitors.  The signal looks clean and surpasses the 400mV pk-pk requirement.  On the FPGA side we have a differential 1.8V SSTL Class 1 signal.

    I know that if I drive SYSREF continuously then I get dataflow.  I do not know for sure that I can start SYSREF before SYNC and then deassert SYSREF after SYNC de-assertion and still get dataflow.  (I haven't tried it yet) It would be immensely helpful to me if I could go to my management with confirmation from TI that SYSREF is required before SYNC will be asserted.  We do not expect this behavior from our understanding of the datasheet.

    Can a violation of SYSREF setup and hold requirements cause JESD204B and DAC output to stop?  We are confused about this because we have seen Altera example code using a lower rate link clock to generate SYSREF using a positive edge.  Since this clock is source synchronous with the device clock, it appears as though we are driving SYSREF exactly the right time to violate the 50ps setup and hold requirements.  Will this merely make the transmit start time non-deterministic from run to run?

    Thanks again for your help,

    Best,

    Scott

  • 0 in reply to Scott Watson43
    TI__Genius 17290 points
    Hi Scott,

    Okay, no issue with the FPGA interface.

    I have confirmed that SYSREF must be issued before SYNC will be asserted (go low). This makes sense in terms of JESD204B, since SYNC is always asserted on an LMFC edge. SYNC can't be asserted if the LMFC edge hasn't been "defined" yet by SYSREF. If an error occurs and the DAC must resync the JESD link, it will do so without receiving SYSREF. So the SYSREF before SYNC requirement is only during initial startup - really after "resetting" the DACs JESD block.

    In terms of the setup and hold question, a setup and hold violation will result in different latency from start up to start up (i.e. not deterministic). The expected variation would be 1 device clock cycle. If you don't care about deterministic latency, then you could always run the part in subclass 0 mode and avoid having to deal with SYSREF altogether, but this will result in a larger latency variation.

    Since you have to AC couple the SYSREF signal, you probably need to be careful about turning on and turning off SYSREF. Turning on and off a pulsed signal that's AC coupled could result in undesired crossing points that could be incorrectly registered as SYSREF pulses. The proper way to sequence SYSREF at startup is as follows:

    1. Hold JESD block in reset
    2. Start generation of SYSREF signal
    3. Enable SYSREF processing - set SYSREF processing and clock divider sync modes to use 1 pulse
    4. Disable SYSREF signal - could use the SYNC signal rising edge to disable SYSREF generation

    Regards,
    Matt Guibord
  • 0 in reply to Matt Guibord
    Prodigy 70 points

    Matt,

    Thank you very much for this detailed explanation! It is truly appreciated.  I implemented code and logic to start SYSREF generation while the DAC JESD is in reset.  I still have control of the DAC output as when I was running SYSREF continuously.  So I can now gate SYSREF generation and still control the DAC output.

    There is one nagging issue...

    I've implemented only one test mode, the JESD short test.  When SYSREF was running continuously, I could make all my lanes pass simultaneously, and then make each lane fail one at a time by writing the correct or incorrect pattern to that lane.  In my build/code that uses the gated SYSREF, I see failures where I don't expect them, and for a given configuration the results are always the same.  For example, when I expect all lanes to pass, lane 0 indicates failure every time, even though I am clearly driving the DAC output on that lane with a sine wave as I expect after the test is finished.  Can you think of a reason that gating SYSREF generation would cause this change in the behavior of the JESD short test?

    Thank you again,

    Scott

  • 0 in reply to Scott Watson43
    TI__Genius 17290 points
    Hi Scott,

    That is interesting. I can't think of a reason why SYSREF generation would have affected short test.

    Can you specify which lanes (RX0-7) are being used and what shorttest alarm bits are indicating failure? Is it just lane 0 indicating falure and RX0 is being used? If you can tell me the LMF mode that you're using, that would be helpful. Also, are there any other errors reported in config100-108?

    Short test requires the JESD204B frames to be packed with the appropriate data in the appropriate order. Did anything get changed in the frame packing scheme between these builds?

    If the LSBs were incorrect, you may not be able to see that with just a sine wave output. Can you measure the noise floor away from the sine wave to see if it has been degraded compared to the previous build?

    Regards,
    Matt Guibord