Difference between revisions of "LDRA Integration for Model References"

From T-VEC Wiki
Jump to: navigation, search
 
(Start TBrun and Load New Test Sequence)
 
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 does 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 39: Line 39:
 
[[Image:VGS_Toolbox.png|VGS Toolbox with get_rtw_types]]
 
[[Image:VGS_Toolbox.png|VGS Toolbox with get_rtw_types]]
  
Simply select the subsytem from the VGS Project window and then execute the get_rtw_types from the Tools menu. It will update the object mappings. Do this for each subsystem that needs to have the object mappings updated.
+
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.
  
 
[[Image:VGS_Toolbox_Execution.png|VGS Toolbox Execution of get_rtw_types]]
 
[[Image:VGS_Toolbox_Execution.png|VGS Toolbox Execution of get_rtw_types]]
Line 53: Line 53:
 
   <rtDWStruct> - defines the localDW variable relating to state data
 
   <rtDWStruct> - defines the localDW variable relating to state data
 
   <rtZCEStruct> - defines the localZCE variable relating to triggers
 
   <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===
 
===Build Test Drivers===
Line 63: Line 141:
  
 
====Load Code File====
 
====Load Code File====
The code is generated the auto generated code file that is the target of the test.
+
In the LDRA Testbed tool use the menu
  
[[Image:LDRA_Select_File.png‎|Select the file to be tested]]
+
File | Select File
  
====Start TBrun and Load New Test Sequence
+
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.
 
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.
  
Line 78: Line 158:
 
*Process Driver Output
 
*Process Driver Output
  
Note: during the Generate Driver process, you might see the following LDRA Question - Answer None:
+
Note: during the Generate Driver process, you might see the following LDRA Question
  
[[Image:Answer_None.png‎|Answer None to LDRA Question]]
+
Dataflow analysis has detected that output parameter "rty_0" is used in the unit
 +
tested by test case 1.
 +
 +
Adding this value to the test case will result in the test case not running until
 +
an expected value is provided
 +
 +
Not adding this variable will add it to the removed variables list from which it
 +
can be restored at a later date if required. The test case will then be executed as
 +
previously, but may fail to compile.
 +
 +
Do you wish to automatically add this variable to the test case?
 +
 
 +
Answer '''None'''.
  
 
====Pre/Post Includes might be necessary====
 
====Pre/Post Includes might be necessary====
  
It is not uncommon to need some pre includes or post includes. Typical pre includes might be a:
+
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
 
  #define ldra_qq_bool_used
  
or
+
or
  
 
  typedef bool boolean
 
  typedef bool boolean
  
 
Typical post includes are the constant definitions associated with state machines.
 
Typical post includes are the constant definitions associated with state machines.

Latest revision as of 10:35, 30 June 2008