Main Content

Iteratively Maximize Clock Frequency by Using Speed Optimizations

This example shows how to iteratively maximize the clock frequency for a model by using various speed optimizations and minimize the resources needed for the design. In this example, you first apply speed optimizations to achieve a desired target frequency, then apply area optimizations to reduce the resources needed for your design on hardware.

The algorithm in this model detects a peak pulse in a noisy signal. The model is designed for deployment onto hardware but it is not yet optimized for speed. In this example, you use Simulink® HDL optimizations to generate optimized HDL code from the model. These optimizations can increase the clock speed of your design and can reduce the amount of hardware components needed for the design. For each iteration of optimizations that you apply, you use the HDL Workflow Advisor to run synthesis on your model and to generate a Resource and Timing summary to determine the clock frequency achieved and the resources used. From the summary, you can determine which optimizations to apply next. The target clock frequency in this example is 230 MHz.

Prerequisites

This example requires Xilinx Vivado® as the synthesis tool. Set up the synthesis tool before beginning this example by using the function hdlsetuptoolpath.

This example targets the Xilinx Zynq® hardware with a speed grade of -1. HDL Coder™ has a default timing database for Xilinx Zynq with a speed grade -1. If you are targeting an FPGA that HDL Coder does not have a characterized timing database for, use the function genhdltdb to create your own database. To see the list of characterized timing databases, see Critical Path Estimation Without Running Synthesis.

If you generate your own timing database, you can use the model parameter TimingDatabaseDirectory to set the timing database for the model to your custom timing database created. See Custom Timing Database Directory.

Open and Simulate the Model

Open and simulate the model to see the peak found using the peak detection algorithm.

modelname = 'pulse_detector';
DUTname = [modelname '/Pulse_Detector_DUT'];
open_system(modelname);

sim(modelname);

Set the Pulse_Detector_DUT as the HDL subsystem so you generate HDL code for the Pulse_Detector_DUT subsystem and not the entire model.

hdlset_param(modelname,'HDLSubsystem', DUTname);

Apply Base Speed Optimizations

When you want to deploy a model to an FPGA, it is a best practice to apply some base speed optimizations. For this example, enable adaptive pipelining and add I/O pipeline registers. Applying an input and output pipeline enables you to clock the I/O for the FPGA. Adaptive pipelining enables you to pipeline and target DSPs. For more information, see Adaptive Pipelining.

hdlset_param(modelname, 'AdaptivePipelining', 'on');
hdlset_param(DUTname, 'OutputPipeline', 1);
hdlset_param(DUTname, 'InputPipeline', 1);

When you apply optimizations that can affect timing or numerical changes in the model, such as adaptive pipelining, it is a best practice to generate a validation model. Enable the generation of the validation model. The validation model compares the generated model and original model and displays any numerical mismatches between the two.

hdlset_param(modelname, 'GenerateValidationModel', 'on');

To view the nondefault HDL code generation parameters for the model, use the function hdlsaveparams.

hdlsaveparams(modelname)
%% Set Model 'pulse_detector' HDL parameters
hdlset_param('pulse_detector', 'AdaptivePipelining', 'on');
hdlset_param('pulse_detector', 'Backannotation', 'on');
hdlset_param('pulse_detector', 'CriticalPathEstimation', 'on');
hdlset_param('pulse_detector', 'GenerateHDLTestBench', 'off');
hdlset_param('pulse_detector', 'GenerateValidationModel', 'on');
hdlset_param('pulse_detector', 'HDLSubsystem', 'pulse_detector/Pulse_Detector_DUT');
hdlset_param('pulse_detector', 'MinimizeClockEnables', 'on');
hdlset_param('pulse_detector', 'OptimizationReport', 'on');
hdlset_param('pulse_detector', 'ResetType', 'Synchronous');
hdlset_param('pulse_detector', 'ResourceReport', 'on');
hdlset_param('pulse_detector', 'SynthesisTool', 'Xilinx Vivado');
hdlset_param('pulse_detector', 'SynthesisToolChipFamily', 'Zynq');
hdlset_param('pulse_detector', 'SynthesisToolDeviceName', 'xc7z045');
hdlset_param('pulse_detector', 'SynthesisToolPackageName', 'ffg900');
hdlset_param('pulse_detector', 'SynthesisToolSpeedValue', '-1');
hdlset_param('pulse_detector', 'TargetDirectory', 'hdl_prj\hdlsrc');
hdlset_param('pulse_detector', 'TargetFrequency', 230);
hdlset_param('pulse_detector', 'TargetLanguage', 'Verilog');
hdlset_param('pulse_detector', 'Traceability', 'on');

% Set SubSystem HDL parameters
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'InputPipeline', 1);
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'OutputPipeline', 1);

hdlset_param('pulse_detector/Pulse_Detector_DUT/Discrete FIR Filter', 'Architecture', 'Fully Parallel');

Note that the Discrete FIR Filter block has the HDL block property Architecture set to Fully Parallel. This option enables subsystem level optimizations to be applied to the filter block. For more information, see Subsystem Optimizations for Filters.

Generate code by using the makehdl command.

makehdl(DUTname)
### Generating HDL for 'pulse_detector/Pulse_Detector_DUT'.
### Using the config set for model <a href="matlab:configset.showParameterGroup('pulse_detector', { 'HDL Code Generation' } )">pulse_detector</a> for HDL code generation parameters.
### Running HDL checks on the model 'pulse_detector'.
### Begin compilation of the model 'pulse_detector'...
### Applying HDL optimizations on the model 'pulse_detector'...
### <a href="matlab:configset.internal.open('pulse_detector','LUTMapToRAM')">'LUTMapToRAM'</a> is set to 'On' for the model. This option is used to map lookup tables to a block RAM in hardware.  To disable pipeline insertion for mapping lookup tables to RAM, please set the option to 'Off'.
### The code generation and optimization options you have chosen have introduced additional pipeline delays.
### The delay balancing feature has automatically inserted matching delays for compensation.
### The DUT requires an initial pipeline setup latency. Each output port experiences these additional delays.
### Output port 1: 9 cycles.
### Output port 2: 9 cycles.
### Output port 3: 9 cycles.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'GenerateModel')">GenerateModel</a>
### Begin model generation.
### Model generation complete.
### Estimated critical path for design: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated')">hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated.m</a>
### Blocks that are not characterized for Critical Path Estimation: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks')">hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks.m</a>
### To clear highlighting, click the following MATLAB script: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m')">hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m</a>
### Generating new validation model: <a href="matlab:open_system('hdl_prj/hdlsrc/pulse_detector/gm_pulse_detector_vnl')">gm_pulse_detector_vnl</a>.
### Validation model generation complete.
### Begin Verilog Code Generation for 'pulse_detector'.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'Traceability')">Traceability</a>
### Working on pulse_detector/Pulse_Detector_DUT/Compute Power as hdl_prj/hdlsrc/pulse_detector/Compute_Power.v.
### Working on pulse_detector/Pulse_Detector_DUT/Local Peak/MATLAB Function as hdl_prj/hdlsrc/pulse_detector/MATLAB_Function.v.
### Working on pulse_detector/Pulse_Detector_DUT/Local Peak as hdl_prj/hdlsrc/pulse_detector/Local_Peak.v.
### Working on pulse_detector/Pulse_Detector_DUT as hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT.v.
### Code Generation for 'pulse_detector' completed.
### Generating HTML files for code generation report at <a href="matlab:web('/tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/html/pulse_detector_codegen_rpt.html')">pulse_detector_codegen_rpt.html</a>
### Creating HDL Code Generation Check Report file:///tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_report.html
### HDL check for 'pulse_detector' complete with 0 errors, 0 warnings, and 3 messages.
### HDL code generation complete.

Because the Traceability parameter for this model is on, the Code Generation Report window opens after the makehdl function completes. This report summarizes the generated code and the HDL code options applied to the model. For more information, see Create and Use Code Generation Reports.

In the left pane, click Delay Balancing. The pipelines added from the base speed optimizations applied add 9 cycles of latency to the generated model.

You can find out more information about the optimizations applied in the Optimization Report section. Each link in this section characterizes an optimization applied to the model. Click High-level resource report to see the initial estimate of resources needed to deploy the model to your target hardware.

Open the generated model gm_pulse_detector to see the optimizations applied to the model. The generated model is located in the hdl_prj\hdlsrc\pulse_detector folder.

Click on the highlighting script hdl_prj\hdlsrc\pulse_detector\criticalPathEstimated.m in the output of the makehdl command to highlight the estimated critical path of the design. This image shows a snippet of the generated model with part of estimated critical path highlighted and the subsystems expanded. The critical path estimation shows the critical path running through a long chain of adders from the Discrete FIR Filter block.

You can also see the estimated critical path in the Code Generation Report by clicking Critical Path Estimation. For this example, the critical path estimated is 93.872 ns. The critical path estimation is an estimation of the critical path of your model when it is implemented on hardware. To accurately capture the critical path, you must run synthesis on your model.

In the Critical Path Estimation pane, you can also click scripts to highlight the estimated critical path of your design and the blocks not characterized by the critical path estimation in both the original model and generated model. Click the script that highlights the uncharacterized blocks, highlightCriticalPathEstimationOffendingBlocks.m. The script highlights the MATLAB Function block. When the HDL block property Architecture is set to MATLAB Function, critical path estimation cannot characterize the MATLAB Function block. While you can still generate code, to most accurately capture the critical path of your design and apply subsystem level optimizations to your MATLAB Function block, consider changing the Architecture of your MATLAB Function block to MATLAB Datapath. This option is explored in the next set of optimizations applied to the model.

To determine if the speed optimizations applied to the model achieve the target frequency, run synthesis on the model to check if the timing constraints are met.

To run synthesis on the model:

  1. In Simulink, the in HDL Code tab, click Workflow Advisor.

  2. In the left pane, click 4. FPGA Synthesis and Analysis > 4.2 Perform Synthesis and P/R > 4.2.2. Run Implementation. Clear Skip This Task.

  3. Right-click 4.2.2 Run Implementation and click Run to Selected Task.

The HDL Workflow Advisor runs through synthesis and implementation for the model. The Result section displays the Resource and Timing summary from synthesis. The Timing summary shows that there is negative slack, which indicates that the timing constraint, the target clock frequency, is not met. When timing is not met, the clock frequency is not calculated in this report.

For reference, you can calculate the clock frequency manually by using this equation:

$$Clock Frequency = 1/(Requirement-Slack)$$

The calculated clock frequency is 110 MHz.

For more information on the code generation and synthesis steps, see HDL Code Generation and FPGA Synthesis from Simulink Model.

Apply Distributed Pipelining

To apply Simulink HDL optimizations to the MATLAB Function block, set the HDL block property Architecture to MATLAB Datapath. This option characterizes the MATLAB Function block for critical path estimation, which helps you get a more accurate estimate of your critical path. For more information on when to set this property to MATLAB Datapath, see HDL Optimizations Across MATLAB Function Block Boundary Using MATLAB Datapath Architecture.

hdlset_param([DUTname '/Local Peak/MATLAB Function'], 'Architecture', 'MATLAB Datapath');

To increase the clock frequency and reduce the critical path, you can enable the HDL optimization distributed pipelining. In order to use distributed pipelining, there already needs to be pipelines in the design that distributed pipelining can move to minimize the critical path. In this example, to break up the long chain of adders causing a long critical path, increase the number of pipeline stages for distributed pipelining to move by increasing the number of output pipelines. For more information on distributed pipelining, see Distributed Pipelining.

Increase the number of output pipeline stages in the DUT to 23 and enable distributed pipelining for the model.

hdlset_param(DUTname, 'OutputPipeline', 23);
hdlset_param(modelname, 'DistributedPipelining', 'on');

Distributed pipelining priority is by default set as Numerical Integrity. Set the Distributed pipelining priority to Performance to allow distributed pipelining to move pipelines with the goal of trying to maximize clock speed. If you do not change this parameter and generate HDL code, the Code Generation Report window displays this message in the Distributed Pipelining pane:

'DistributedPipeliningPriority' set to 'Numerical Integrity' is
preventing movement of pipelines around certain blocks. Consider
changing the priority to 'Performance' if numerical inaccuracies can be
ignored. Note that this can lead to validation model mismatches during
the initialization cycles or whole simulation time if the model has feedback loops.

It is important to note that when you set Distributed pipelining priority to Performance, the model behavior might not strictly match the generated code behavior. If strict numerical integrity is a requirement, keep Distributed pipelining priority set to Numerical Integrity. Instead, consider moving the placement of initial pipelines set in the design, in this case the output pipelines stages, to locations where the pipelines are not blocked by distributed pipelining barriers. For more information on distributed pipelining priority, see Pipelining Parameters. For more information on distributed pipelining barriers, see Highlight blocks inhibiting distributed pipelining.

hdlset_param(modelname, 'DistributedPipeliningPriority', 'Performance');

To apply distributed pipelining across all subsystems in the DUT and see all blocks at the same level in the generated model, enable the FlattenHierarchy parameter on the DUT subsystem. Alternatively, to keep the subsystem hierarchy while still applying distributed pipelining across subsystems, enable Hierarchical distributed pipelining for the model.

hdlset_param(DUTname, 'FlattenHierarchy', 'on')

Report the nondefault HDL parameters for the model to see the new applied optimizations for the model.

hdlsaveparams(modelname)
%% Set Model 'pulse_detector' HDL parameters
hdlset_param('pulse_detector', 'AdaptivePipelining', 'on');
hdlset_param('pulse_detector', 'Backannotation', 'on');
hdlset_param('pulse_detector', 'CriticalPathEstimation', 'on');
hdlset_param('pulse_detector', 'DistributedPipelining', 'on');
hdlset_param('pulse_detector', 'DistributedPipeliningPriority', 'Performance');
hdlset_param('pulse_detector', 'GenerateHDLTestBench', 'off');
hdlset_param('pulse_detector', 'GenerateValidationModel', 'on');
hdlset_param('pulse_detector', 'HDLSubsystem', 'pulse_detector/Pulse_Detector_DUT');
hdlset_param('pulse_detector', 'MinimizeClockEnables', 'on');
hdlset_param('pulse_detector', 'OptimizationReport', 'on');
hdlset_param('pulse_detector', 'ResetType', 'Synchronous');
hdlset_param('pulse_detector', 'ResourceReport', 'on');
hdlset_param('pulse_detector', 'SynthesisTool', 'Xilinx Vivado');
hdlset_param('pulse_detector', 'SynthesisToolChipFamily', 'Zynq');
hdlset_param('pulse_detector', 'SynthesisToolDeviceName', 'xc7z045');
hdlset_param('pulse_detector', 'SynthesisToolPackageName', 'ffg900');
hdlset_param('pulse_detector', 'SynthesisToolSpeedValue', '-1');
hdlset_param('pulse_detector', 'TargetDirectory', 'hdl_prj\hdlsrc');
hdlset_param('pulse_detector', 'TargetFrequency', 230);
hdlset_param('pulse_detector', 'TargetLanguage', 'Verilog');
hdlset_param('pulse_detector', 'Traceability', 'on');

% Set SubSystem HDL parameters
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'FlattenHierarchy', 'on');
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'InputPipeline', 1);
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'OutputPipeline', 23);

hdlset_param('pulse_detector/Pulse_Detector_DUT/Discrete FIR Filter', 'Architecture', 'Fully Parallel');

hdlset_param('pulse_detector/Pulse_Detector_DUT/Local Peak/MATLAB Function', 'Architecture', 'MATLAB Datapath');

Generate HDL code and open the generated model gm_pulse_detector.

makehdl(DUTname)
### Generating HDL for 'pulse_detector/Pulse_Detector_DUT'.
### Using the config set for model <a href="matlab:configset.showParameterGroup('pulse_detector', { 'HDL Code Generation' } )">pulse_detector</a> for HDL code generation parameters.
### Running HDL checks on the model 'pulse_detector'.
### Begin compilation of the model 'pulse_detector'...
### Applying HDL optimizations on the model 'pulse_detector'...
### <a href="matlab:configset.internal.open('pulse_detector','LUTMapToRAM')">'LUTMapToRAM'</a> is set to 'On' for the model. This option is used to map lookup tables to a block RAM in hardware.  To disable pipeline insertion for mapping lookup tables to RAM, please set the option to 'Off'.
### The code generation and optimization options you have chosen have introduced additional pipeline delays.
### The delay balancing feature has automatically inserted matching delays for compensation.
### The DUT requires an initial pipeline setup latency. Each output port experiences these additional delays.
### Output port 1: 30 cycles.
### Output port 2: 30 cycles.
### Output port 3: 30 cycles.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'GenerateModel')">GenerateModel</a>
### Begin model generation.
### Model generation complete.
### Estimated critical path for design: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated')">hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated.m</a>
### Blocks that are not characterized for Critical Path Estimation: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks')">hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks.m</a>
### To clear highlighting, click the following MATLAB script: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m')">hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m</a>
### Generating new validation model: <a href="matlab:open_system('hdl_prj/hdlsrc/pulse_detector/gm_pulse_detector_vnl')">gm_pulse_detector_vnl</a>.
### Validation model generation complete.
### Begin Verilog Code Generation for 'pulse_detector'.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'Traceability')">Traceability</a>
### Working on pulse_detector/Pulse_Detector_DUT as hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT.v.
### Code Generation for 'pulse_detector' completed.
### Generating HTML files for code generation report at <a href="matlab:web('/tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/html/pulse_detector_codegen_rpt.html')">pulse_detector_codegen_rpt.html</a>
### Creating HDL Code Generation Check Report file:///tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_report.html
### HDL check for 'pulse_detector' complete with 0 errors, 0 warnings, and 3 messages.
### HDL code generation complete.

The optimization options applied to the model add 31 cycles of latency to the generated model. This increase in latency is due to the large number of output pipelines, which reduced the critical path.

Below is a snippet of the generated model with the estimated critical path highlighted. The estimated critical path is now only through a single multiplier block because distributed pipelining broke up the long chain of adders in the Discrete FIR Filter by inserting pipelines throughout the original critical path. As a result, the adder chain with pipelines now has a shorter path than the multiplier block by itself.

The estimated critical path is now 5.971 ns, which is much smaller than the initial value of 93.872 ns. This decrease in estimated critical path is a result of the speed optimizations applied across the entire DUT, including its subsystems and the MATLAB Function block.

Check if your timing constraints have been met by running the HDL Workflow Advisor through step 4.2.2. The synthesis results show that there is positive slack, indicating that the timing constraint is met. The clock frequency is now 255 MHz and is higher than the target frequency of 230 MHz and the initial clock frequency of 110 MHz.

Apply Distributed Pipelining Using Synthesis Timing Estimates

While the clock frequency is achieved from the previous optimizations applied, another speed optimization you can use specifically for distributed pipelining is using synthesis timing estimates. For more information, see Distributed Pipelining Using Synthesis Timing Estimates.

hdlset_param(modelname, 'UseSynthesisEstimatesForDistributedPipelining','on');

Report the nondefault HDL parameters for the model.

hdlsaveparams(modelname)
%% Set Model 'pulse_detector' HDL parameters
hdlset_param('pulse_detector', 'AdaptivePipelining', 'on');
hdlset_param('pulse_detector', 'Backannotation', 'on');
hdlset_param('pulse_detector', 'CriticalPathEstimation', 'on');
hdlset_param('pulse_detector', 'DistributedPipelining', 'on');
hdlset_param('pulse_detector', 'DistributedPipeliningPriority', 'Performance');
hdlset_param('pulse_detector', 'GenerateHDLTestBench', 'off');
hdlset_param('pulse_detector', 'GenerateValidationModel', 'on');
hdlset_param('pulse_detector', 'HDLSubsystem', 'pulse_detector/Pulse_Detector_DUT');
hdlset_param('pulse_detector', 'MinimizeClockEnables', 'on');
hdlset_param('pulse_detector', 'OptimizationReport', 'on');
hdlset_param('pulse_detector', 'ResetType', 'Synchronous');
hdlset_param('pulse_detector', 'ResourceReport', 'on');
hdlset_param('pulse_detector', 'SynthesisTool', 'Xilinx Vivado');
hdlset_param('pulse_detector', 'SynthesisToolChipFamily', 'Zynq');
hdlset_param('pulse_detector', 'SynthesisToolDeviceName', 'xc7z045');
hdlset_param('pulse_detector', 'SynthesisToolPackageName', 'ffg900');
hdlset_param('pulse_detector', 'SynthesisToolSpeedValue', '-1');
hdlset_param('pulse_detector', 'TargetDirectory', 'hdl_prj\hdlsrc');
hdlset_param('pulse_detector', 'TargetFrequency', 230);
hdlset_param('pulse_detector', 'TargetLanguage', 'Verilog');
hdlset_param('pulse_detector', 'Traceability', 'on');
hdlset_param('pulse_detector', 'UseSynthesisEstimatesForDistributedPipelining', 'on');

% Set SubSystem HDL parameters
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'FlattenHierarchy', 'on');
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'InputPipeline', 1);
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'OutputPipeline', 23);

hdlset_param('pulse_detector/Pulse_Detector_DUT/Discrete FIR Filter', 'Architecture', 'Fully Parallel');

hdlset_param('pulse_detector/Pulse_Detector_DUT/Local Peak/MATLAB Function', 'Architecture', 'MATLAB Datapath');

Generate HDL code and open the generated model gm_pulse_detector.

makehdl(DUTname)
### Generating HDL for 'pulse_detector/Pulse_Detector_DUT'.
### Using the config set for model <a href="matlab:configset.showParameterGroup('pulse_detector', { 'HDL Code Generation' } )">pulse_detector</a> for HDL code generation parameters.
### Running HDL checks on the model 'pulse_detector'.
### Begin compilation of the model 'pulse_detector'...
### Applying HDL optimizations on the model 'pulse_detector'...
### <a href="matlab:configset.internal.open('pulse_detector','LUTMapToRAM')">'LUTMapToRAM'</a> is set to 'On' for the model. This option is used to map lookup tables to a block RAM in hardware.  To disable pipeline insertion for mapping lookup tables to RAM, please set the option to 'Off'.
### The code generation and optimization options you have chosen have introduced additional pipeline delays.
### The delay balancing feature has automatically inserted matching delays for compensation.
### The DUT requires an initial pipeline setup latency. Each output port experiences these additional delays.
### Output port 1: 30 cycles.
### Output port 2: 30 cycles.
### Output port 3: 30 cycles.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'GenerateModel')">GenerateModel</a>
### Begin model generation.
### Model generation complete.
### Estimated critical path for design: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated')">hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated.m</a>
### Blocks that are not characterized for Critical Path Estimation: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks')">hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks.m</a>
### To clear highlighting, click the following MATLAB script: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m')">hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m</a>
### Generating new validation model: <a href="matlab:open_system('hdl_prj/hdlsrc/pulse_detector/gm_pulse_detector_vnl')">gm_pulse_detector_vnl</a>.
### Validation model generation complete.
### Begin Verilog Code Generation for 'pulse_detector'.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'Traceability')">Traceability</a>
### Working on pulse_detector/Pulse_Detector_DUT as hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT.v.
### Code Generation for 'pulse_detector' completed.
### Generating HTML files for code generation report at <a href="matlab:web('/tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/html/pulse_detector_codegen_rpt.html')">pulse_detector_codegen_rpt.html</a>
### Creating HDL Code Generation Check Report file:///tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_report.html
### HDL check for 'pulse_detector' complete with 0 errors, 1 warnings, and 3 messages.
### HDL code generation complete.

The optimizations applied to the model add 31 cycles of latency to the generated model.

The estimated critical path is 5.971 ns, which is the same as the previous model. Because critical path estimation is an estimate, you need to run synthesis to determine how this option changed your clock frequency and resources.

Depending on your design, using synthesis timing estimates for distributed pipelining can improve your clock speed or keep it similar to the clock frequency when using synthesis estimates for distributed pipelining is not enabled.

Using synthesis timing estimates for distributed pipelining can increase your clock speed if your design has different types of components with nonzero propagation delay, and the delays of each type of block are different from one another. For example, if you have Add and Multiply blocks in your design that have nonzero propagation delays, but the numerical value of the delays are significantly different, using synthesis timing estimates for distributed pipelining can increase your clock frequency.

Using synthesis timing estimates for distributed pipelining might not improve your clock frequency if there is such a large number of delays in the model that regardless of how distributed pipelining moves the delays, they are placed in the same or similar locations in the design.

Check if your timing constraints have been met by running the HDL Workflow Advisor through step 4.2.2. The synthesis results show that there is positive slack, which indicates that the timing constraint is met. The clock frequency is now 236 MHz and is higher than the target frequency of 230 MHz.

Apply Area Optimizations

The target frequency is now met due the applied speed optimizations, but the model uses significant resources. The Resource summary table displays the resource usage for the model.

To reduce the area used by the design, apply sharing to the DUT. If you look at the generated model you can see a significant portion of the FIR Filter block uses adders. Ensure resource sharing is applied to the adders by enabling the sharing of adders. You can increase or decrease the sharing factor depending on the area requirements for your design. For this example, set the SharingFactor to 8 to reduce the DSP usage by about a factor of eight.

hdlset_param(DUTname,'SharingFactor', 8);
hdlset_param(modelname, 'ShareAdders','on');

Resource sharing creates a multirate model due to the serializer subnetworks added in the generated model. Synthesis tools require a constraint file to indicate if a path is using a slower clock enable where it can tolerate multiple clock cycles. If a synthesis tool does not have a constraint file when there are multiple clock rates, the synthesis tool might report that the critical path is in a slow part of the logic that does not need to be executed every single clock cycle. You can generate this constraint file by enabling the generation of a multicycle path constraint for your model. Generating this constraint file can also improve the timing of your design and reduce synthesis time. For more information, see Meet Timing Requirements Using Enable-Based Multicycle Path Constraints.

hdlset_param(modelname, 'MulticyclePathConstraints', 'on');

Report the nondefault HDL parameters for the model.

hdlsaveparams(modelname)
%% Set Model 'pulse_detector' HDL parameters
hdlset_param('pulse_detector', 'AdaptivePipelining', 'on');
hdlset_param('pulse_detector', 'Backannotation', 'on');
hdlset_param('pulse_detector', 'CriticalPathEstimation', 'on');
hdlset_param('pulse_detector', 'DistributedPipelining', 'on');
hdlset_param('pulse_detector', 'DistributedPipeliningPriority', 'Performance');
hdlset_param('pulse_detector', 'GenerateHDLTestBench', 'off');
hdlset_param('pulse_detector', 'GenerateValidationModel', 'on');
hdlset_param('pulse_detector', 'HDLSubsystem', 'pulse_detector/Pulse_Detector_DUT');
hdlset_param('pulse_detector', 'MinimizeClockEnables', 'on');
hdlset_param('pulse_detector', 'MulticyclePathConstraints', 'on');
hdlset_param('pulse_detector', 'OptimizationReport', 'on');
hdlset_param('pulse_detector', 'ResetType', 'Synchronous');
hdlset_param('pulse_detector', 'ResourceReport', 'on');
hdlset_param('pulse_detector', 'ShareAdders', 'on');
hdlset_param('pulse_detector', 'SynthesisTool', 'Xilinx Vivado');
hdlset_param('pulse_detector', 'SynthesisToolChipFamily', 'Zynq');
hdlset_param('pulse_detector', 'SynthesisToolDeviceName', 'xc7z045');
hdlset_param('pulse_detector', 'SynthesisToolPackageName', 'ffg900');
hdlset_param('pulse_detector', 'SynthesisToolSpeedValue', '-1');
hdlset_param('pulse_detector', 'TargetDirectory', 'hdl_prj\hdlsrc');
hdlset_param('pulse_detector', 'TargetFrequency', 230);
hdlset_param('pulse_detector', 'TargetLanguage', 'Verilog');
hdlset_param('pulse_detector', 'Traceability', 'on');
hdlset_param('pulse_detector', 'UseSynthesisEstimatesForDistributedPipelining', 'on');

% Set SubSystem HDL parameters
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'FlattenHierarchy', 'on');
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'InputPipeline', 1);
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'OutputPipeline', 23);
hdlset_param('pulse_detector/Pulse_Detector_DUT', 'SharingFactor', 8);

hdlset_param('pulse_detector/Pulse_Detector_DUT/Discrete FIR Filter', 'Architecture', 'Fully Parallel');

hdlset_param('pulse_detector/Pulse_Detector_DUT/Local Peak/MATLAB Function', 'Architecture', 'MATLAB Datapath');

Generate the HDL code and open the generated model gm_pulse_detector.

makehdl(DUTname)
### Generating HDL for 'pulse_detector/Pulse_Detector_DUT'.
### Using the config set for model <a href="matlab:configset.showParameterGroup('pulse_detector', { 'HDL Code Generation' } )">pulse_detector</a> for HDL code generation parameters.
### Running HDL checks on the model 'pulse_detector'.
### Begin compilation of the model 'pulse_detector'...
### Applying HDL optimizations on the model 'pulse_detector'...
### <a href="matlab:configset.internal.open('pulse_detector','LUTMapToRAM')">'LUTMapToRAM'</a> is set to 'On' for the model. This option is used to map lookup tables to a block RAM in hardware.  To disable pipeline insertion for mapping lookup tables to RAM, please set the option to 'Off'.
### The DUT requires an initial pipeline setup latency. Each output port experiences these additional delays.
### Output port 1: 95 cycles.
### Output port 2: 95 cycles.
### Output port 3: 95 cycles.
Warning: The model contains multiple rates, which are either explicitly
designed or introduced by optimizations. Critical Path Estimation does not
account for multiple rates in the reported timing estimates. 
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'GenerateModel')">GenerateModel</a>
### Begin model generation.
### Model generation complete.
### Estimated critical path for design: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated')">hdl_prj/hdlsrc/pulse_detector/criticalPathEstimated.m</a>
### Blocks that are not characterized for Critical Path Estimation: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks')">hdl_prj/hdlsrc/pulse_detector/highlightCriticalPathEstimationOffendingBlocks.m</a>
### To clear highlighting, click the following MATLAB script: <a href="matlab:run('hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m')">hdl_prj/hdlsrc/pulse_detector/clearhighlighting.m</a>
### Generating new validation model: <a href="matlab:open_system('hdl_prj/hdlsrc/pulse_detector/gm_pulse_detector_vnl')">gm_pulse_detector_vnl</a>.
### Validation model generation complete.
### Begin Verilog Code Generation for 'pulse_detector'.
### MESSAGE: The design requires 8 times faster clock with respect to the base rate = 1.
### Begin Verilog Code Generation for 'Pulse_Detector_DUT_tc'.
### Working on Pulse_Detector_DUT_tc as hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_tc.v.
### Code Generation for 'Pulse_Detector_DUT_tc' completed.
### Working on... <a href="matlab:configset.internal.open('pulse_detector', 'Traceability')">Traceability</a>
### Working on pulse_detector/Pulse_Detector_DUT as hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT.v.
### Code Generation for 'pulse_detector' completed.
### Generating HTML files for code generation report at <a href="matlab:web('/tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/html/pulse_detector_codegen_rpt.html')">pulse_detector_codegen_rpt.html</a>
### Writing Vivado multicycle constraints XDC file <a href="matlab:edit('hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_constraints.xdc')">hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_constraints.xdc</a>
### Creating HDL Code Generation Check Report file:///tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_tc_report.html
### HDL check for 'Pulse_Detector_DUT_tc' complete with 0 errors, 1 warnings, and 0 messages.
### Creating HDL Code Generation Check Report file:///tmp/Bdoc22b_2054784_3457179/tp98e30a8e/hdlcoder-ex56941969/hdl_prj/hdlsrc/pulse_detector/Pulse_Detector_DUT_report.html
### HDL check for 'pulse_detector' complete with 0 errors, 2 warnings, and 4 messages.
### HDL code generation complete.

The optimizations add 96 cycles of latency to the generated model. This increase in added latency is due to the resource sharing area optimizations. Sharing resources for multiple operations serializes the design and as a result, the optimized design requires more clock cycles to produce the output. In this example because there is no requirement to maximize throughput, reducing the area consumed at the cost of added latency is a good trade-off.

The critical path estimated is 6.213 ns, which is slightly larger than without area optimizations applied.

Check if your timing constraints have been met by running the HDL Workflow Advisor through step 4.2.2. The synthesis results show that there is positive slack, which indicates that the timing constraint is met. The clock frequency is now 234 MHz and is higher than the target frequency of 230 MHz.

As indicated by the resource summary, the DSP usage decreased significantly from 28.67% of the DSPs used to 3.67% used. The trade-off for this decrease in area is a minor decrease in clock frequency and a slight increase in the usage of slice LUTs and slice Registers.

Summary

Below is a table summarizing the impact of the HDL optimizations applied in each section.

See Also

|