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.

  • Resolved

DAC3282 EVM with Spartan 6 SP605

Prodigy 40 points

Replies: 7

Views: 1238


I am using the DAC3282 Evaulation module with Xilinx's SP605 Spartan 6 SP605 board via the FMC-DAC Adapter rev D. I have gotten to point of getting an output from the DAC EVM into a Spectrum analyzer. I use the DAC3282 GUI software to configure the DAC-EVM.

I use a waveform generated with Matlab of varying frequencies hard-coded into my VHDL code with a select statement. I believe my sample frequency is 76.8Mhz or one  half my Data Clock. One test frequency uses 4 samples per period, giving a single tone at 19.2Mhz. The resulting spectrum looks just about correct, however there is a large amount of harmonics of 4.8MHz, most of which are only 20dB down from the desired tone. If I use a lower frequency, the desired tone becomes indistinguishable from the harmonics.

My frequency settings are as follows:

Mod Ref In Div: 8 -> 76.8 MHz

Dac Clock DIV: 4 -> 153.6MHz

FIFO OSTR div:  64 ->9.6MHz

TSW3100 (FPGA) clk div: 4-> 153.6MHz

Test Port div 8-> 76.8MHz

 I have tried a few different divisions for the OSTR signal and the FPGA clk but this is the configuration i believe to be correct. I read a FIFO collision flag in the GUI, but I am unsure of what could be causing collisions.

I have seen requests for HDL for various devices, if reference material exists for the DAC3282 EVM that would helpful.

Any help would be appreciated,


  • Jayme,

    At 1x interpolation, the DACCLK is 1/2 of the DATACLK rate due to DDR quad interleave input bus structure. However, your CDCE62005 setting set the DACCLK at 153.6MHz. This is different than the 76.8MHz DACCLK that you have mentioned. You may want to double check your clock setup.

    You may also want to check the input bus timing to verify if the setup/hold time error causes glitches at multiples of 4.8MHz. Measure the DATACLK and any data bits (preferably LSB for faster toggle rate) to check setup/hold time. 

    Below list the test procedure for IO testing. If any of the bits from the LVDS data input do not match the pre-programmed keys, then the error will show up in configuration8. You will need to clear the register by writing all 0s, then read back to check to see if there are any errors.

    The steps to program the DAC for IO Pattern checker are:

    1. program the IO pattern checking keys (configuration9 to configuration16)

    2. enable IO Pattern checking (config1, bit2)

    3. optional: enable alarm_out (config0, bit2) Keep in mind this disables 4-wire mode

    4. optional: unmask alarm_from_iotest (config6, bit3 set to 0).

    5. start sending pattern from FPGA, with FRAME pulse indicating the first sample. these are the patterns programmed from config9 to confi16

    6. after about 100 clock cycles, clear config7 and config8. Read back config7 and config8 to see if there are any errors.

    7. repeat with new patterns if necessary

    You may refer to the following app note for interfacing FPGA with DAC3482:

    The input bus pattern may be different, but you can change it accordingly.


  • In reply to Kang Hsia:

    Thank you for your quick reply.  

    I apologize I  forgot to mention that I have the interpolation set to 2x and 76.8MHz is the sample rate pre-interpolation. With this change, do all the clock settings make sense, in particular the OSTR? Should OSTR and the FRAME signal be the same frequency?

    As for the IO testing procedure, because I am using the DAC3282EVM, my serial interface with the board is through USB and with the DAC3282 GUI. Is there a method for individual register control through the EVM's USB with or without the GUI? Because serial is coming from the PC, 100 clock cycles is all but impossible, is any length of time after this acceptable?

    Thanks again,


  • Hi Jayme,

    With 2x interpolation and input rate per A or B channel of 76.8MSPS, the DACCLK should be running at 153.6MHz. I believe that you have set the clock correctly. Just to make sure we are referring to the same terminology, I have attached a document referring to the clock rates.

    The OSTR rate should be slower than Fdac/(n*interpolation*8) or Fdac/n/16 in your case. WIth /64 of 9.6MHz, you have set this correctly as well. You may set the FRAME rate the same as the OSTR rate.

    Regarding the IO Testing procedure, the 100 clock cycles is just a suggestion. Ideally, the longer the time frame to better to get a good understanding of bit error. While the input pattern feature is enabled on the DAC side and the test pattern is running continuously, you can clear the alarms by clicking on the radio buttons of the GUI. If you can clear the alarms, this means the input pattern is registered correctly. If the alarm is high consistently, then you will need to check the setup/hold time of the input bus. Once you achieved error free  operation for a given amount of time (the physical time to clear the alarms on the GUI should be sufficiently long when compared to 76.8MSPS of input rate), your input bus should be operating correctly. 


  • In reply to Kang Hsia:


    DAC3282-3 Byte Wide DDR Clocking.pdf
  • In reply to Kang Hsia:

    Thank you I will be testing the IO in this method.

    There are 2 radio buttons for each alarm: Mask and Status. Status seems to indicate the alarm; is status the one that is clicked to clear the alarm? What is the function of the mask button?

    I am assuming the drop down box TXENBALE/Alarm should be set to Alarm and the IO test enabled. Is this correct? Is there any other settings that I need to change?

  • In reply to Jayme Christensen1:


    The status alarm is the alarm that you need to clear. The masking is used to mask the alarms from triggering the ALARM/SDO pin. Typically in a system, there are two types of alarms: polling and interrupt service routine. The polling process can check the alarms in CONFIG7 at some time interval. However, there may be some critical alarms such as FIFO collision that cannot be missed in between the polling process. Therefore, you will need to unmask the critical alarms so these alarms will trigger the ALARM/SDO pin for the interrupt service routine (ISR).

    By default, the Alarm for the ISR is disabled. You will need to enable it for the ISR. For IOpattern checking, you may not need to use the ISR. Polling process would work fine since it is not a critical alarm.


  • In reply to Kang Hsia:

    It does not seem that clicking the radio button is clearing the ALARM flags. I have when I initialize the board the FIFO collision flag is active, regardless of whether the FPGA is connected or not. Using the IO TEST gives me an ALARM as well. If I exit IO test mode and try to clear the flag, the flag persists. It appears to me that this is a LabView VI, is the source VI available for this?



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.