Kintex UltraScale KCU1500 Acceleration Development Board
49
UG1234 (v2017.1) June 20, 2017
www.xilinx.com
Chapter 6:
Install, Bring-Up, and Use
Timing Closure
The platform contains many clock domains. With the exception of setup violations on the
kernel clock domain (and if used, also kernel clock 2 domain) intra-clock paths, all paths
must meet timing with each compiler run. Failure to do so results in the flow reporting a
timing failure and not producing an .
xclbin
file.
In the event that only kernel clock paths do not meet their timing requirement and contain
only setup violations, the flow will report a message similar to the following:
WARNING: [XOCC 60-732] Link warning: One or more timing paths failed timing targeting
300 MHz. This design may not work properly on the board with this target frequency.
The frequency is being automatically changed to 240 MHz
When the application is executed, the SDAccel runtime will automatically change the
operating frequency of the kernel clock to the reported lower frequency in order to
compensate for the setup violation. This automatic frequency scaling feature allows user
kernels to operate in hardware, even if at a lower frequency than intended.
As described in
Expanded Partial Reconfiguration in Chapter 2
, each compiler run places
and routes user kernels together with the remainder of the logic in the reconfigurable
expanded region. While expanded partial reconfiguration has clear benefits, a potential
side effect of the approach is that paths in clock domains other than the kernel clock can
sometimes fail their timing requirement if there are significant kernel timing violations. This
behavior is simply a result of how the Vivado tools prioritize timing closure of critical paths.
The likelihood of such violations, which prevent
.xclbin
generation, is reduced through
the use of
HIGH_PRIORITY
clock properties as described in
Design Constraints Detail in
Chapter 5
.
To reduce the likelihood of large kernel timing violations affecting other paths and thus
preventing automatic frequency scaling, users are advised to specify an achievable kernel
clock frequency if all kernel logic is not likely to meet the default of 300 MHz - a process
which might be iterative. For example, if a user kernel is likely to achieve timing closure at
a maximum of 150 MHz, you should specify such a frequency target:
--kernel_frequency 150
In this way, kernel developers can decouple preliminary hardware operation from
optimization of kernel code to achieve higher frequencies.
Send Feedback
