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.

DAC5681 Issue at power-on reset

Other Parts Discussed in Thread: DAC5681, DAC5681Z

Hi,

I have a question about power-on reset.
Does user have problem by incompletely reset of power supply pin at power-on reset? 
-> I think the case of that some pin of AVDD, CLKVDD, DVDD, IOVDD and VFUSE are reset and some pin are not reset by capacitor near the these power pin of DAC5681.

Background of this question is the following.
I posted this question for resolving below issue.

My customer sometime has FIFO_err and DLL unlock at power-on reset.
and DAC5681 output sometime has spurious as below picture.
This spurious continues once this situation is out until power-on reset again.

Best regards,
Shimizu

  • Shimizu,

    We are looking into this.

    Regards,

    Jim

  • Hi Shimizu,

    Can you ask customer to change config10 bit2:0(DLL_ifixed) parameter to different value after power on reset and toggle the config8 bit 2(DLL reset) and also try to toggle the SYNC signal.

    Regards,
    Neeraj Gill
  • Hi Neeraj,

    Thank you for your support.

    I will try to make customer change config10 bit2:0.

    and I add question.
    Q1: I want to hear your opinion about this issue.
    Do you think that this reason of spurious is for mismatching of DLL_ifixed?

    Q2: DCLK is 400MHz and CLK is 800MHz at customer .
    At first setting, To what value should customer set DLL_ifixed?

    Q3: I think that it for first setting is "000" as words of datasheet page 9.
    -> CONFIG10 = '11000000' = 0xC0 325-500 MHz
    Is it correct?

    Best regards,
    Shimizu
  • Hi Shimizu,

    Yes I think mismatching of DLL_Ifixed may be responsible for the spurs.

    The basic idea of using DLL is to skew the DCLK and DATA such that the edges(rising and falling) of DCLK are in middle of DATA( data is most stable). if there is skew between DCLK and DATA CONFIG10 DLL_delay parameter can to used adjust the two.

    After POR the config10 becomes 0x00, where as according to datasheet it should be 0xC0 for 325-500MHz. And also as I mentioned before try to adjust DLL_ifixed value. Ask the customer to adjust the config10 parameters and then use config8 bit2 DLL restart to the DLL.

    Regards,
    Neeraj Gill
  • Hi Neeraj,

    Thank you for your support.
    My cusotmer has two question below.
    Please answer me.

    Q1: Could you tell me how to adjust DLL_ifixed?
    You showed at privious post that following.
    It is only?
    >After POR the config10 becomes 0x00, where as according to datasheet it should be 0xC0 for 325-500MHz.
    >And also as I mentioned before try to adjust DLL_ifixed value.
    >Ask the customer to adjust the config10 parameters and then use config8 bit2 DLL restart to the DLL.


    Q2: In page of 23, Datasheet show that "maximum bias current and minimum delay range ".
    What is "bias current"? and What is "delay range"?

    Is bias current "Self-bias" in Figure 28?

    Best regards,
    Shimizu

  • Hi Shimizu,

    DLL_IFIXED can be adjusted by config10. Also page 9 of the datasheet gives the values to be used in config10 parameter based on your DCLK frequency. The main idea here is adjust the phase of DCLK and Data such that you are meeting the TSKEW(A) and TSKEW(B)(DCLK to Data skew) according the values shown in table on page 9 of the datasheet.

    Bias current is internal to the DLL based on value of bias current the delay between DCLK and DATA is adjusted. This bias current is the same parameter DLL_IFIXED from CONFIG10. The relationship between the bias current and delay between DCLK and data is explained on page 23 of the datasheet.

    No figure 28 in datasheet is showing something else. It is showing the DCLK signal is AC coupled and it is self bias to correct common mode voltage internal to the chip.

    Regards,

    Neeraj Gill

  • Hi Neeraj,

    At first, my customer has mistake.
    It is device name. Customer uses DAC5681z.
    Please think this issue at DAC5681z.

    My customer did tuning of DLL_ifixed.
    But The spurious issue at power-on reset occured in all tuning case(DLL_ifixed = 010, 001, 000, 111, 110 and 101).

    And About DLL unlcok, at DLL_ifixed = 000, when DLL delay is 50°~ 90°, DLL unlcok did not occur.
    But When DLL delay is over 95°, DLL unlcok occured.

    I add questions.

    Q1: Could you tell me what change by DLL_ifixed tuning, please?
          -> Is it possible that you explain in circuit level?

    Q2: In customer bench work, DLL unlock issue occurred by deference of DLL delay.
          Does DLL unlock issue have something to do with setting of DLL delay? 

          -> I think DLL unlock issue occur by DCLK quality. for the reason DLL unlock issue is not related to setting of DLL delay.
              Is it correct?

    Best regards,
    Shimizu

  • Hi Neeraj,

    I'm sorry for the many questions.
    How is the progress?

    Best regards,
    Shimizu
  • Hi Neeraj,

    How is the progress?

    Best regards,
    Shimizu
  • Hi Shimizu,

    DLL_ifixed(2:0) is responsible for adding delay in DCLKs path and the delay is inversely proportional to DLL_Ifixed value. i.e more bias current means less delay and less current means more delay.

    Yes if DCLK is not stable and DLL is not able to lock to it. it might cause that issue.

    Can you ask customer to run DAC at lower DCLK(150MHZ) and then they can disable the DLL and see if they still observe the spurs when there is power-on-reset? This will tell if it is DLL issue or not.

    Regards,
    Neeraj Gill
  • Hi Neeraj,

    Thank you for your reply.

    >DLL_ifixed(2:0) is responsible for adding delay in DCLKs path and the delay is inversely proportional to DLL_Ifixed value.
    >i.e more bias current means less delay and less current means more delay.
    ->Q1: I image this circuit as the attached file.
             I think that Unlock means the phase lock out of CK0 and CK360 of attached file circuit.
             and DLL_delay[3:0] is to select clk from CK0~CK270 of attached file circuit.
             Is it correct?

    Q2: I think this DLL_ifixed is current setting for charge pump circuit on the attached file circuit.
          Is it correct?

    >Can you ask customer to run DAC at lower DCLK(150MHZ) and then they can disable the DLL and see if they still observe the spurs when there is power-on-reset?
    >This will tell if it is DLL issue or not.
      ->Thank you for your advice.
         I ask customer this.
      

    DLL image.pptx

    Best regards,
    Shimizu

  • Yes both of your assumption sound correct.

    Regards,

    Neeraj Gill

  • Hi Neeraj,

    I answer below.
    and I add a question.

    >Can you ask customer to run DAC at lower DCLK(150MHZ) and then they can disable the DLL and see if they still observe the spurs
    >when there is power-on-reset?
    >This will tell if it is DLL issue or not.
    -> Customer disabled the DLL, then spurious issue occured.


    Add Q: About DLL_ifixed.
    How many does Delay by setting DLL_delay change by tuning of DLL_ifixed?
    For example DCLK=400MHz, DLL_delay='0000(=90°)'
    DLL_ifixed = ”100” ->?
          ”101” ->? 
          ”110” ->?  
          ”111” ->?
          ”000” ->90°   
          ”001” ->+91?°  
          ”010” ->?
          ”011” ->? 

    Best regards,
    Shimizu

  • Hi Neeraj,

     How is the progress?

    Best regards,

    Shimizu

  • Hi Shimizu,

    We cannot provide you the delay information.

    Since you mentioned the customer is seeing the issue even then the DLL is turned off, it tell me that may they are not meeting the setup and hold time for DCLK to data.

    Can you ask customer to make sure they are meeting setup and hold timing( tskew(a), tskew(b) when DLL is used) for the device as shown in table 6.7.

    Regards,
    Neeraj Gill