AR# 61599

描述

Are Vivado results repeatable for identical tool inputs?

解决方案

For the most part the answer is yes, Vivado should generate identical results between runs involving identical:

• Design sources
• Constraints
• Tcl scripts and command sequences
• Tool and command options
• Vivado software version
• Operating Systems

This applies to all parts of the design flow from HDL synthesis through bitstream generation. For example a build script should generate identical results when run repeatedly on the same system or when run on a similarly configured machine.

Results between different Operating Systems are generally repeatable but not guaranteed, particularly in the case of Linux vs. Windows.

Known Exceptions

Some flows and tool options do not guarantee repeatability. These include:

• route_design -ultrathreads option: this option trades repeatability for faster compilation.
• place_design -ultrathreads option: this option enables per-SLR multithreading for placement with a potentially different result compared to placement without the -ultrathreads option.
  The maximum number of threads, assigned using "set_param general.maxThreads" can also affect repeatability when using place_design -ultrathreads.
  If the maximum number of threads is less than the number of device SLRs, the per-SLR multithreading is disabled, giving a different result compared to placement with the maximum number of threads greater than to or equal to the number of device SLRs.
  Note that as of the 2020.2 release, place_design -ultrathreads is enabled by default when using the placer default settings or the directive options RuntimeOptimized and Quick. Additional directives might enable ultrathreads in a future release.
• Loading a routed design checkpoint (DCP) and running post-route phys_opt_design might give different results compared to running post-route phys_opt_design immediately after route_design with the design already in memory in Vivado.

Identifying repeatability issues

The most common symptoms of divergent runs are different post-route timing results. If you suspect a case of non-repeatability and have verified that the tool inputs are identical, you can further verify divergence using checksums.

Vivado reports a checksum in the log at each intermediate stage of each implementation command, a signature based on the design netlist and physical data.

Checksums can be compared between different runs and checksum mismatches help identify where results diverge.

Example: The checksums below begin to diverge and thereafter never converge. If all inputs are identical then this is likely a repeatability issue.

Checkpoints vs in-memory runs

Checkpoints should produce repeatable results compared to the equivalent in-memory design flow. Consider the following command sequences, one running the entire design flow in memory and the other re-entering the flow at phys_opt_design using the placed checkpoint from the in-memory flow.

These two runs should give identical results. Although checksums might differ due to netlist sorting differences after the open_checkpoint command, checksums should converge after the first implementation command which is phys_opt_design:

Each implementation command automatically sorts the netlist before running to ensure netlist consistency, so that results do not diverge due to netlist differences. There might be rare cases where results diverge between in-memory and checkpoint flows but results are repeatable between the two.

Reporting Non-Repeatability

If you encounter non-repeatability with identical inputs as described in the Solution introduction, please open a Service Request and provide a test case that demonstrates the problem.

Without a test case it might be difficult to pinpoint and fix any problems but it helps to supply as much information as possible.

Non-repeatability between Linux and Windows is expected to occur occasionally and the recommended solution is to restrict Vivado runs to Linux-only or Windows-only.

Work-arounds for Non-Repeatability

If you encounter a non-repeatability issue and repeatability is absolutely critical to your design environment, the following can help maximize repeatability:

Running in single-threaded mode.

When using different number of CPUs between runs, simultaneous threads might execute operations in different orders and cause diverging results, even when run using the same machine and OS.

To run in single-threaded mode, use the following:

set_param general.maxThreads 1

This disables multithreading and eliminates associated repeatability issues.

Eliminate known sources of non-repeatability

Refer to the earlier section on Known Exceptions to repeatability and ensure that none of those situations are present.

Running on the same machine or running on machines using the same OS.

This reduces the chances of encountering non-repeatability due to the way core functions and system calls are implemented from one operating system to another, especially in the case of Windows vs. Linux.

The chances are further reduced by

1) Fine-tuning the environment to eliminate all of the following scenarios:

• Different versions of the same operating system
• Different service pack levels (Windows)
• Different distributions or different patch levels (Linux)

2) Eliminating differences in computing hardware:

• Use the same general physical and virtual memory capacity.
• Use the same processor architectures and same number of cores.
• If using virtual machines, ensure that you are using identical configurations.