nctnico,
Good shout on the TTi unit. Looking at its datasheet it appears to be DDS only with a reasonably fast clock speed, though it may be limited to 16kpoints (been reading so many now it's becoming a bit of a blur, LOL). Its price is somewhere in between the value brands like Rigol / Siglent and the more established like Keysight / Tektronix.
Joe,
Sounds like an interesting setup you have there too
If it's of interest you might want to have a look at how Motorola (back in the day) implemented the angle clock in the (e)TPU in devices such as the MPC555 / MPC5554. An interesting approach that avoids the need for division to get from time ticks to angle ticks
switchabl,
I have a propensity for throwing Occam's Razor out the window, LOL - so yes perhaps I am over thinking it. Though I also think we might be slightly cross threads here, so for the avoidance of doubt, I was referring to edge jitter on *square* edges, not zero-crossing jitter on sinusoids. I would be interested to know the source of your claim that even units such as the 335xx runs its DAC(s) at fixed sample clocks - because Keysight claim that with Trueform they can get edge jitter down to 1ps. I don't see how that is in any way possible for *square* edges unless you are clocking your DAC at 1THz (which they don't claim).
With regard to the TrueArb etc technologies, I have already acknowledged that there is some form of interpolation / oversampling etc but none of that mitigates the fact that a 250MHz has time quanta of 4ns, you cannot place an edge with any greater temporal resolution - which leads us on to polyphasic clocking. Even with a base clock of 1GHz, in order to be able to place edges with 1ps precision, you would need to have have at least 500 phases (assuming you can invert them all, which would then generate 1000 polyphase clock sources, allowing you to sub-divide the 1ns period into 1ps subdivisions). I'm not aware of any FPGAs that would support that many phases, moreover, normal polyphase setups may derive these phases from a faster PLL (decimation with phase shifted overflows)... so you'd need to have a master PLL running at 1THz for that (probably not happening), *OR* you'd need to have MANY PLLs (which are each then running much slower, but which you could likely enforce some sort of phase offset on). All of this to say that yes, agreed, polyphasic clocking will get you further than you could normally. Maybe you can have 8 phases, and maybe you can invert them to give you 16 phases in total, which might give you 62.5ps resolution with a DAC nominally running at 1GS/s. None of this touches on the fact that you're now dealing with essentially different clock domains, and crossing clock domains is never trivial... so then you need to pipeline it... work out the value *and* the phase of the sample after the next sample - that way at the point of modifying the phase, you're only having to worry about crossing skewed-phase clock domains at the very last point before the clock waveform and the data exits the FPGA. You also need to pay careful attention to delta-phase between successive sample so you don't end up with a timing violation (ie if you decided to advance 180 degrees in a single cycle then you have effectively doubled the frequency during that change, and that may be past the silicon's limit). Hope you can see why I was leaning toward them using a different approach which can generate a precise frequency to clock the point-to-point (or square / pulse wave) samples. Building a PLL with 1Hz resolution is considerably easier than dealing with THz signals.
Agreed on the difference between the Siglent 2000X / 6000X support for 0th-order. I think I did spot something like that in the Keysight info as well. Rigol SiFi 2 looks to have something similar (when you set the "Filter" to "Interpolate", which seem a misnomer but kind of makes sense given that you can then configure the edge slope ["interpolation"] whereas "Step" and "Smooth" look like it is akin to Sinc).
I did spend a little while checking if / what sort of FPGA are in use in these wavegens. In Dave's teardown of the SDG2000X series he suggested an Altera part, and I seem to recall mention of a Spartan in the DG800/900 series Rigols. All this to say that if it's FPGA based then functionality could be expanded /altered in the future, FPGA resources allowing.
Fungus,
As already alluded to in my reply to switchabl, I am referring to square edges (at 10 degrees in a 720 degree frame). Given that 720 and 8192 do not divide nicely, there is literally nothing that you can do to improve the data itself. The two workable solutions that do exist are a) allow sample lengths other than 8192 in DDS mode, or have an option to disable the inter-sample interpolation when running in Sample Rate mode. You are of course right that with "analogue" waveforms you can play around with the data to improve its fidelity. But to place an edge at a notional 10 degrees into a 720 frame, that edge would have to occur at sample 113.77777777 - so you are left with a choice of putting it at sample 113 or sample 114, so you end up with an error no matter what you do - you're introducing jitter as a result. Hope this makes sense.
Cheers,
Pat.