Difference between revisions of "LDRA Integration for Model References"

From T-VEC Wiki
Jump to: navigation, search
(Update Model Reference Names and Types)
(Update Model Reference Names and Types)
Line 31: Line 31:
 
[[Image:stoplight_sm_example.png|Model Reference Code Generation]]
 
[[Image:stoplight_sm_example.png|Model Reference Code Generation]]
  
The names extracted from the exported model information do not necessarily correspond with the different the code generation works. There is tool provided with the release called
+
The names extracted from the exported model information do not necessarily correspond to the names produced by the code generator. There is a tool provided with the release called
  
 
  get_rtw_types.bat --- Download it here [http://www.t-vec.com/download/get_rtw_types.bat get_rtw_types.bat]
 
  get_rtw_types.bat --- Download it here [http://www.t-vec.com/download/get_rtw_types.bat get_rtw_types.bat]
Line 112: Line 112:
 
In addition the corresponding variables rtu_0 and rtu_1 are replaced in their corresponding object mappings with the variables rtu_0_obj, and rtu_1_obj.
 
In addition the corresponding variables rtu_0 and rtu_1 are replaced in their corresponding object mappings with the variables rtu_0_obj, and rtu_1_obj.
  
Finally, the updated version of the program updates the following 5 variables to the other dependent object mappings files. These dependent files are defined in the user defined variable:
+
Finally, the updated version of the program updates the following 7 variables to the other dependent object mappings files. These dependent files are defined in the user defined variable:
  
 
  <dependencies> = '__triggerFallingB,signal_light__sf__a';
 
  <dependencies> = '__triggerFallingB,signal_light__sf__a';
Line 121: Line 121:
  
 
  <functionName>
 
  <functionName>
  <rtDWStruct>
+
  <isModelReference>
  <rtZCEStruct>
+
  <isReusable>
 
  <ldraExternalDeclarations>
 
  <ldraExternalDeclarations>
 
  <ldraParameterPointerInitialization>
 
  <ldraParameterPointerInitialization>
 +
<rtDWStruct>
 +
<rtZCEStruct>
  
 
If any of these variable do not exist, one is added just before the following line:
 
If any of these variable do not exist, one is added just before the following line:

Revision as of 10:22, 30 June 2008

Contents

LDRA Integration for Model References

The Simulink/Stateflow code generation process for model references is different from that of non-model reference code. The follow briefly describes how to use capabilities in T-VEC Tester for Simulink and Stateflow 4.1.0.

The typical processes include:

  • RTW Build
  • Export
  • Translate - update LDRA Schema Reference first
  • Load T-VEC VGS
  • Build T-VEC Project to generate test vectors
  • Update Model Reference Names and Types
  • Build Test Drivers
  • Copy Generated LDRA .tcf file to code directory
  • Execute LDRA
  • Load Code File
  • Invoke TBrun and Load New Test Sequence
  • Add necessary Pre/Post includes

LDRA Schema Reference

However, there is a special schema for LDRA:

C:\T-VEC\translators\sl2tvec\test_drivers\testbed_tcf_generic.sch

Place this in the Advance Translation Options, as shown in the following image.

Advanced Translation Options

Update Model Reference Names and Types

The typical location where code is generated for a model reference is reflected by the following figure.

Model Reference Code Generation

The names extracted from the exported model information do not necessarily correspond to the names produced by the code generator. There is a tool provided with the release called

get_rtw_types.bat --- Download it here get_rtw_types.bat

An easy way to use the program is to put it in the c:\t-vec\bin directory. This is usually defined as one of your path variables. Then use the VGS Toolbox under Tools | Toolbox and set up as shown below:

VGS Toolbox with get_rtw_types

Simply select the subsystem from the VGS Project window and then execute the get_rtw_types from the Tools menu. It will update the object mappings for the subsystem selected and for all its dependencies.

VGS Toolbox Execution of get_rtw_types

What the get_rtw_types program does

This is a perl program that takes two parameters:

  • Project Directory
  • Subsystem Name

It then updates the object mapping associated with that subsystem by looking through the .h file associated with the subsystem. The object mapping provides the name of the code in the user-defined variable called: <simulinkSubsystemName>. It updates two key user defined variable:

 <rtDWStruct> - defines the localDW variable relating to state data
 <rtZCEStruct> - defines the localZCE variable relating to triggers

It also performs further analysis of the code generated for model references. Normally when there are input scalar variables in a model, the code that is produced looks like the following:

extern void mr_stoplight_sm(boolean_T rtu_0, boolean_T rtu_1,
  boolean_T *rty_0, boolean_T *rty_1, boolean_T *rty_2, rtDW_mr_stoplight_sm
  *localDW, rtZCE_mr_stoplight_sm *localZCE);

The variable rtu_0 and rtu_1 are scalar inputs. These default situations are handle properly by the sl2tvec translator. However, for unknown reasons, the code is sometimes produced as follows:

extern void mr_stoplight_sm(const boolean_T *rtu_0, const boolean_T *rtu_1,
  boolean_T *rty_0, boolean_T *rty_1, boolean_T *rty_2, rtDW_mr_stoplight_sm
  *localDW, rtZCE_mr_stoplight_sm *localZCE);

In such situation there are changes required in the sections called:

  • <ldraExternalDeclarations>
  • <ldraParameterPointerInitialization>

The following changes are made by the get_rtw_types program - the following example shows that a global LDRA variable must be added to the <ldraExternalDeclarations>

<ldraExternalDeclarations> = '
<if(<isModelReference> != 0)>{    # Begin Global
 
     File = <codeDirectory>\<functionFilename>.cpp
     Name = rtu_0_obj
     Decl_type = boolean_T
 
   # End Global
  
   # Begin Global
 
     File = <codeDirectory>\<functionFilename>.cpp
     Name = rtu_1_obj
     Decl_type = boolean_T
 
   # End Global

Similarly, corresponding entries must be made to the parameter pointer initialization as shown below:

<ldraParameterPointerInitialization> = '
<if(<isModelReference> != 0)>{    # Begin Variable
 
     Name = rtu_0
     Decl_type = boolean_T*
     Usage = P
     Value = &rtu_0_obj
 
   # End Variable
  
   # Begin Variable
 
     Name = rtu_1
     Decl_type = boolean_T*
     Usage = P
     Value = &rtu_1_obj
  
   # End Variable

In addition the corresponding variables rtu_0 and rtu_1 are replaced in their corresponding object mappings with the variables rtu_0_obj, and rtu_1_obj.

Finally, the updated version of the program updates the following 7 variables to the other dependent object mappings files. These dependent files are defined in the user defined variable:

<dependencies> = '__triggerFallingB,signal_light__sf__a';

Note, for example, that signal_light__sf__a is a subsystem related to the user model, but __triggerFallingB is a utility subsystem generated by the translator. It will not have a .map file.

The updated version of the program replaces the values of the following variables if they exist with the value from the object mapping subsystem from which it was called.

<functionName>
<isModelReference>
<isReusable>
<ldraExternalDeclarations>
<ldraParameterPointerInitialization>
<rtDWStruct>
<rtZCEStruct>

If any of these variable do not exist, one is added just before the following line:

EMBED_PERL '<SCHEMA_HOME>\<embedFile>';

Build Test Drivers

The referenced schema produces a .tcf file in the test_drivers directory. If the particular subsystem is related to a state chart, then those dependent subsystems are include in the parent's .tcf file. This allows one file to be executed for verification of test coverage. The reference to a dependent subsystem is defined by the user-defined variable dependencies as shown in the following example.

<dependencies> = '__triggerRisingB,signal_light__sf__a';

Execute LDRA

The LDRA tool provides a significant number of features. This description provides the following minimal steps to execute the generated LDRA script .tcf file against the generated code.

Load Code File

In the LDRA Testbed tool use the menu

File | Select File

Select the auto-generated code file that is the target of the test.

Start TBrun and Load New Test Sequence

This is where the generated .tcf file is loaded into TBrun. If you copied the .tcf file to the code directory. Load that .tcf file as the test sequence. Otherwise load it from the test drivers directory where it was produced by VGS.

Execute the Run Drivers command or execute the commands separately:

  • Generate Driver
  • Build Driver

If successful

  • Execute Driver
  • Process Driver Output

Note: during the Generate Driver process, you might see the following LDRA Question - Answer None.

Pre/Post Includes might be necessary

It is not uncommon to need some pre includes or post includes. Make sure that the files included are the correct ones and that the sysearch.dat file and sysppvar.dat file have all the information required.

Typical pre includes might be a:

#define ldra_qq_bool_used

or

typedef bool boolean

Typical post includes are the constant definitions associated with state machines.