DDS Spur-Reduction Patent

So far neither of you have posted anything that would indicate the variable propagation delay if the logic producing the data would impact in any significant way the output of a DAC driven by the digital logic. Making a claim is one thing, showing it is valid is another.

You would be right to question it. I was estimating the math in my head and multiplied by 20, then multiplied by 2 again rather than multiplying by 10 and 2, lol. It should be below -120 dBc in the final analysis from the >> Hmm. You said elsewhere that you couldn't measure spurs even at -60

Of course. The issues of the DAC depend on the DAC and have nothing to do with the math of the DDS. There are no timing errors in the logic or it truly is an *error*, meaning you get the wrong numbers. The clock jitter is a design issue and again has nothing to do with the math of the DDS.

I am talking about the math of the DDS, not the DAC. Besides this whole conversation has been about the close in spurs generated by phase truncation when using a LUT. The DAC will not generate appreciable spurs close in unless you try to push the Nyquist rate too hard... which again is a design issue and not fundamental to a DDS.

What commercial products are you referring to? There are *many* DDS that are used internally in products that you will never see the specs for. Not all of them even have to be converted to analog which is the case in one of the reference designs we have discussed. That design in particular is well over a decade old. It would not have been easy to implement this sort of algorithm then without using considerable chip area as it requires a multiplier. With today's technology this design fits in even a small FPGA and would not be a large part of any but the smallest of custom chips.

the DAC changes state matters in the DDS context. Not a hell of a lot, but this is all about low-level nitpicking.

the

the

DAC

is

dependent way, you'll see it on the spurs.

by

sing in another chip is unlikely to affect the exact instant that analog ou tput of a DAC changes, but processing within the DAC chip can, and at some

- hopefully hard to measure - level and will affect the timing of the outpu ts.

The effect will show up in the alphabet soup you are retreating into, if th ese parameters are measured right. As a referee I reject a paper on the mea surement of DAC properties - it got published anyway - because the techniqu e lumped everything together, and DACs notoriously behave badly when when l ots of digits in the digital word being decoded change at once.

I saw a better paper on the subject published - in the IEEE Transaction of on Communications, a few years later - so there are presumably people aroun d who do know how to do it right, but I know which measuring technique the marketing department is going to prefer.

end of a digital device and - sometime later - an output comes out at the o ther. There are tolerances on the propagation delay from an input to an out put, and the delay doesn't have to be exactly identical from one clock edge to the next.

ronised with the clock (which they aren't) or logic delay (within the DAC c hip) has *no* impact on the DAC output.

s-a-vis the clock as the propagation delays from the clock through the coun ter to the outputs change. Manufacturers specify minimum, maximum and typic al propagation delays (if you are lucky, and using a well-specified part). Some of the tolerance can show up as cycle to cycle variation - again, not a hell of lot of it, but we are talking about low-level spurs.

rfect, though some logic - ECLinPS - is more nearly perfect than others.

affect exactly when the analog outputs of the DAC change with respect to th e clock edge that's driving the change.

So you've reached the limits of what you are willing to understand, probabl y a little earlier than is prudent.

tails. ]]

doesn't there is no in between. Voltage levels, propagation delays, io sta ndards etc. has nothing to do with that

y time, but there are tolerances on when it produces them, and the actual p ropagation delay through any chip is finite, and can change - some extent, to a degree that's usually hard to measure - from cycle to cycle.

The subject-line for this thread is "DDS-spur reduction patent".

The DAC is an essential part of the systems that is producing the almost-si ne-waves which have the spurs that need reducing.

It is still not a part of the digital logic an is in no way impacted by that logic.

If you wish to provide some evidence of you position I am happy to listen. But so far it is all just your assertions.

Read a DAC data sheet, and the tolerances on the propagation delay from the clock transition to analog output.

ails. ]]

t doesn't there is no in between. Voltage levels, propagation delays, io st andards etc. has nothing to do with that

ery time, but there are tolerances on when it produces them, and the actual propagation delay through any chip is finite, and can change - some extent , to a degree that's usually hard to measure - from cycle to cycle.

t-sine-waves which have the spurs that need reducing.

It's taking data as digital input, and a digitally generated clock. It's im pacted all right.

In practical terms, the logic in the DAC chip is connected to the digital g round and the digital supply rail, and unless you are very careful, can get messed about by the fluctuations in rail voltage level caused by the varyi ng current drawn by the up-stream digital logic. In a DDS chip, the connect ion is even more intimate.

Even if the DAC were perfect, it could only do what it was told. Clock jitter blows straight through the best DAC.

Cheers

Phil Hobbs

What about it? I've never seen one specify a delay based on the stimulation on the data input.

Absolutely. Bill is trying to say that the digital data on the input to the DAC will appreciably affect the delays in the DAC device and therefore affect the analog output. What he is describing is a second order effect at best and so far he has not even been able to show that it exists at all. He started out talking as if the data being presented was directly converted to the analog output without a clock so that the differing delays in the digital logic would jitter the output. Then he talked about the data pattern affecting the noise on the supply rails which would impact the analog output. He also seems to be saying the data presented to the DAC will jitter the clock appreciably.

I suppose everything affects everything to some extent. But I seriously doubt that in a properly designed system if the variable delays of the digital logic will have any measurable impact on the analog output of the DAC. Now he is saying I need to learn about DACs by reading data sheets. I really don't get what he is going on about.

There are pattern dependent digital delays due to power supply sag, among other effects, as Bill mentioned. (It feels weird agreeing with him.) ;)

Jitter and wander is a serious enough problem that high speed links use "elastic buffers", i.e. continually tuned propagation delays to make the bits line up with each other within the setup and hold times. (I used to work with some of the folks at IBM who made that sort of stuff.) Propagation delay also depends to some degree on the data edge timing. It isn't much, but 0.1 ps is only 50 dB down at 5 GHz!

Communications applications often require much higher spectral purity than most other jobs, especially at high frequencies. That 20 log N phase noise multiplier shines a ghastly light on small imperfections.

Cheers

Phil Hobbs

absolutely, but I'm talking about the data. As long as the logic produces t he right bits and present them to the DAC with proper setup and hold I expe ct the DAC (with proper supplies, clean clock etc. etc.) to make those bits into an analog signal within its spec.

-Lasse

I suppose that the sine table pattern could be optimized for the exact frequency selected, or at least the dac codes could be fine-tuned to eliminate spurs at any given frequency. The math, already mind-boggling, gets much worse.

I wonder if some algorithm, some sort of FFT, could anticipate the spurs associated with this particular frequency, and fine-tune the DAC codes. Or maybe drive another DAC, low amplitude off to the side, that nulls the computed spurs. With enough compute power, that might work at a few Hz!

We are designing a waveform playback box, FIFO feeding a DAC and a lowpass filter. The data from the FIFO is clocked out from a DDS (MSB only, no analog filtering) and the DAC is clocked at a constant rate, namely by the DDS clock. So, without tricks, the data stairsteps and the edges jitter. We're arguing algorithms to improve things.

I suggested simple linear interpolation,

which turns out to be pretty ratty reproducing a sine wave at even half of Nyquist... makes a "slime wave" with lots of random AM. Processing more points than two lets the interpolation follow the curve of the data, rather than a straight line, which works much better. It needs four points, to tell us the bendy directions of both ends of the segment we're currently outputting... we need to torque both ends of the linear interpolation to bend things properly. That turns out to be a cubic spline, which is about the same as a sliding FIR filter of some sort.

Pinning a flexible rod down at four points on a table is the curve fit analogy; the middle section is bent by the two endpoints. There are cases, like an inverted parabola shape, where the interpolated midpoint has higher amplitude than any of the input points, which linear interpolation can't do. Which is why the spline fit makes less AM than interpolation.

This stuff is fun to play with, especially as I have really smart kids to do the heavy math and the hard thinking. I can do Pointy Haired Signal Processing.

Twisted-pair things like Ethernet and PCIe have to tolerate many bits of delay skew on the different pairs in a cable. CAT5 cables can have numbers like 45 ns per 100 meters delay difference between twisted pairs.

These effects may exist, but will be very low order effects and mitigated by proper power delivery system (PDS) design. Give me a spec for the power and I will give you a PDS design that will meet it. So this term in the output equation can be mitigated.

Now you are talking about the data itself being seen correctly by the receiver. That is digital system design and is not related to the DAC issue. But as an example of the inter-connection of digital and analog design, yes, they two are not isolated completely as would be ideal.

Ok, but I'd like to see some concrete evidence that I need to consider my digital delays when estimating the noise on the output of my DAC.

AFAIK you have to do clock-recovery on links like that, so the small stuff is automatically corrected.

The elastic buffers are for on-board links, e.g. from processor to memory controller.

Cheers

Phil Hobbs

I don't think they can compute a impact score of a patent (versus an article) because most articles do not cite patents.

Hmm. I'd be interested in reading some of your patents.

I may simply have missed it.

Preys on low-information people.

Joe Gwinn

PCIe sends bytes per lane, 8b10b or something, from 1 to 16 lanes. The receivers apparently PLL separately on each lane. The byte data from each lane is buffered and each data packet is reconciled after all the bytes have arrived. You can even swap lanes around to make PCB layout easier, or disable some of the lanes, and it works somehow.

You know, this is getting really silly. There are multiple books on just this issue. Already mentioned by name are two such books, and these books each have extensive lists of references. There is an immense literature available. Go do your homework. We can't do it for you.

Most DDS units do have DACs, and so cannot evade the infirmities of real hardware.

What Sobrig does is to generate the sinewave voltages directly with full precision in phase and amplitude, and use this to feed a digital multiplier, most likely in a FPGA. This approach reduces truncation errors to insignificance, as is required for an instrument that is intended to have a noise floor below -200 dBc, as discussed in the other TSI patents I published a week or two ago.

If one can stay in the digital domain, this can work.

DDS is a well understood art, with a huge literature and a billion-dollar market. While it's true that many DDS implementations are not sold as components, the underlying technology is the same. And if one does come upon a new and better way to implement DDS, it's best to patent is, lest it slip away. This is why Timing Solutions got Sobrig's DDS design patented, rather than keeping it as a trade circuit.

Joe Gwinn