A key problem with traditional RF design methods is that errors arefrequently not detected until modules can be physically tested at theprototype stage.
Model-based design canaddress this problem by providing an environment for creatingexecutable specifications that provide a high-level view of the designthat can be used to explore system-level analysis and trade-offs, anddetect potential design and implementation errors.
This article demonstrates how models were used to design a digitaldown converter (DDC) for a software-definedradio (SDR).
DDC is a key component of a digital radio. The DDC performs thefrequency translation necessary to convert the high sample rates downto lower sample rates for further and easier processing.
The frequency and performance specifications of the DDC vary basedon the actual application, but are invariably stringent and hard todesign and implement.
The baseband signal is then low-pass filtered by a Cascaded Integrator- Comb (CIC)filter followed by two FIRdecimating filters to achieve a low sample-rate of 270kHz ready fordemodulation. The final stage often includes a resampler thatinterpolates or decimates the signal to achieve the desired samplerate, depending on the application.
Further filtering can also be achieved with the resampler. Thisdesign concentrates on the three-stage multirate decimation filter,which includes a CIC and two decimating FIR filters. The CIC filter issuitable for this high-speed application (69.333MHz) because of itsability to achieve high decimation factors and the fact that it'simplemented without using multipliers.
The CIC in this example will perform decimation by 64. The secondfilter is a 21-tap CIC-compensation FIR filter (CFIR) which has aninverse-sincpassband response, and decimates by 2.
The third stage filter is a 63-tap FIR filter (PFIR), which ensuresthat theoverall filter response meets the GSM spectral mask. It also decimatesby 2 to achieve an overall decimation factor of 256.
The CIC filter performs moderate spectral filtering to avoid spectralimaging while decimating by 64. The input data type is set to signedarithmetic with 20bit word length and 18bit fractional length (S20,18),and the output word length set to 20, which results in a fractionallength of -12. We define, analyze and plot the theoretical magnituderesponse of the CIC filter that will operate at the input rate of69.333MHz.
It is clear that the CIC filter has a huge passband gain due to theadditions and feedback within the structure. We can normalize the CIC'smagnitude response by cascading the CIC with a gain that is the inverseof the CIC's gain.
Normalizing the CIC filter response to have 0dB gain at DC will makeit easier to analyze the overlaid filter responses of the CIC and theFIR compensating filter. It may be noted by zooming in on the passbandregion that the CIC has about -0.4dB of attenuation or droop at 80kHz,which is within the bandwidth of interest. This droop must becompensated by the FIR filter in the next stage.
The compensation filterwillcompensate for the passband droop caused by the CIC filter, which isabout -0.4dB at 80kHz. This filter will operate at 1/64 the inputsample rate of 69.333MHz and will decimate by 2. The compensatingfilter is designed using a technique that offers an inverse-sincpassband response.
After cascading the CIC with the inverse sinc filter, we determineif the passband droop caused by the CIC is eliminated. As the middletrace shows, the passband droop appears to be corrected as intended (Figure 1, below ).
|Figure1. The graph shows the overlay of CIC filter response indicating -0.4dBattenuation, the response of the compensation FIR decimator, and thecombined response of the CIC filter coupled with the FIR compensator.|
The GSM spectral mask requires an attenuation of 18dB at 100kHz.Consequently, for the third and final stage, a simple equiripplelow-pass filter is used.
As before, the coefficients are quantized to 16bits. Another designrequirement for this filter is that it also needs to decimate by 2.When defining a multirate filter, the accumulator word size istypically determined automatically to maintain full precision.
However, in the current case, as the design specification restrictsthe output to only 20bits, we set the output word length to 20bits witha fractional resolution of 12bits.
After designing and quantizing the three filters, the overall filterresponse can be obtained by cascading the normalized CIC and the twoFIR filters. Again, the normalized CIC filter is used to ensure thatthe filter responses use the same scale.
Stages 2 to 4
In the second stage of model-based design (simulation), we overlay theGSM spectral mask on the filter response to see if the overall filterresponse meets the GSM specifications.
Simulation results show that the overall filter response is withinthe constraints of the GSM spectral mask. We also need to ensure thatthe passband ripple meets the requirement that it is less than 0.1dBpeak-to-peak.
We can verify this by zooming in using the axis command and confirmthat the passband ripple is well below the 0.1dB peak-to-peak GSMrequirement.
The third stage is implementation – either by manually coding thespecification or by automatically generating code from thespecification. In this case, we use automatic code generation togenerate synthesizable (RTL) VHDL code.
It is also very convenient to either automatically generate ormanually create testbenches in VHDLor Verilog, orscripts forsimulating, testing and verifying the RTLimplementation. In this case, we generate only the VHDL code, as weintend to use a system-level testbench that gives greater flexibility,visualization capabilities and speed of simulation than traditional HDLtestbenches.
During filter design, a systemlevel model of the complete filterchain is generated automatically. This system-level model will serve asthe golden reference, and allows direct comparison of simulationresults of the HDL code implementation directly against the originaldesign.
Direct co-simulationbetween the system-level golden reference model and the HDL simulatorwill be very useful to functionally verify that the generated HDL codeproduces the same results as the original design.
In this example, we use Simulinkas the environment for model-based design and for implementing thesystem-level testbench. We use ModelSim for performing HDL simulationsand Link for ModelSim to establish cosimulation connectivity betweenthe model-based design environment and the HDL simulator.
In the system-level testbench, there are two signal paths. Onesignal path produces results from the Simulink behavioral model -golden reference – of the three-stage multiratefilter. The other path produces the results of simultaneouslysimulating the automatically generated VHDL code implementation of thefilter chain in ModelSim .
During HDL code generation, the hardware latency and the hardwarereset latency are automatically estimated. These estimates are thenused directly in the system-level testbench.
|Figure2. Shown are results of system-level verification done throughco-simulation.|
For the behavioral model simulation, we generated a block comprised ofthe three-stage multirate filter we designed and placed that in thesystem-level model from which we co-simulated with an HDL simulator (Figure 2, above ). The trace on thetop is the excitation chirp signal.
The second signal from the top, labeled ref , is thesimulationoutput produced by the system-level behavioral model of the three-stagemultirate filter. This behavioral model was automatically created as apart of the process of modelbased design based on the originalspecifications and simulations during the initial stages.
The third signal from the top, labeled cosim , is theoutput ofsimulating the automatically generated VHDL code in an HDL simulator.Again, using the principles, both the behavioral model and thegenerated code are simulated at once and from the same designenvironment.
The last signal at the bottom is the per-sample computed differencebetween the simulation results of the behavioral model and thesynthesizable VHDL code. The error is zero for each sample.
Paul Pacheco is Manager, MATLABSignal Processing, and Brian Ogilvie is Principal Engineer at The Mathworks Inc.