CPLD Jitter

In article , Andrew Holme wrote: [...]

If you have other signals running through the CPLD, part of the problem could be crosstalk. Power supply noise will also show up as a jitter.

There seems to be a bad solder joint in the upper left corner.

Check the LM78M05 for oscillations. We don't see the traces hooking up the bypasses on it.

You also have to be careful when making things like flip-flop phase comparitors inside the MAX series. When I made one, I had to add some extra logic after the flip-flops so that the "both" state of the flip-flop pair was used to gate off the output. I think the CLRN timing was the problem bit once I got it working, I stopped looking for the root cause.

IIRC:

BothLatch = (UpFlipFlop # DownFlipFlop) & BothLatch # UpFlipFlop & DownFlipFlop;

Up = UpFlipFlop & !DownFlipFlop & !BothLatch;

--
--
kensmith@rahul.net   forging knowledge

Can you measure the raw oscillator output?

It may not be as good as you expect. Many low volume oscillators now use a PLL. They program the dividers rather than grind the crystal to get custom frequencies.

I'd expect that numbers like 10 MHz would have enough volume so that they would avoid the PLL but maybe it's cheaper to have one production setup and use it for the common frequencies too.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

I would suggest inserting a 100 ohm resistor between C3 and C7 and placing a 100uF capacitor in parallel with C7. The noise on the output of U4 is just as critical as the noise on the + input of U3.

You may also want to add an RC filter on the output of U5 before feeding it to U6.

Daniel Lang

Hello Andrew,

Check its data sheet. If it doesn't have any noise specs on there get a better one. Or better yet, roll your own. CTS is a good source though.

How are the Altera GND pins connected to the plane? I can't see any connections. If that is via traces that's the first easy thing to fix.

Look at your VCC. Switch the scope to AC and crank it way up. When called out to clients that is were I found the main contributors for phase noise. Video line sync, RAM banking spikes, whatever, it all ended up adding a little AM modulation to the logic output stages which in turn causes jitter.

Sometimes others thought now I'd gone crazy: It often helps to take a very good comm receiver, put on tight fitting headphones and listen to your signals. Both sidebands plus wide open w/o IF filter. Often that revealed the tiny telltale "weeeee" or "rat-tat-tat". A spectrum analyzer on the pins and also on VCC can help as well.

Then there is the usual, such as 0.01uF caps tightly fitted from VCC pins (all of them) to the ground plane. Also, check what else is happening in the FPGA. As Ken wrote this could cause crosstalk, especially if other outputs are heavily loaded or must drive longer traces.

Regards, Joerg

Andrew,

Asides from the supply/clocking suggestions already made, I'd also add the following caution: the output stages of most programmable digital parts are not intended for producing clean reference signals to a PLL used for low-noise RF signal generation.

A few times over the years that I've considered doing this, the first thing I've done is build something like a pulse output divide-by-ten in the intended technology, driven the part with an oscillator having known phase noise, and looked at the divider output on both a spectrum analyzer & phase noise measurement system.

Most of the programmable parts I've measured have had output spurs

50-60 db down that vary strongly in frequency with supply voltage, and can cross over the intended output frequency, making it impossible to keep them out of the loop BW. ( also, the crud in the output spectrum will generally behave differently with an even duty cycle output than for a pulse output divider )

other (hastily conceived) random thoughts: - what's the noise floor of your spectrum analyzer at 1 KHz? - try using a surplus ocxo for your 10 MHz source - if you disable the uC/SRAM, and implement a fixed divide entirely internal to the CPLD, does the noise get any better?

have fun, Brian

Thanks to all for the suggestions.

The ground pins were connected by threading wires through the holes, and soldering them to the ground plane before fitting the PLCC socket.

Personally, I now think the monolithic regulator supplying U4 is the main noise source. Thanks, Daniel. I've been pouring over Rohde and Egan, trying to get my head round spectral density stuff. I'd appreciate it if someone could check my math. I've calculated the equivalent noise voltage that would have to be injected at the loop filter input (U4 output) to produce -95 dBc/Hz at a 1 KHz offset on the VCO. The following script was executed in SCILAB:

// Closed-loop gain from PFD output to VCO output pd_2_vco = h/kpd/kn;

// -95 dBc/Hz theta_rms = sqrt(10^(-95/10) * 2);

// Equivalent noise injection at PFD output (1 KHz offset) v_rms = theta_rms / horner(pd_2_vco, 2*%pi*1000)

This gives 20nV/sqrt(Hz). Since U4 output is a 50% duty cycle square wave(XOR PFD), presumably I would still only need 40nV/sqrt(Hz) on the regulator output? Is 40nV/sqrt(Hz) at 1 KHz credible for a 78L05 with 100n

• 10n hanging off its output?

Script notes: h = Closed loop gain kpd = PFD gain kn = Divider gain horner() returns magnitude of transfer function at specified freq

The 78L05 datasheet quotes an output noise voltage of 40uV for 10Hz

Sorry, I think that was wrong. That h was the closed-loop gain from ref input to vco output.

A safer way to calculate it, using the SCILAB /. operator is:

t_pd_vco = (f * kvco/s) /. (kpd * kn);

where f = loop filter transfer function.

Now I get v_rms = 793 nV/sqrt(Hz)

Hmm....

In article , Winfield Hill wrote: [...]

Most closed loop things have a noise that rises to a peak at the gain cross over point. This would apply to the LM7805 like devices.

In the OP's case this band of noise is almost certain to alias to exactly where it causes the most trouble. At some output frequency, the peak near the crossover will alias near zero. When I had a situation very like the OPs, I argued like this:

The noise is confined to a band with a 3dB width of about 1/4 the gain cross over and thus we can find the nV/sqrt(Hz) for the noise. (This was true for the noise spectrum I was dealing with.)

At the frequency where the noise makes the most trouble, the noise spectrum is shifted near zero by aliasing. In this situation, the noise spectrum now appears flat.

The gain of the aliasing process can be measured by injecting a signal near the frequency that is being aliased.

The frequency noise in the PLL output is mostly above the gain cross over point of the PLL. The hardware after the PLL adds other band width limiting effects and also may further alias this to make the final results.

--
--
kensmith@rahul.net   forging knowledge

Hello Andrew,

You could always build your own regulator or, as some say, filter the dickens out of it.

Regards, Joerg

What are you using to measure the phase noise? I'd hate for some troubles to be found there.

The results you consider to be "poor" are with integer-N values to low comparison frequencies? Have you tried integer-N values with higher comparison frequencies?

I've wanted to put together a nice Fractional-N synth for a while but haven't gotten around to it. One thing on my list is to have the phase compator external (high precision analog component) and have the final stage of the divided frequencies go through isolated single-gate registers clocked off the VCO and Oscillator so the divided clocks have no induced noise from my programmable device. If you insist on having the PFD in the CPLD, you will have edge noise injected by signals elsewhere on the FPGA, notable I/O that are nearby but also general functionality. You may be able to arrange the system so any package noise is minimized (Xilinx has had some recent discussions about cross-coupled noise in promoting their Virtex-4 parts). If the CPLD has different I/O banks, you might improve the situation by removing unrelated I/O from the I/O bank that contains the PFD.

I hope you can demonstrate some nifty results.

synthesizer

At

these

are

performance

my

I'm using a Marconi 2382 spectrum analyzer. At current levels, I can see it no problem wthout any special test setup. If I get another 10 or 20 dB improvement, then I'd need a more sophisticated method.

I've tried 100 KHz and 500 KHz comparison frequencies.

Yesterday, I thought the phase noise might be due to the reference or the PFD, and when I estimated the dBc/Hz at the PFD, I thought the numbers were poor. Now, I'm not so sure the CPLD is the biggest problem. I think I may just need better power supply filtering after the monolithic regulators.

I see what you're saying about implementing the PFD externally, and re-synchronising the divider outputs to the VCO and REF clocks. No doubt that would deliver the ultimate in performance. What sot of PFD did you have in mind?

it

You're taking the bandwidth into account? Usually spectrum analyzers like to report in dBm - bandwidhts need to be considered along with slopes to determine "real" dBc/Hz or dBc/sqrt(Hz).

You might find a trend in noise improvement as you increase the comparison frequency, averaging the effect of nonlinearities of the system. By doing your initial investigation at integer-N values, the spurs that "should" be filtered out aren't a concern in wideband noise measurements. Only when you know what to expect at higher frequencies can you figure out what an ideal reference frequency may be.

I consider the biggest advantage to using fractional-N synthesis (particularly with programmable logic) is the high comparison frequencies used to get the desired ratios. If you're using a 10 MHz oscillator, use that value undivided and check the 20 MHz performance with a VCO divide-by-2. Step back to 19.8 MHz with the fractional 1.98 value and see if there's noticeable degredation from the noise shaping for close-in phase noise.

were

may

You noted an improvement going from 100k to 500k comparison frequencies. If power-supply noise were dominant, I wouldn't expect to see that 13 dB change in phase noise.

For my own synth design, I'd like to use a clock generator with integrated PFD/VCO with good characterization so I know what to expect when running 50 MHz (or similarly large) reference frequencies. The MiniCircuits devices are great to prototype with or do one-off pieces of test gear, but when going for those kinds of designs the actual AD9901 might be the most productive way to go.

The integrated PFD/VCO devices tend to generate much higher frequency VCOs internally (to be entirely on the silicon) but are often divided down internally to give a "usable" output frequency.

I think the part I was looking at most recently (because of the integrated, programmable loop filters) was an idt device - the part number eludes me at the moment (some of this research is at home). With an appropriate clock generator (ideally single channel), the reference frequency from the fractional-N generator can internally go through an integer-N multiply to get to the desired output frequency. All the intelligence in in the FPGA/CPLD, all the analog precision is in the clock generator.

Of course. I'm subtracting 10dB for 10Hz RBW.

No, there was no difference, no 13dB change. That was my point.

Once you have cleaner supply filtering to the 1G125, you could try different Phase comparitors : eg a HC4046/7046, then try the same logic inside the CPLD. Gives you ideas, and also a comparison point.

Simple XOR detectors have poor PSRR, as you note, and also low phase gain. Better synthesisers use charge balancing, or a combination of detectors / gains. Good designs also avoid a complete null, on phase match, to avoid dead-zones, on their charge balancing detectors.

If you are looking for absolute best performance, also look at doing a balanced (Push-Pull) Phase Det - that gives better PSR.

-jg

Hello Andrew,

So just hang the analyzer onto the VCC and look. But ease it onto the rail slowly and don't power cycle the board while probing. Else you might fry its input.

Regards, Joerg

I'm not sure why you think you should be seeing a 13dB difference at the input. If I can make some gross assumptions here, I'm going to assume that your system is second order, highly overdamped (the poles are widely separated), and that the bandwidth, even at the 100kHz update rate, is much greater than 1kHz. Then, if your dominant noise source is at the reference input, the gain from input to output close to the carrier is N. If your dominant noise source is at the VCO input, the gain close to the carrier is N/(Kd*R). In both cases, you have a gain of N. Looking at your data, I see that if the noise at 1KHz offset is constant, whether it's at the reference input or the VCO input, the noise should change by about 14dB.

You're measuring 13dB instead of 14dB... so, what's the problem?

-- Mike --

I think we can take things one step further. Mini Circuits thoughtfully provides us with the typical phase noise of their VCO (-86dBc @1kHz offset), and the VCO gain (1-4MHz/V, which we will take to be 2.5MHz/V).

If we insert this noise at the VCO output in a simple PLL, and again assuming that you're overdamped with a loop bandwidth wider than 1kHz, the loop gain at 1kHz offset is approximately wN/(KoKdR). So, based on your measured values,

-95 = -86 + 20log(wM/(KoKdR))

where

w = 2pi*1kHz Ko = 2pi*2.5MHz M = 39

Solving for KdR,

KdR = wM/(Ko*10^(-9/20)) = 0.044

You haven't published your loop filter design, but most of the PLLs I've designed in the past few years have had Kd*R somewhere in the range of 0.01 to 0.05, so the value I've obtained above looks like it might be about right.

The point of all this is that your noise is probably not coming from your crystal reference oscillator. I think it's more likely that it's coming from your VCO, and (if my assumptions about Kd*R are roughly correct) is approximately what you'd expect to see.

-- Mike --