Chapter 6 The Reactis Harness Editor
Reactis does not modify your C source files. Instead the tool stores
project-specific information that it requires in a Reactis Harness Library
(.rsh file). The primary way for users to view and edit the data in these
files is via the Reactis Harness Editor, as described in this chapter. The key components
of a harness are inputs, outputs, an initialization function,
and an entry function. To construct a test
for a harness, Reactis for C first calls the initialization function.
It then repeatedly performs the following steps:
-
Selects values for each harness input.
- Calls the entry function with the selected inputs.
- Records the generated outputs.
Each harness library contains one or more harnesses. As shown in
Figure 6.1, the harness selector in the toolbar of the
Reactis Harness Editor enables the user to select a harness from those defined in the currently
loaded .rsh file, to create a new harness, or to delete a harness. The
currently selected harness is displayed in parentheses beside the .rsh file
name in the title bars of the main window and harness editor.
Figure 6.1: The Reactis Harness Editor. |
The Reactis Harness Editor contains seven panes used to control different aspects of testing:
-
General.
-
Displays the initialization function,
entry function,
harness name, sample rate, and some additional
settings which control simulation.
The initialization function is called once per test,
and the entry function is called once per step during simulation and testing.
- Inputs.
-
A set of variables used as inputs.
A new value is generated for each input prior to taking
a step during simulation or test-generation. The user may constrain the
set of allowed values for each input.
- Outputs.
-
A set of variables used as outputs.
After each step the values of the outputs are recorded.
- Configuration Variables
-
A set of variables which may
change prior to the start of a test, but not during a test.
- Error Checking
-
Settings which specify the action to take when an anomalous condition,
such as a numeric overflow, occurs.
- Coverage Metrics
-
Settings that specify which coverage metrics will be tracked during simulation
and the details of each metric.
- Excluded Coverage Targets
-
A set of coverage targets which are excluded from coverage tracking.
Note that the contents of an .rsh file may only be modified when
Simulator is disabled. When Simulator is running, the
Reactis Harness Editor operates in read-only mode as indicated by the appearance
of [read only] in the editor window’s title bar.
Although not necessary, the default naming convention assumes that the
.rsm file and .rsh file of a project share the same base name; for
example, if the .rsm file file is named cruise.rsm, then the name
of the associated .rsh file is assumed to be cruise.rsh. A
.rsh file named differently may be associated with a program by loading
the build file in Reactis and selecting File -> Select Harness
Library....
6.1 Creating a new harness
To create a new harness, either select Edit -> New Harness... within the main
Reactis for C window or select the Create new harness... option in the harness
selector drop-down box. This will bring up the dialog shown in Figure 6.2.
Figure 6.2: The Create Harness dialog. |
The numbered items in Figure 6.2 let you specify a harness as follows:
- Harness name. Specify a name for the harness being created in
this entry box.
- Initialization function Each harness has an
initialization function – a function that
Reactis for C will call once per test, before the first step of the test is taken.
The initialization function can either be set to
None, or the name of a function can be entered into the text entry box.
- Entry function This text entry box lets you specify an entry
function, which
Reactis for C will call for every step in a test. To construct a test for a
harness, Reactis for C repeatedly:
-
Selects values for each harness input.
- Calls the entry function with the selected inputs.
- Records the generated outputs.
- ... Clicking this button opens a dialog that lets you select an
entry function from a list of candidate functions.
- ... Clicking this button opens a dialog that lets you select an
initialization function from a list of candidate functions.
Only functions
which have no arguments and do not return a value can to be used
as initialization functions.
- Create separate input/output for each structure member This menu
determines how structures in the test harness are handled and has two choices:
(1) split the structure into a separate input or output for each member of the
structure, or (2) create a single input or output for the entire structure.
- Create new harness. Creates a new harness with the minimum set of inputs and
outputs, as inferred from the entry function’s parameters and return value type:
-
Each pass-by-value argument to the entry function is added as an input.
- Each pass-by-reference argument to the entry function is added as an output
- If the entry function’s return value type is non-void then an output is added for
the return value.
- Copy existing harness. Copies inputs, outputs and configuration
variables from an existing harness in the current harness library. This
can be useful when defining harnesses for different entry functions that
share some of the inputs, outputs and configuration variables.
- When Copy existing harness is selected, this menu lets you
specify the harness to copy.
- Create harness from .rsi file Copy inputs, outputs, and
configuration variables from an .rsi file created with Reactis for
Simulink for a Simulink model. This option is useful if test cases
for the model have been created with Reactis for Simulink and C
code was automatically generated from the model. When a harness is
constructed with this option, tests generated from the model can be
directly run on the C code with Reactis for C.
- RSI file. If copying harness info from an .rsi file, enter the
.rsi file name in this text box.
- ... Open a file selection dialog to specify an .rsi file from
which to copy harness info.
- Variable Renaming The names of Simulink inports and outports
might not match exactly with the names of corresponding variables in the
C code. The Variable Renaming section of the dialog provides a
way to map the names to resolve any differences. Using the text boxes in
this section, you can specify common prefixes or suffixes for the
items in the .rsi file and/or the C code. For each
inport/outport/configuration variable in an .rsi file, the
following process is used to try to map it to an item in the
C code:
-
itemname1 = the name of the inport/outport/configuration variable
as found in the .rsi file.
- itemname2 = the result of removing the prefix specified in the
RSI File prefix column from the beginning of itemname1.
- itemname3 = the result of removing the suffix specified in the
RSI File suffix column from
the end of itemname2.
- itemname4 = the result of adding the prefix specified in the
C Code prefix column to the beginning of itemname3.
- itemname5 = the result of adding the suffix specified in the
C Code suffix column to the end of itemname4.
- In the C code, if a global variable or parameter of the entry
function is named itemname5 then it will be added as an
input/output/configuration to the harness. Its harness name will be
itemname1 and it will map to C code item itemname5.
If itemname5 does not match any global variable or entry function
parameter, then Reactis will produce a warning that a match could
not be found.
Figure 6.3 shows some mapping examples:
-
Example A
- Mapping inport/outport names with prefixes or suffixes to C variables:
-
Simulink inports named “SLin_name” will map to “name” in the C code.
- Simulink outports named “name_SLout” will map to “name” in the C code.
- Example B
- Mapping inport/outport names to C variables with prefixes or suffixes:
-
Simulink inports named “name” will map to “Cin_name” in the C code.
- Simulink outports named “name” will map to “name_Cout” in the C code.
- Example C
- Mapping with prefixes or suffixes in both inport names and
C variables: Simulink inports named “SLPrefix_name_SLSuffix” will
map to “CPrefix_name_CSuffix” in the C code.
- Automatically match embedded coder functions/variables. If the
C code was produced using MATLAB Embedded Coder, checking this box will
automatically apply renaming rules which match model names to code names.
- Help. Clicking this button opens the help dialog.
- Ok. Clicking this button causes the harness creation to proceed.
- Cancel. Clicking this button closes the dialog without creating a
harness.
Figure 6.3: Examples for different mapping configurations |
6.2 General
Figure 6.4: The General pane of the Reactis Harness Editor |
The General tab of the harness editor is shown in Figure 6.4.
The settings controlled by this tab are labeled 1 through 5 in Figure 6.4.
-
cruise_main. This pull-down menu is used to select the current harness,
create a new harness, or delete the current harness. The displayed value is the
name of the current harness.
- Initialization Function. The initialization function is called at
the start of each test.
- Sample rate. The sample rate is the number of seconds to add to the time
(__t__)
at the end of each step. When performing back-to-back testing, the test harness
sample rate will typically match the sample rate of the model.
- Create and use cache files for C code.
When checked, Reactis will generate a Reactis object file
for each C source file. These files have extension .rso and are stored in
the directory containing the C source file from which they were compiled.
Subsequently, the C source file will only be recompiled if it is modified
or if a new version of Reactis is installed.
- Promote ’float’ values to ’double’ to reduce round-off error.
When checked, single-precision floating-point values will always be converted to
double-precision prior to any calculation, which reduces round-off error in some
cases. For strict C99 compliance, this should be disabled (not checked).
- Set Test Execution Report defaults. This button opens a dialog which
controls the default settings for test execution reports.
6.3 Inputs
The Inputs tab (see Figure 6.5)of the harness editor
enables you to define a set of inputs.
Inputs are either parameters to the entry function
or global variables which are designated as inputs by selecting Edit -> Add... and then
choosing from the candidate list.
Parameters which are passed by reference can also be designed as inputs via the
the same mechanism.
Figure 6.5: The Inputs tab of the harness editor defines
the set of inputs and limits on the values that
the inputs can assume during simulation and test generation. |
The Inputs tab contains six columns for each input value.
These are numbered 1 through 6 in Figure 6.5.
The purpose of each column is as follows:
-
1. #
- The number of the input (1 … N).
- 2. Name
- The name of an input is usually, but not always, the same
as the name of the variable which holds the input value. See Section 6.7
for details.
- 3. Variable
- The name of the variable which holds the input value.
- 4. File
- The name of source file in which the variable which holds the
input value is defined.
- 5. Properties
- A code which describes how the input is passed through
the harness and stored in the program under test.
See Section 6.8 for details.
- 6. Type
-
This field specifies the set of values that can be assigned to the input.
See Section 6.9 for details.
6.4 Outputs
The Outputs tab of the harness editor enables the user to add and
remove items to the set of outputs. A value is recorded for each output at
the end of each simulation step as tests are constructed. By default all
pass-by-reference parameters of the entry function are considered outputs,
but they may be removed from the list and global variables may be added.
When the Outputs tab is displayed, entries from the
Edit menu may be used to add or remove items to/from the list.
Figure 6.6: The Outputs pane of the harness editor. |
The Outputs tab contains six columns for each input value.
These are numbered 1 through 9 in Figure 6.6.
The purpose of each column is as follows:
-
1. #
- The number of the output (1 … N).
- 2. Name
- The name of an output is usually, but not always, the same
as the name of the variable which holds the output value.
See Section 6.7 for details.
- 3. Variable
-
The name of the variable which holds the output value.
- 4. File
-
The name of source file in which the variable which holds the
output value is defined.
- 5. Properties
-
A code which describes how the output is
stored in the program under test
and
passed through
the harness.
See Section 6.8 for details.
- 6. Type
-
The type of the output. Double clicking opens a type editor dialog from which
the type can be changed.
- 7. Tolerance
- The tolerance method to use when comparing
an actual output value with the value in a test suite (see Section 6.4.1).
- 8. Relative
- The relative tolerance value. If the method does
not use relative tolerance, this will be blank.
- 9. Absolute
- The absolute tolerance value. If the method does
not use absolute tolerance, this will be blank.
6.4.1 Tolerance Methods
There are five methods
for computing the tolerance:
Absolute, Relative, Max, and Min,
and Inherit.
The absolute tolerance
method flags a difference between a computed
value and a test value if the absolute value of the difference
exceeds a given amount.
More precisely, given two values x and y and an absolute tolerance є,
the difference between x and y is flagged if and only if |x−y| > є.
The relative tolerance
method flags a difference between a computed value
and a test value if it exceeds an amount determined by multiplying
the tolerance by either the computed or test value.
More precisely, given two values x and y and a relative tolerance є,
the difference between x and y is flagged if and only if any of the
following conditions are true:
• |x−y| > є × | x | | when | x ≠ 0 |
• |x−y| > є × | y | | when | y ≠ 0 |
• |x−y| > є2 | when | x = 0 or y = 0
|
A relative or absolute tolerance of zero will require that the model and test
values always be the same, a relative tolerance of 0.1 will allow a difference
of 10%, and a relative tolerance of 1 will allow the model value to be
at most twice the test value.
The max tolerance method
uses both a relative and absolute tolerance.
A difference is flagged only if it is flagged by both the absolute and relative
tolerance methods.
The min tolerance method
uses both a relative and absolute tolerance.
A difference is flagged
if it is flagged by either the absolute or relative tolerance method.
If the tolerance method is set to Inherit, then
the tolerance method is inherited from the model’s global tolerance
setting (set in the Error Checking pane of the Reactis Harness Editor).
6.5 The Tolerance Editor Dialog
Figure 6.7: The dialog for specifying the tolerance to use
when comparing computed and test suite values. As shown, an absolute tolerance
of 0.1 is specified for port speed, which means that differences which
are less than or equal to 0.1 will be ignored. |
Tolerances are specified via the tolerance editor dialog, which is shown in
Figure 6.7. The labeled items in Figure 6.7
are explained as follows:
-
This pull-down menu lets you choose the tolerance method. The possible choices
are Inherit, Relative, Absolute, Min, or
Max. These are explained in Section 6.4.1.
- This data entry box contains the relative tolerance value used by the
selected method, which must be non-negative.
If the method does not use relative tolerance, it will be
disabled.
- This data entry box contains the absolute tolerance value used by the
selected method, which must be non-negative.
If the method does not use absolute tolerance, it will be
disabled.
- This button opens the help dialog for the tolerance editor dialog.
- This button accepts the displayed tolerance value and closes the tolerance
editor dialog.
- This button ignores any changes made to the tolerance and closes the tolerance editor
dialog.
6.6 Configuration Variables
Configuration variable directives allow certain
scalar global variables to be treated as “configuration
variables” whose values can only change between tests (but
not during a test).
A configuration variable is created by clicking on Edit -> Configuration Variables...
in the main Reactis window, then selecting Edit -> Add...
in the menu bar of the Reactis Harness Editor window that comes up. Reactis will
display a list of all candidate configuration variables which users may select
from. The types associated with these configuration variables in .rsh files are
the same as those that may be assigned to inputs.
Note, however, that configuration variables may not be given delta types, since
the variables are not allowed to change during a test or simulation run.
Figure 6.8: The Configuration Variables tab of the harness editor. |
As shown in 6.8, the Configuration Variables
tab has five columns, whose meaning is as follows:
-
1. #
- The number of the configuration variables (1 … N).
- 2. Name
- A user-defined name which is usually, but not necessarily then
as the name of variable.
See Section 6.7 for details.
- 3. Variable
-
The name of the configuration variable in the source code.
- 4. File
-
The name of source file in which the configuration variable is defined.
- 5. Type
-
This field specifies the set of values that can be assigned to the configuration variable.
See Section 6.9 for details.
6.7 Names
The Inputs, Outputs and Configuration Variables tabs
of the Reactis Harness Editor have columns titled Name and Variable.
Both of these columns contain names. The name displayed in the Variable field
is the actual name of the variable in the source code. This name cannot be changed and
does not have to be unique.
The name displayed in the Name field, on the other hand, can be changed and
must be unique.
6.8 Properties
The Inputs and Outputs tabs
of the Reactis Harness Editor have a column labeled Properties,
which contains a code describing how
each input and output is passed through the harness
and stored in the program under test.
There are four property codes, P, P*, R and
G, whose meaning is given by the following table:
Code | Meaning |
P | Pass-by-value parameter to entry function. |
P* | Pass-by-reference parameter to entry function. |
R | Return value of entry function. |
G | Global variable. |
6.9 Types
The Inputs, Outputs and Configuration Variables tabs
of the Reactis Harness Editor have a column labeled Types.
The Types column contains
type specifications.
For inputs and configuration variables, the type specification
determines what values may be assigned to the variable
during simulation, test generation and validation.
The initial type specification for each variable is the equivalent of its C type.
This indicates that the full range of values which the variable can hold
should be generated during testing.
In many cases, the set of desired input values is actually smaller than the full range
of the C type. For example, an input may have a type of char
, but may
actually be used as a Boolean value whose allowed values are 0 or 1.
If this is the case, then editing the type specification will significantly improve coverage
results during testing.
Note that for outputs, the type specification for an input is permanently
fixed to the equivalent to its C type.
Type specifications can be changed from the Inputs and
Configuration Variables tabs of the harness editor.
A type specification starts with a base type, which is selected from
the list:
int8, int16, int32,
uint8, uint16, uint32,
double, single.
A base type can then be extended by notation to specify (1) ranges
and subsets within a base type, (2) rate-of-change (or delta) constraints,
(3) resolution constraints and (4) array types. The full set of type specifications
is defined by the following grammar (in which rsiType is the starting symbol).
intType | : | int8, int16, int32, uint8, uint16, uint32 |
floatType | : | double, single |
fixedPointType | : | sfix bitsSlopeBias |
| | | ufix bitsSlopeBias |
numberType | : | intType |
| | | floatType |
| | | fixedPointType |
baseType | : | numberType |
| | | boolean |
rsiType | : | baseType |
| | | baseType { val1, val2, ... , valn } |
| | | numberType [ min, max ] |
| | | numberType delta [ min, max ] |
| | | numberType [ min, max ]
delta [ min, max ] |
| | | floatType [ min : step : max ] |
| | | floatType [ min : step : max ]
delta [ min, max ] |
| | | <| rsiType1 * rsiType2 *
... * rsiTypen |> |
| | | vectorType |
| | | structType |
vectorType | : | <| rsiType1 * rsiType2 *
... * rsiTypen |> |
structType | : | { fieldName1 : rsiType1
, ... , fieldNamem : rsiTypem } |
| | | structName -> { fieldName1 : rsiType1
, ... , fieldNamem : rsiTypem } |
val | : | value |
| | | value : weight |
The variables in this grammar are defined as follows. min, max, step, and
value are elements of the given base type, weight is an integer
greater than zero and less than one thousand.
For a vector type <|
rsiType1 *
rsiType2 *
... *
rsiTypen |>
, the base types of all
rsiTypei must be identical. For a structure type, the base types
of the different field types rsiTypei may be different.
Fixed point types are strings that specify a set of parameters for
the generalized slope-bias encoding scheme for representing real
numbers using integers. These strings consist of a prefix of either
sfix
(signed) or ufix
(unsigned) followed by a suffix of
the form bitsSlopeBias. The suffix is further divided into one
required substring bits and two optional substrings
slope and bias. These three substrings are defined as
described below. Note that fpDecimal is a string that encodes a
decimal value by replacing a negative sign “-” with “n” and the
decimal point “.” with “p”. For example, “-4.9” is represented
as “n4p9” and “2.3” as “2p3”. Similarly fpInt is a string
that encodes an integer value by replacing a negative sign “-” with
“n”.
- bits
- is a positive integer indicating the number of bits
to be used to represent values of the type.
- slope
- is a decimal specified in one of two ways
-
as
_S
fpDecimal such that slope = fpDecimal
- as
_F
fpDecimal_E
fpInt
such that slope = fpDecimal×2fpInt
- bias
- is a decimal specified as
_B
fpDecimal.
If the slope substring is omitted a default value of 1 is used.
If the bias substring is omitted a default value of 0 is used.
The following examples show some legal types and the sets of values
they specify.
RSI Type | Values in Type |
double [0.0,4.0] | All double-precision floating-point
numbers x ,
where 0.0 <= x <= 4.0 |
double [-10.0:0.25:10.0] | -10.0, -9.75, -9.5, ..., 9.5, 9.75, 10.0 |
int16 [-1,1] | -1, 0, 1 |
int32 {0, 4, 7} | 0, 4, 7 |
uint8 {0:1, 1:3} | 0, 1 |
<| double { 1.0,2.0,3.0 } * double {10.0} |> | <| 1.0, 10.0 |>, <| 2.0, 10.0 |>, <| 3.0, 10.0 |> |
double delta [-1.0,1.0] | All double-precision floating-point
numbers, but input values of this type can
increase
or decrease by at most 1.0 during successive
simulation
steps. |
<| double { 1.0,2.0,3.0 } * double {10.0} |> | <| 1.0, 10.0 |>, <| 2.0, 10.0 |>, <| 3.0, 10.0 |> |
{ x : uint8 { 1, 2 }, y : unit8 { 3, 4} } | { x = 1, y = 3 } , { x = 1, y = 4 }
{ x = 2, y = 3 } , { x = 2, y = 4 } |
In range types (i.e. those of form t[l,u]) the lower and upper
bounds are inclusive. In enumeration types (i.e. those of form
t{u1, …, un}) the probability weights in the ui enable
the user to influence the probabilities of the different values in the
type being selected during simulation, test generation, and C code
validation.
For example, an input having type uint8 {0:1, 1:3}
would be
assigned the value 0 in 25% of random simulation steps and the value
1 in 75% of random simulation steps, on average. In general, if
input x is assigned the type t{ v1:w1, v2:w2, ...,
vn:wn}, then the probability of each value in the type being
assigned to x is computed as follows. Let W = w1 + w2 + ... +
wn, where wi denotes the probability weight assigned to vi (a
weight of 1 is assumed if no explicit weight is given). During
“random” simulation or test generation, the probability of an input
x being assigned the value vi is wi/W.
Using delta types (i.e. those of form t
delta
[l,u]) users may constrain how the values fed into
inputs change from one simulation step to the next. For example, an
input representing a sensor measuring temperature might have the type
double delta [-1.0,1.0]
to specify that temperature can either
increase or decrease by at most 1 degree between any consecutive
simulation steps. In general, if input x has type t delta
[l,u] and the current value of x is v1 then in the next
simulation step the new value, v2, of x must satisfy:
v1 + l <=
v2 <=
v1 + u
.
Using resolution types (i.e. those of form
double
[i:j:k] where i
is a lower bound, j is a resolution, and k is an upper
bound) users may specify that each value that a variable of this type
may assume will differ from i by some multiple of j. A delta
constraint may also be added to a resolution type.
6.10 The Type Editor Dialog
The Type Editor Dialog, shown in Figure 6.9, helps
users construct types for inputs and configuration
variables. In the following discussion, we use TUC to denote the
type under construction, i.e. the type currently being defined
with the dialog.
Figure 6.9: The dialog for specifying type information for inputs or
configuration variables. As shown here a type of double is specified for input x which will be converted to fixed-point
before being stored in the memory of the program under test.
Furthermore, the input values for x have been constrained to the set
{ −10000000.0, 0.0, 10000000.0 }. During random
simulation, x will be assigned one of these three values with equal
probability. |
The Type Editor may be invoked from either the Inputs
or Configuration Variables tabs and selecting an input or configuration
variable row with a single click, and then right-clicking in the body of the Reactis Harness Editor
and selecting Edit Type, or selecting menu item Edit -> Edit....
6.10.1 Using the Type Editor
A type may be constructed with the dialog by performing the following
steps. Recall that TUC denotes type
under construction, i.e. the type currently being defined with the
dialog. The process for editing a type works as follows:
-
Do you wish to use a type in the test harness which
is different from the type in the C source code?
-
No.
- Leave the harness base type unchanged (it will initially match the
internal base type) and proceed to step 2.
- Yes.
- Use the pull-down menu (item 1 in Figure 6.9)
to select the desired type and proceed to step 2.
- Should the values chosen during simulation
include all values in the base type, only a subrange of the base type,
or only a set of specific values in the base type?
-
All values in base type.
- Select the Complete range of
base type radio button (item 3 in Figure 6.9) and proceed
to step 3.
- Only a subrange of the base type.
- Select the
Subrange of base type radio button (item 4 in Figure 6.9)
and specify a lower and upper bound for the range using window
items 5 and 6 respectively. If the input
has a base type of
double
or single
, then you may specify a
resolution for
the values in the TUC. To do so click the Resolution
check box (item 7 in Figure 6.9) and enter a resolution value in the
text box to the right (item 8 in Figure 6.9). When a resolution is
specified, a variable of the TUC will only
assume values that differ from the lower bound (item 5 in Figure 6.9)
by some multiple of the resolution value (item 8 in Figure 6.9).
Proceed to step 3.
- A specific set of values in the base type.
-
Select the Set of specific values radio button (item 9 in Figure 6.9)
and use the Add, Edit, and Remove buttons
(items 12, 13, and 14 in
Figure 6.9) to create a list of
values. Each value must be an element of the base type of the TUC and
may be assigned a probability weight. See Section 6.3
for a description of probability weights.
Proceed to step 3.
- Do you wish to constrain how the values
fed into the the input parameter may change from one step to the next during simulation?
-
No.
- Select the Complete radio button (item 16 in Figure 6.9) and proceed
to step 4.
- Yes.
- Select the Limits radio button (item 17 in Figure 6.9) and
enter values in the Minimum and Maximum
text entry boxes (items 18 and 19 in Figure 6.9).
If min and max are the values specified here,
then values fed into the entry function parameter with the TUC
will be constrained as follows. If v1
and v2 are values for such a port in consecutive
simulation steps, then
v1 + min
<=
v2 <=
v1 + max
.
Proceed to step 4.
- Does the C code expect a fixed-point value as input?
-
No.
- Leave the internal type unchanged and proceed
to step 5.
- Yes.
- Select Fixpoint from the internal base type pull-down menu
(item 21 in Figure 6.9), then select a scaling mode (item 22 in Figure 6.9),
and finally the scaling parameters (item 25 in Figure 6.9)
Proceed to step 5.
- Does the conversion from the harness type to the
internal type require rounding or can it overflow?
-
No.
- Proceed to step 6.
- Yes.
- Select a rounding mode (item 26 in Figure 6.9)
and/or overflow behavior (item 27 in Figure 6.9).
Proceed to step 6.
- When you are satisfied with the type you have
constructed click the Ok button to update type and dismiss
the Type Editor dialog.
- Select File -> Save to save your changes to the .rsh file.
6.10.2 Labeled Window Items
This section describes the labeled items in
Figure 6.9. Recall that TUC denotes type
under construction, i.e. the type currently being defined with the
dialog.
-
This pull-down menu changes the base type of the harness
variable.
- The radio buttons in this group (window items 3,
4, and 9)
enable the user to specify the values from the base type to be
include in the TUC.
- Selecting this radio button indicates
that all values from the base type should be included in the TUC.
- Selecting this radio button indicates that only a subrange
of values from the base type should be included in the TUC.
- When the Subrange of base type
radio button is selected, this entry box enables the user to specify a
lower bound for the subrange.
- When the Subrange of base type
radio button is selected, this entry box enables the user to specify
an upper bound for the subrange.
- If the Subrange of base
type radio button is selected for a base type of
double
or single
,
then this check box may be checked in order to specify a
resolution for the TUC. - When the Resolution check box
(window item 7) is checked, a resolution value must be entered in this
text box. When a resolution is specified, a variable of the TUC
will only assume values that differ from the lower bound specified in
window item 5 by some multiple of the resolution value here.
- Selecting this radio button indicates that only
a specified set of values from the base type should be included in the
TUC. Window items 10-14 are used to specify the set of values.
- The entries in this column enumerate the values in the TUC.
- The entries in this column associate a probability weight with
each value in the TUC. See Section 6.3 for a
description of probability weights.
- Add a new value (a new entry in each of window
items 10 and 11) to the TUC.
- Edit the probability weight for the currently
selected value.
- Remove the currently selected value.
- The radio buttons in this group (window items 16 and 17) enable
the user to specify whether or not the type has a delta
constraint. For a parameter with the TUC, such a constraint
limits the allowable changes in value from one simulation step
to the next.
- The TUC has no delta constraint.
- The TUC has the delta constraint indicated by window items
18 and 19.
- The value for a parameter with the TUC may
change by no less than the value specified here. If v1 and v2
are the values of the parameter in consecutive simulation steps then
v2 − v1
>=
min . - The value for a parameter with the TUC may
change by no more than the value specified here. v2 − v1
<=
max . - The items in this panel (labeled 21-27 in Figure 6.9)
- . This pull-down menu changes the internal type from
a fixed-point type. It can only be used when the type in the source code is an
integer type.
- . This pull-down menu determines the scaling used when the
internal base type is a fixed-point type. Available choices are
Binary Point or Slope and Bias.
- The signedness of the fixed-point type is displayed here.
It matches the signedness of the underlying integer type and cannot be
changed.
- The width (in bits) of the fixed-point type is displayed here.
It matches the width of the underlying integer type and cannot be
changed.
- When binary point scaling is selected,
the fraction width (in bits) of the fixed-point type is entered here.
If slope and bias scaling is chosen, the fraction width will be replaced
with entries for the slope and bias.
- This pull-down menu determines the rounding mode to use
when converting values from the harness type to the internal type.
Possible choices are Zero,
Ceiling, Floor, or Nearest.
- This pull-down menu determines the overflow mode to use
when converting values from the harness type to the internal type.
Possible choices are Saturate or Wrap over.
- View help on the type editor dialog.
- Update the TUC and dismiss the dialog. The revised TUC
will appear in the appropriate row of the Reactis Harness Editor and
“[modified]” will appear in the title bar. Selecting
File -> Save will write the .rsh file to disk and cause the
“[modified]” tag in the title bar to disappear.
- Discard any changes to the TUC and dismiss the dialog.
- Update the TUC without dismissing the dialog.
6.11 Error Checking
Figure 6.10: The Error Checking pane of the Reactis Harness Editor. |
The Error Checking pane of the Reactis Harness Editor, shown in Figure 6.10,
lets you specify what action to take when
anomalous conditions occur during program execution. The settings controlled
via this pane are numbered 1-12 in Figure 6.10:
-
The action to take when a type delta exceeds the range of the type.
Possible actions are Clip Delta,
Clip delta and produce warning, or Produce error.
- The default tolerance to use when comparing floating-point test suite outputs to program
outputs.
- The default tolerance to use when comparing fixed-point test suite outputs to program
outputs.
- The action to take when a signed integer overflow occurs.
Possible values are Wrap over, Produce warning,
or Produce error.
- The action to take when an unsigned integer overflow occurs.
Possible values are Wrap over, Produce warning,
or Produce error.
- The action to take when an overflow occurs while converting an unsigned
integer value to signed integer.
Possible values are Wrap over, Produce warning,
Produce error, or Inherit from "On signed integer overflow".
- The action to take when an overflow occurs while converting an floating
point value to (signed or unsigned) integer.
Possible values are Wrap over, Produce warning,
Produce error, or Inherit from "On signed integer overflow".
- The action to take when a NaN (not-a-number) or infinite value is detected.
Possible values are No action, Produce warning,
Produce error.
- The action to take when a subnormal floating-point value is detected.
Possible values are No action, Produce warning, or
Produce error.
- The action to take when an invalid pointer is detected. Possible values
are No action, Produce warning, or Produce error.
- The action to take when an empty structure or union type is defined. Possible values
are No action, Produce warning, or Produce error.
- The action to take when an undefined is called. Possible values
are Return zero, or Produce error.
- The action to take when an extern variable is never defined.
Possible values are Initialize to zero,
Produce warning and initialize to zero,
or Produce error.
- The simulation time limit (in seconds) for a simulation step to finish.
A value of 0 makes the step time unlimited.
6.12 Coverage Metrics
Figure 6.11: The Coverage Metrics pane of the Reactis Harness Editor. |
The Coverage Metrics pane of the Reactis Harness Editor is used to specify which metrics should
be tracked and how they should be tracked. An annotated screenshot of the
Coverage Metrics pane appears in Figure 6.11.
The following items are labeled Figure 6.11:
-
This setting enables or disables the C Statement metric.
See section 7.1 for details.
- This setting enabled or disabled the C Function metric.
See section 7.2 for details.
- This setting enabled or disabled the C Function Call metric.
See Section 7.3 for details.
- This setting controls which expressions are considered to be decisions.
Possible values are
Expressions which control if/while/for statements,
Expressions which control if/while/for statements or the ? operator, or
All non-trivial Boolean expressions.
See Section 7.4 for details on the effect of this setting.
- This setting enables or disables the Decision metric.
See Section 7.4 for details.
- This setting enables or disables the Condition metric.
See Section 7.5 for details.
- This setting enables or disables the Modified Condition/Decision Coverage (MC/DC) metric.
See Section 7.6 for details.
- This setting enables or disables the Multiple Condition Coverage (MCC) metric.
See Section 7.7 for details.
- This setting controls the maximum number of conditions per decision for
which MCC targets will be created. No MCC targets will be created for
decisions which are composed from more conditions than the given limit.
Note that 2N MCC targets are created for a decision composed from N
conditions, so use caution when changing this setting.
See Section 7.7 for details on the MCC metric.
- This setting enables or disables the Boundary Value metric.
See Section 7.8 for details.
- This setting enables or disables the User-Defined Target metric.
See Section 10.1.2 for details.
- This setting enables or disables the Assertion metric.
See Section 10.1.1 for details.
- This specifies if assertion targets should be created for each assert
statement in a program.
6.13 Excluded Coverage Targets
Figure 6.12: The Excluded Coverage Targets pane of the Reactis Harness Editor. |
The Excluded Coverage Targets pane is shown in Figure 6.12.
Each row of this pane contains one target excluded from coverage. There are
five data items per target:
-
Metric. The metric measured by the target.
- Item. A description of the target (a location and source code
fragment).
- Target. A description of the action which causes the target
to be covered. For example, if a target’s metric is Condition, then
the target will be either Condition true or Condition false.
- Status. The target status, which is either excluded,
or excluded with assertion.
- System. The source file and (possibly) library where the target is located.