Improved Adaptive Pipelining (Tech Preview)

R2026b

Since R2026b

Note

Improved adaptive pipelining is a tech preview in R2026b. The behavior, implementation, and interfaces might change before general release. Do not use the optimization in production designs.

To enable the improved adaptive pipelining optimization, run this command at the start of each MATLAB session:

matlab.internal.feature("GlobalAdaptivePipelining",1);

To send feedback about improved adaptive pipelining, email the development team.

When you enable improved adaptive pipelining and generate code, the code generator analyzes the critical path of the design under test (DUT) and inserts pipeline registers at locations where the propagation delay along a path exceeds the timing budget for your target frequency. Use improved adaptive pipelining to help meet timing on your target device without manually placing pipeline registers throughout the design. This topic describes how improved adaptive pipelining works and how to enable it on your design.

How Improved Adaptive Pipelining Works

When you enable improved adaptive pipelining, the optimization:

1. Analyzes the critical path of the design by using critical path estimation (CPE). For more information, see Critical Path Estimation Without Running Synthesis.

2. Determines where the propagation delay exceeds the timing budget for the target frequency.

3. Inserts pipeline registers to break the critical path at those locations. For some operations, the optimization inserts pipeline registers differently. For more information, see Operations with Specialized Pipelining Rules.

4. Re-analyzes the critical path and iterates until the estimated timing meets the target frequency.

Improved adaptive pipelining accounts for other optimizations, such as input and output pipelines, clock-rate pipelining, and design delays, in its timing analysis. For optimizations that conflict with improved adaptive pipelining, see Limitations.

Device Timing Characterization Data

Improved adaptive pipelining depends on the timing characterization data available for your target device. HDL Coder provides default timing characterization databases for several device families. To characterize additional devices, generate a database by using the genhdltdb function. Generating a timing database for your device can result in more accurate critical path analysis and pipeline insertion.

Blocks that appear in the database contribute measured propagation delays to the analysis. Blocks that do not appear in the timing characterization database are analyzed as having a 0 ns propagation delay. If uncharacterized blocks lie on the critical path, improved adaptive pipelining can underestimate the delay and insert too few pipeline stages, and the generated HDL might not meet timing after synthesis. To identify uncharacterized blocks, check the critical path estimation report.

Differences Between Adaptive Pipelining and Improved Adaptive Pipelining

Improved adaptive pipelining changes what HDL Coder pipelines, how it chooses pipeline depth, and how it uses device timing data. This table describes the differences between adaptive pipelining and the improved adaptive pipelining optimization:

Aspect	Adaptive Pipelining	Improved Adaptive Pipelining
Scope	Pipelines only operations that map to DSP.	Pipelines across the design when it is necessary to break the critical path.
Pipeline depth	Looks up the depth from a coarse table indexed by multiplier bit-width tier and DSP count, and selects the minimum pre-characterized depth whose achievable frequency meets the target.	Calculates depth from a critical path analysis at the specified target frequency.
DSP register packing	Selects depth from the per-bitwidth-tier DSP frequency table and uses the synthesis tool to absorb registers into DSP primitives.	Uses per-port propagation-delay data to insert pipeline registers next to the DSP input and output ports, which enables the synthesis tool to absorb them into DSP internal registers.
Target frequency awareness	Uses the target frequency to select a pipeline depth from a coarse bit-width-tier lookup table. Does not adjust register placement to a specific DSP input or output port.	Adjusts pipeline depth and register placement based on the target frequency by using per-port propagation-delay data.
Default device coverage	Supports these device families: AMD Kintex-7 AMD Virtex-7 AMD Zynq One generic Altera family	Supports these device families, with component-level timing data: Artix-7 Cyclone V Kintex-7 Kintex UltraScale PolarFire SoC Stratix V Virtex-7 Zynq Zynq UltraScale+ The Cadence Genus 45nm ASIC library
Operations characterized	Characterizes multiplier operations only, as achievable frequency versus pipeline depth.	Characterizes operations such as add, multiply, multiply-accumulate, logic, relational, shift, and serializer operations.
Timing data	Maximum frequency at each pipeline depth, tabulated by multiplier bit-width tier and DSP count.	Port-level propagation delay in nanoseconds, parameterized by data width, for every characterized component.

Enable Improved Adaptive Pipelining

Improved adaptive pipelining requires timing characterization data for your target device and a target frequency greater than 0 MHz. To enable improved adaptive pipelining on your design:

1. Generate the timing database for your target device. If your target device does not have a default database, or you need to recharacterize your device, generate a database by using the genhdltdb function. For example, to characterize the AMD Zynq UltraScale+ xczu9eg-ffvb1156-2-e device by using AMD Vivado:

   genhdltdb(SynthesisDeviceConfiguration={"Zynq UltraScale+","xczu9eg-ffvb1156-2-e"}, ...
       TimingDatabaseDirectory="C:\Work\Database", ...
       SynthesisToolName="Xilinx Vivado", ...
       SynthesisToolPath="C:\Xilinx\Vivado\2025.1\bin\vivado.bat");

   Note

   If your device family is not included in the default device coverage and you do not generate a custom database, the code generator uses a generic timing database. If the device family is supported, but the speed grade is not, the code generator uses the closest available speed grade.

   Note

   If you generate a custom timing database in a release earlier than R2026b, you must regenerate the databases by using the genhdltdb function.

2. If you generated a timing database, point the model at the output directory so that HDL Coder loads the custom timing data instead of the default databases. Set the Custom Timing Database Directory model configuration parameter to the same path you used for the TimingDatabaseDirectory argument of genhdltdb. For example:

   hdlset_param(model, "TimingDatabaseDirectory", "C:\Work\Database");

3. Configure the model. Set the Target Frequency parameter to a value greater than 0. Set the Synthesis Tool, Family, and Device parameters for your target device. Then, enable improved adaptive pipelining on the DUT subsystem by setting AdaptivePipelining to on.

   hdlset_param(model, "SynthesisTool", "Xilinx Vivado");
   hdlset_param(model, "SynthesisToolChipFamily", "Zynq UltraScale+");
   hdlset_param(model, "SynthesisToolDeviceName", "xczu9eg-ffvb1156-2-e");
   hdlset_param(model, "TargetFrequency", 300);
   hdlset_param(dut, "AdaptivePipelining", "on");

4. Set the latency strategy for fixed-point iterative-algorithm blocks. If the design contains fixed-point iterative-algorithm blocks, such as Sqrt blocks where the Architecture HDL block property is SqrtFunction, Divide blocks where the Architecture property is ShiftAdd, or Trigonometric Function blocks where the Architecture property is Trigonometric, and you previously set LatencyStrategy to a value other than Auto, set the LatencyStrategy HDL block property to Auto on each block so improved adaptive pipelining can size those pipelines to the target frequency.

5. Optionally, exclude subsystems that you do not want improved adaptive pipelining to modify. In the subsystem, set the AdaptivePipelining HDL block property to off.

6. Generate HDL code by using the makehdl function.

   makehdl(dut);

7. Review the results. The MATLAB Command Window reports the number of pipeline registers that the optimization inserted. Open the code generation report to inspect the CPE timing.

8. Iterate, if needed. If the target is not met, check the code generation report for uncharacterized blocks on the critical path. Add manual pipeline registers by setting the InputPipeline or OutputPipeline HDL block properties on those blocks, then rerun the makehdl function.

If results are not as expected, see Troubleshoot Improved Adaptive Pipelining Results (Tech Preview).

Operations with Specialized Pipelining Rules

During improved adaptive pipelining, the optimization inserts pipeline registers on any signal path whose propagation delay exceeds the timing budget for the target frequency. For some operations and blocks the code generator takes additional actions. The tables in this section describe operations that require additional configuration or that follow specialized pipelining rules.

Blocks that Use Fixed-Point Iterative Algorithms

The pipelining behavior of fixed-point iterative algorithm blocks depends on the setting of the LatencyStrategy HDL block property. For these blocks, set the Architecture HDL block property to the specified value so improved adaptive pipelining can pipeline them:

Block	Required Architecture setting
Sqrt	SqrtFunction
Divide	ShiftAdd
Reciprocal	ShiftAdd
Reciprocal Sqrt	RecipSqrtNewtonSingleRate
Trigonometric Function	Trigonometric
Complex to Magnitude-Angle	Cordic
Magnitude-Angle to Complex	Pol2CartCordic
Product, Matrix Multiply	ShiftAdd

For the Reciprocal Sqrt block, this rule applies only when you set the Method block property to Newton-Raphson.

The Trigonometric architecture of the Trigonometric Function block uses a CORDIC approximation and applies to all supported operators, including sin, cos, atan, and atan2.

For these blocks, if you set LatencyStrategy to Auto, the code generator generates code with zero predefined latency and improved adaptive pipelining inserts pipeline stages into the surrounding logic based on critical path analysis for the target device and frequency. When you set LatencyStrategy to a value other than Auto, such as Max, Min, or Custom, improved adaptive pipelining does not adjust the pipeline stages inside the block.

DSP Operations

These operations map to DSP primitives on FPGA devices. Improved adaptive pipelining analyzes the target device DSP characteristics and inserts only the pipeline registers necessary to meet the target frequency.

Operation	Requirements	Behavior
Multiplier blocks	Integer inputs and outputs, a known synthesis tool, and a target frequency greater than 0 MHz.	The critical path estimator searches pipeline depths from 0 to 20 stages and selects the minimum depth that meets the timing budget for the target device and frequency. Registers are packed into the DSP primitive only when needed to meet that budget.
Gain blocks	Integer inputs and outputs, the ConstMultiplierOptimization HDL block property set to none, a gain value that is not a power of 2, a known synthesis tool, and a target frequency greater than 0 MHz.	The critical path estimator searches pipeline depths from 0 to 20 stages and selects the minimum depth that meets the timing budget for the target device and frequency. Registers are packed into the DSP primitive only when needed to meet that budget.
Multiply-Accumulate blocks	Integer inputs and outputs, a known synthesis tool, and a target frequency greater than 0 MHz.	The critical path estimator searches pipeline depths from 0 to 20 stages and selects the minimum depth that meets the timing budget for the target device and frequency. Registers are packed into the DSP primitive only when needed to meet that budget.

The code generator generates power-of-2 gains as fixed-shift operations which do not require DSP resources.

Operations That Require Manual Pipelining

For some operations, improved adaptive pipelining does not insert pipeline stages:

• Blocks that are not characterized in the timing database.

• Blocks with floating-point inputs or outputs.

• Native floating-point and vendor floating-point IP architectures.

• Gain blocks with the ConstMultiplierOptimization HDL block property set to a value other than none, such as csd or fcsd.

• Fixed-point iterative algorithm blocks where the LatencyStrategy HDL block property is a value other than Auto.

If these operations appear on the critical path, use the InputPipeline or OutputPipeline HDL block properties to add manual pipelines. For troubleshooting guidance, see Troubleshoot Improved Adaptive Pipelining Results (Tech Preview).

Limitations

• MATLAB-to-HDL code generation is not supported in this Tech Preview.

• The optimization does not support specifying an upper bound for the total latency. Improved adaptive pipelining inserts as many pipeline stages as needed to meet the target frequency.

• For each DSP operation, such as a multiplier, gain, or multiply-accumulate, the critical path estimator searches pipeline depths from 0 to 20 stages. Operations that need more than 20 stages to meet the target frequency at the selected device might not meet timing requirements.

• Pipelining floating-point IP is not supported. Improved adaptive pipelining does not pipeline native floating-point IP and vendor floating-point IP.

• Using distributed pipelining with improved adaptive pipelining is not recommended in designs that have feedback loops. Distributed pipelining can obscure the design delay that improved adaptive pipelining uses to insert registers, which can lead to excessive latency that does not meet the target frequency. Feed-forward paths that combine both optimizations are supported.