Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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.


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
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


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

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.


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
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:
Quoted text here. Click to load it


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

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

Quoted text here. Click to load it
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 count22%29, 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...


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
  Peter A is probably asleep now, so I'll try and reply;

Quoted text here. Click to load it

No, the target is now /2229

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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%

Quoted text here. Click to load it

  That would also work, but you consume more logic in doing a count=22%29
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


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
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...
snipped-for-privacy@xilinx.com


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

Makes perfect sense Peter, I hadn't even considered the cost of the
decode. I guess I haven't been around long enough  :-)

In my past life doing VLSI research I built single AND gates with up to
64 inputs (!)  (using threshold-logic that actually worked, and was
about three times faster and disippated far less power than an
equivalent tree of domino CMOS).

Thanks for your help again.

PeterC.


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
Completely clear now Jim, many thanks.

PeterC.


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?

Quoted text here. Click to load it
Rather than doing a limit compare, use a 13 bit loadable down-counter.  
Load it with 2229-2 when the left bit='1' (which happens when the count
reaches -1).  The sign bit is a one clock wide pulse.  If you need a
wider pulse, you can use the next bit down (bit 11) which will be '0'
for 1024 clocks of the 2229 clock cycle.  This way, there is no decoding
which uses up resources and slows the counter down.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?
Quoted text here. Click to load it

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


Re: Generating 44.1 kHz clock from 98.304 MHz crystal on FPGA ?


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


Site Timeline