Main Content


Represent a model as a code generation verification object that has methods to configure and execute a model in a variety of simulation modes to automate verification of numerical equivalence of executing the generated code


A code generation verification (cgv) object executes a model in different environments such as, simulation, Software-In-the-Loop (SIL), or Processor-In-the-Loop (PIL) and stores numerical results. Using the cgv.CGV class methods, you can create a script to verify that the model and the generated code produce numerically equivalent results.

cgv.CGV and cgv.Config use two of the same properties. Before executing a cgv.CGV object, use cgv.Config to verify the model configured for the mode of execution that you specify. If the top model is set to normal simulation mode, referenced models set to PIL mode are changed to Accelerator mode.


cgvObj = cgv.CGV(model_name) creates a handle to a code generation verification object using the default parameter values. model_name is the name of the model that you are verifying.

cgvObj = cgv.CGV(model_name,Name,Value) constructs the object using the parameter values, specified as Name,Value pair arguments. Parameter names and values are not case sensitive.

The cgv.CGV function accepts these arguments:


Name of the model that you are verifying.

Name-Value Pair Arguments

Optional comma-separated pairs of Name,Value arguments, where Name is the argument name and Value is the corresponding value. Name must appear inside single quotes (''). You can specify several name-value pair arguments in a variety of orders, such as Name1,Value1,…,NameN,ValueN.

  • 'ComponentType' — Define the SIL or PIL approach

    If topmodel (default), top-model SIL or PIL simulation mode and standalone code interface.

    If modelblock, model block SIL or PIL simulation mode and model reference code interface mode.

    If mode of execution is simulation (Connectivity is sim), choosing either value for ComponentType does not alter simulation results.

  • Connectivity — Specify mode of execution

    If sim or normal (default), mode of execution is Normal simulation.

    If sil, mode of execution is SIL.

    If pil, mode of execution is PIL.

Example: Test Model for Numerical Equivalence


expand all

Specify a description of the object.

Specify a name for the object.

Object Functions

activateConfigSetActivate configuration set of model
addBaselineAdd baseline file for comparison
addConfigSetAdd configuration set
addHeaderReportFcnAdd callback function to execute before executing input data in object
addInputDataAdd input data
addPostExecFcnAdd callback function to execute after each input data file is executes
addPostExecReportFcnAdd callback function to execute after each input data file executes
addPostLoadFilesAdd files required by model
addPreExecFcnAdd callback function to execute before each input data file executes
addPreExecReportFcnAdd callback function to execute before each input data file executes
addTrailerReportFcnAdd callback function to execute after the input data executes
compareCompare signal data
copySetupCreate copy of cgv.CGV object
createToleranceFileCreate file correlating tolerance information with signal names
getOutputDataGet output data
getSavedSignalsDisplay list of signal names to command line
getStatusReturn execution status
plotCreate plot for signal or multiple signals
runExecute CGV object
setModeSpecify mode of execution
setOutputDirSpecify folder
setOutputFileSpecify output data file name


collapse all

The general workflow for testing a model for numerical equivalence using the cgv.CGV class is to:

Create a cgv.CGV object, cgvObj, for each mode of execution and use the cgv.CGV set up methods to configure the model for each execution. The set up methods are:

  • addInputData

  • addPostLoadFiles

  • setOutputDir

  • setOutputFile

  • addCallBack

  • addConfigSet

Run the model for each mode of execution using the method.

Use the cgv.CGV access methods to get and evaluate the data. The access methods are:

  • getOutputData

  • getSavedSignals

  • plot

  • compare

An object should be run only once. After the object is run, the set up methods are not used for that object. You then use the access methods for verifying the numerical equivalence of the results.


Simulink® Test™ is a separate product that provides additional capabilities for SIL and PIL testing, for example, test sequence construction and test management.

Version History

Introduced in R2009b