A survey by Collet International Research showed that only 39% of designs were bug-free at first silicon while 60% contained logic or functional flaws[2]. Detecting flaws this late in the design cycle is expensive since, according to Maxfield and Goyal, “each delay in detection and correction of a design problem makes it an order of magnitude more expensive to fix.”[3] Using model-based design, algorithm developers, RF designers, software and hardware engineers and other development team members can cooperate to make trade offs and evaluate solutions with the goal of enhancing performance and reducing costs.

Components of digital radio

In a simplified digital radio design, the high-frequency signal received from the antenna first passes through an RF section followed by analog-to-digital conversion. In the case of a global system for mobile communications (GSM) system, the frequency of the incoming signal at this stage is around 70 MHz. This high-frequency signal then passes through a digital downconverter (DDC), which performs frequency translation and produces the corresponding baseband signal. In the case of a GSM system, the baseband frequency is around 270 kHz. The digital radio then recreates the audio signal after demodulating the baseband signal.

GSM DDC design specifications

The digital downconverter (DDC) is a key component of a digital radio. The DDC performs the frequency translation necessary to convert the high sample rates down to lower sample rates for further and easier processing. The frequency and performance specifications of the DDC vary based on the actual application, but are invariably stringent and hard to design and implement. In this GSM example, we consider the specifications of the GrayChip GC4016 Quad DDC chip.[4] The DDC in this implementation operates at approximately 70 MHz and must decimate the rate down to 270 kHz. Figure 3 shows a graphical representation of the out-of-band rejection mask specifications of a DDC to be used in GSM systems.

The GSM passband bandwidth of interest is 80 kHz. The GSM requirements for the overall response of the three-stage multirate filter of the DDC includes:

  • decimating the input signal by 256;
  • less than 0.1 dB of peak-to-peak passband ripple; and
  • 18 dB of attenuation at 100 kHz.

Digital downconverter (DDC)

One possible schematic representation of a GSM DDC is shown in Figure 2 and consists of a numeric-controlled oscillator (NCO) and a mixer to quadrature downconvert the input signal to baseband. The baseband signal is then low-pass filtered by a cascaded integrator-comb (CIC) filter followed by two finite impulse response (FIR) decimating filters to achieve a low sample rate of 270 kHz ready for demodulation. The final stage often includes a re-sampler, which interpolates or decimates the signal to achieve the desired sample rate depending on the application. Further filtering can also be achieved with the re-sampler.

This design concentrates on the three-stage multirate decimation filter, which includes a CIC and two decimating FIR filters. The CIC filter is suitable for this high-speed application (69.333 MHz) because of its ability to achieve high decimation factors and the fact that it's implemented without using multipliers.

The CIC in this example will perform decimation by 64. The second filter is a 21-tap CIC-compensation FIR filter (CFIR), which has an inverse-sync passband response, and decimates by two. The third-stage filter is a 63-tap FIR filter (PFIR), which ensures that the overall filter response meets the GSM spectral mask. It also decimates by two to achieve an overall decimation factor of 256.

We will now attempt to apply the model-based design methodology to design, simulate, implement and verify the DDC specified earlier.

Stage 1: filter design

The CIC filter performs moderate spectral filtering to avoid spectral imaging while decimating by 64. The input data type is set to signed arithmetic with 20-bit word length and 18-bit fractional length (S20, 18) and the output word length set to 20, which results in a fractional length of -12. We define, analyze and plot the theoretical magnitude response of the CIC filter that will operate at the input rate of 69.333 MHz. It is clear that the CIC filter has a huge passband gain, due to the additions and feedback within the structure. We can normalize the CIC's magnitude response by cascading the CIC with a gain that is the inverse of the gain of the CIC. Normalizing the CIC filter response to have 0 dB gain at dc will make it easier to analyze the overlayed filter responses of the CIC and the FIR compensating filter.

Figure 3 shows the normalized response of the CIC filter. It may be noted by zooming in the passband region that the CIC has about -0.4 dB of attenuation or droop at 80 kHz, which is within the bandwidth of interest. Figure 4 shows a zoomed-in view of the passband region showing the attenuation. This droop must be compensated by the FIR filter in the next stage.

Compensation FIR decimator

The compensation filter will compensate for the passband droop caused by the CIC filter, which is about -0.4 dB at 80 kHz. This filter will operate at 1/64th the input sample rate of 69.333 MHz and will decimate by two. The compensating filter is designed using a design technique that offers an inverse-sync passband response. After cascading the CIC with the inverse sync filter, we determine if the passband droop caused by the CIC is eliminated. As the middle trace in Figure 7 shows, the passband droop appears to be corrected as intended.

Third-stage FIR decimator

As shown in Figure 1, the GSM spectral mask requires an attenuation of 18 dB at 100 kHz. Consequently, for the third and final stage, a simple equiripple low-pass filter is used. As before, the coefficients are quantized to 16 bits.

Another design requirement for this filter is that it also needs to decimate by two. When defining a multirate filter the accumulator word size is typically determined automatically to maintain full precision. However, in the current case, as the design specification restricts the output to be only 20 bits, we set the output word length to 20 bits with a fractional resolution of 12 bits.

After designing and quantizing the three filters, the overall filter response can be obtained by cascading the normalized CIC and the two FIR filters as shown in Figure 6. Again, the normalized CIC filter is used to ensure that the filter responses use the same scale.

Stage 2: Filter response simulation

In the second stage — simulation — of model-based design, we overlay the GSM spectral mask on the filter response to see if the overall filter response meets the GSM specifications. The simulation results are shown in Figure 7. We see that the overall filter response is within the constraints of the GSM spectral mask. We also need to ensure that the passband ripple meets the requirement that it is less than 0.1 dB peak to peak. We can verify this by zooming in using the axis command and confirm that the passband ripple is well below the 0.1 dB peak-to-peak GSM requirement.

Stage 3: hardware implementation — automatic VHDL code generation

The third major stage in model-based design is implementation — either by manually coding the specification or by automatically generating code from the specification. In this case, we use automatic code generation to generate synthesizable (RTL) VHDL code.

It is also convenient to either automatically generate or manually create test benches in VHDL or Verilog or scripts for simulating, testing and verifying the RTL implementation. A snippet of generated code is shown in Figure 8. In this case, we generate only the VHDL code, as we intend to use a system-level test bench that gives greater flexibility, visualization capabilities, and speed of simulation than traditional HDL test benches.

Stage 4: design verification — co-simulation with HDL simulator

During filter design, a system-level model of the complete filter chain is generated automatically. This system-level model will serve as the golden reference, and allows direct comparison of simulation results of the HDL code implementation directly against the original design.

Direct co-simulation between the system-level golden reference model and the HDL simulator will be useful to functionally verify that the generated HDL code produces the same results as the original design. In this example, we use Simulink, from The MathWorks, as the environment for model-based design and for implementing the system-level test bench. We use ModelSim for performing HDL simulations, and Link for ModelSim, also from The MathWorks, to establish co-simulation connectivity between the model-based design environment and the HDL simulator.

In the system-level test bench, there are two signal paths. One signal path produces results from the Simulink behavioral model — golden reference — of the three-stage multirate filter. The other path produces the results of simultaneously simulating the automatically generated VHDL code implementation of the filter chain in ModelSim. During HDL code generation, the hardware latency, and the hardware reset latency are automatically estimated. These estimates are then used directly in the system-level test bench as shown in Figure 9.

The single block ‘filter’ at the top level is actually comprised of the three filter stages that we designed earlier, as shown in Figure 10.

Verification results

For our behavioral model simulation we will generate a block comprised of the three-stage multirate filter we designed and place that in the system-level model from which we'll co-simulate with an HDL simulator. The results obtained from this co-simulation of the system-level test bench — implemented in this case in Simulink — and an HDL simulator — in this case ModelSim — are shown in Figure 11.

The trace on the top is the excitation chirp signal. The second signal from the top, labeled ref, is the simulation output produced by the system-level behavioral model of the three-stage multirate filter. Recall that this behavioral model was automatically created as a part of the process of model-based design, based on the original specifications and simulations during the initial stages.

The third signal from the top, labeled co-sim, is the output of simulating the automatically generated VHDL code in an HDL simulator, in this case, ModelSim. Again, using the principles, both the behavioral model and the generated code are simulated at once, and from the same design environment.

The last signal at the bottom is the per-sample computed difference between the simulation results of the behavioral model and the synthesizable VHDL code. As one expects and hopes, the error is zero for each sample.

Conclusion

This example demonstrates how model-based design was used to streamline the process of designing a high-speed digital front-end for an SDR. Model-based design provided a complete design flow that made it possible to use a single model for algorithmic exploration; system design, simulation and visualization; implementation with automatic code generation; and testing validation and design verification. This approach can substantially reduce the cost and improve the performance and reliability of RF designs.

References
  1. Warwick, Colin and Mulligan, Mike, “Using Behavioral Models to Drive RF Design and Verify System Performance.” RF Design, March 2005.

  2. Horgan, Jack, March 29, 2004. “Hardware/Software Co-verification.” EDA Café Weekly.

  3. Maxfield, Clive, and K. Goyal, 2001, “EDA: Where Electronics Begins.” TechBites Interactive.

  4. GC4016 Multistandard Quad DDC Chip Data Sheet, Rev. 1.0. August 2001, Texas Instruments. (Formerly Graychip Inc.). Document: slws133a.pdf.

ABOUT THE AUTHORS

Paul Pacheco received a MSEE degree from University of Massachusetts at Dartmouth in 2002. He has been with The MathWorks since 1993, and is manager, MATLAB signal processing. He and his team are focused on developing tools for the design of advanced fixed-point digital filters for signal-processing applications. He can be reached at paul.pacheco@mathworks.com.

Brian Ogilvie received a BSEE from the University of Illinois in 1983. Since 2002, he has been a principal engineer at The MathWorks working on automatic code generation. Previously, he was with LSI Logic Corp. where he worked on intellectual property for consumer electronics and cryptography. Prior to that, he was with TLW Inc., focusing on multimedia and communications ICs. He holds several patents in the area of digital video and has presented extensively at EDA industry events. He can be reached at brian.ogilvie@mathworks.com.

For the PDF version of this article, click here.