Usage of Different Subsystem Types
You can follow these guidelines to learn how to use different types of subsystems in your design and model your algorithm hierarchically. Each guideline has a severity level that indicates the level of compliance requirements. To learn more, see HDL Modeling Guidelines Severity Levels.
Virtual Subsystem: Use as DUT
Guideline ID
2.4.1
Severity
Strongly Recommended
Description
A virtual subsystem is a Subsystem that is not a conditionally-executed Subsystem or an Atomic Subsystem. By default, a regular Subsystem block that you add to your Simulink® model is a virtual subsystem. Nonvirtual subsystem types include Atomic Subsystem, model reference, Variant Subsystem, and a variant model. You can learn about these subsystem types in the preceding sections.
To determine whether a subsystem is virtual, you can use the get_param function with the
parameter IsSubsystemVirtual. For
example:
get_param('sfir_fixed/symmetric_fir', 'IsSubsystemVirtual')
Atomic Subsystem: Generate Reusable HDL Files
Guideline ID
2.4.2
Severity
Recommended
Description
You can specify the DUT as an Atomic Subsystem. To specify a Subsystem as an Atomic Subsystem, in the Block Parameters dialog box of that Subsystem, select Treat as atomic unit. Use atomic subsystems to generate a single HDL file for identical instances of the subsystems that you use at lower levels of a hierarchy. To learn more, see Generate Reusable Code for Atomic Subsystems.
To enable resource sharing on a subsystem unit, specify all subsystems that you want to share as atomic subsystems. To learn more, see General Considerations for Sharing of Subsystems.
Variant Subsystem: Using Variant Subsystems for HDL Code Generation
Guideline ID
2.4.3
Severity
Mandatory
Description
The Variant Subsystem, Variant Model block is a template preconfigured to contain two Subsystem blocks to use as Variant Subsystem choices. At simulation time, a variant control decides which among the two Subsystem blocks is active. Therefore, you can use the Variant Subsystem to create two different configurations or subsystem behaviors and then specify the active configuration at simulation time.
You cannot use a Variant Subsystem as the DUT. To generate code, place the Variant Subsystem inside the Subsystem that you want to use as the DUT. The file name and instance name of the generated code is unique to the active configuration that is chosen at code generation time.
You cannot share multiple Variant Subsystem blocks by using the Variant Subsystem optimization.
You must make sure that when verifying the functionality of the generated code, the active variant that you used when simulating the model is the same as the active variant that you used for generating HDL code.
For an example, open the model hdlcoder_variant_subsystem_design.slx. If you open the DUT Subsystem, you see a Variant Subsystem block, Divide. The Variant Subsystem has two different subsystems, Recip and Op. If you open the Block Parameters dialog box for the Divide Subsystem, you see the Variant control expression and the Condition that determines which Subsystem to enable during simulation. In this case, Recip is 1, and the Recip Subsystem becomes active during simulation.
load_system('hdlcoder_variant_subsystem_design') set_param('hdlcoder_variant_subsystem_design','SimulationCommand','Update') open_system('hdlcoder_variant_subsystem_design/DUT/Divide')
variantRecip =
Simulink.Variant
Condition: 'Recip == 1'
variantOp =
Simulink.Variant
Condition: 'Recip == 0'
Recip =
1
To generate HDL code, run this command:
makehdl('hdlcoder_variant_subsystem_design/DUT')
A HDL file with the name Recip.vhd is generated because the code is generated for the Recip Subsystem which is active at code generation time.
Model References: Build Model Design Using Smaller Partitions
Guideline ID
2.4.4
Severity
Recommended
Description
Modeling a large design hierarchically can increase code generation time. If you specify generation of reports such as the traceability report, the code generation time can further increase significantly. To avoid such performance issues, it is recommended that you partition your design into smaller partitions. Use the Model block to unify a model that consists of smaller partitions. It also enables incremental code generation. You can generate HDL code for the parent model or the referenced model. To see the generated HDL code, in the hdlsrc folder, a folder is created for the parent model with a separate subfolder for the referenced model.
When generating the HDL test bench, if the test bench consists of blocks that operate with a continuous sample time, you can convert the DUT to a referenced model. This conversion enables the DUT to run at a fixed-step, discrete sample time. To learn more, see Convert DUT Subsystem to Model Reference for Testbenches with Continuous Blocks.
For an example, open the model hdlcoder_divide_parentmodel.slx. When you double-click the DUT Subsystem, you see a Model block that references the model hdlcoder_divide_referencedmodel.
load_system('hdlcoder_divide_parentmodel') set_param('hdlcoder_divide_parentmodel', 'SimulationCommand', 'Update') open_system('hdlcoder_divide_parentmodel/DUT')
To see the referenced model, double-click the Model block:
open_system('hdlcoder_divide_parentmodel/DUT/Model')
To generate HDL code, enter this command:
makehdl('hdlcoder_divide_parentmodel/DUT')
For more information, see Model Referencing for HDL Code Generation.
Block Settings of Enabled and Triggered Subsystems
Guideline ID
2.4.5
Severity
Mandatory
Description
A Triggered Subsystem is a subsystem that receives a control signal via a Trigger block. The Triggered Subsystem executes for one cycle each time a trigger event occurs. When you generate HDL code for a triggered subsystem:
Do not use the Triggered Subsystem block as the DUT. Place the Triggered Subsystem inside another Subsystem block, and use that Subsystem as the DUT.
Make sure that the initial condition of the Triggered Subsystem must be zero.
You can add unit delays to the output signals of the Triggered Subsystem. The unit delays prevent the code generator from inserting additional bypass registers in the HDL code.
Make sure that the Use trigger signal as clock setting does not result in timing mismatches when you simulate the testbench to verify the generated code. To learn more, see Using Triggered Subsystems for HDL Code Generation.
For other preferences when configuring the Triggered Subsystem block for HDL code generation, see HDL Code Generation on the Triggered Subsystem page.
An Enabled Subsystem is a subsystem that receives a control signal via an Enable block. The Enabled Subsystem executes at each simulation step where the control signal has a positive value. When you generate HDL code for an Enabled Subsystem:
Do not use the Enabled Subsystem block as the DUT. Place the Enabled Subsystem inside another Subsystem block, and use that Subsystem as the DUT.
Make sure that the initial condition of the Enabled Subsystem is zero.
You can add unit delays to the output signals of the Enabled Subsystem. The unit delays prevent the code generator from inserting additional bypass registers in the HDL code.
You can add a State Control block in
Synchronousmode inside the Enabled Subsystem. The State Control block converts the Enabled Subsystem block to an Enabled Synchronous Subsystem block. This block generates more efficient and hardware-friendly HDL code. To learn more, see Synchronous Subsystem Behavior with the State Control Block.
For other preferences when configuring the Enabled Subsystem block for HDL code generation, see HDL Code Generation on the Enabled Subsystem page.