|
|||||||||||||||||||
|
|
Designing digital downconverters May 1, 2006 12:00 PM By Brian Ogilvie and Paul Pacheco A key problem with traditional RF design methods is that errors are frequently not detected until modules can be physically tested at the prototype stage. Model-based design can address this problem by providing an environment for creating executable specifications that provide a high-level view of the design.
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.
|
|
||||||||||||||||||||
| Back to Top |