Generated Model and Validation Model

HDL Coder™ enables you to view the effect of HDL optimizations and block settings in the 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 an intermediate model 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^® DUT and the generated HDL code. Delays that the code generator inserts are highlighted in the generated model in various colors. See the table below for different delays in code generation, the corresponding highlight color, and how the delays are named in the generated model.

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, you can see additional integer delays next to blocks if you request optimizations and additional balanced delays wherever necessary to maintain the accuracy of the algorithm. You see additional rates in the model if you request resource sharing or streaming optimization where the same operator is time multiplexed across multiple operations.

The generated model is used in RTL testbench generation. The input stimulus and output response are captured from the generated model instead of the original model because the generated model reflects the algorithms 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 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 Naming and Layout Options for Model Generation.

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. For example:

HDL block property such as InputPipeline specified on the block, or certain HDL architectures or optimizations such as distributed pipelining that moves 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 makehdl or hdlset_param.

Customize the Validation Model

To customize the suffix of the generated validation name, use the ValidationModelNameSuffix property with 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 the DUT subsystem has no unconnected output ports. See Terminate Unconnected Block Outputs and Usage of Commenting Blocks.

Documentation