Model-Based Design

A methodology that addresses todays growing challenges of designing embedded systems.

by Ali Behboodian
Applications Engineer The MathWorks ali.behboodian@mathworks.com Embedded systems have transformed technology products from everyday consumer electronic devices to complex industrial systems. As hardware and memory become less expensive and more powerful, embedded systems will become even more pervasive. At the same time, the designs will become more complex. To meet this demand, engineers must find ways to efficiently develop software and hardware at an even faster rate. A methodology that addresses this is model-based design. The MathWorks Simulink product family enables you to apply model-based design in a graphical, interactive environment, where you can visualize your system models and subsystem designs using intuitive block diagrams. The models are hierarchical and you can partition the system into functional units. The graphical environment allows you to understand the design and the interactions of the subsystems more easily than text-based models. In this article, Ill present a model-based design methodology in the context of the design and implementation of the Sobel edge-detection algorithm on an FPGA. Note that you can readily apply these concepts for embedded designs in a wide range of applications in different industries, such as aerospace and defense, automotive, communications, consumer electronics, and medical electronics. 52
DSP magazine
Copyright 2006 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc. All other trademarks are the property of their respective owners.

May 2006

Figure 1 shows the elements of modelbased design. The center focus of this design methodology is a model, whose four main elements are: Executable specifications Design with simulation Implementation with code generation Continuous test and verification Ill explain the above four elements and apply them to the design and implementation of the Sobel edge-detection algorithm. For a more comprehensive application of model-based design, see the article, The Design and Implementation of a GPS Receiver Channel from Issue 1 of DSP Magazine (www.xilinx.com/publications/ magazines/dsp_01/dsp_gps01.htm). Executable Specification As designs become larger and more complicated, it becomes necessary to first describe them at a high level of abstraction. Simulink, together with applicationspecific blocksets such as the Signal Processing Blockset, the Communications Blockset, and the Video and Image Processing Blockset, provides an excellent graphical environment for a high-level description of embedded algorithms. System engineers usually develop this high-level description. A high-level Simulink model serves several purposes: It enables designers to perform simulations by directly executing the Simulink model It is used throughout the development process for testing, verification, and implementation It allows developers to identify bugs early on and avoid costly bug discovery towards the end of development It eliminates the need for paper-based specification, which is easily prone to misinterpretations, and replaces it with the executable specification Each member of a design team can understand and execute the model and
May 2006

Figure 1 Elements of model-based design

can focus further in developing parts of the main model We call this high-level model the executable specification, or golden reference. The executable specification for the Sobel edge-detection algorithm is illustrated in Figure 2. The algorithm comprises two 2D filters, each with a 3 x 3 kernel (one filter estimating the edges at the x direction and one in the y direction), two square operations, and a threshold operation. The

model is the start for a path that will lead all the way to an FPGA implementation. Figure 2 also shows the input image to the algorithm as well as the output of the algorithm. In the Simulink environment, you can also examine and visualize every signal throughout the model. Note that the input and output images in the executable specification are test vectors for the algorithm. You can use these test vectors throughout the design process to validate your design against the executable specification. Because the entire design is performed in the Simulink environment, there is no need for extra overhead in porting the test vectors into different applications, or creating test harnesses in HDL that are prone to human errors. The test harness used in the executable specification is used throughout the design. Design with Simulation When designing the executable specification, the system engineer generally does not keep the implementation details in mind, but rather designs the algorithm to match the behavioral requirements for the system. Once the system engineer submits the exeDSP magazine

Figure 2 Executable specification/golden reference for the Sobel edge-detection algorithm

53

cutable specification to the development team, the team may need to make modifications to it to fit the design into a real-time embedded system that may have limited resources, such as memory or processing power. These modifications may cause the output of the new design to deviate from the original design. Design engineers should decide if the deviation is acceptable. In this section, Ill make two modifications to the algorithm to make it suitable for hardware implementation and demonstrate how to continuously verify the design against the executable specification. Redesigning the Algorithm Lets say that the developers decide to eliminate the square operations in Figure 2 and replace them with the absolute value operations for more efficient hardware implementation. Generally, such changes in the model are required for hardware implementation and are mostly done by experienced engineers in a design team. Simulink provides an environment where you can redesign an algorithm and validate your designs in a relatively short time. After switching the square operations with the absolute value operations, the final result does not exactly match the output of the executable specification, but the difference is quite small and in this case acceptable. Fixed-Point Implementation Because the ultimate goal is to implement the algorithm in an FPGA, for my example I must convert my double-precision design to a fixed-point design. This can be done easily using Simulink. I used the doubleprecision model I developed to directly develop a fixed-point model without introducing any new blocks. Simulink allows you to determine the number of bits and scaling for data as well as mathematical operations, and provides a great environment for analyzing the fixedpoint operation of a system. In the fixed-point design, the inputs to the filters are signed 9-bit integers and the outputs of the filters are signed 11-bit integers. The developers can tune the bit width and scaling related to the internal compu54
DSP magazine

tations of the blocks. This gives huge leverage to the designer to compromise between matching the output of the executable specification while using the least number of bits necessary to save area on the device. Figure 3 shows the new fixed-point design after replacing the square operations with absolute value operations. In this figure, the new design is compared to the executable specification and the difference is shown both visually as well as numerically. Continuous test and verification is a key part of model-based design and is crucial to the success of a project. Simulink provides an excellent environment for this purpose. Elaboration of the Design In my example, the input to the edgedetection algorithm has been a two-dimensional image of 200 x 100 pixels. In a real-time system, the input is most likely

To this extent, I first serialized the input image. Then I performed the 2D filtering on this serial data. I later de-serialized the stream of data to be able to compare the output to the executable specification. This operation is done only for the bottom filter. I also added two delay elements to compensate for the buffering in the serializer block. As expected, the new design is still producing the same exact results as before. This design also showcases the multirate capability of Simulink. The output rate of the serializer block is 20,000 times higher than the input rate. (Remember that the image size is 200 x 100. Because the image rate is 1 image per second, the sample rate after serialization is 20,000 samples per second.) Figure 4 illustrates the elaborated design.

Figure 3 -The image on the left shows the output of the executable specification. The one in the middle shows the output of the new design, including fixed-point design, and replaces the square operations of Figure 2 with absolute value operations. The one on the right depicts the difference between the two designs. The mean difference is 2.793%.

Figure 4 Elaborated design. A serializer and deserializer are designed and the 2D filter is operating on a stream of 1D data.

not a matrix but a serial stream of data; for example, this serial stream of data can be generated by a charge-coupled device (CCD). Therefore, I need to modify the structure of the design such that the edgedetection algorithm accepts and performs 2D filtering on a serial stream of data.

Implementation Now that Ive elaborated the design of one of the 2D filters in the Sobel edge-detection algorithm, I can now hand the elaborated design to the hardware designers for HDL implementation. There are two different approaches to consider in this secMay 2006

tion. The first approach assumes that the hardware designers will hand-code the filter algorithm in VHDL or Verilog. The second approach assumes that the developers will translate the Simulink model from the last section to a Simulink model based on Xilinx System Generator blocks and automatically generate HDL code. In both cases, the developers will verify their design against the executable specification and check the validity of their design in the Simulink environment. Manual HDL, Co-Simulation, and Verification The HDL designer on the development team can use the 2D filter design depicted in the bottom window of Figure 4 to write the corresponding VHDL or Verilog code. Once the code is written, the HDL designer can use Link for ModelSim, also from The MathWorks, to simulate the HDL design using ModelSim in the Simulink environment and compare the output of the HDL design to the output of the executable specification. Note that in this process, there is no need to generate an HDL test bench. The Simulink model feeds the input test vector to ModelSim through Link for ModelSim and extracts the data from ModelSim back to the Simulink environment. The HDL designer can

Get Published

Figure 6 Modeling of the 2D filter depicted in the bottom window of Figure 4 using Xilinx System Generator

readily verify whether the HDL code runs in accordance with the specifications. The model in Figure 5 co-simulates ModelSim and Simulink and allows you to verify the validity of the VHDL code. As you can see, the mean difference is the same as the previous model. Automatic HDL Generation, Xilinx System Generator Using Xilinx System Generator, you can build and debug DSP systems in Simulink using the Xilinx blockset. You can also automatically generate VHDL or Verilog code and run hardware-in-theloop simulations. Figure 6 illustrates a filter design (using Xilinx System Generator blocks) that is equivalent to the filter depicted in the bottom window of Figure 4. The simulation in the Simulink environment is bit-true and cycle-true. Once you have verified the results of the System Generator design against the executable specification, you can automatically generate synthesizable VHDL or Verilog code for the filter. Conclusion Model-based design helps you create better embedded software and hardware by increasing the accuracy and speed of system development. You can confidently begin integration, test, and deployment of your embedded application knowing that you have identified design errors and met your requirements. Model-based design provides a proven solution that reduces development time and cost and fosters quality and innovation in the development of embedded systems. For more information, visit www. mathworks.com/applications/dsp_comm/.

Would you like to be published in DSP Magazine?

It's easier than you think! Submit an article draft for our Web-based or printed DSP Magazine and we will assign an editor and a graphic artist to work with you to make your work look as good as possible. For more information on this exciting and highly rewarding program, please contact:

Forrest Couch
Publisher, Xcell Publications

xcell@xilinx.com

Figure 5 Co-simulation with ModelSim

May 2006

DSP magazine

55