Intel® Hyperflex™ Architecture High-Performance Design Handbook

ID 683353
Date 10/04/2021

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents Step 2: Instantiate the Variable Latency Module

You can use the Fast Forward Compilation feature to help identify suitable locations for automatic pipeline insertion. The following locations are typically suitable for automatic pipeline insertion:
  • Clock boundaries that are transferring constantly changing data allow the Fitter to spread the blocks far apart when advantageous.
  • Locations adjacent to a complex combinational function are suitable for a function that has trouble meeting timing.
  • Locations between two independent functional blocks on the same clock domain allow the Fitter to spread the blocks far apart when advantageous.

Instantiating Variable Latency at Clock Domain Boundaries

Fast Forward Compilation recommends adding pipeline stages at clock domain boundaries, where additional latency can be simple to accommodate. Instantiating variable latency at clock boundaries allows the Fitter to spread these blocks far apart when advantageous. In such cases, you can simply instantiate the hyperpipe_vlat module either before or after a synchronizer or FIFO. Instantiate hyperpipe_vlat with no other registers or logic between the comb function and hyperpipe_vlat, with respect to netlist connectivity.

This instantiation allows the Hyper-Retimer to automatically insert just enough pipeline registers to meet the timing requirement. A latency-insensitive false path is inappropriate in this case because the data is constantly changing.

Instantiating Variable Latency Adjacent to Complex Combinational Functions

You can instantiate the hyperpipe_vlat module adjacent to a complex combinational module to allow the Hyper-Retimer to insert just enough registers to meet the timing requirement. Instantiate the hyperpipe_vlat module after the complex combinational module because backwards retiming does not require additional reset cycles to accommodate any initial conditions. You cannot control whether a register in the hyperpipe_vlat module retimes forward, into the logic following it, or backward, into the combinational module.

Instantiating Variable Latency Between Independent Functional Blocks

You can instantiate the hyperpipe_vlat module between two independent functional blocks in the same clock domain. This instantiation allows the functional blocks to spread apart during placement, while only adding the number of pipeline stages between the blocks necessary to meet the timing requirements.

Note: Do not place the variable latency module directly adjacent to a partition boundary. Rather, place a register between the latency module and the partition port to separate them. The variable latency module does not autopipeline during retiming if you place the hyperpipe_vlat module immediately adjacent to a partition boundary, as Improper Variable Latency Module Placement Prevents Autopipelining shows.
Figure 37. Improper Variable Latency Module Placement Prevents Autopipelining
Figure 38. Place Registers Between Variable Latency Module and Partition to Allow Autopipelining

Applying False Path or Exception Constraints

If instantiating the hyperpipe_vlat module between independent functional blocks, you must add a false path (set_false_path) or other timing exception to allow the connected blocks to float apart during placement. You apply the false path or exception to the vlat_r register in the hyperpipe_vlat module. By placing the timing exception within a conditional if statement, the Timing Analyzer does not use the exception when the vlat adds registers, nor during final timing sign-off, ensuring each register meets the clock requirement.

Without the corresponding false path or exception constraint, hyperpipe_vlat provides little benefit. Without a false path or exception constraint, the Hyper-Retimer only recognizes a single pipeline stage in hyperpipe_vlat during placement and routing. The Hyper-Retimer only adds the additional pipeline stages after placement and routing completes. The Compiler tends to place two functional blocks connected by a single pipeline stage close together, unless the paths between them are cut.

The following lines show the appropriate .sdc syntax to apply a set_false_path exception for the hyperpipe_vlat instance at my|top|design|hyperpipe_vlat_inst. Add similar lines to your .sdc for any hyperpipe_vlat instances that connect to independent functional blocks:

if { ! [is_post_route] } {
     set_false_path -to my|top|design|hyperpipe_vlat_inst|vlat_r[*]}

Furthermore, if you limit the number of pipelines with the MAX_PIPE parameter, consider applying the max_delay or multicycle exception, rather than a set_false_path exception. If there is a MAX_PIPE constraint on the vlat instance, then a set_false_path exception may move the logic so far away, that the MAX_PIPE constraint is insufficient. For this reason, the multicycle exception is better. For example, If NUM_PIPES=3, you can add a multicycle exception equal to NUM_PIPES(3).

if {![is_post_route]} {
set_multicycle_path -setup –to my|top|design|hyperpipe_vlat_inst|vlat_r[*] 3
set_multicycle_path –hold –to my|top|design|hyperpipe_vlat_inst|vlat_r[*] 2}

Apply Variable Latency Constraints -from or -to

You can use the variable latency module to add Hyper-Registers forward or backward in the register chain. Use the following constraint methods when pushing registers through combinational logic:
  • -from—place vlat_r before combinational logic that you want to pipeline, then apply the multicycle or false path –from constraint.
    Figure 39. Inserting vlat_hr Before Combinational Logic
  • -to—place vlat_r after combinational logic that you want to pipeline, then apply the multicycle or false path –to constraint
    Figure 40. Inserting vlat_r After Combinational Logic