Generated Model and Validation Model

HDL Coder™ enables you to view the effect of HDL optimizations and block settings in your generated model.

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
Block implementation RAM mapping	Cyan	The block is highlighted in cyan. Delay blocks inside this block use the default name `Delay` and are not highlighted.
Constrained Output Pipelining	Green	Constrained output pipelining: `rd_n`
Distributed Pipelining InputPipeline and OutputPipeline Delay Balancing Clock-Rate Pipelining Adaptive Pipelining	Orange	Distributed pipelining: `rd_n` Input pipelining: `in_n_pipe_in_pipe` and output pipelining: `out_n_pipe_in_pipe` Delay balancing: `delayMatch` Clock-rate pipelining: `rd_n` Adaptive pipelining: `HwModeRegister` at block inputs and `PipelineRegister` at the block output.

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 none 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 gm_myModel.

Customize the Generated Model

To customize the prefix of the generated model name, use the GeneratedModelNamePrefix property with the functions makehdl or hdlset_param. See Prefix for generated model name.

You can also specify various options for the naming and layout of the generated model. See Prefix for generated model name.

Validation Model

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.

Latency Differences

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.

Numeric Differences

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.

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.
Use the GenerateValidationModel property with the functions makehdl or hdlset_param.

Customize the Validation Model

To customize the suffix of the generated validation name, use the ValidationModelNameSuffix property with the functions makehdl or hdlset_param. See Suffix for validation model name.

Restrictions

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.