How to use an FPGA to test a PLL band calibration algorithm - Embedded.com

How to use an FPGA to test a PLL band calibration algorithm

It's a common technique to split the required frequency tuning range of a controlled oscillator into discrete bands. The advantage of having many bands is that a wide tuning range can be covered while keeping a relatively low voltage-controlled oscillator (VCO) gain within each band. Low VCO gain is good for achieving low VCO phase noise. It's required that the frequency bands overlap. The tuning bands are changed with a digital band control signal.

When an oscillator with discrete tuning bands is used in a phase-locked loop (PLL), the desired band must be selected before the PLL can proceed to phase lock. This necessary step has many names (band calibration, auto-band selection, band selection, and so on), but the idea is the same: to pick the right frequency band before allowing the PLL to lock.

A straightforward way to calibrate the band is by racing two counters, one clocked with the reference clock and the other clocked with the feedback clock that is the frequency divided version of the VCO output. The frequency division occurs in a block called a multi-modulus divider (MMD).

The counters are forced to start at the same time and permitted to count up to a predetermined value. Whichever counter gets to the value first is noted as the winner; it follows that that clock was greater in frequency.

Using the information about which counter was the winner, the band control of the VCO can be either incremented or decremented to bring the frequencies closer. This algorithm is implemented in a band calibration block (BCAL). Instead of waiting for an expensive ASIC fabrication run that includes the entire PLL and other circuits, you can implement a band calibration algorithm and test it on an FPGA. This article shows you how.

VCO band calibration (BCAL)
In communications chips, frequency synthesizers are ubiquitous functional blocks. A frequency synthesizer is loosely defined as a PLL that generates an output frequency that's directly proportional to a reference frequency. The constant of proportionality is a specific subset of integer or real numbers, depending on the synthesizer implementation.

One use for a synthesizer in a receiver front-end is the creation of the local oscillator input to a mixer that downconverts the received radio frequency (RF) signal to an intermediate frequency. Channel selection is achieved by setting the synthesizer's constant of proportionality. In general, RF = Ndiv * REF, where RF is the output frequency, Ndiv is the constant of proportionality, and REF is the reference frequency.

Ndiv can be a ratio of integers, N/R, where N is an integer divide value for the output of the VCO, and R is another integer divide ratio for dividing the reference oscillator. If even finer frequency resolution is needed, the N value can be added to a sigma-delta modulated code that dithers the divider function and gives a fractional resolution of REF/2^(# sigma-delta accumulator bits).

Frequency synthesizers multiply a fixed frequency crystal oscillator up to the required frequency. The PLL acts as a closed-loop negative feedback system to implement this exact multiplication. The job of the MMD is to divide the frequency of the VCO output by the integer value N.

The phase of this signal is compared with the phase of the reference, and the difference in phases is filtered to remove high-frequency components. The filtered signal is used as the voltage control of the VCO. If there is any phase difference between the output of the MMD and the reference, the control voltage at the VCO will adjust to correct that phase difference.

For the application at hand, the synthesizer needed to create frequencies from 3,000 to 4,000 MHz. Continuous tuning of the VCO is accomplished by changing the bias voltage across a varactor which is part of the parallel inductor-capacitor (LC) resonant circuit. The fabrication technology limits the control voltage to a maximum change of about 1.5 V. It's difficult to build a varactor that will change its reactance enough to cause a frequency change of 1,000 MHz with only a control voltage change of 1.5 V.

Furthermore, a large VCO gain of 1,000 MHz/1.5 V would make the PLL susceptible to high phase noise. For these reasons, the tuning range is split up into discrete bands. The discrete bands are implemented by adding binary-weighted capacitors to the parallel LC tank circuit. They are switched on or off depending on the digital band setting. The band must be set before the PLL can be allowed to lock and track in a continuous manner.

The BCAL circuit operates as a second feedback loop controlling the VCO through its band input. During band calibration, the VCO control voltage is fixed at a convenient voltage, usually the mid-point of its allowable control voltage range. The phase-detector is also disabled during band calibration.

My goal was to design and test the band calibration algorithm before integrating it with the PLL on an RF receiver ASIC. To that end, a system analogous to the PLL when it's being band-calibrated was constructed entirely with circuits that could be implemented on an FPGA. Since the VCO and MMD lumped together act as a programmable oscillator with output frequencies around the reference frequency, their functionality can be modeled by a numerically-controlled oscillator (NCO), shown in Figure 1 .


Click on image to enlarge.

For the synthesizer to have low phase noise, a crystal generates the frequency reference. The reference frequency is typically in the tens of MHz, which is well below the maximum speed of the logic that can be implemented on today's FPGAs. The BCAL algorithm itself can be described and designed with digital techniques.

At its simplest, its inputs are two clocks, the reference and the output of the NCO; its output is the band signal for the NCO. The combination of the band calibration, NCO, and an externally applied reference signal forms a closed loop system with negative feedback that is analogous to the PLL operating during its band calibration mode, all of which can be coded in RTL and tested on an FPGA before spending money on an ASIC fabrication.

What you need
1. An FPGA and its programming software

2. Matlab/Simulink for algorithm development and verification

3. A signal source for generating the reference clock, such as 10 to 15 MHz

4. An oscilloscope for debugging

I used Matlab/Simulink to enter the initial design and testbench. The support for fixed-point numbers that comes with the Fixed-Point Toolbox and Simulink Fixed Point is useful for making the model accurately reflect the implementation in RTL. The RTL code was written in verilog and run on Altera's Stratix II DSP Development Kit.

From within Altera's Quartus II software all-things-FPGA could be accomplished: design entry, simulation for functionality, simulation for timing, synthesis, fitting, configuring the FPGA with the design, and debugging. When I tested the band-calibration in real time, I used the signal source and oscilloscope.

Design and prototyping procedure
The design and prototyping procedure is the iteration of the following familiar steps: 1. Design Entry; 2. Test; 3. Debug; 4. Go To 2. This cycle is repeated as many times as necessary until the desired functionality is reached.

First, I built the NCO as a Simulink subsystem. The NCO Simulink model was reverse-engineered from the verilog for an NCO I found on the web at www.mindspring.com/~tcoonan/nco.v. The NCO was based on a programmable modulo counter. Its output frequency equals Fs*(BAND+STEP)/MOD where STEP and MOD are fixed values and BAND is the 8-bit band signal.

The NCO's functionality was verified by running transient simulations using Fs=11MHz and sweeping through the BAND values, 0 to 255, and calculating the resulting output frequency. The resulting output frequency versus BAND, or band tuning curve, was monotonic but not perfectly linear. Since it was monotonic, it was deemed acceptable to use in the closed-loop test setup for the BCAL.

After establishing that the NCO has a monotonic tuning curve and can produce frequencies in the range 10 to 14 MHz, which is approximately the PLL's reference frequency, I built the BCAL model. The BCAL algorithm works by racing two identical 10-bit counters. One counter is clocked by the reference; the NCO clocks the other.

Since they both start from 0, the first counter to get to a constant HIT_VALUE, is clocked by the greater frequency. To determine which counter gets to HIT_VALUE first, each count value is continuously compared with the HIT_VALUE, and the XOR of the two comparison results is used to clock a “1” into a D flip-flop.

When both count values are less than HIT_VALUE, the comparators both output 0, and the XOR result is 0. At the instant one of the values exceeds the HIT_VALUE, the XOR output transitions to 1 and captures a 1 on the DFF output. Sometime thereafter, the other count value will get to HIT_VALUE, and the XOR result returns to 0.

Another comparator is used to compare the reference counter to a constant RESET_VALUE, and when the count exceeds this value, both counters are reset to 0 and the race begins over again. If the HIT_VALUE is 230, a plausible RESET_VALUE is 240. Meanwhile, the bit of information about which clock was faster is used as input to a binary search block.

The binary search block holds the current band output value and determines what the next band value will be based on which clock won the race. The binary search block either adds or subtracts the appropriate binary weighted value from its current output. For an 8-bit band, the initial band value is mid-range at 128, and seven consecutive races are conducted to fill in the 8-bits from MSB to LSB. An example run of the BCAL algorithm is shown in Figure 2 .


Click on image to enlarge.

After building the band calibration algorithm in Simulink from logic gates, comparators, registers, delays, and look-up tables, the design was entered in the Quartus II software. To make debugging easier, every wire in the Simulink model was named.

During the translation process, I used the same names for signals in the Verilog code. If a signal originated from a register (or a delay in a triggered subsystem) in the Simulink model, I made it a register in Verilog; otherwise the signal was a wire. As a result, the design entry from Simulink primitive subsystems to Verilog was straightforward.

In a manner similar to the testing done in Simulink, all the submodules were simulated and verified in Quartus II. After functionality was confirmed for the submodules, a test schematic for the entire BCAL was made. The test schematic includes the NCO which is controlled by the BCAL band output.

To complete the loop, the NCO output is used as one of the clock inputs to the BCAL. The BCAL reference input was wired through one of the FPGA pins to an SMA connector on the board so it could be clocked with an external signal source.

The BCAL testbench was synthesized and fitted, and the timing netlist was simulated. Immediately, it was apparent there was a bug in the design because some of the band bits were going into undefined states, shown as “U” in Quartus II.

The bug came from the asynchronous comparisons of the counter values to the HIT_VALUE. After registering these comparison results and retiming the asynchronous data paths to the reference clock, the design functionality was okay in simulation. The next step was to load the design onto the FPGA and verify through measurement.

The testing proceeded by changing the reference frequency generated by the signal source from 10 to 14 MHz in increments of approximately 100 kHz. The test setup is shown in Figure 3 . At each reference frequency, the band calibration was initiated by a reset tied to a push-button. Switch debouncing would have made a cleaner testbench but was not necessary.


Click on image to enlarge.

Multiple resets caused by the switch bounce cause the algorithm to start over repeatedly; when the switch stops bouncing, the BCAL operates normally. The 8-bit band value was mapped to two 7-segment displays on the FPGA board to display the final band value in hexadecimal.

The BCAL algorithm finishes in 146 ┬Ás (= 7*230/11 MHz), so only the final value appears to a human observer. The readout made it easy to compare against the theoretical value from the Simulink model. In this way, the BCAL algorithm was pass/fail tested for 50 possible frequencies from its minimum to maximum band values.

Potential pitfalls and tips
One of the challenges of this particular design was its asynchronous nature. The frequency of the NCO clock changes during the band calibration, and some logic elements in the BCAL depend on the timing of the edges of that clock. Likewise, other logic elements change synchronously to the reference clock edges.

The FPGA design software is not conducive to asynchronous design. It's not impossible to make an asynchronous design, but don't be surprised if you have to look through documentation on a collection of warnings to determine if your code does what you intend. Since the reference frequency never changes, the design was modified to make all the data paths synchronous to the reference clock.

When the data path needed to jump clock domains, it was retimed with cascaded registers to minimize metastability. Similarly, another pitfall was not registering combinatorial comparator outputs. These are both examples of problems that arise in actual hardware but may not show up in the idealized models in Simulink, unless you explicitly add them in your model.

To ease the migration of the Simulink model to RTL, try to use Simulink function blocks that are primitives in the RTL language of your choice. For example, logic functions such as XOR, AND, and greater-than map directly from Simulink to Verilog. A delay or explicit DFF in Simulink is modeled as a register in Verilog.

I also recommend naming all the signals in the Simulink model and using the same names in the Verilog code. It's okay to first build the model using floating-point data types in Simulink, but if you migrate the floating-point design to fixed-point, it will ease the coding process and lead to a design that is easier to debug.

The end result
After running the RTL code on the FPGA and judging that the design is functional and meets specifications based on measured data, it was time to implement the code on an ASIC. The logic synthesis and layout was done with Cadence's Encounter software. As a final check, I simulated the resulting logic netlist and also the extracted layout netlist with parasitic resistors and capacitors to make sure the functionality was still okay after Encounter's synthesis and place-and-route.

The functionality checked out okay in those simulations. Since then, the RF receiver ASIC that includes the frequency synthesizer was fabricated and measurements of the chip show the frequency synthesizer phase locks over its range of possible output frequencies. This implies that the band calibration functions correctly. As a result, the design team can focus on squeezing better performance out of the analog portions of the ASIC.

The process of prototyping a design on an FPGA before committing it to an ASIC is useful not only verification purposes but also for the possibilities it provides for algorithm experimentation. If the context of the algorithm can be replicated on the FPGA as it will appear on the ASIC, any number of algorithm implementations may be tried and compared in terms of area efficiency, current consumption, or speed. Happy prototyping!

Russell Mohn is a senior design engineer at Epoch Microelectronics, an IC design services company specializing in mixed-signal, analog, and RF design. At Epoch, his focus has been on the design of fractional-N frequency synthesizers for communications applications. In 2001, he received his B.E. in EE from Cooper Union. His interests include FPGA prototyping, system modeling, and signal processing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.