UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 

Saving Compile Time Series 3: Using Incremental Synthesis

Xilinx Employee
Xilinx Employee
6 0 332

The Incremental Synthesis Flow:

Incremental synthesis works in a similar manner to the incremental implementation flow, but it only works for the synthesis phase, and will not guide the implementation phases which follow it.

A standalone synthesis reference file (post-synthesis DCP) is required, so you will need to complete an initial synthesis run to get the first post-synthesis DCP file. For the incremental runs, unchanged parts of the design are reused and only changed portions are resynthesized. The reused portions are preserved at the partition level.

You can find more information about how those portions are preserved in this blog entry:

https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Vivado-Incremental-Synthesis-Flow/ba-p/976545

The chart below shows a non-project flow with scripts:

blog3-1.png

Figure: Incremental Flow chart

There are two methods supported for specifying the reference checkpoint in the GUI:

  • Using an automatic incremental reference checkpoint (currently only supported in the GUI)
  • Using a user specified reference checkpoint

To enable the automatic mode in Project mode, open the synthesis settings, and check the “Automatically use the checkpoint from the previous run” option.

In this mode, the synthesis run will automatically copy the recent post-synthesis netlist into the local <project directory>/project.srcs/utils_1/import/design area of the project directory.

After the flow completes, the new routed checkpoint is ready to be used as a reference for the next run and will be updated when the run is reset.  If the automatic mode is not checked, the user specified DCP can also be entered as a reference checkpoint to guide the next runs.

blog3-2.png

Figure: Design Run Setting

When to adopt this flow

When your design size is greater than 50K instances, it is always recommended to enable this flow. If the design is too small, the incremental mode will be ignored and the design will be run in normal flow, as the potential improvement would not be great enough.

The average improvement for synthesis runs great than 20 minutes with the incremental synthesis flow is 2.06x.  The figure below shows the speedup trend across 26 big designs, and the compile time saving can be up to 4x with a limited amount of design changes.

The time spent for each design shown in the table also demonstrates that the longer the reference run is, the more likely you are to get more time reduction in the incremental run, given the small design changes. So this flow is especially beneficial for big designs. 

It is suggested that you always have auto mode enabled for incremental synthesis on large designs. However, to use incremental synthesis right away, there must be synthesis data written to the reference checkpoint. This is achieved using the write_checkpoint -incremental_synth switch.

blog3-3.pngblog3-4.png

Figure: Compile time Speedup across some example designs

 

The attached getSynStepsRunTime.sh script can be used to generate a profiling table for the time for each phase of synth_design.

To run the script, you can use this command as in the example below and generate a table for both initial and incremental runs. The actual and phase columns list the time and cumulative time spent for each phase.

getSynStepsRunTime.sh ./vivado.log

synthtime.PNG

During the incremental synthesis run, the steps RTL Optimization, Area Optimization, Timing Optimization, and Technology Mapping will have a shorter compile time compared to the reference run.

The table below shows an example user design. Note the time spent for each synthesis phase in the reference run and incremental run. As these phases contribute most of the reference compile time, they disproportionately impact overall runtime.

Compile Time

Reference Run(seconds)

Incremental Synthesis Run(seconds)

RTL Optimization

51

9

Area Optimization

478

53

Timing Optimization

76

16

Technology Mapping

202

15

Other phases

611

502

 

Other phases like RTL Elaboration, Constraint Validation, Applying XDC Timing Constraints, I/O Insertion, Global Opt, Netlist Generation and other stitching phases will see less time improvement during incremental synthesis.

Note: the out-of-context flow works in a different way, making the submodules work like individual IPs, and so needs more manual intervention like creating a module wrapper and constraints scoping. It can also help improve compile time, and it is particularly good when you have a large module that is static and does not change, saving you the time of optimizing that specific module.

Factors that can affect incremental synthesis

Before adopting this flow, several things can help to get the most out of the incremental flow:

  • Choose the right checkpoint. You need to make sure that the reference checkpoint is at the same part as in the design to be guided, and it is synthesized by the same Vivado release as the current run. DCPs generated by a different release are not supported. Most importantly, the reference DCP must be generated in the same session that synthesis was run in and be created with the -incremental_synth switch during write_checkpoint.
  • The synth_design settings should always be kept the same, and the timing constraints should be kept consistent.
  • Limit the number of genomes you impact and cross boundary optimizations, to ensure design closure consistency and timing closure. Too much change to the design logic (>50%) could lead to more impacted modules needing to be resynthesized, resulting in longer compile time or a poor guiding result.
    Also, if the small design changes introduce new timing problems that did not exist in the reference design, more effort and run time might be required, and the design might not meet timing. The following figure shows how the M1 and M3 modules are re-synthesized if the inter module paths are changed due to cross boundary optimization.
    Keep changes in a single individual module if possible, or any changed or dissolved partitions will need to be re-synthesized. Also to prevent cross boundary optimization from happening, you can use the PRESERVE_BOUNDARY property on the hierarchy module name if you have already registered the in/out module ports. For example:
set_property BLOCK_SYNTH.PRESERVE_BOUNDARY 1 [get_cells [list {M1 M3}]]

blog3-5.png

Figure: Synthesis Reference run vs. Incremental run with cross module optimization

  • If a design module is instantiated multiple times in a design, any small changes in the module could have a big impact on the module’s instantiation times. So in this case, it’s necessary to consider the total amount of design change.
  • Big designs will always benefit more from incremental synthesis in terms of potential compile time reduction than small designs.

 

Generate the incremental compile time saving report


The synthesis run log includes the details of the netlist reuse percentage.

In this example, only a small instance is modified, and if changes happen in a sub-module, the module name will also be listed in the table.

blog3-6.png

Summary


We can achieve fast iteration of synthesis runs by adopting the incremental synthesis flow. It is easy to set up and beneficial for design consistency and compile time reduction. More details can be found in (UG901).