For some arithmetic operations, a processor might need to take
an * n*-bit fixed-point value and store it
in

`m`

`m`

`n`

`m`

`n`

`Inf`

or `NaN`

.
Other processors, especially digital signal processors (DSPs), handle
overflows by saturating or wrapping the value.For more information about saturation and wrapping for integer overflow, see Saturation and Wrapping (Fixed-Point Designer).

For charts, you can control whether or not saturation
occurs for integer overflow. Use the chart property, **Saturate
on integer overflow**, to control overflow handling.

Check Box | When to Use This Setting | Overflow Handling | Example of the Result |
---|---|---|---|

Selected | Overflow is possible for data in your chart and you want explicit saturation protection in the generated code. | Overflows saturate to either the minimum or maximum value that the data type can represent. | An overflow associated with a signed 8-bit integer saturates to –128 or +127 in the generated code. |

Cleared | You want to optimize efficiency of the generated code. | The handling of overflows depends on the C compiler that you use for generating code. | The number 130 does not fit in a signed 8-bit integer and wraps to –126 in the generated code. |

Arithmetic operations for which you can enable saturation protection are:

Unary minus: –

`a`

Binary operations:

`a + b`

,`a`

–`b`

,`a * b`

,`a / b`

,`a ^ b`

Assignment operations:

`a += b`

,`a`

–`=b`

,`a *= b`

,`a /= b`

In C charts, increment and decrement operations:

`++`

,`--`

Keep the following considerations in mind when you select **Saturate
on integer overflow**:

Saturation applies to all intermediate operations, not just the output or final result.

The code generator can detect cases when overflow is not possible. In these cases, the generated code does not include saturation protection.

Charts use ANSI^{®}
C rules for integer promotion.

All arithmetic operations use a data type that has the same word length as the target word size. Therefore, the intermediate data type in a chained arithmetic operation can be different from the data type of the operands or the final result.

For operands with integer types smaller than the target word size, promotion to a larger type of the same word length as the target size occurs. This implicit cast occurs before any arithmetic operations take place.

For example, when the target word size is 32 bits, an implicit cast to

`int32`

occurs for operands with a type of`uint8`

,`uint16`

,`int8`

, or`int16`

before any arithmetic operations occur.

Suppose that you have the following expression, where `y`

, `u1`

, `u2`

,
and `u3`

are of `uint8`

type:

y = (u1 + u2) - u3;

Based on integer promotion rules, that expression is equivalent to the following statements:

uint8_T u1, u2, u3, y; int32_T tmp, result; tmp = (int32_T) u1 + (int32_T) u2; result = tmp - (int32_T) u3; y = (uint8_T) result;

For each calculation, the following data types and saturation limits apply.

Calculation | Data Type | Saturation Limits |
---|---|---|

`tmp` | `int32` | `(MIN_INT32, MAX_INT32)` |

`result` | `int32` | `(MIN_INT32, MAX_INT32)` |

`y` | `uint8` | `(MIN_UINT8, MAX_UINT8)` |

Suppose that `u1`

, `u2`

, and `u3`

are
equal to 200. Because the saturation limits depend on the intermediate
data types and not the operand types, you get the following values:

`tmp`

is 400.`result`

is 200.`y`

is 200.

Suppose that you set **Wrap on overflow** in
the **Diagnostics: Data Validity** pane of the Model
Configuration Parameters dialog box to `error`

or `warning`

. When you select **Saturate
on integer overflow**, Stateflow^{®} does not flag cases
of integer overflow during simulation. However, Stateflow continues
to flag the following situations:

Out-of-range data violations based on minimum and maximum range checks

Division-by-zero operations

Was this topic helpful?