1. Home
  2. Field-Programmable Gate Arrays
  3. NCO Clock driven Designs in FPGA

NCO Clock driven Designs in FPGA

Hi everyone, I have a few doubts that are not being addressed in fpga groups(at least i could not find the one ) though it is very common in DSP design using FPGAs.

  1. In many a communication receiver systems a resampler (NCO based) is required. The output of the resampler is fed to other logics. Can NCO output be used to drive the portion of the design ? as is sayed that in FPGA clock derived from (combinational/sequential) logics should be avoided and whenever a rate change is required use enable signal instead. But this approach requires the whole design to be run at the highest clock consuming much more power.What could be the power efficent method of doing the same. Most common example is a CIC filter used for large rate change (Not by integer factor but rather rate change is driven by a NCO) where input is at much higher rate while the output is at lower rate.

  1. If at all NCO is used for clocking the design that is required to run at much slower speed what care should be the taken for NCO master clock driving NCO , to NCO output clock ? (I feel higher the ratio lower the jitter will be).

  2. Can NCO clock be further used to drive a DCM to produce a high freq clock that can be used for serial MAC fir (for efficient fpga fabric usage.)

regards. rajeev shukla.

Reply to
rajeev
Loading thread data ...

"DCM" suggests Xilinx, so...

The NCO output can be fed to a BUFGMUX to drive other logic, no problem. The reason the clock enables are suggested in many designs is to keep the clock domains between the full speed and lower speed portions of the circuit in the same clock domain, eliminating problems with crossing imprecisely aligned clocks. If you need to communicate between the NCO (or other logic driven by the master clock) and logic driven by the NCO's clock, you need to worry about crossing time domains.

Higher clocks for the NCO (or DDS) produce less jitter, certainly. Often jitter at this level doesn't matter in circuits; only when crossing to or from the analog realm (such as an ethernet PHY) is jitter critical.

The DCM should have troubles if fed a clock with high jitter. There are specific jitter specs included for the DCM input in the DC & Switching Characteristics for your device. It's tough to establish a lock in a delay line based architecture when the clock is always way too early or way too late. If you need a "clean" clock, consider an A/D to generate a true DDS sinewave or, better yet, use a clock chip such as the IDT5V9885 to clean up the NCO-generated jitter. You can get a more expensive zero-delay buffer style of jitter cleanup with an ICS part.

Reply to
John_H

The NCO isn't a sample rate changer, it, along with a mixer will move your signal to base-band where you can then low pass filter it and decimate it to reduce the sample rate to something in line with the bandwidth of your signal after filtering. For large rate changes, a CIC filter does make sense. You'll still need additional filters in most cases to improve the Q of the resulting filter bank. Typically, I use a CIC filter followed by two stages of decimate by 2 FIR filters.

Rather than changing the clock rate, it is far easier to use clock enables to flag when good data is present at the decimated rate. This is especially true when you don't know what the output sample rate is going to be because of a programmable bandwidth and decimation ratio.

Your downstream design can take advantage of the fact that for a given output sample rate there are N invalid samples between each valid sample. Use those spare clock cycles to reduce the size of the hardware with a combination of bit- or digit-serial computation and sequential computation (in other words trade the spare clock cycles for smaller hardware). Your limitation is the minimum number of clocks per sample, which occurs with the highest output sample rate that you can set the design up for. Many wireless designs have a fairly high minimum decimation ratio, so everything after the CIC filter can be bit serial and might even be shared between multiple channels if the bnadwidth of all the channels is the same. The comb side of the CIC filter can also be made bit serial to save some additional hardware.

If there is a fixed integer division in the sample rate, then you can use a divided clock if that makes sense for your design. You should probably avoid an arbitrary non-integer clock divide because getting the data reliably across the clock domain and servo-ing the clock so that you don't have data over or underruns is a rather hard design to get right. If you do need that, then you probably need to be looking at more sophisticated resampling such as a Farrow resampler.

Reply to
Ray Andraka

I got lazy and used a gated clock in a low-speed UART (9600 baud from a

100MHz sysclk). Later I re-used it and wanted to ramp up the speed and had all kinds of problems. Finally I observed the UART behavior on the scope and found that the baudclk was correct but the behavior of the logic clocked by it was inconsistent, appearing to miss many edges. Of course I wasted a lot of time thinking my NCO was wrong before I realized what was going on. I turned it into a clock enable instead of a clk and suddenly it worked fine (at 921600bps, even).

Next I plan to touch a hot stove to see if it's really a bad idea like everyone says...

--
Ben Jackson

http://www.ben.com/
Reply to
Ben Jackson

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.