Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

I would like to ask if anyone knows of a good way to generate a 44.1
kHz clock (without ridiculous jitter) on an FPGA that is driven by a
98.304 MHz crystal.

It is required for an audio application (CD audio is sampled at 44.1
kHz). The digital frequency synthesizer core from Xilinx is not good
enough (frequency resolution is too coarse), and neither are the DCMs
(98.304 and 44.1 don't divide nicely). I also don't want to do sample
rate conversion!

Any suggestions would be greatly appreciated.

PeterC.

It depends what you mean by ridiculous jitter. The ratio is, as you
know, 2,229.1156.
You can build a DDS (phase accumulator) running at 98.304 MHz clock
rate, and achive a jitter that is max half a period, i.e. <5 ns.
You could also build a controlled divider that can divide by 2229 or
2230, and switch between the two  ratios with a separate sequencer.
Better yet:
Can you stand a frequency error?  If you simply divide by 2229, you
have an error of about 50 ppm, and your incoming frequency will hardly
be more accurate. The advantage is: No jitter at all, except from the
incoming clock..

All these circuits can be built with two dozen flip-flops, i.e. just a
couple of CLBs in Xilinx parlance. And the frequency is very benign.
Peter Alfke, Xilinx Applications

PeterC wrote:
> I would like to ask if anyone knows of a good way to generate a 44.1
> kHz clock (without ridiculous jitter) on an FPGA that is driven by a
> 98.304 MHz crystal.
> 
> It is required for an audio application (CD audio is sampled at 44.1
> kHz). The digital frequency synthesizer core from Xilinx is not good
> enough (frequency resolution is too coarse), and neither are the DCMs
> (98.304 and 44.1 don't divide nicely). I also don't want to do sample
> rate conversion!
> 
> Any suggestions would be greatly appreciated.

98.304 to 44.1KHz is ~52ppm error, about the same as a low cost crystal.
How precise does it need to be ?
-jg

Thanks Peter, I appreciate your insight.

The divider sounds most promising - 50 ppm frequency error is about as
good as my 98.304 MHz source as you said. The next question I suppose
is how best to do a divider by 2229?

The obvious design would be a counter with the limit set to 2229 as
this number is obviously not DCM friendly. This amounts to a 13 bit
counter which would indeed be quite small. If you can suggest an even
simpler way (or any other possible alternatives as to me the counter
seems like to only way) I'd like to hear it (judging by your 6 easy
pieces tech-xclusive you know a trick or two!).

PeterC.

52 (or 51.88 to be exact) is good enough for me, thanks jg.

The easiest method is to build a presettable 12-bit counter, which
naturally divides by 4096.
Extend it by an overflow bit to 13 bits. Whenever the 13th bit becomes
1, it acivates the synchronous loading, and preset the whole counter to
the appropriate value (you figure it out, but make sure you account for
the one-bit overflow time, and dont forget to set the 13th bit to 0.)
The 13th bit gives you a 1-period spike, while the 12th bit gives you a
nice long signal.

There are LFSRs, but they are not worh the trouble, now that we have
carry structures.
You can also get rid of the 13th bit, by looking at a 11 of the two
MSBs.
Or you ould build a divide-by-three prescaler, but all of that is just
unnecessary trickery.
In Virtex-4 you might use the 42-bit accumulator/counter in the same
way.

The important thing is to build it as a synchronous counter and avoid
all ripple or asynchronous circuitry. (Well,the carry structure
ripples, but it i plenty fast enough, and you do not see the ripple
delay on any output)
I take it, you are in Sidney. Nice city. I spent some time at Darling
Harbor (?), even crawling through a submarine...
Peter Alfke

PeterC wrote:
> Thanks Peter, I appreciate your insight.
>
> The divider sounds most promising - 50 ppm frequency error is about as
> good as my 98.304 MHz source as you said. The next question I suppose
> is how best to do a divider by 2229?
>
> The obvious design would be a counter with the limit set to 2229 as
> this number is obviously not DCM friendly. This amounts to a 13 bit
> counter which would indeed be quite small. If you can suggest an even
> simpler way (or any other possible alternatives as to me the counter
> seems like to only way) I'd like to hear it (judging by your 6 easy
> pieces tech-xclusive you know a trick or two!).
> 
> PeterC.

OK, I'm not sure I follow your reasoning.

>From what I understand of your reply - the 13th bit, which toggles
every 8192 cycles, would be used to set the counter limit to the
"appropriate value" - either 2229 or 2230?

The 1-period pulse on the 13-th bit comes from the fact that the
counter limit is reloaded when the 13-th bit is set to 1, and when this
occurs 13-th bit is reset to 0, correct?

Could you please clarify what would be the purpose of using the 12-th
bit? I apologize for the ingnorance, but I'm thoroughly confused. I
appreciate you may not have time for a detailed response but any
further hints would be very useful.

I had envisaged using nothing more than the Xilinx counter core with a
fixed limit set at 2229. But then again additional logic would be
required to detect the case of count=2229, but I don't see any problems
here (from memory I think the counter core has a "threshold" output
which could be used for this purpose).

Yes, we are based in beautiful Sydney, about 5 minutes walking time
from Darling Harbour, and I think the submarine is still there! Not
exactly San Jose as far as technical/commercial action is concerned
though...

  Peter A is probably asleep now, so I'll try and reply;

PeterC wrote:
> OK, I'm not sure I follow your reasoning.
> 
>>From what I understand of your reply - the 13th bit, which toggles
> every 8192 cycles, would be used to set the counter limit to the
> "appropriate value" - either 2229 or 2230?

No, the target is now /2229

> The 1-period pulse on the 13-th bit comes from the fact that the
> counter limit is reloaded when the 13-th bit is set to 1, and when this
> occurs 13-th bit is reset to 0, correct?

Yes, the 13 th bit is effectively a synchronous carry-out, that is
hi only one clock cycle.

> Could you please clarify what would be the purpose of using the 12-th
> bit? I apologize for the ingnorance, but I'm thoroughly confused. I
> appreciate you may not have time for a detailed response but any
> further hints would be very useful.

Difference is duty cycle. 13th/cary bit is one CLK wide, or 10ns,
whilst 12th bit is going to be 1024/1205, or not far off 50%.
Both are 44.1KHz.
If you needed a clock-enable inside the FPGA, at 44KHz, then the 13th 
bit could be a better choice; if you want to clock an external ADC/DAC, 
they will prefer something around 50%

> 
> I had envisaged using nothing more than the Xilinx counter core with a
> fixed limit set at 2229. But then again additional logic would be
> required to detect the case of count=2229, but I don't see any problems
> here (from memory I think the counter core has a "threshold" output
> which could be used for this purpose).

  That would also work, but you consume more logic in doing a count==2229
compare, plus it is slower.
  The SyncCarry scheme costs one FF, and then you preset the counter 
with a value that results in a period of 2229 clocks.

-jg

Whoever said Kiwis and Aussies cannot work together?  :-)
My suggestion divides just by 2229, for minimum jitter, accepting a
frequency error.
The basic idea is to avoid decoding the counter ( 12-input AND gate!)
and instead loading the counter (synchronously!) with the 2s
complement, so that if overflows every 2229th clock tick.
That technique goes back to the 74161 days of the 1970s: "Don't decode,
load instead. It's faster, simpler, and cheaper".
Any questions, send me an e-mail.

Peter Alfke, from home, just woke up...
peter@xilinx.com

Completely clear now Jim, many thanks.

PeterC.