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!
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.
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!).
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 th> Thanks Peter, I appreciate your insight.
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...
Yes, the 13 th bit is effectively a synchronous carry-out, that is hi only one clock cycle.
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%
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.
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
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).
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.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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.