It's just arithmetic. Your programmable logic gets told how much time you want between each zero crossing and programs the counter to step the DAC along at maximum or minimum output until you want the ramp to start, then steps it through the ramp look-up table picking up the series of values that will put the zero-crossing in the right place.
Actually you can. There are going to be a lot of different ramps in there - each with the same slope - each one putting the zero-crossings at different particular offsets from the clock, and the arithmetic engine has to pick the right set of sample to generate the right ramp.
If the clock ticks are the integral part of the delay, the offset of the zero-crossing from the clock tick is the fractional part, and you pick the set of DAC inputs you want to give you that offset, and step through just them.
It might if you weren't thinking about what you were doing.
What you are describing won't get you the timing alignment required. The point of the DDS is to provide a waveform that, once filtered, has accuracy better than the clock period. The sine generation uses additional resolution in amplitude to provide additional resolution in timing.
I'm not sure what "logic" you are describing. I think you have not looked at how the logic would need to operate if you aren't using a LUT.
You "pick"? Yes, that's a good description if you aren't actually designing it. The phase accumulator controls the timing and selects the amplitude through the lookup table. I'm not picturing how this would work usefully to generate a largely rectangular pulse with the same rise/fall times independent of frequency. So something else would need to be used. I'm not sure how you get the appropriate fractional clock timing.
Typical Sloman response when he is in over his head. You don't actually know what you are doing at this point, so you criticize the person you are talking to. Ok, I get it.
If you say so.
Bottom line is, this complex goofy thing is not even needed. A programmable octave divider can follow a proper DDS using a 2:1 range to give the same timing precision and jitter from any frequency the DDS outputs down as low as you wish to go. No goofy complexities. Just a simple design that has been proven over and over again. If all the logic is implemented in the same FPGA, it can all be updated simultaneously to never cause a glitch in the pulse timing.
In John Larkin's application, you only need to get it right at the zero-crossing points, and the trapezium approach provides the extra resolution where you need it, and pretty much only where you need it.
You are using look-up table. For a 14-bit DAC you'd select one of 1024 possible 16-step ramps to get the zero -crossing at one of 1024 possible points between clock edges.
After each output edge you use an adder to work out exactly when the next output clock edge has to appear. You know where the last output clock edge was - to an integral number of clock ticks plus that fraction of the tick that you set up, and you just add the delay you want to get time location of the next output clock edge. The sum has integral number of clock ticks plus a fractional part. You start the ramp exactly eight clock ticks before the interval where you want to the zero crossing to happen, and the fractional part selects which of the 1024 possible ramps you chose to get the next clock edge in the right place.
It's just arithmetic.
It's a brief description that tells you what the design has to do. It doesn't seem to have told you enough.
I knew exactly what I was doing, but I was keeping the description short.
You clearly didn't.
I do say so, and I hope I've given enough detail this time around so that it is now as obvious to you as it was to me.
The fact that you didn't get it doesn't actually make it goofy, and it's less complex than a DDS because it's only making the square wave and leaving out the sine.
Analog Devices will sell you the whole DDS as a single (expensive) chip which would make life simpler for the designer, but it may not be the cheapest, or the lowest jitter solution.
None that you are aware of.
If you use a DDS chip. most of the logic is implemented inside the chip, not in an FPGA. My impression was that John Larkin was planning on avoiding paying for an expensive DDS chip by doing his own logic in an FPGA and using it to drive a DAC, which is perfectly feasible, if rather fiddly.
No, John L does not care if the sine is perfect. The issue is to interpolate the zero crossing region to achieve picosecond time accuracy despite using 100 MHz NCO clock.
I don't want a perfect sine, but a classic sine-output DDS is easy to understand and changes frequency coherently.
Here's a minor revelation:
At lower frequencies, using more MS bits of the phase accumulator (ie, a bigger sine lookup table) and more DAC bits makes a surprisingly clean sine wave in my sim. 15 bits of lookup and 12 bits of dac look great for output frequencies from 15 MHz to well below 150K, which is two decades of frequency.
But the sine slope gets low at low frequencies. Using a single-end terminated lowpass filter helps 2:1, at least. But the comparator may well be the jitter limit.
Our old product uses an AD9850 DDS chip. It has a max output voltage of 1.5 unipolar; divide by 2 for a double-loaded LC filter. What's worse is that we used the chip's internal comparator, which is on the same chip as all the clocked logic, and crosstalk will be hideous.
With that succinct restatement of the OP, I'll repeat my answer.
Use only the top bit of the DDS phase accumulator, with as many as you can of the following bits stuffed into a digital delay generator that's triggered by that top bit.
John already knows how to do a good DDG. It needs to be linear, of course, or be fed through a lookup table that's calibrated.
The concept is sound, but it would need a delay generator that has picosecond accuracy and can be reloaded about every 60 ns. Some pipelining would be involved, which is OK for a frequency source.
That's what the trapezium slope generator seems to offer. If you wanted pico-second resolution you'd need at least a 500Mhz clock and a 16 -bit DAC. My example envisaged a 2.5GHz clock and 14-bit DAC and had a 0.4psec granularity. The clock and the DAC would have to be pretty good to offer that kind of accuracy.
Honestly I think filtering a staircase to get a ramp to feed into a comparator looks a lot harder (with many more variables to control) than just triggering a linear(-ized) ramp into the same comparator. But that's just me, I never claimed to be a picosecond guy.
It's not the picoseconds per se that are the problem, but the accuracy, Buying the ADC to make the ramp buys you a lot of accuracy. Making a linear ramp that's accurate to a picosecond over a nanosecond or two is doable, but it's a better than 0.1% accurate current into a better than 0.1% stable capacitor, and when I last did something like it back in around 1988 we autocalibrated the system every ten minutes to keep it accurate. It only took a few milliseconds but it's a considerable complication. The ADC saves you from that.
That's all true in theory, but there are a lot of details to work out. How is this complexity, in any way superior to using a conventional DDS design in an FPGA with an external DAC and filter running over a 2:1 ratio, followed by an octave divider, all updatable from a single command, so completely synchronized, never producing a glitch pulse?
Of course, if you buy an Analog Devices DDS chip, the logic is all buried in the chip, so you don't have to buy or program the FPGA.
The reason that John Larkin isn't doing that does seem to be that the Analog Devices DDS chips are expensive, and an FPGA and a DAC to do the same job are cheaper (and harder to copy and look more like an original design). Once you've got to that point, it may be worth thinking about using the same components in a slightly different way, which is what circuit designers do.
It also does not meet all his requirements, which is to produce pulses without glitches when retuned. By implementing the DDS in the FPGA, the DDS and the octave divider can be reprogrammed on the same clock cycle, making a glitchless transition.
There may be one issue to work out. The DDS will be running from the master clock. The octave divider will be running on the DDS output clock. So the octave threshold setting update will, by definition, not be perfectly synchronous with the DDS update. So this might need a bit of thought to make sure there are no glitches during a rate transition.
Have you any idea how the Analog Devices chips work? Or what's being asked for? The Analog Devices part produce a continuous signal through a frequency transition so one transition is going to be in the wrong place in terms of either frequency regime, but that's inevitable, unless you make the transition on an output clock edge. which would take work.
The trapezium ramp scheme wouldn't need an "octave divider" so it wouldn't have that problem.
Of course it isn't designed. I'm not going to put it into production, and John Larkin wouldn't pay me money to design it for him.
The detailed design phase is where you find and sort out a whole lot of - hopefully - minor problems. Back when I was getting paid to do that kind of work I was pretty good at it, but that's a long time ago. What I've spelled out here strikes me as good beginning, but John Larkin may have some particularly rabid customer to satisfy, and he hasn't been all that forth-coming about the end application.
A lot of the point of having this kind of early stage design is to clarify what's going on and what needs to go on.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.