• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 5330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DAC37J82: Initialization Set Up

Mark Guastaferro
Genius 11645 points

Part Number: DAC37J82
Other Parts Discussed in Thread: DAC37J84

The DAC37J82 is being used with the following Serdes configuration:

LMF = 421, S=1, HD=1, interp = 1. DAC PLL is bypassed. 

When following the Initialization steps in section 8.3 in the data sheet, step 12 calls for checking the SERDES PLL lock status. This check returns 0 for both rw0_pll and rw1_pll.  Is this expected considering lanes 7:4 are not being used (rw1_pll)?

Are there other things that can be checked at this point to verify that things are in a good state?  

  • 0
    TI__Guru* 91947 points

    Mark,

    What is your DAC sample rate? What is your "K" value? What frequency is SYSREF?

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Genius 11645 points

    Hi Jim

    Sample rate is 925 MHz

    SysRef is something like 11.5625 MHz

    K = 32 (I think)

  • 0 in reply to Mark Guastaferro
    TI__Guru* 91947 points

    Mark,

    If using K = 32, you must set the RBD to 32 and SYSREF must be 28.90625MHz or a integer divide of this. The SYSREF you are using will work for K and RBD = 20.

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Genius 11645 points

    Hi Jim,

    We are double checking the RBD  and K value setting.

    Assuming these get set properly and going back to the original question, what would be the expected alarm readings for rw0_pll and rw1_pll when running through the initialization steps?

  • 0 in reply to Mark Guastaferro
    TI__Guru* 91947 points

    Mark,

    After writing a 0 to config108 to clear the alarms, I did a read and got back a 0x07 with our setup, which is rw0_pll = 0 and rw1_pll = 1, indicating pll1 is not locked, which is true as this pll is not used in the 4 lane mode. When I switched to 8 lane mode, this value read back as 0x03, indicating both serdes blocks are locked.

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Genius 11645 points
    Hi Jim,
    I have an update on this issue. There are still some SerDes alarms that we need help with.

    The lane configuration has been changed from the initial post . Here are the latest settings:
    LMF = 1 2 4 (only one SerDes lane)
    Input sample rate = 231.25 M DAC set for 4x interpolation so DAC rate = 925 Msps
    K = 32
    SYSREF = 7.2265625 MHz

    With RBD = 32, there are two alarms from the DAC and the SYNC de-assets.
    First alarm is an elastic buffer overflow. If RBD is set between 17 and 29, this alarm goes away. This seems to correct this issue, but I had the assumption the RBD = K was a safe setting as it provides the maximum buffer delay. Is this indicating some other configuration issue ?

    The second alarm is a link configuration error, which occurs regardless of the RBD value. Since only one lane is being used, the other lanes are disabled, but no other changes are made to their default settings. Could the default settings of the disabled lanes cause the configuration error?
    I have requested the DAC configuration settings for review.
  • 0 in reply to Mark Guastaferro
    TI__Genius 11645 points
    Hi Jim,
    I received the DAC configuration and a capture of the signal tap from the Altera FPGA. The ILA link configuration data matches the DAC configuration registers, plus I used the spreadsheet tool I found in another forum post to double check these as well as the checksum. I can share these if needed.
    Any suggestions as to what else would cause link configuration errors with the Altera interface? We are reviewing the Altera/DAC compatibility report that was done one the DAC37J84.
    We also noticed that bit 0 of config100 (read_empty) is also high after ILA. Not sure what this means and if it is related to the other errors.
  • 0 in reply to Mark Guastaferro
    TI__Guru* 91947 points

    Mark,

    Please send the DAC config files and I will duplicate there setup and see if I have any issues.

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Genius 11645 points

    Register settings are in the attached text file

    Fullscreen DAC37J82-reg-config.txt Download 
    0x002C; #Config26
0x1000; #Config49
0x0800; #Config59
0x1828; #Config60
0x0088; #Config61
0x0108; #Config62
0x0044; #Config70
0x190A; #Config71
0x31C3; #Config72
0x011E; #Config74
0x2000; #Config37
0x0040; #Config36
0x52B8; #Config0	
0x5080; #Config3	
0x1E03; #Config75
0x1F00; #Config76
0x0100; #Config77
0x0F0F; #Config78
0x1CC1; #Config79
0x00FF; #Config81
0x00FF; #Config82
0x4444; #Config92
0x0001; #Config97
0x2002; #Config2	
0x0000; #Config8	
0x0000; #Config9	
0x0000; #Config10
0x0000; #Config11
0x0400; #Config12
0x0400; #Config13
0x0400; #Config14
0x0400; #Config15
0x0000; #Config16
0x0000; #Config17
0x0000; #Config18
0x0000; #Config19
0x0000; #Config20
0x0000; #Config21
0x0000; #Config22
0x0000; #Config23
0x0000; #Config24
0x0000; #Config25
0x0000; #Config27
0xFFFF; #Config30
0xE0EE; #Config32
0x1BAB; #Config34
0x01FF; #Config35
0x0000; #Config38
0x0001; #Config45
0xFFFF; #Config46
0x0000; #Config48
0x0000; #Config4	
0xE403; #Config5	
0xFFFF; #Config6	
0x0000; #Config110 
0x0000; #Config111 
0x0000; #Config112 
0x0000; #Config113 
0x0000; #Config114 
0x0000; #Config115 
0x0000; #Config116 
0x0000; #Config117 
0x0000; #Config118 
0x0000; #Config119 
0x0000; #Config120 
0x0000; #Config121 
0x0000; #Config122 
0x0000; #Config123 
0x0000; #Config124 
0x0000; #Config125 
0x0000; #Config100
0x0000; #Config101
0x0000; #Config102
0x0000; #Config103
0x0000; #Config104
0x0000; #Config105
0x0000; #Config106
0x0000; #Config107
0x0000; #Config108
0x5081; #Config3	
0x0000; #Config100
0x0000; #Config101
0x0000; #Config102
0x0000; #Config103
0x0000; #Config104
0x0000; #Config105
0x0000; #Config106
0x0000; #Config107
0x0000; #Config108
0x52BC; #Config0	 
0x0000; #Config100
0x0000; #Config101
0x0000; #Config102
0x0000; #Config103
0x0000; #Config104
0x0000; #Config105
0x0000; #Config106
0x0000; #Config107
0x0000; #Config108
0x0101; #Config74

  • 0 in reply to Mark Guastaferro
    TI__Guru* 91947 points

    Mark,

    Is this using the DAC PLL or external clock mode? If PLL, what is the reference clock frequency?

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Genius 11645 points
    Hi Jim,
    DAC PLL is not being used (external clock mode).
    SerDes PLL is being used, reference frequency is 925 MHz.
  • 0 in reply to jim s
    TI__Guru* 91947 points
    Mark,

    Have them try using a K = 16.

    Regards,

    Jim
  • 0 in reply to jim s
    TI__Genius 11645 points

    Hi Jim,

    They found some timing errors in the FPGA set-up and now have the link errors are corrected, even with K= 32.  Also ran a JESD test pattern with D21.5 data and it it works. So it seems the SerDes link is OK. 

    Now trying to get on output on the DAC output ports. Inputting a continuous D21.5 pattern (1010 alternate), but no output.

    Can you check the configuration settings I sent earlier to see if something in the data path is set wrong?  For example, I'm not sure the input/output mux settings in Config34 are correct. 

  • 0 in reply to Mark Guastaferro
    TI__Genius 11645 points
    Hi Jim,
    Adjusting the config34 register to correct the output mux setting looks like there is now an output. Now testing other input patterns. I'll let you know if there are any new questions.