|
|
|
| R2011b Documentation → Simulink Fixed Point | |
Learn more about Simulink Fixed Point |
|
| Contents | Index |
| On this page… |
|---|
Reduce Cumbersome Multiplications Optimize the Number of Multiply and Divide Operations Reduce Multiplies and Divides with Nonzero Bias Minimize Internal Conversion Issues |
You can use the Simulink Model Advisor to help you configure your fixed-point models to achieve a more efficient design and optimize your generated code. To use the Model Advisor to check your fixed-point models:
From the Tools menu of the model you want to analyze, select Model Advisor. The Model Advisor appears.
In the left pane, expand the By Product node and select Embedded Coder.
From the Model Advisor Edit menu, select Select All to enable all Model Advisor checks associated with the selected node. For fixed-point code generation, the most important check boxes to select are Identify questionable fixed-point operations, Identify blocks that generate expensive saturation and rounding code, and Check the hardware implementation.
Click Run Selected Checks. Any tips for improving the efficiency of your fixed-point model appear in the Model Advisor window.
The sections that follow discuss possible messages that might be returned when you use the Model Advisor check titled Identify questionable fixed-point operations. The sections explain the messages, discuss their importance in fixed-point code generation, and offer suggestions for tweaking your model to optimize the code.
Efficiency trade-offs related to lookup table data are described in Effects of Spacing on Speed, Error, and Memory Usage. Based on these trade-offs, the Model Advisor identifies blocks where there is potential for efficiency improvements. Messages like the following are shown in the browser to alert you to these cases:
Lookup table input data is not evenly spaced. An evenly spaced table might be more efficient. See fixpt_look1_func_approx.
The lookup table input data is not evenly spaced when quantized, but it is very close to being evenly spaced. If the data is not tunable, then it is strongly recommended that you consider adjusting the table to be evenly spaced. See fixpt_evenspace_cleanup.
Lookup table input data is evenly spaced, but the spacing is not a power of two. A simplified implementation could result if the table could be reimplemented with even power-of-two spacing. See fixpt_look1_func_approx.
Targeting an Embedded Processor discusses the capabilities and limitations of embedded processors. Design Rules recommends that inputs to a multiply operation should not have word lengths larger than the base integer type of your processor. Multiplication with larger word lengths can always be handled in software, but that approach requires much more code and is much slower. The Model Advisor identifies blocks where undesirable software multiplications are required. Visual inspection of the generated code, including the generated multiplication utility function, will make the cost of these operations clear. It is strongly recommended that you adjust the model to avoid these operations. Messages like the following are shown in the browser to alert you to this situation:
A very cumbersome multiplication is required by this block. The first input has 8 bits. The second input has 32 bits. The ideal product has 40 bits. The largest integer size for the target has only 32 bits. Saturation is ON, so it is necessary to determine all 40 bits of the ideal product in the C code. The C code required to do this multiplication is large and slow. For this target, restricting multiplications to 16 bits times 16 bits is strongly recommended.
A very cumbersome multiplication is required by this block. The first input has 8 bits. The second input has 32 bits. The ideal product has 40 bits. The largest integer size for the target has only 32 bits. The relative scaling of the inputs and the output requires that some of the 8 most significant bits of the ideal product be determined in the C code. The C code required to do this multiplication is large and slow. For this target, restricting multiplications to 16 bits times 16 bits is strongly recommended.
The number of multiplications and divisions that a block performs can have a big impact on accuracy and efficiency. The Model Advisor detects some, but not all, situations where rearranging the operations can improve accuracy, efficiency, or both.
One such situation is when a calculation using more than one division operation is computed. A browser message will identify Product blocks that are doing multiple divisions. Note that multiple divisions spread over a series of blocks are not detected by Model Advisor:
This Product block is configured to do more than one division operation. A general guideline from the field of numerical analysis is to multiply all the denominator terms together first, then do one and only one division. This improves accuracy and often speed in floating-point and especially fixed-point. This can be accomplished in Simulink by cascading Product blocks.
Another situation is when a single Product block is configured to do more than one multiplication or division operation. A browser message will identify Product blocks doing multiple operations:
This Product block is configured to do more than one multiplication or division operation. This is supported, but if the output data type is integer or fixed-point, then better result are likely if this operation is split across several blocks each doing one multiplication or one division. Using several blocks allows the user to control the data type and scaling used for intermediate calculations. The choice of data types for intermediate calculations affects precision, range errors, and efficiency.
Rules for Arithmetic Operations discusses the implementation details of fixed-point multiplication and division. That section shows the significant increase in complexity that occurs when signals with nonzero biases are involved in multiplication and division. The Model Advisor puts a message in the browser that identifies blocks that require these complicated operations. It is strongly recommended that you make changes to eliminate the need for these complicated operations:
This block is multiplying signals with nonzero bias. It is recommended that this be avoided when possible. Extra steps are required to implement the multiplication (if possible). Inserting a Data Type Conversion block before and after the block doing the multiplication allows the biases to be removed and allows the user to control data type and scaling for intermediate calculations. In many cases the Data Type Conversion blocks can be move to the "edges" of a (sub)system. The conversion is only done once and all blocks can benefit from simpler bias-free math.
Scaling adjustment is an extremely common operation in fixed-point designs. In the vast majority of cases, shifts left or shifts right are sufficient to handle the scaling adjustment. This occurs when the slope adjustment is an exact power of two, and the bias adjustment term is zero. Situations where shifts are not sufficient to handle scaling adjustments are called mismatched scaling. Cases of mismatched scaling can involve either mismatched slopes or mismatched biases.
For mismatched slopes, it is necessary to multiply by an integer correction term in addition to shifting. The need for this extra multiplication often represents a design oversight. The extra multiplication requires extra code, slows down the speed of execution, and usually introduces additional precision loss. By adjusting the scaling of the inputs or outputs, you can eliminate mismatched slopes. The most efficient designs minimize the number of places where mismatched slopes occur. The need to handle mismatched slopes can occur in many Simulink blocks, including Product, Sum, Relational Operator, and MinMax. A browser message will identify these blocks. The Data Type Conversion block can also face mismatched slopes, but it is assumed that this explicit conversion is intentional, so no Model Advisor messages are issued:
This block is multiplying signals with mismatched slope adjustment terms. The first input has slope adjustment 1.01. The second input has slope adjustment 1. The output has slope adjustment 1. The net slope adjustment is 1.01. This mismatch causes the overall operation to involve two multiply instructions rather than just one as expected. The mismatch can be removed by changing the data type of the output.
This Sum block has a mismatched slope adjustment term between an input and the output. The input has slope adjustment 1.5. The output has slope adjustment 1. The net slope adjustment is 1.5. This mismatch causes the Sum block to require a multiply operation each time the input is converted to the outputs data type and scaling. The mismatch can be removed by changing the scaling of the output or the input.
This MinMax block has mismatched slope adjustment terms between an input and the output. The input has slope adjustment 1.125. The output has slope adjustment 1. The net slope adjustment is 1.125. This mismatch causes the MinMax block to require a multiply operation each time the input is converted to the data type and scaling of the output. The mismatch can be removed by changing the scaling of either the input or output.
This Relational Operator block has mismatched slope adjustment terms between the first and second input. The first input has slope adjustment 1. The second input has slope adjustment 1.125. The net slope adjustment is 1.125. This mismatch causes the relational operator block to require a multiply operation each time the nondominant input is converted to the data type and scaling of the dominant input. The mismatch can be removed by changing the scaling of either of the inputs.
For mismatched bias, it is usually necessary to add or subtract an integer correction term as a separate step in addition to the normal shifting. Like slope mismatch, the need to do this extra addition often represents a design oversight. Except for the Data Type Conversion block, Model Advisor assumes mismatched bias is an oversight. A message such as the following appears in the browser, identifying blocks that could be made more efficient by eliminating mismatched biases:
For this Sum block, the addition and subtraction of the input biases do not cancel with the output bias. The implementation will include one extra addition or subtraction instruction to correctly account for the net bias adjustment. Changing the bias of the output scaling can make the net bias adjustment zero and eliminate the need for the extra operation.
Many fixed-point operations need to do internal data type and scaling conversions. Fixed-point operations are based upon lower-level operations, such as integer addition and integer comparisons, that require the arguments to have the same data type and scaling. This is why blocks built on these operations, such as Sum, Relational Operator, and MinMax, must do internal conversions. There can be issues related to these internal conversions, such as range errors, that lead to overflows and loss of efficiency. Model Advisor warns separately about these two issues with messages like the following:
For this Relational Operator block, the first input has the greater positive range. The second input is converted to the data type and scaling of the first input prior to performing the relational operation. The first input has range 0 to 255.996 but the second input has range -4 to 3.96875 so a range error can occur when casting.
For this MinMax block, an input is converted to the data type and scaling of the output prior to performing the relational operation. The input has range 0 to 255.996 but the output has range -256 to 255.992, so a range error can occur when casting.
For this Relational Operator block, the second input has the greater positive range. The first input is converted to the data type and scaling of the second input prior to performing the relational operation. The first input has range -4 to 3.96875 but the second input has range 0 to 255.996, so a range error can occur when casting.
The Sum block can have a range error prior to the addition or subtraction operation being performed. For simplicity of design, the sum block always casts each input to the output's data type and scaling prior to performing the addition or subtraction. One of the inputs has range -128 to 127.996 but the output has range -32 to 31.999 so a range error can occur when casting the input to the outputs data type. Users can get any addition subtraction their application requires by inserting data type conversion blocks before and/or after the sum block. For example, suppose the inputs were a combination of signed and unsigned 8 bits with binary points that differed by at most 5 places. The output of the sum block could be set to signed 16 bit with scaling that matched the most precise input. When the inputs were cast to the outputs data type there would be no loss of range or precision. A conversion block after the sum block would allow the final result to be put in whatever data type was desired.
The Sum block can have a range error prior to the addition or subtraction operation being performed. For simplicity of design, the sum block always casts each input to the output's data type and scaling prior to performing the addition or subtraction. Note, for better accuracy and efficiency, nonzero bias terms are handled separately and are not included in the conversion from input to output. The ranges given below for the input and output exclude their biases. One of the inputs has range -4 to 3.96875 but the output has range 0 to 63.999 so a range error can occur when casting the input to the outputs data type. Users can get any addition subtraction their application requires by inserting data type conversion blocks before and/or after the sum block. For example, suppose the inputs were a combination of signed and unsigned 8 bits with binary points that differed by at most 5 places. The output of the sum block could be set to signed 16 bit with scaling that matched the most precise input. When the inputs were cast to the outputs data type there would be no loss of range or precision. A conversion block after the sum block would allow the final result to be put in whatever data type was desired.
For some operations, the need to do an internal conversion can represent a design oversight. The impact of this oversight is a loss of efficiency, and possibly a loss of accuracy. As an example, consider the comparison of a signal against a constant using a Relational Operator block. To compare a fixed-point signal against a constant, the underlying implementation should directly compare the stored integer of the input signal against an invariant stored integer. If the scaling or data type of the signal and constant are different, then it is also necessary to do a conversion operation. This extra conversion work is usually inefficient and is often unexpected. The Model Advisor warns about these situations with messages like the following:
For this MinMax block, an input is converted to the data type and scaling of the output prior to performing the relational operation. The input has precision 0.00390625. The output has precision 0.0078125, so there can be a precision loss each time the conversion is performed.
For this relational operator block, the data types of the first and second inputs are not the same. A conversion operation is required every time the block is executed. If one of the inputs is invariant (sample time color magenta), then changing the data type and scaling of the invariant input to match the other input is a good opportunity for improving the efficiency of your model.
For this MinMax block, the data types of the output and an input are not the same. A conversion operation is required every time the block is executed.
Specify rounding options for fixed-point operations by setting a combination of these parameters:
Integer rounding mode
Use the Integer rounding mode parameter on your model's blocks to simulate the rounding behavior of the C compiler that you use to compile code generated from the model. This setting appears on the Signal Attributes pane of the parameter dialog boxes of blocks that can perform signed integer arithmetic, such as the Product block.
Signed integer division rounds to parameter
This parameter is available from Configuration Parameters > Hardware Implementation > Embedded Hardware. It describes how to produce a signed integer quotient for the production hardware. For most blocks, the value of Integer rounding mode completely defines rounding behavior. For blocks that support fixed-point data and the Simplest rounding mode, the value of Signed integer division rounds to also affects rounding. For details, see Simplest rounding.
Traditional handwritten code, especially for control applications, almost always uses "no effort" rounding. For example, for unsigned integers and two's complement signed integers, shifting right and dropping the bits is equivalent to rounding to floor. To get results comparable to, or better than, what you expect from traditional handwritten code, use the simplest rounding mode. In general the simplest mode provides the minimum cost solution with no overflows. If the simplest mode is not available, round to floor.
The primary exception to this rule is the rounding behavior of signed integer division. The C standard leaves this rounding behavior unspecified, but for most production targets the "no effort" mode is to round to zero. For unsigned division, everything is nonnegative, so rounding to floor and rounding to zero are identical. To improve rounding efficiency, set Configuration Parameters > Hardware Implementation > Embedded Hardware > Signed integer division rounds to using the mode that your production target uses.
For more information on properties to consider when choosing a rounding mode, see Choosing a Rounding Method in the Fixed-Point Toolbox documentation.
Use the Model Advisor to alert you when rounding optimizations are available.
From the Tools menu of the model you want to analyze, select Model Advisor. The Model Advisor appears.
In the left pane, expand the By Product node and select Embedded Coder.
Select Identify blocks that generate expensive saturation and rounding code.
Click Run Selected Checks. Any tips for improving the rounding efficiency of your fixed-point model appear in the Model Advisor window.
The Model Advisor alerts you when rounding optimizations are available.
To obtain the most efficient generated code, change the Integer rounding mode parameter of the following block to Simplest or to Floor if Simplest is not available.
Integer division generated code could be more efficient. C language standards do not fully specify the rounding behavior of signed integer division. When faced with this lack of specification, the code generated for division can be large to ensure bit-true agreement between simulation and code generation.
Configuration Parameters > Hardware Implementation > Embedded Hardware > Signed integer division rounds to allows you to describe the rounding behavior of signed integer division for your production target. The rounding behavior for this model is currently set to Undefined. You can reduce the size of the code generated for division by setting this parameter. The most common behavior is that signed integer division rounds to zero.
When a change of fixed-point slope is not a power of two, net slope correction is necessary. Normally, net slope correction is implemented using an integer multiplication followed by shifts. Under some conditions, an alternate implementation requires just an integer division by a constant. One of the conditions is that the net slope can be very accurately represented as the reciprocal of an integer. When this condition is met, the division implementation produces more accurate numerical behavior. Depending on your compiler and embedded hardware, the division implementation might be more desirable than the multiplication and shifts implementation. The generated code might be more efficient in either ROM size or model execution size.
The Model Advisor alerts you when:
You select the Use integer division to handle net slopes that are reciprocals of integers optimization parameter, but your model configuration is not compatible with this selection.
Your model configuration is suitable for using integer division to handle net slope correction, but you do not select the Use integer division to handle net slopes that are reciprocals of integers optimization parameter.
See Example: Using the Model Advisor to Detect When to Use Integer Division for Net Slope Correction.
This example uses the following model.
In this model, the net slope for the Data Type Conversion and Product blocks is 1/1000.
To set up the model:
For the two Inport blocks, U and V, set the Data type to int16.
For the Data Type Conversion block, set the Integer rounding mode to Floor. Set the Output data type to fixdt(1, 33, 1000, 0).
For the Product block, set the Integer rounding mode to Convergent. Set the Output data type to fixdt(1, 16, 1000, 0).
Set the Hardware Implementation > Embedded Hardware > Signed integer division rounds to configuration parameter to Zero.
Select the Optimization > Use integer division to handle net slopes that are reciprocals of integers configuration parameter.
Save the model.
To run the Model Advisor check:
From the model menu, select Tools > Model Advisor.
The Model Advisor appears.
In the left pane, expand the By Product node and then expand the Embedded Coder node.
Select Identify questionable fixed-point operations.
Click Run This Check.
The Model Advisor provides warnings that your model configuration is not compatible with the use of division for net slope correction. It also provides recommendations on how to change your model configuration to make it compatible:
The Product block is not using the correct rounding mode. Change the Integer rounding mode parameter to Simplest or to match the configuration parameter setting, Hardware Implementation > Embedded Hardware > Signed integer division rounds to.
The Data Type Conversion block is not using the correct rounding mode. Change the Integer rounding mode parameter to Simplest or to match the configuration parameter setting, Hardware Implementation > Embedded Hardware > Signed integer division rounds to.
The Data Type Conversion block is using multiword operations. Change the word length of the block to avoid multiword operations.
Make the suggested changes:
For the Product and Data Type Conversion blocks, change the rounding mode to Simplest.
For the Data Type Conversion block, change the Output data type from fixdt(1, 33, 1000, 0) to fixdt(1, 16, 1000, 0) to avoid multiword operations.
Save the model.
This is your model configuration.
Rerun the Model Advisor Identify questionable fixed-point operations check.
The Model Advisor no longer reports the warnings about rounding mode and multiword operations. Your model configuration is compatible with using integer division to handle net slope correction.
This example uses the following model.
In this model, the net slope for the Data Type Conversion and Product blocks is 1/1000.
To set up the model:
For the two Inport blocks, U and V, set the Data type to int16.
For the Data Type Conversion block , set the Integer rounding mode to Simplest. Set the Output data type to fixdt(1, 16, 1000, 0).
For the Product block, set the Integer rounding mode to Simplest. Set the Output data type to fixdt(1, 16, 1000, 0).
Set the Hardware Implementation > Embedded Hardware > Signed integer division rounds to configuration parameter to Zero.
Clear the Optimization > Use integer division to handle net slopes that are reciprocals of integers configuration parameter.
Save the model.
To run the Model Advisor check:
From the model menu, select Tools > Model Advisor.
The Model Advisor appears.
In the left pane, expand the By Product node and then expand the Embedded Coder node.
Select Identify questionable fixed-point operations.
Click Run This Check.
The Model Advisor warns that your model configuration is not optimal and provides the following recommendation:
The Product and Data Type Conversion blocks are not using integer division for net slope correction. Selecting Optimization > Use integer division to handle net slopes that are reciprocals of integers might generate more efficient code.
Select the Use integer division to handle net slopes that are reciprocals of integers optimization parameter.
Rerun the Model Advisor Identify questionable fixed-point operations check.
The Model Advisor no longer reports the warning. Your model now uses integer division to handle net slope correction. This configuration results in more efficient code if division is more efficient than multiplication followed by shifts on your target hardware. For more information, see Handle Net Slope Correction.
 | Optimizing Your Generated Code | Fixed-Point Advisor Reference |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
