Model Referencing for HDL Code Generation

Model referencing in your DUT subsystem enables you to:

Partition a large design into a hierarchy of smaller designs for reuse, modular development, and accelerated simulation.
Incrementally generate and test code.
HDL Coder™ incrementally generates code for referenced models according to the Configuration Parameters dialog box > Model Referencing pane > Rebuild options. For more information, see Rebuild.
However, HDL Coder treats If changes detected and If changes in known dependencies detected as the same. For example, if you set Rebuild to either If changes detected or If changes in known dependencies detected, HDL Coder regenerates code for referenced models only when the referenced models have changed. The referenced model targets are rebuild when the software detects a change that could affect simulation results. A structural checksum is a computation used to detect changes in the model that can affect simulation results. For more information about the kinds of changes that affect the structural checksum, see Simulink.BlockDiagram.getChecksum.

How To Generate Code for a Referenced Model

By default, Generate VHDL or SystemVerilog code for model references into a single library is enabled. The VHDL code is generated in a single library instead of separate libraries. In this case, set the ScalarizePorts property to off before generating HDL code.

When generating code, if you encounter typing or naming conflicts between vector ports when interfacing two or more generated VHDL^® code modules, use the ScalarizePorts property to generate non-conflicting port definitions. For more information, see Scalarize ports.

Use of vector or matrix ports at the model reference boundary requires ports to be scalarized in generated VHDL code, or the type definition or code to be placed in single library. When generating VHDL code, either set Scalarize ports to on or enable Generate VHDL or SystemVerilog code for model references into a single library option.

You can generate HDL code for the referenced model using the UI or the command line.

Using the UI

Right-click the Model block and select HDL Code > HDL Block Properties.
For Architecture, select ModelReference.
Generate HDL code from your DUT subsystem.

Using the Command Line

Set the Architecture property of the Model block to ModelReference. For example, for a DUT subsystem, mydut, that includes a model reference, referenced_model, enter this command:
```
hdlset_param ('mydut/referenced_model', ... 
              'Architecture', 'ModelReference');
```
Generate HDL code for your DUT subsystem.
```
makehdl ('mydut');
```

Generate Code for Model Arguments

To generate a single Verilog^® or SystemVerilog module or VHDL entity for instances of a referenced model with different model argument values, see Generate Parameterized Code for Referenced Models.

Generate Comments

If you enter text in the Model Block Properties dialog box Description field, HDL Coder generates a comment in the HDL code.

Limitations

Model block must have default values for the Block parameters.
Multiple model references that refer to the same model must have the same HDL block properties.

HDL Coder cannot move registers across a model reference. Therefore, referenced models can inhibit these optimizations:

Distributed pipelining
Constrained output pipelining
Streaming
Clock-rate pipelining
Resource sharing

To use these optimizations, consider using subsystem references instead of model references. For more information, see Create and Use Referenced Subsystems in Models.

When you have model references and generate HDL code, the generated model, validation model, and cosimulation model can fail to compile or simulate. To fix compilation or simulation errors, make sure that the referenced models are loaded or are on the search path.

The coder can apply the resource sharing optimization to share referenced model instances. However, you can apply this optimization only when all model references that point to the same referenced model have the same rate after optimizations and rate propagation. The model reference final rate may differ from the original rate, but all model references that point to the same referenced model must have the same final rate.