Generated Model and Validation Model
HDL Coder™ enables you to view the effect of HDL optimizations and block settings in your generated model.
Before generating code, HDL Coder creates a behavioral model of the HDL code called the generated model. The generated model is a model created during HDL code generation that captures cycle-accurate and bit-true behavior of the generated code in area and timing optimizations during code generation. It shows latency and numeric differences between your Simulink® design under test (DUT) and the generated HDL code. Delays that HDL Coder inserts are highlighted in the generated model in various colors. Different delays in code generation, the corresponding highlight color, and how the delays are named in the generated model are listed in this table.
|Delays||Highlight Color||Naming Convention|
The block is highlighted in cyan. Delay
blocks inside this block use the default name
|Green||Constrained output pipelining:
With timing and area optimizations, the generated model is substantially different from the original model. For example, there are additional integer delays next to blocks if you request optimizations and additional balanced delays to maintain the accuracy of the algorithm. If you request resource sharing or streaming optimization where the same operator is time multiplexed across multiple operations, there are additional rates in your model. When the original model does not have any optimizations, the generated model is the same as the original model. The generated model simulates the generated HDL code. The generated model is useful for visualizing changes in latency, rates, and dataflow from the original model.
While the original model and generated model have the same simulation settings,
these models are not required to have the same code generation settings. For
example, if you set ResetType to
none for a
delay block in your model, this setting might not appear in the
generated model equivalent delay block because it does not
affect simulation. To see the delay
block with ResetType set to
mapped to the generated HDL code, see Navigate Between Simulink Model and HDL Code by Using Traceability.
The generated model is used in Register Transfer Level (RTL) test bench generation. The input stimulus and output response are captured from the generated model instead of the original model because the generated model reflects the algorithm timing changes required for optimizations. If you disable model generation, you cannot generate a test bench in HDL Coder.
After code generation, the generated model is saved in the target folder. By
default, the generated model prefix is
gm_. For example, if your
model name is
myModel, your generated model name is
Customize the Generated Model
To customize the prefix of the generated model name, use the
GeneratedModelNamePrefix property with the functions
hdlset_param. See Prefix for generated model name.
You can also specify various options for the naming and layout of the generated model. See Naming and Layout Options for Model Generation.
Because the generated model is often substantially different from the original model, the coder can also create a validation model to compare the original model to the generated model. The validation model inserts delays at the outputs of the original model to compensate for latency differences and compares the outputs of the two models. When you simulate the validation model, numeric differences in the output data trigger an assertion.
Using the validation model, you can verify that the output of the optimized DUT is bit-true to the results produced by the original DUT.
A validation model contains:
A generated model.
An original model that has compensating delays inserted.
Original inputs, routed to the original model and the generated model.
Scopes for comparing and viewing the outputs of the original model and generated model.
Some block architectures and optimizations introduce latency. For example, for the Reciprocal block, you can specify HDL block architectures that implement the Newton-Raphson method. The Newton-Raphson method is iterative, so block architectures that use it are multicycle and introduce latency at the block rate.
Similarly, the resource sharing area optimization time-multiplexes data over a shared hardware resource, which introduces local multirate and latency at the upsampled rate.
HDL block architectures can introduce numeric differences between the original and generated model. For example:
An HDL block property, such as InputPipeline specified on the block, or certain HDL architectures or optimizations, such as distributed pipelining, that move delays to the input of the block.
The Newton-Raphson method is an approximation. If you select a Newton-Raphson block implementation, the generated model shows a change in numerics.
HDL implementations for signal processing blocks, such as filters, can change numerics.
See also Locate Numeric Differences After Speed Optimization.
Generate a Validation Model
In the Configuration Parameters dialog box, in the HDL Code Generation > Global Settings > Model Generation pane, select Validation Model.
In the HDL Workflow Advisor, in the HDL Code Generation > Generate RTL Code and Testbench pane, enable Generate validation model.
GenerateValidationModelproperty with the functions
Customize the Validation Model
To customize the suffix of the generated validation name, use the
ValidationModelNameSuffix property with the functions
hdlset_param. See Suffix for validation model name.
To generate a validation model, you must generate HDL code for the DUT Subsystem. Model generation is not supported for generating code for the entire model instead of the DUT Subsystem.
Make sure that the DUT subsystem has no unconnected output ports. See Terminate Unconnected Block Outputs and Usage of Commenting Blocks.