DAC3162EVM + TSW1400: Channel A can't be programmed; noisily tracks whatever is programmed to Channel B

Hi,

The person supporting the DAC31x2 will be looking into this shortly.   In the meantime, I support the DAC31x4 and DAC31x1 devices, so I took a look at the datasheet for this DAC and at the EVM schematics.  The DAC3162 is a simpler device than those other DACs I support, so the usual things that I often see get in the way of initial bring-up don't apply here, such as getting the DAC FIFO reset properly, since this DAC doesn't have those features.   That leads me to suspect the setup/hold timing of the data bus into the DAC.  Since this DAC does not have a FIFO to decouple the data bus from the DACCLK timing, the data bus must meet timing around the DACCLK.   And since channel A data is captured on one edge of the DACCLK and channel B data on the opposite edge, it seems the data is fairly stable around one of the edges but not the other, and if the channel A samples are not getting latched reliably, then it would make sense that the channel B samples are seeming to bleed into channel A.  But I am not following you on what you mean by channel A appearing to 'float' when the channel B data is constant. 

The TSW1400 will have a certain default timing of the output data relative to the DACCLK set by the FPGA firmware, but for our other DACs this timing is not critical because the other DACs have the FIFO to absorb clock skews.   There isn't anything to 'program' on this EVM since there are no SPI programmable registers, so bus timing would be my first suspect.  If you have a suitable scope, you might look at the timing of the data bits to DACCLK and compare what you see to the datasheet requirements, while we are looking into this from our side. 

Regards,

Richard P.

Thank you, Richard.

This sounds about right.  I'll check on the DACCLK timing relative to some of the data lines and report back.

I might also note that at this point, I'm not fixed on the DAC3162.  I am running an experiment and any DAC EVM that is at least 12 bits and 250 MSPS for 2 channels will work for me now.  My only constraint is that I don't want to get into really high speed DACs since I don't need them.  And the DAC3162 seemed ideal for my purposes. 

However, if there's another 2-channel DAC >= 12 bits @ >= 250 MSPS that you know to be stable with the TSW1400, please suggest an EVM.  I've been at this problem with the DAC3162EVM a bit too long as it is, I'm afraid.

Regards,

Cliff

Cliff,

I have a DAC3162EVM connected to a TSW1400EVM and able to capture data just fine on both IOUTA2 and IOUTB2 SMA's with an input sample clock of both 250Msps and 500Msps. The sig gen is set to 12dBm of output power. On HSDP Pro GUI, make sure the DAC Option is set to Offset Bin and the correct sample frequency is entered in the Data Rate (SPS) box (see attached). Make sure the jumpers on the board  are setup as follows:

JP27 pins 1-2

JP25 pins 1-2

JP26 pins 1-2

JP4 open

JP24 pins 1-2

JP1 pins 1-2

JP2 pins 1-2

If you think there may be a problem with your EVM, we can replace it with a new one.

Regards,

Jim

DAC3162 HSDC Pro Setup.pptx

Thank you, Jim.

I have verified all the jumpers on the DAC3162EVM are as you specified and have checked and verified all voltage TPs on both DAC3162EVM and TSW1400.  I have, in fact, touched no jumpers on any EVM or TSW1400 since I received them. 

The only thing I haven't yet checked is the DACLK as Richard had suggested.

I really am stumped here.  I have good, clean 5V going to TSW1400 and DAC3162EVM, and my HSDC GUI looks just like yours (except different waveform).  My external CLK to EVM is a pure 250 MHz sine at +13 dBm.  Varying the amplitude of that CLK between +7 dBm and +14 dBm has no effect on the issue (and that is all within spec for the CDCP1803, so this is to be expected).

But I have 2 TSW1400 units and 2 DAC3162EVM cards, and running both stacks simultaneously generates different results with similar symptoms.  The only thing in common is the Windows 7 box running HSDC GUI 4.20 (I move the USB cable from one TSW1400 to the other).

For stack A, it is as described above (data that's supposed to be on Channel A seldom or never appears on Channel A, but data sent to Channel B appears in fragmentary/noisy format on Channel A; meanwhile data sent to Channel B looks pretty good on Channel B).

For stack B, it is almost the opposite.  Data sent to Channel B appears very clean and nice on Channel A, while what should appear on Channel A is noisily apparent on Channel B...but after a few minutes, cleans up and I can run for some period of time with what appear to be the correct waveforms, just on the opposite channels that I programmed.

This really does sound like a DDR clock sync/skew problem to me, though I'm just keying off what Richard suggested above.

Is it possible that I have 2 bad DAV3162EVMs?  Have you ever seen anything like this?

If I need to check DACLK, is there a recommended procedure?

Thanks,

Cliff

Hi Richard,

Is it possible for me to get the FPGA source project that produces the current DAC_SAMPLE_WISE.rbf FW? I see some older posts when this was provided to users...hoping that's still the case. I'm pretty sure that the issue I'm seeing with the DAC3162EVM is indeed a setup and hold timing thing and I'd like to have a chance to tune it up, as the 3162 is my desired target part at this point.

Thanks,

Cliff

Hi,

We are looking for the source code repository at this time for you.   May we have an email address to send it to when we locate it? 

We will also look to see what hooks may have been included in the current firmware for timing, if any.  If provision has already been made then this would make things easier.  We think there may be provision for inverting the clock our of the FPGA which would be shifting the data 180 degrees, but if there is that hook in the code then there may be more. If not, then modifying the code as you are suggesting would be the next step.   We haven't had need for these provisions for our DACs that have the FIFO on the data path. 

You had asked earlier if there was another choice of DAC that might be better.    The DAC3162 is the simplest of the DACs that I know if in this speed range, and I would not try to talk you out of it except for the issue of meeting timing from the FPGA to the DAC.   The DAC3164 is also a fairly simple DAC, but it adds the FIFO on the data path from the FPGA to the DAC.   The normal clocking topology would be that there is a clean low-jitter clock supplied to the DAC, and a copy of that clock supplied back to the FPGA.  The FPGA takes that clock to create an output bus of sample data with data clock back to the DAC.  If the DAC has the FIFO, then the length of the clocking path is not an issue from the clock source back to the FPGA and back to the DAC again.  The FIFO absorbs any skew.   But without the FIFO, the round trip clocking path all the way back around to the DAC again now becomes an issue, as the data must meet setup/hold time around the DACCLK at the DAC pins.    Adding the FIFO in a device like DAC3164 simplifies the clocking, but at a cost of other complexity.   The FIFO must be properly reset after power up with either the SYNC/ALIGN signals or through a SPI register write software sync.  And then that adds a SPI port to control the FIFO and DAC.  That FIFO reset and additional SPI port is the complexity you'd be adding to get the FIFO that makes the clocking easier.   Its a tradeoff.  I won't try to persuade you one way or the other.  If you can meet the timing for the data into the DAC3162 then that would be the most basic implementation. 

Regards,

Richard P.

Hi Richard,

My email is CLardin@mezmeriz.com. Thanks very much for looking into this.

I appreciate the explanation of the tradeoffs of FIFO or no FIFO. In our own design, I am reasonably confident that we could meet the timing requirements of the 3162 bus without a FIFO.

So, I would really prefer to find a way to get the DAC3162EVM working now (prior to selecting a part for my own design) since, in the end, it's all I need.

Thank you for your suggestion of the DAC3164.

As it happens, I just received a DAC3482EVM (since I didn't see the more appropriate 3164EVM in the list of EVM modules for the TSW1400EVM). It's far too fast for my purposes, and I don't need 16 bits, but it was the next most compatible demo part I was aware of. However, I can't get it to generate a waveform, though I am following all the stems in slau432a.pdf.

So, I am likely to return this DAC3482EVM to DigiKey regardless. I'd prefer not to have to try to get a DAC3164EVM working, but if there aren't timing hooks in the FW as-is, or I can't get the source for the FW project to work with myself, that's looking like my best option.

Thanks,

Cliff

Cliff,

The TSW1400 LVDS firmware for the ADC and DAC modes is released in the TSW1400EVM folder.  Please have a look in the Software section under the Related Products portion of the TSW1400EVM folder:

The direct link is here:

If you run this installer, it will place a zip file containing the quartus projects for the LVDS ADC and DAC in the following directory on your PC (this is the install directory for HSDC Pro):

C:\Program Files (x86)\Texas Instruments\High Speed Data Converter Pro\Source Code

This quartus project is being provided as-is without any implied support.

Ken

Thank you very much for this.

I have it and have successfully built the DAC project under Quartus 16.

I will have to see if adjusting the DAC CLK PLL will give me the control I want over multiple 3162 EVMs, or if I need to take on the additional overhead (power, footprint, config) of the 3164 EVM.

My thanks to all of you for your support. I consider this matter resolved.

Best,

Cliff