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

testing DAC3484

Ramakrishna Bachimanchi
Intellectual 300 points
Other Parts Discussed in Thread: DAC3484, CDCE62005

Hello,

I am using the eval boards from TI for DAC3484 with TSW1400. I configured the TSW1400 to be in JTAG mode by changing the resistors, so that I can do some development. I did the JTAG mostly to look at the signals on signal tap

coming to the questions, I have

1.When I connected the boards yesterday, for some reason the temperature sensor was reading 127 all the time. I touched the chip and it wasn't that hot. I am not sure what happened there. This morning I disconnected everything and connected them back and it is reading 33 deg C. My question is how do I know, if DAC3484 got damaged or not, if it was true 127 deg C. I am not sure how to do the same test that is explained in the evm testing procedure as I modified the TSW1400 board

2. Another question is, I just want to make sure I am heading in the right direction with the design parameters

I would like to generate 4x56 MHz signals at the output with no interpolation. I am using 112 MHz DDR for the DATACLK and 56 MHz for DACCLK.

If these setting are right, I am having issues with generating OSTR signal, which will be DACCLK/8 as there is no interpolation. This is more of a limitation from the CDCE62005. Is there a simpler way to handle the FIFO? I have read through the data sheet and the question is what happens, if I bypass the FIFO or use the same signal for read and write FIFO (like SYNC or FRAME). I understand there could be some timing issues, if it is done that way.

Thanks,

Ramakrishna

  • 0
    TI__Guru* 91947 points

    Ramakrishna,

    We are looking into this.

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Guru* 91947 points

    Ramakrishna,

    The DACCLK should be 112MHz and the DATACLK should be 56MHz for your case, not the other way around. What do you mean by 4x56 MHz signals? Is this four DAC's with a 56MHz tone coming out of each one? Are you still having issues with the temperature sensor? 

    Regards,

    Jim

  • 0 in reply to jim s
    Intellectual 300 points
    Hi Jim,
    Thanks for your reply. Temperature sensor is acting better (not stuck at 127 anymore) and I think the DAC is working ok.I haven't generated a tone yet, but I wrote all '0's and '1's and used the pattern test (IO test) and it works fine.
    Yes, I am working on generating 14 MHz square wave(I+,Q+,I-,Q-, 4 samples @ 56 MHz and the pattern repeats @ 14 MHz) signals coming out of each DAC (4 altogether).
    I am probably getting confused with DACCLK and DATACLK
    my understanding was if the DATACLK is 112 MHz, it takes two clock cycles to load all four channels because of the double data rate. So the DAC update rate is 56 MHz and I was thinking DACCLK is 56 MHz too as it would be pushing all the samples (all 4 channels) at 56 MHz. Please correct me, if this relation is not right
    Also it should be fine, if I send a pulse only once with strobe/frame signal on the input side to reset the input fifo pointer and indicate the first data and use the OSTR from the CDCE62005 for the output side?

    Thanks,
    Ramakrishna
  • 0 in reply to Ramakrishna Bachimanchi
    TI__Guru* 91947 points

    Ramakrishna,

    Since you are using four DAC's, the DACCLK will have to be 4X the data clock, not 2x like I mentioned in the earlier post. You could pulse the OSTR once but you must also make sure the Frame signal only pulses once as well. One resets the FIFO read pointer and the other resets the FIFO write pointer. It is probably a good idea to have both continuously running though to compensate for any data misalignment that may occur over time. Please see the attached app note for more information regarding this.

    Regards,

    Jim

     slaa584.pdf