Simulink-targetlink Datatypes Defnt Problem

Innnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnn

TargetLink Data Types Application Note September 2004 1 snnnnnnnnnnnnnnn

Simulink Scaling Parameters and TargetLink

This application note is about Simulink data types and how they are

dealt with in the TargetLink environment. This includes fixed-point

settings introduced with Simulink 5 .

TargetLink’s General Approach

TargetLink’s approach to production code development is as follows:

n The control strategy is designed either with Simulink with

subsequent conversion to TargetLink, or with TargetLink’s blockset

from scratch. In either case, the algorithm is simulated with

Simulink’s simulation engine using TargetLink blocks (MIL

simulation mode). All signals are computed in floating-point.

Scaling parameters are tagged to the TargetLink blocks. During

MIL simulations, the resulting ranges are compared to the actual

floating-point signal ranges (overflow detection).

n Production code is generated according to the scaling parameters

and run on the host (SIL mode) or on a target EVB (PIL mode). This

allows fixed-point effects to be investigated directly.

Thus, fixed-point effects are not investigated using blocks and the

Simulink simulation engine, but using the production code itself.

There is no fixed-point arithmetic in MIL mode.

Simulink’s General Approach

Simulink’s approach to production code development is as follows:

n The control strategy is designed with Simulink blocks. To allow the

generation of fixed-point code, integer data types are supported.

To scale signals, a Fixed-Point license is needed. When signals are

scaled, the associated blocks mimic fixed-point arithmetic. The

objective of mimicking fixed-point arithmetic is to predict how the

code to be generated will behave on ECU targets.

snnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

TargetLink Data Types Application Note September 2004

nnnnnnnnnnnnnt

2 nnnnnnnnnnnnnnnt

n Production code is generated according to specified types and

scaling parameters and run on the selected target.

Thus, fixed-point effects are investigated using blocks and the

Simulink simulation engine.

Comparison of Simulink and TargetLink

The two approaches sometimes conflict and cause problems with

models that were converted to TargetLink (see below). Some of these

problems have been solved, for example, by introducing the Cast

output signal to TargetLink type feature. Others cannot currently

be solved.

Simulink-to-TargetLink Conversion

During Simulink-to-TargetLink conversion, Simulink blocks are

replaced by corresponding TargetLink blocks. In the replacement

process, block parameters are read from the blocks being replaced and

written to the replacing blocks. For example, when a Simulink Gain

block is replaced, the Gain parameter is written to the TargetLink Gain

block.

The rule is that after conversion, the converted subsystem with

TargetLink blocks shows the same simulation behavior as the original

subsystem. However, due to TargetLink’s approach to data types, this

rule does not hold if non-double data types are involved. Simulink data

types are read from the blocks being replaced and written to the

TargetLink blocks. For TargetLink, data types are only tagged to the

blocks to be evaluated for production code generation. Unlike

Simulink data types, TargetLink data types have no impact on the

simulation bevaviour of the blocks.

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnt

TargetLink Data Types Application Note September 2004 3

snnnnnnnnnnI

snnnnnnnnnnnnnnn

E A subsystem is converted to TargetLink. Inside the subsystem is a

Simulink Gain block whose output signal type is specified to be

uint16. Consequently, the output data type (output.type) property of

the replacing TargetLink block is set to UInt16, and this type is used

during production code generation. However, the TargetLink Gain

block will not simulate uint16 using integer arithmetic, but will

produce doubles. This applies even if the Gain block’s input signal has

an integer data type. During MIL simulation, the output is checked for

compliance with the UInt16 range (overflow detection).

This has two consequences:

n When integer data types are involved, the simulation behavior may

be different after conversion.

n Since signal data types have changed, conversion might introduce

data type conflicts, which makes simulation after conversion

impossible without additional manual work, i.e. insertion of

DataTypeConversion blocks.

The latter could be the case if, for example, the Gain block’s output is

fed to another block outside the converted subsystem, whose input is

required to be uint16. After conversion, the Gain block’s output is

double, so the model cannot be initialized.

Evaluation of Simulink Data Types

During conversion, Simulink data types of block outputs are evaluated

and used when the data types (output.type property) of the replacing

TargetLink blocks are set. Two approaches to evaluating Simulink data

types have been implemented, as described below.

Compiled Scaling Parameters

During conversion, a model can be set to the so-called compiled

mode. In this mode, the data types and scaling parameters of all

signals (block outputs) can be read out using the Simulink API.



nnnnnnnnnnnnnt

4 nnnnnnnnnnnnnnnt

The precondition for this mode is that the model can be initialized.

This is the main reason why Simulink-to-TargetLink conversion of

subsystems in models requires that the model can be initialized, and

why conversion does not proceed if the Conversion Tool detects that

the model is not initializable. This mode is also used to evaluate signal

widths.

Simulink libraries cannot be set to compiled mode. Thus, if a library (or

a part of a library) is converted to TargetLink, data types cannot be

evaluated using compiled mode. The same problem arises with signal

widths.

Evaluating data types in compiled mode has a big advantage: inherited

data types can be considered as well as data types which are explicitly

set. In compiled mode, it makes no difference, for example, whether

the output type of a Product block is int16 because it has been

explictly set, or because the block context and inheritance rules result

in an int16 output type.

Evaluating compiled data types also has a big disadvantage (Simulink

Version 5 and 6 only): The resulting types depend on whether Simulink

runs with or without a Fixed-Point license. With a license, all fixed-

point settings are taken into account, and signals can be fixed-point

with or without scaling. Without a license, the user must set model-

specific settings so that all signals are double, as otherwise the model

fails to initialize. Thus, without a license, Simulink fixed-point settings

have no impact on the types in compiled mode. Moreover, this

behavior differs in some details between Simulink 5 and Simulink 6.

In other words, which scaling parameters are set during Simulink-to-

TargetLink conversion depends on whether there is a Fixed-Point

license or not. If Simulink fixed-point types are used, it is therefore

strongly recommended to invoke conversion on Simulink installations

with Fixed-Point licenses.



snnnnnnnnnnI

snnnnnnnnnnnnnnn

Block-specific Scaling Parameters

After compiled data types have been evaluated and TargetLink types

set accordingly, scaling parameters are retrieved on a block-by-block

basis. This is possible without compiling the model, for both model

and library conversion. However, if a block’s output inherits, for

example, an integer data type, this method will fail to detect it.

Additionally, since Simulink blocks do not have explicit scaling

parameters in Simulink 4, this step is confined to version 5 and later.

This is the second step in the conversion process. Thus, if model

compilation is not possible (for libraries), or if no Fixed-Point license is

available, Simulink scaling parameters will be mapped to TargetLink

scaling parameters during this step.

In Simulink 6, more blocks support block-specific types than in

Simulink 5. The overall number will most likely increase in future

Simulink versions.

The following table shows which Simulink block types support fixed-

point data types. Some blocks additionally support scaling parameters,

i.e., the output can be scaled. Output scaling is also taken into account

during conversion. The Simulink properties which define the fixed-

point settings are listed in the third column.

Block Type Ver. Simulink properties Scaling Remarks

DataStoreMemory 6.0+ DataTypeOutDataTypeOutScaling

Yes

Gain 5.0+ ParameterDataTypeModeParameterDataTypeParameterScalingModeParameterScalingOutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes Both output and gain can be typed

Constant 5.0+ OutDataTypeModeOutDataTypeOutScalingConRadixGroup

Yes



nnnnnnnnnnnnnt

6 nnnnnnnnnnnnnnnt

Note that Simulink parameters that have the same name do not

always mean the same, and vice versa.

Logic 5.0+ OutDataTypeModeLogicDataType

No

Lookup1D 5.0+ OutDataTypeMode Yes

Lookup2D 5.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

DiscreteIntegrator 6.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

Math 6.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

MinMax 6.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

Product 5.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

Sum 5.0+ OutDataTypeModeOutDataTypeOutScalingSaturateOnIntegerOverflow

Yes

RelationalOperator 5.0+ LogicOutDataTypeModeLogicDataType

No

Relay 5.1+ OutputDataTypeScalingModeOutDataTypeOutScalingConRadixGroup

Yes

Inport 6.0+ DataTypeOutDataTypeOutScaling

Yes Written to associated TargetLink Inport block

Block Type Ver. Simulink properties Scaling Remarks



snnnnnnnnnnI

snnnnnnnnnnnnnnn

Mapping Rules

The following table shows how Simulink data types and scaling

parameters are mapped to TargetLink scaling parameters. The rules

apply both to compiled and block-specific scaling parameters.

The rules apply to Simulink scaling parameters evaluated during model

compilation as well as on a block-by-block basis.

Typing Parameters

The output of Const blocks and the gain of Gain blocks are

parameters as opposed to block outputs and states. Parameters in this

sense are variables which keep a constant value during simulation. The

value is specified by a MATLAB expression.

Simulink TargetLink Remarks

data typesint8, int16, int32, uint8, uint16, uint32, single, boolean

Int8, Int16, Int32, UInt8, UInt16, UInt32,.Float32, Boolean

For Math blocks, integer types are only set if supported for current function

data type double To the currrent default TargetLink data type according to the current data dictionary (Int16 in a default installation)

For Math blocks, integer types are only set if supported for current function

Slope and Bias output.lsb and output.offset

If the block is vectorized, all elements are set to the values specified in Simulink

sfix, ufix, sint, uint, float, sfrac, ufrac

To corresponding signed or unsigned integer or floating-point type Integers only if number of bits is 8, 16, or 32

Types like ufix(4) are not mapped to TargetLink, since 4-bit integers are not supported in TargetLink

SaturateOnIntegerOverflow To output.checkmin and output.checkmax

Only if Simulink type is integer. Note that Simulink does not support saturation to one bound only.



nnnnnnnnnnnnnt

8 nnnnnnnnnnnnnnnt

In Simulink, both Constant block outputs and gains can have scaling

parameters. In TargetLink, they are scaled only if the associated

variable class (output.class or gain.class property) is not set to

default. “default” means that in generated production code, the

variable (gain or const) will not be represented by a variable but

merged into operations.

If a Simulink Const or Gain is detected to be scaled, the Conversion

Tool selects a suitable variable class and writes it to the block. For this

purpose, the first dSPACE Data Dictionary variable class object which

complies with the following requirements is selected:

n The property Const is on,

n The property Scope is Global,

n The property Macro is off,

n The property Storage is default,

n The property Info is none,

n The property Optimization is movable or erasable.

Additionally, a message such as the following is output:

To enable setting of scaling parameters, the gain.class

property was set to Const.

Reconversion to Simulink

Simulink fixed-point settings which applied before a subsystem was

converted to TargetLink ought to be restored by the reconversion

process. However, there are some differences between TargetLink and

Simulink which make it difficult to unambiguously map TargetLink

scaling parameters to Simulink scaling parameters:

n Various TargetLink scaling parameter sets (that is, data type, LSB

and offset values) can be mapped to different Simulink parameter

sets. For example, TargetLink’s UInt16, LSB = 2^0, Offset = 0 can

be mapped either to Simulink ufix(16), [Slope Bias] = [2^0 0], or to

uint16. There are many cases where mapping is similarly

ambiguous.



snnnnnnnnnnI

snnnnnnnnnnnnnnn

n For vectorized variables, TargetLink LSB and offset values can be

set for each vector element individually, while in Simulink the

associated parameters are scalars which apply to all vector

elements.

n Saturation on integer overflow in Simulink cannot be specified for

the lower and upper bounds separately, as is possible in

TargetLink.

To resolve these issues, the following approach has been

implemented:

n During Simulink-to-TargetLink conversion, all data type and scaling

related parameters are saved to the replacing TargetLink block.

This applies only to Simulink 5 and 6.

The saved Simulink scaling parameters are retrieved from the

TargetLink blocks during TargetLink-to-Simulink conversion. In many

cases, there are none, either because the block concerned does not

originate from a conversion (but was directly copied from TargetLink’s

blockset), or because the conversion was done with Simulink 4. If

there are no scaling parameters, no such parameters are written to the

Simulink block, which therefore has Simulink’s default settings for

scaling parameters. If there are any scaling parameters, the conversion

routine checks whether they correspond to the current TargetLink

parameters according to the table above. If they do, they are written

to the replacing Simulink block. This resolves most ambiguity

problems. If they do not, the table below applies.



nnnnnnnnnnnnnt

10 nnnnnnnnnnnnnnnt

Simulink TargetLink Results

Saved Simulink data type wasint8, int16, int32, uint8, uint16, uint32, single, double, or boolean.

TargetLink data type is Int8, Int16, Int32, UInt8, UInt16, UInt32,.Float32, Float64, Boolean or a user-defined type whose base type is one of these types.

The Simulink data type is written to the block. The TargetLink LSB and offset are not used.

Saved Simulink data type was specified with an sfix function call, or an uint, sint, ufrac or sfrac function call and [LSB offset] is not [20 0] or [2-wordwidth 0], respectively.

TargetLink data type is Int8, Int16, Int32, UInt8, UInt16, UInt32,.Float32, Float64, Boolean or a user-defined type.

Int8 -> sfix(8)Int16 -> sfix(16)Int32 -> sfix(32)UInt8 -> ufix(8)UInt16 -> ufix(16)UInt32 -> ufix(32)Float32 -> float(‘single’)Float64 -> float(‘double’)[LSB offset] -> [Slope Bias]If the LSB or offset is different across vector, the first values are written and a warning is issued.

Saved Simulink data type was specified with an uint or sint function call, and [LSB offset] is [20 0].

TargetLink data type is Int8, Int16, Int32, UInt8, UInt16, UInt32 or a user-defined type with integer base type.

Int8 -> sint(8)Int16 -> sint(16)Int32 -> sint(32)UInt8 -> uint(8)UInt16 -> uint(16)UInt32 -> uint(32)

Saved Simulink data type was specified with an ufrac or sfrac function call, and [LSB offset] is [2-wordwidth 0].

TargetLink data type is Int8, Int16, Int32, UInt8, UInt16, UInt32 or a user-defined type with integer base type.

Int8 -> sfrac(8)Int16 -> sfrac(16)Int32 -> sfrac(32)UInt8 -> ufrac(8)UInt16 -> ufrac(16)UInt32 -> ufrac(32)

SaturateOnIntegerOverflow

output.checkmin and output.cheeckmax

If Simulink type is integer: SaturateOnIntegerOverflow is set to the value of output.checkmin if output.checkmin == output.checkmax. Otherwise, a warning is issued.



snnnnnnnnnnI

snnnnnnnnnnnnnnn

Signal Data Types of TargetLink blocks

As stated before, TargetLink blocks behave differently than

corresponding Simulink blocks with regard to non-double data types.

Simulink blocks support numerous inheritance schemes, and for many

blocks the signal output can be set explicitly, which in turn influences

the type of the input signals.TargetLink blocks generally emit doubles

and accept any nonscaled type at their inputs. However, some

TargetLink blocks deviate from this in specific details. In any of these

cases, the different behavior might result in models which cannot be

initialized after Simulink-to-TargetLink conversion.

The following list provides some details. “All Simulink types” means

int8, int16, ..., single, double, boolean. “Scaled signals

accepted” means that signals which are scaled in Simulink can be fed

into the block. “Same as Simulink” means that the block behaves

exactly like the corresponding Simulink block. The Typecast column

indicates whether the block supports the Cast output signal to

TargetLink type feature.

Nr Block Type Input(s) Output(s) Typecast Remarks

1 Abs All Simulink types

double Yes

2 Assignment Same as Simulink

Same as Simulink

No

3 Constant - According to type of Constant value

No

4 Counter/Alarm double double No

5 Custom Code All Simulink types

double No

6 D Flip-Flop All Simulink types

double Yes

7 D Latch All Simulink types

double Yes

8 Data Store Memory - - No

9 Data Store Read Same as Simulink

Same as Simulink

No



nnnnnnnnnnnnnt

12 nnnnnnnnnnnnnnnt

10 Data Store Write Same as Simulink

Same as Simulink

-

11 Direct Look-Up Table (n-D)

All Simulink types

double Yes

12 Discrete Filter double double Yes

13 Discrete State-Space

double double Yes

14 Discrete Transfer Function

double double Yes

15 Discrete-Time Integrator

double double Yes

16 FIR Filter double double Yes

17 Fcn Same as Simulink

Same as Simulink

No

18 Gain Same as Simulink

double Yes

19 Inport All Simulink types

If set to virtual: same as input type otherwise double

Only if non-virtual

20 Interpolation (n-D) using PreLook-Up

UInt32 or double double Yes UInt32 input holds index and fraction. The common variable for index and fraction is TargetLink-specific and not supported by Simulink

21 J-K Flip-Flop All Simulink types

double No

22 Logical Operator All Simulink types

double or boolean

No Boolean if model-specific setting BooleanDataType is set

23 Look-Up Table All Simulink types

double Yes




snnnnnnnnnnI

snnnnnnnnnnnnnnn

24 Look-Up Table (2D) All Simulink types

double Yes

25 Math double double Yes

26 Merge Same as Simulink

Same as Simulink

No

27 MinMax All Simulink types

double Yes

28 Multiport Switch All Simulink types

double Yes

29 Outport All Simulink types

If set to virtual: same as input type otherwise double

Only if non-virtual

30 PreLook-Up Index Search

All Simulink types

double or UInt32

Yes UInt32 output holds index and fraction. The common variable for index and fraction is TargetLink-specific and not supported by Simulink.

31 Preprocessor If Same as Simulink

Same as Simulink

No

32 Product All Simulink types

double Yes

33 Rate Limiter Same as Simulink

double Yes

34 Relational Operator

All Simulink types

double or boolean

No Boolean if model-specific setting BooleanDataType is set.

35 Relay Same as Simulink

double Yes

36 S-R Flip-Flop All Simulink types

double No

37 Saturation All Simulink types

double Yes




nnnnnnnnnnnnnt

14 nnnnnnnnnnnnnnnt

38 Sign All Simulink types

double No

39 Sink All Simulink types

- -

40 Sum All Simulink types

double Yes

41 Switch All Simulink types

double Yes

42 Trigonometric Function

All Simulink types

double Yes

43 Unit Delay All Simulink types

double Yes

44 Unit Delay Reset Enabled

All Simulink types

double Yes




snnnnnnnnnnI

snnnnnnnnnnnnnnn

Note that scaled fixed-point signal types are generally not supported

by TargetLink blocks.



nnnnnnnnnnnnnt

16 nnnnnnnnnnnnnnnt

TargetLink Stand-Alone Blockset

In TargetLink’s Stand-Alone Blockset, the blocks are basically just

masked Simulink blocks. Thus, their data type behavior generally

corresponds to Simulink. There are some details to note:

n The TargetLink data type (output.type property) has no impact on

the signal type during MIL simulations. The Cast output signal to

TargetLink type feature is not supported.

n Custom Code blocks behave identically in full-featured and stand-

alone mode (except that signal logging is generally not possible in

stand-alone mode).

n TargetLink Inport and Outport blocks are always virtual. Their input

signals are simply fed through the output.

• The signal data type behavior of Index Search and Pre Look-up

Interpolation blocks is the same in full-featured and stand-

alone mode, except that in stand-alone mode, the Cast output

signal to TargetLink type feature is not supported.

Thus, the signal data type behavior in TargetLink stand-alone

mode does not exactly correspond to the signal data type

behavior in full-featured mode. It also does not correspond to

Simulink’s behavior , either. This might result in invalid models

after the mode has been switched.

Documents

Simulink-targetlink Datatypes Defnt Problem