Main Content

Pass through, No HDL, and Cascade Implementations

Pass-through and No HDL Implementations

ImplementationDescription
Pass-through implementations

Provides a pass-through implementation in which the block's inputs are passed directly to its outputs. HDL Coder™ supports the following blocks with a pass-through implementation:

  • Convert 1-D to 2-D

  • Reshape

  • Signal Conversion

  • Signal Specification

No HDL

The NoHDL implementation completely removes the block from the generated code. Thus, you can use the block in simulation but treat it as a “no-op” in the HDL code. This implementation is used for many blocks (such as Scopes and Assertions) that are significant in simulation but would be meaningless in HDL code.

You can also use this implementation as an alternative implementation for subsystems.

Logic driving a NoHDL subsystem might cause unconnected logic that is eliminated in the HDL code. For more information, see Remove Redundant Logic and Unused Blocks in Generated HDL Code.

Output ports of NoHDL subsystems are not recommended. NoHDL subsystems appear in the generated model but are removed, along with any logic that only drives the subsystem, before code generation. To generate HDL for the surrounding logic of a NoHDL subsystem, comment through the subsystem in Simulink® instead. For more information, see Using Comment Out and Comment Through of Blocks.

For more information related to special-purpose implementations, see External Component Interfaces.

Cascade Architecture Best Practices

HDL Coder supports cascade implementations for the MinMax block. These implementations require multiple clock cycles to process their inputs; therefore, their inputs must be kept unchanged for their entire sample-time period. Generated test benches accomplish this by using a register to drive the inputs.

A recommended design practice, when integrating generated HDL code with other HDL code, is to provide registers at the inputs. While not strictly required, adding registers to the inputs improves timing and avoids problems with data stability for blocks that require multiple clock cycles to process their inputs.