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.

DAC38J84EVM: SYSREF to NCO phase reset delay inconsistency

Part Number: DAC38J84EVM
Other Parts Discussed in Thread: DAC38J84

Hi,

I am using the DAC38J84 on the EVM with an Arria10 dev board and for now, the JESD part works fine. However I am facing a problem using the NCO on this DAC. For my project, I plan to use the NCO to shift the input frequencies to higher ones and I need to really control the phase of the NCO output, that is I need to have a constant time between the NCO reset assertion and the NCO output phase reset with the device clock and interpolation used. 

To do that, I use the SYSREF sync source on the Mixer AB, Mixer CD and NCO Acc. Here are the steps to achieve the test that I am doing :  

  1. Program the FPGA with an image containing a JESD204b TX.
  2. Establish the JESD link between the EVM and FPGA.
  3. Once the link has been established, disable the SYSREF syncing to the clock dividers and the and to the JESD link0 
  4. Change the pulser to be only 1 pulse 
  5. Use the constant input to the dac option 
  6. Configure the NCO 
  7. create a SYSREF pulse by using the Sysref trigger button on the EVM.
  8. Use the falling edge of the SYSREF pulse as trigger and capture the DAC A output. 
  9. Monitor the time between the falling edge trig point and the point  of phase disruption of the output sine.

Doing this, the time seems to vary quite a lot (up to 10ns). Is this something expected from the EVM? Is this due to the AC coupling of the SYSREF on the eval board?  Is there a way to have a constant time between sysref and nco phase output reset? 

Thanks!

  • HM,

    See attached file.

    Regards,

    Jim

    Dual_DAC38J84_NCO_test.pptx

  • Thank you for your response.

    I redid the test following the steps especially starting from slide 10 and I still have the problem with the time varying. The variation is quite small, around 5ns (in the slides, the time base is 100ns /div and in my test, I have it at 5ns/div). By variation I mean that if I repeatedly send sysref, the time changes with each sync.

    Here are oscilloscope's screen for my test, showing the extremes (latest and earliest for around 10 syncs that I did) : 

    Is this variation to be expected from the EVM?

    Regards,

    HM

  • HM,

    For the NCO’s to maintain synchronization,  the NCO tone must be a factor of 2 multiple of the SYSREF since the NCO counter will reset  after every rising edge of SYSREF. is this the case with your test? If not, give this a try.

    Regards,

    Jim

  • Jim, 

    I'm sorry but I don't really understand what you mean by the NCO's maintaining synchronization. 

    If a single pulse sysref gives out slightly different time between sysref and NCO phase output reset everytime sysref is applied, then I can't see how the continuous SYSREF will bring any difference.


    Anyhow, in this project, I can't use the continuous SYSREF so it really is about the constant and precise time between the rising edge of a single pulse of SYSREF and the NCO phase output reset. Is this something related to the EVM (on how the SYSREF is wired between the DAC and the LMK) or is it related to the DAC itself? 

    Is the default value for the SYSREF delay in relation to the device clock going to the DAC (clkout 2 and 3) respecting the setup and hold time needed by the DAC or can this be the culprit? Currently I am using the default values of the LMK that are calculated by the DAC3xj8x gui. 

  • Also, just to test out, I tried the continuous SYSREF but intentionally with the NCO output not being a multiple of the SYSREF so that we can see the phase disruption. As expected, the reset time varies by 5ns between the latest and the earliest. I tried playing around with the SDCLK delays but that didn't solve the problem.

    So here we can see the phase disruption :

    And if I zoom in, the 5ns "jitter" is present :

  • HM,

    What I sent was for a continuous SYSREF which appears you are not doing. This issue may be related to the LMK device like you are mentioning. When you issue a single pulse, there may be a chance this is not always occurring at the same time with respect to the device clock. I would submit this question to the high speed clocking forum to get a better understanding of this.

    Regards,

    Jim  

  • Jim, 

    I actually tried that just after I wrote my first reply (cf the 2nd part). I also noticed something : if I superpose the waves by using the infinite sample accumulation of my oscilloscope, there seems to be only 3 values of reset times : latest, earliest, and one in the middle.

    I don't know how to interpret this regarding the DAC and its nco reset signal sampling but maybe it has something to do with it?

  • HM,

    See page 10 of attached document. Try the same test with NCO tone a factor of 2 multiple of the SYSREF.

    Jim

    7651.DAC38J84 SYSREF Configuration.docx 

  • HM,

    Since the DAC uses the rising edge of SYSREF, you should be using this edge for your trigger in case the pulse varies for some unknown reason. We are going to set this up in our lab and try to duplicate this test. You may be hearing from another engineer regarding this as I will be out on vacation soon.

    Regards,

    Jim

  • Jim, 

    The test was done with the rising edge of SYSREF being the trigger. 

    Just to be sure, I also used the falling edge of SYSREF and that gave the same result. 

    Thank you, I'll wait for the reply then.

    Have a good vacation.

    Regards, 

    HM

  • HM,

    I was able to get this tested with what equipment I have available at home. With my scope, I am measuring about 313ns of delay pretty consistently. I am using a scope probe on the trace between C91 and R83 since J19 is AC coupled and a single pulse is not getting through.

    What are you using for the trigger test point?

    Regards,

    Jim

  • Jim,

    Somehow on my setup, SYSREF still got through the AC coupling on J19, maybe it's because of my clock setup.

    Nevertheless, I tried the single shot test again by probing the same point as you and by using the midway of the rising edge (and I repeated the test with the falling edge) and I still get the same problem, still seeing the inconsistencies of this 5ns. 

    Regards,

    HM.

  • I think that my problem comes from the LMK0428's setting.

    If I understood the LMK correctly, the 'SYSREF Divider' divides the VCO output. The "DCLK Dividers' are also dividing this same VCO output so if SYSREF Divider is not a multiple of the DCLK Divider it is referenced to, then I would see 'phase' movements of the SYSREF in relation to the DCLK. I guess this is what is making my reset time inconsistent.

    The default value for the parameter I chose on "quickstart" for the 'SYSREF divider' is 160 and for the dac device clock, DCLK divider is '3' so I guess that's why I am seeing this problem. I will need to look more into the LMK's functionalities and JESD204B subclass 1's requirement for SYSREF to make sure that I am doing things correctly. I wonder though how the DAC28j84 GUI calculates the SYSREF divider value.

    Hopefully this can help you shed some light on this problem?

    Thanks!

    Regards, 

    HM 

  • Hi HM,

    I believe you are looking at the potential issue.

    Currently, the device clock divider is set to 3, the SYSREF divider is set to 160. 160/3 = 53.33… so the phase between device clock and SYSREF isn’t constant. The SYSREF frequency is being generated by the SYSREF divider running at 18.432MHz. Even in pulser mode, the only thing the pulser is doing is temporarily letting one cycle of that divider output through to the SDCLKoutY outputs. So the SDCLKout3 edge phase, with respect to the DCLKout2 edge, is going to be one of three different possible values. This could be causing a setup and hold violation for the SYSREF signal, and provides a possible explanation for the ~10ns (one DCLK cycle) variation in observed NCO reset time. As long as SYSREF_DIV / DCLKout2_DIV is an integer, that would work.

    Regards,

    David Chaparro