PeterC wrote:
> Daniel - this may well be an option (excellent suggestion - thank
> you!), and is essentially the same technique as used in some
> sample-rate converters (for arbitrary up-sample rate ratios). Except in
> this case the output rate is the same as the input rate, which
> simplifies the design substantially as a simple linear interpolation
> between adjacent samples would suffice.
> 
> I guess the DAC being driven by a clock which has a highly jittery
> period should be spectrally correct if the data is interpolated in time
> to the word clock edges which drive it.
> 
> I will give this more thought over the coming weeks and may even try an
> inplementation if time allows.

  This would depend on the DAC designs - some have quite long settling 
times, so this might not work too well on those.
  Plus, you need to know the exact nature of your jitter ?
-jg

Daniel - this may well be an option (excellent suggestion - thank
you!), and is essentially the same technique as used in some
sample-rate converters (for arbitrary up-sample rate ratios). Except in
this case the output rate is the same as the input rate, which
simplifies the design substantially as a simple linear interpolation
between adjacent samples would suffice.

I guess the DAC being driven by a clock which has a highly jittery
period should be spectrally correct if the data is interpolated in time
to the word clock edges which drive it.

I will give this more thought over the coming weeks and may even try an
inplementation if time allows.

Cheers,
PeterC.

PeterC wrote:
>> I do need the same degree of control around 50 kHz (ideally even better
> than 1 Hz, down to as low as 0.1 Hz) so I don't think a simple integer
> division is acceptable.
Hi, PeterC
Here is a method that gives very fine resolution at low cost, but is
not so easy to tune:

Use the DCM in frequency synthesis mode. Let's assume a 100 MHz input
clock. By using various mixtures of Multiply and Divide, you can
generate, for example, 16 different frequencies between 103.22 MHz and
106.6 MHz (starting with 32/31, the 31/30, then 30/29 etc)  Yes, you
can multiply 100 MHz by 32 if you simultaneously also divide it down to
a resonable value.
>From this large (or even larger) number of tightly-spaced frequencies,
you can divide down to 50 kHz with a granularity of a few Hz (perhaps
even below 1 Hz if you have some patience playing with the numbers.
The output frequency is 100 MHz x (A/B) / C,, where A and B are any
integer up to 32, and C is any integer that you need. Jitter will be
low, but there might be some wander. Best check for spectral purity.

The problem is that this approach is not straightforward. It needs
pre-computation. But if you need just a few hundred frequencies, you
can store the constants in a BlockRAM. And you have to reconfigure the
DCM whenever you need to change A or B.  That may be the biggest
drawback.
I remember that you needed to convert between specific audio
frequencies last summer. This method might be interesting for that. I
did not think of it then.

Peter Alfke, Xilinx Applications

On 9 Feb 2006 21:24:28 -0800, "PeterC" <peter@geckoaudio.com> wrote:

>As far as Peter's comments - I simply don't know exactly what the
>jitter spec and freq resolution should be - it all depends on other
>parts of the system which are being simultaneously designed. It comes
>down to a certain amount of experimentation to see how the audio DAC
>output spectrum will behave with jittery clocks.

1.2ns of jitter would be good for about 14 bits accuracy on a 20kHz
signal, assuming a traditional multi-bit DAC. Oversampling,
noise-shaping DACs ("1-bit" outputs) tend to be less tolerant of jitter
as it affects the entire audio spectrum instead of mainly high frequency
signals.

- Brian.

"PeterC" <peter@geckoaudio.com> wrote in message 
news:1139532804.420372.21440@f14g2000cwb.googlegroups.com...
>
> Yes, I need the MSB out of the FPGA, to drive an audio DAC. It's value
> Peter C.
>

Would it be possible to use the FPGA to interpolate the values going to the 
DAC to compensate for the clock jitter?  Use the previous and current 
uncorrected DAC values and the phase error for the current clock pulse to 
estimate the corrected DAC value.  This would ease your clock jitter 
requirements greatly.

Daniel Lang

PeterC wrote:

> John -
> 
> Pipelining the accumulators I will certainly look at and this should be
> simple, since they have simple ripple-carry carry chains, will try 8
> then 4-bit granularity if needed.
> 
> On your point (2), I'm not sure I understand completely - this would
> require MUXing both inputs of a single adder - both the feedback and
> the input tuning words, adding an additional MUX delay? Yes, my tuning
> range spans about 10kHz around the 50 kHz point, and I would like to do
> this with single Hz resolution. If you can send a quick sketch to peter
> (at) geckoaudio (dot) com that would be great.

The accumulator feeds four values but only one of those values (Acc+N) 
feeds back to the accumulator.  The other three values (Acc+N/4, 
Acc+N/2, Acc+3N/4) are simple adders where all you care about are the 
MSbits.  Are you a Verilog guy?  It would be much easier to send you a 
few lines of code rather than a sketch.

> By "reducing the resolution of the non-accumulating adders" I take it
> to mean that since N/4 etc will be a relatively small number, it
> certainly would not need to sit in a 32-bit register?

It's not about the size of the number, it's that you don't need 32 bits 
of precision to decide if the edge should go at at the quarter-period 
point or at the half-period.  If your jitter is already at about 1/4 
cycle, your adders don't have to be much more precise than that to give 
you 4 MSBits for 4 clock phases with no (noticeably) additive jitter.

> The bit serial approach is interesting, but I think the internal fabric
> clock limit is around 300 MHz anyway, and an 8-bit or 4-bit pipelined
> adder would probably run at close to this anyway (I'm guessing here)?
> 
> On the topic of *fun* - how does knowing the ratio of the contents of
> the accumulator to the tuning word (N) after it turns over? Excuse my
> ignorance, but I don't see how this is useful.
> 
> Cheers,
> PeterC.

If you're running a phase accumulator at a master clock rate, at the 
update of that clock when the MSBit changes will have LSBits in the 
range of 0<=Acc<N where N is the phase value you're adding every cycle. 
  How long ago the "virtual" edge (zero crossing) occurred is the 
fraction of Acc/N.  If the Acc is zero, the "virtual" edge is at the 
clock that generated that value.  If the Acc is nearly N, that edge was 
nearly a full master clock period ago.  If the Acc is N/2, the 
transition would have ideally happened in the middle of that clock 
period.  The trouble with a "simple" implementation is that division 
isn't so simple.


It's my belief that the sub-50kHz signals won't feel the difference in 
10 ns of jitter but your experiments could surprise me.  As far as the 
12 MHz and 24 MHz signals go, look at what the DSM can offer you for 
fixed values.  I would hope these wouldn't need to be tuned like the low 
frequencies.

Please consider that adding dither to spread out your sidebands may have 
detrimental effects.  The dither (especially multi-bit dither) will add 
energy to the overall sideband spectrum.  While audio can deal with a 
higher noise floor but can't accommodate audio spurs, the investigations 
I've done for telecom jitter issues may not help me as much with the 
insight for your issues.

One more thing to consider if you like the idea of a sped-up output: 
Rather than an NCO where you'd have to have multiple adders to get 
multiple output phases, or a divider that doesn't give you the 
resolution you want, consider an N/N+1 divider where the choice of N or 
N+1 comes from a smaller NCO.

If you want to use a 24MHz clock for the divider and NCO (as just one 
extreme example) your divider would be 480 or more for 50kHz or less. 
For 49.999kHz, you'd want a divider of 480.009600.  Use a divider 
configured for divide by 480 or 481 and a 20-bit NCO (could be fewer but 
his gives outrageous 1ppm accuracy) with the decision of which divide to 
use controlled by the rollover of the NCO; when the fraction is large 
(480.96) the large phase value rolls over most cycles but in the 
49.999kHz case rarely rolls over.  When the divider goes to zero, the 
little NCO increments the fractional value.  The fractional value will 
give you a binary fraction *of the clock period*.  If you use the 4 
MSBits of the NCO, you'll have a range of 0-15 to select the clock phase 
for the output clock to feed a 16x speed edge generator.  (I've ignored 
the fact that the divider approach needs a 2x output clock to provide 
both edges of the output clock but the approach still applies)

Ain't frequency control fun?

Jim - the numbers you have chosen are of course correct, but I'm
missing the point -

14,000.7000 Hz = 200 MHz / 14285. Next divisor is 14286,, which gives
13999.7200 Hz, so yes 0.7 Hz control is possible for a 14 kHz output
frquency. But sub 1 Hz adjustment is also possible Fo = 15 kHz for
example.

I do need the same degree of control around 50 kHz (ideally even better
than 1 Hz, down to as low as 0.1 Hz) so I don't think a simple integer
division is acceptable.

As far as Peter's comments - I simply don't know exactly what the
jitter spec and freq resolution should be - it all depends on other
parts of the system which are being simultaneously designed. It comes
down to a certain amount of experimentation to see how the audio DAC
output spectrum will behave with jittery clocks.

Peter, you fist of all, have to decide on frequency resolution, and
acceptable jitter or phase noise.
Resolution is easy with DDS, just make the accumulator long enough.
Jitter is fundamentally determined by the clock frequency. I would try
200 MHz or (in Virtex-4) 400+ MHz. That gets you to a few ns. If you
need better, you can struggle with a factor of 2, but anything below 2
ns is tough, and below 1 ns is impossible, unless you use MGTs.
There you can get 300 ps granularity from the 3 Gbps outputs, which
sounds like 150 ps jitter. It takes some trickery and some duplication
of resources, so it's not all that cheap. And Spartan and its friends
do not have 3 Gbps transmitters...
Find out first what you really need. Jitter is your enemy. And fighting
it is never cheap.
Peter Alfke, Xilinx (from home)

PeterC wrote:
> Jim,
> 
> I can tolerate a 1 Hz step (I need real-time tuning with at least this
> resolution, as well as a small number of "coarse" steps of about 5kHz).
> Apologies for not posting this initially to eliminate this as a
> candidate, I have thought about the simple integer division - but my
> range and tuning require DDS. As much as I'd like to, I can't use a PLL
> due to cost!

  The DPLL I meant, was the Clock module inside the FPGA, not an 
external one.

  A simple divider, from ~200Mhz, gives better than 1Hz dF, below 14KHz 
Fo.  Could that be good enough ? [It will have vey low jitter]

-jg

Jim,

I can tolerate a 1 Hz step (I need real-time tuning with at least this
resolution, as well as a small number of "coarse" steps of about 5kHz).
Apologies for not posting this initially to eliminate this as a
candidate, I have thought about the simple integer division - but my
range and tuning require DDS. As much as I'd like to, I can't use a PLL
due to cost!

Cheers,
Peter.