Techniques for Creating Models and Generating Optimized Code for Fixed-Point Designs
 

[B]Techniques for Creating Models and Generating Optimized Code for Fixed-Point Designs Using Simulink 6[/B]


[B]by[/B] [EMAIL="[email protected]"]Tom Erkkinen[/EMAIL] and [EMAIL="[email protected]"]Vinod Reddy[/EMAIL]
Creating and implementing fixed-point designs is challenging because we live (and think) in a floating-point world. For example, my outside thermometer currently reads 33°F, not 100001°F. Yet thousands of engineers use [URL="http://www.mathworks.com/products/simulink/"]Simulink[/URL] every day to design fixed-point embedded systems and will continue to do so for as long as fixed-point processors perform calculations faster and are less expensive than their floating-point counterparts.
[URL="http://www.mathworks.com/products/simfixed/"]Simulink Fixed Point[/URL] helps engineers transition from floating- to fixed-point by providing automatic scaling tools and intrinsic fixed-point data types. [URL="http://www.mathworks.com/products/rtwembedded/"]Real-Time Workshop Embedded Coder[/URL] automatically generates code from fixed-point designs that will run in mass-production embedded systems.
A popular article describing tips and techniques for quickly creating fixed-point models and generating optimized fixed-point code using MathWorks products appeared in the November 2002 issue of MATLAB Digest. It was prepared by MathWorks developers and based on Simulink 5. We have updated this article based on Simulink 6 and it is now available on [URL="http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=7197&objectType=FILE"]MATLAB Central[/URL].
The update provides an overview of fixed-point, key definitions, design considerations, and a generalized design process. The majority of the article, however, and its most heavily referenced section, is the rich collection of tips about modeling style and code generation options for designing and implementing fixed-point designs optimized for:[LIST][*]RAM[*]ROM[*]Execution speed[*]Accuracy[*]Ease of design[*]Ease of integration[/LIST][B]Fixed Point Quiz[/B]

Not sure if the article update is worth reading? Take this quiz.[LIST=1][*]In [URL="http://www.mathworks.com/products/stateflow/"]Stateflow[/URL], which action statement produces the most optimized code?[LIST=1][*]y1 = x + 4.5;[*]y2 = x + 4.5c;[/LIST][*]In Simulink, which x-axis table values produce the most optimized code for an input signal with a resolution of 2^-10?[LIST=1][*]x_breakpoints = [20.05 20.1 20.15 20.2][*]x_breakpoints = [20.0498 20.0996 20.1494 20.1992][/LIST][/LIST]The answer to both questions is (b). In fact, the efficiency savings is quite large and may even determine whether you can fit your code within a processor’s existing memory resources or need to add extra memory. This can quickly become expensive if, let's say, you must add $5–10 more memory per unit and you plan to make 1,000,000 parts.
The following tip describes the importance of using the Stateflow operator C per question (1) above, but you will have the read the updated [URL="http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=7197&objectType=FILE"]article[/URL] to learn about question (2) and many others.
[B]Example Tip – Use Stateflow Operator “C”[/B]

Use the C qualifier after literal constants in Stateflow to make the code generator automatically consider the usage context of the constant. This causes the code generator to use the optimal data type for that constant.
Figure 1 shows a Stateflow chart in a Simulink model. The content of this Stateflow chart allows us to compare not using the C qualifier with using it. Notice that the first equation, called “simple” in the figure, does not use the C qualifier with the constant 4.5. The second, called “better,” does. (The “c” is not case-sensitive.)
Figure 1 also shows the generated code. In the first equation (simple), the addition operation occurs in floating-point because the C qualifier was not specified in the Stateflow chart for the constant 4.5. In contrast, because the C qualifier was specified in the second equation (better), the code generator converted the 4.5 constant to its equivalent fixed-point value (36). It did so based on context. “Context” refers to the data type and scaling of the other operands in the expression. You can also explicitly specify parameter objects in the base workspace and not rely on context. In this example, the data type and scaling of the constant is that of the variable “x,” namely sfix16_En3. Therefore, using the C qualifier automatically selects the appropriate data type and scaling of the constant, based on the context, and the addition occurs with integer mathematics. As a result, ROM consumption and execution time decrease compared with the first equation.
[URL="http://www.mathworks.com/company/newsletters/digest/2005/mar/images/sfmodel_wl.jpg"][IMG]http://www.mathworks.com/company/newsletters/digest/2005/mar/images/sfmodel_w.gif[/IMG][/URL] [I]Figure 1. Stateflow model and code showing C qualifier. Click on image to see enlarged view.[/I]

[URL="http://www.mathworks.com/company/newsletters/digest/2005/mar/fixpt_designs.html"]更多...[/URL]