Click here for the enhanced PDF version of this article

The main job of an RFIC is to modulate and demodulate data for transmission and reception of a desired signal. With the advent of digital signal processing, more and more RFIC architectures have integrated the analog functions and the digital signal processing blocks required to process the signal.

However, the complexity of the cellular standards requires flexibility of the cellular chipset as a whole, and the RFIC in particular. This flexibility translates directly to programmability.

For several generations of stand-alone RFICs, the input structure has been that of a serial peripheral interface (SPI) map. Figure 1 shows a regular SPI map architecture. This SPI map approach can essentially be thought of as a grid of switches and knobs into the RFIC. Typically, there are several enable bits (switches) and several parameters of operation (knobs). Thinking about a PLL, there is typically at least one enable bit to turn the PLL on, and possibly several tuning parameters to determine the frequency out of the PLL.

When the controlling IC (typically termed a digital baseband (DBB) decides to program the PLL, it must write the parameters and the enable bit. In a SPI map-based interface architecture, the DBB firmware needs to know the address and bit location of each bit it needs to write. It also needs to know the structure of the PLL so that it can correctly calculate the required parameters. Occasionally, there is a timing dependency between these bits that must be honored as well to ensure correct operation.

Taken individually, this is not a terrible burden on the DBB firmware. Once you have put together an entire IC, however, the story becomes much more complex.

The number of programmable bits can reach into the thousands. In some cases, there are dependencies between different subsystems on the RFIC that, even with the best documentation, may or may not be well understood by the DBB firmware team.

Even after the DBB firmware team successfully integrates an RFIC into a chipset, the DBB firmware is now intricately locked into the specifics of a single RFIC. With defensive and hierarchical coding methods, there still remains residue that cannot be completely washed away. From a business aspect, this means that second sourcing a part with a single software build is next to impossible, and two builds will have to be maintained. Also, the following generations of RFIC will have improvements/enhancements/modifications and exact register compatibility may be difficult, if not impossible, to maintain.

The traditional solution to these problems in the software world is abstraction. In software, abstraction generally means that there is a collection of routines that are used by another entity to accomplish a task. To a first order, the higher-level entity doesn't care how the lower-level entity accomplishes its job. It just requires that everything operate within expected parameters.

The set of lower-level routines used by the higher-level software is referred to as an application-programming interface (API).

This desire for abstraction holds, to an extent, in the world of distributed ICs within a system platform. The added layer of abstraction relieves the DBB from needing to know bare-metal detail of the RFIC. Instead, a command can simply be issued, “turn on the receiver” or more pragmatically, “turn on the receiver to this channel, apply this AFC correction, and set the gain based on this expected signal level at the antenna (Figure 2).”

Of course, the use of abstraction through an API does not alleviate the system team from understanding the parametric and functional operating conditions of the parts involved. As with any complex system, it is crucial that various use scenarios be understood and communicated to the lowest design level. Group understanding of the required operation provides for more perfect silicon and helps prevent (or at least curb) overengineering.

Once the use scenarios involving distributed ICs are understood a robust API can be developed. In software, the API consists of functions. For a hardware API, the analogous idea would be commands transmitted to the RFIC via an interface.

The command definition and command parameters can be tackled from a top down method in a straightforward manner. This will cover 70% to 80% of the functionality required.

An RFIC lives to transmit and receive. So, for a multimode cellular transceiver, you would want commands to accomplish the following:

• enable and/or disable the GSM receiver;
• enable and/or disable the GSM transmitter;
• enable and disable the WCDMA receiver; and
• enable and disable the WCDMA transmitter.

Thus, starts the skeleton for the API. Each of the possible commands provides a high-level idea. Now, each command needs some sort of parameterization in order to make them more useful. Some common ideas for each command that could be made a parameter include:

• desired channel number;

• current band (if you cannot determine from the channel number); and

• AFC correction (if, based on the system, the RFIC plays a part in AFC correction).

Each command will have its own specific parameters as well. Some possible examples of command-specific parameters are transmit power levels, number of active slots, and power measurement requests.

Given the specific-use scenarios defined, there may be a few ancillary commands as well. These ancillary commands could include a soft reset function, or a way to return a part ID. Understanding the housekeeping tasks required to provide a robust and world-class system will help define these extra commands.

One of the key aspects of using an API like this is that all of the command and control are now messages, not register writes. An example of a command from our API would be the GRS command used to enable the GSM receiver. Figure 3 shows a possible bit mapping for the message.

The command is structured with the following high-level information:

1. The band of operation.
2. The expected Rx level at the antenna (dBm).
3. A desired channel number via ARFCN.
4. An RF AFC correction value in PPM.

Note that all of the units are essentially hardware agnostic. This allows the DBB firmware to simply know what it wants to do and the RFIC will take care of programming the PLL, setting any required Rx line-up gains. Historically, the DBB firmware would need to know specific hardware details to determine the various gains required in the RFIC based on the power of the input signal. Now, the DBB firmware simply informs the RFIC about the signal strength level, and the RFIC will appropriately configure itself.

In addition to defining commands for operating the RFIC in the system, it is important to describe and define the information that will be returned from the RFIC to DBB.

Certainly, in the case of an RFIC in a receive mode, some sort of Rx sample will be returned. However, there needs to be additional information that must also be returned:

• any status messages;

• any error messages (if generated by the RFIC); and

• any information needed for complete operation:

  • RSSI
  • gain settings
  • power read back settings

Though often overlooked, the ability to return an error to the DBB firmware is critical. The efficiency of debug and convergence to a root cause cannot be paralleled. An example structure of an error message is shown in Figure 4.

Good error checking would provide for dozens of error codes to attempt to cover all possible failures that may occur. Chances are that most will never be used, but if needed, these bits of information are absolutely essential.

After defining all of the commands, the parameters for each command, and the ancillary commands, you are ready to map commands onto a bitstream. However, it is imperative that two principles are maintained while finalizing the API:

• Keep the commands, parameters, and units as generic as possible.

• Leave room for expansion.

Since you've taken the time and trouble to use an API between two ICs, don't undo all of your work by making it specific to the two devices involved. If the adjunct part has a DAC, for example, it might be more generic to provide a value in dB instead of DAC counts. Of course, this can be simple in some cases and more challenging in others. It takes diligence to stay the course, but you are giving up on one of the primary benefits of the API if you stray.

Though one of the main benefits of the API is the ease in which backward compatibility can be maintained, that does not imply that there will be no growth; quite the opposite. Future generations of parts can add new features, operations, customizations while still adhering to the original API. Instead, the future generations will simply enhance the existing API. plan for growth, but guard against extreme “future proofing.”

The final aspect of API design for an RFIC is how to handle part and device-specific customizations. For a given RFIC, it may be possible to re-use the same part in several phone platforms. Each platform, however, may have various front-end components based on the specific phone and the features that phone supports. Additionally, some parts in a cellular platform may require some sort of factory calibration once the entire system has been assembled.

The designed API must be able to handle these phone-to-phone or platform-to-platform specific configuration parameters. And, it needs to be done such that the configuration parameters are as generic as possible too. Recall that one objective is to maintain as much backward compatibility as possible. You need to keep the configuration elements as generic as possible too.

All of this flexibility comes at a price that must be paid by the design team. The complexity that was formerly contained in the DBB is now, at least partially, contained in the RFIC.

This directly translates to increased complexity of the RFIC, which in turn, requires increased verification of the IC prior to tape-out. This may cause unanticipated resource needs in projects in order to avoid increased cycle times for development.

Also, given all of the command parsing and execution required by the RFIC, a choice must be made between a custom state machine, or using an embedded processor, as shown in Figure 5.

Each solution has its own advantages and drawbacks. A custom finite-state machine (FSM) will certainly be smaller, more power efficient, and sits well in the core competency of digital design groups. The main disadvantage is, of course, that once designed the FSM is what it is. The cost of changing it is prohibitively high, save a major bug.

Use of an embedded MCU provides an incredible amount of flexibility. But it requires software expertise, will be comparatively larger, will consume more power, and your design team may or may not be comfortable with integrating and verifying an IC with an embedded MCU. Additionally, there are several potential “gotchas” when incorporating an MCU, from software-related issues (watchdog timers, ROM vs. RAM, etc.) to any additional noise generated on chip. But, the flexibility is undeniable.

With all of this added complexity, why would anyone implement it? It's simple really, time to market. By having the team that specifies, analyzes, designs, and validates the part also write and own the API interface into the part, the firmware for the DBB can integrate a new IC into the stack in record time. Simply follow the protocol, play within the lines, and the bring up is significantly simpler than the “SPI map”-based chips of the past. All of the work to translate the ideas (“enable the receiver at this frequency with this AFC correction”) to the actual register writes inside the RFIC has been done and verified by the design team.

What has really occurred with the use of an API in the RFIC is that a boundary was established. The RFIC design team essentially has taken ownership of full verification and validation to a specific set of well-bounded commands. The DBB firmware has agreed to play within a specific set of well-bounded commands too. This brings clarity of purpose in that the use scenarios are relatively well defined for all involved.

The use of an API to define the communications between a DBB and an RFIC in a platform can reduce time to market significantly by forcing well-defined use scenarios on both the designing team and the end user. It also provides a generic interface so that future generations can more easily be backward compatible, attempting to minimize impact on the DBB firmware and increasing adoption time of a new part.

Nick Jungels has been with Freescale's radio products division for two years, and in the semiconductor industry for 10 years. He leads the digital design and firmware team in Tempe, Ariz. Jungels graduated from Iowa State University in 1997 with a B.S. in computer engineering. He can be reached at nick.jungels@freescale.com.

Vivek Bhan has been with Freescale's radio product division for three years and in the semiconductor industry for nine years. Vivek is engineering manager for the Arizona Design Center in Tempe, Ariz., managing teams for transceivers and power management projects for cell phone applications. Bhan graduated from Arizona State University with a M.S. in electrical engineering in 1998 and a MBA in 2007. He can be reached at vivek.bhan@freescale.com.

RSS    Save to Del.icio.us  Digg This