DAC tester

As far as I can see, the data is clocked on the rising edge of WRTx, that's also shown in top figure pg 7. Tpd is also measured from rising edge

Then as written is the text, the data is latched on the falling edge of the WRTx signal. Lastly, DAC output is changed on the next rising edge of CLKx

Funny way to do that, probably done to be syncronous with CLK

If it's a transparent latch, "clocked" is not a precise statement.

If indeed the first thing is a transparent latch controlled by WR, I could just strap WR high!

The architecture may be a way to implement the interleaved mode, where only one set of 14 data lines is used, but still allow simultaneous output strobing. I'll have 28 independent data lines.

A good Spice model would be nice. There are a few DACs in LT Spice, but not the AD9767, which looks a lot like the TI part.

The text does say it is latched through on rising edge, so I do not think it will work with permanently pulled high

Maybe there is Application note code available, so you can see how they access it. Or if you can wait, ask TI support

Questions to the TI forums about the DAC2904 are answered with "we don't have anyone here who knows anything about this part."

You know, that's something I noticed in databooks when I was a teenager! They would often say "edge" and "clock" when talking about transparent latches. Sometimes they seemed to swap the meaning of the latched state and the pass-through state.

Write/call the FAE directly

They usually say "go to the forums." That DAC2904 is an old Burr-Brown part that nobody remembers about.

The good news is that the TxDac family is a standard, for function and pinout. I can use DAC2904, DAC5672A, or AD9767, and maybe some others. I think I'll build a few of my proto board and have someone test them all.

RF people don't usually care much about time delay, so are happy to throw away a full clock time. I want to bang data into the DAC whenever I need to, and want the analog to settle asap. So I guess I should test parts.

Looks like I might

Apply data wait 1 or 2 ns raise WRT wait 1 ns raise CLK get an analog output in 1 ns

something like that. Certainly not connect WRT to CLK and waste 8 ns.

That's all to common.

"Data is transferred into the register at the rise of XFR"

could mean edge triggered, could mean a transparent latch.

One old DAC2904 data sheet said that data was transferred to (or made available to) the second register at the falling edge of WRT, even though the scond register has its own clock.

Someone could make a living reviewing data sheets; most are bad to horrible. It would save the semi companies tons of support time and lost business.

Hey, start a web site of worst data sheets for starters. Pity that BADSHEETS.COM is already taken.

I'd do that if I had time. And have a sister site, ICBUGS.COM.

technology.com:

ays

ean

on

ch.

ing edge

e of

dge

re

ey

the datasheet says 1.5ns hold on WRT so I'd guess that with less than ~2ns from WRT to CLK might get the previous input data

I have this debate with other engineers: what if we measure a part and see what it actually does, and guardband that a bit, instead of believing an old data sheet?

The FPGA tools assume abs min/max temperature, voltages, and process variation, and report 4:1 possible speed range. I can control two of those. I'm even going to include a DAC on one product, that sets fpga core voltage.

technology.com:

niptechnology.com:

tand

I says

t mean

red on

latch.

RTx,

rising edge

edge of

g edge

, I

where

us

e,

they

if you have a 200MHz clock for reference you can use ODELAY

I can also temperature compensate pin-to-pin delay, or the delay tempco of the entire product.

technology.com:

niptechnology.com:

ndsniptechnology.com:

erstand

. TI says

ight mean

ferred on

nt latch.

f WRTx,

om rising edge

ent.

ng edge of

sing edge

WR, I

not

e, where

neous

pice,

how they

we

own

and

rs.

em

s.

that is part of what IDELAY and ODELAY is for, it keeps the (adjustable) delay constant using the 200MHz as a reference

Can you conveniently put a speed test into the HDL to make sure?

Are the speed variations with temperature and voltage predictable at all? Maybe the right answer is just high voltage + enhanced cooling.

Cheers

Phil Hobbs

That's the problem. The Xilinx tools are absolute worst-case and don't allow us to constrain, say, supply voltage or temperature. And HDL has gotten so abstract that people aren't sure what's actually going on electrically any more. Predicted delays span about a 4:1 range.

I tested one Artix 7 that had about 8 ns pin-pin in our critical path. Temperature seemed to have almost no effect, but supply voltage sure does. Going from 1.00 volts core to 1.07 saved a full nanosecond. Abs max is 1.1.

That's one picosecond per 70 uV. Think about the jitter implications of that!

In the last couple of years, some people have reverse-engineered a number of small FPGAs (including iCE40, ECP5 and I think Artix 7) and written open-source tools (SymbiFlow?) for generating the bitstreams. You might find that you can use the open-source tools and have a lot more information about how your design is being implemented and how the propagation delays ought to change when you alter the design.

Also, the open-source tools are not multi-gigabyte bloatware, and obviously you get the source code, so you can even run them on the microcontroller that is inside your instrument. That is nice if you want to for example allow a very complex trigger expression to be entered on the front panel, because your micro could then express that trigger expression in a HDL, compile it into a bitstream and program it into a FPGA in milliseconds to maybe seconds, which might be much more efficient in gate count and propagation delay than trying to make some "fixed" function in the FPGA before you ship the instrument, that is somehow versatile enough to do everything that every customer thinks of.

Yikes!

Cheers

Phil Hobbs

That's the word for sure.

I have a dedicated voltage regulator just for the core voltage on this one FPGA. Might need something even better!

TCA0372 snooped by a chopamp. ;)

Cheers

Phil Hobbs