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.

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.

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.

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.

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.

Previous 1 2 3

RSS    Save to Del.icio.us  Digg This