For C and C++ designs only a single clock is supported. The same clock is applied to all functions in the design.
The clock period, specified in nanoseconds (ns) or MHz, is defined when the HLS components is created, or can be changed in the HLS config file under the General category as shown below.
The default clock period is 10 ns. The HLS component also uses the concept of a clock uncertainty to provide a user defined timing margin for scheduling processes within the design. You can define the clock uncertainty for your design in the same way and at the same time as you specify the clock. The default clock uncertainty, when it is not specified, is 27% of the clock period.
platform= instead of part= you must use also freqhz= instead of clock=. This is
because the platform specifies a clock in freqhz form, and you can only
override it using the same form. Using the clock frequency and part information for the HLS component the tool estimates the timing of operations in the design. However, it cannot know the final component placement and net routing as these operations are performed by logic synthesis of the output RTL. As such, the tool can only estimated delays.
To calculate the clock period used for synthesis the tool subtracts the clock uncertainty from the clock period, as shown in the following figure.
This provides a user specified margin to ensure downstream processes, such as logic synthesis and place & route, have enough timing margin to complete their operations. If the resources of the device are mostly consumed by the HLS componet the placement of cells and routing of nets to connect the cells might tight and result in a design with larger than expected timing delays. For situations such as this increasing the clock uncertainty can ensure that the HLS component does not create a design with too much logic packed into each clock cycle and allows RTL synthesis to satisfy timing in cases with less than ideal placement and routing options.
The Vitis unified IDE and v++ command tries to
satisfy all constraints: timing, throughput, latency. However, if a constraint cannot be
satisfied the tool still produces an RTL design. If the timing constraints inferred by
the clock period cannot be met the tool issues message SCHED-644 as shown below, and creates a design with the best achievable
performance.
@W [SCHED-644] Max operation delay (<operation_name> 2.39ns) exceeds the effective
cycle time
A design report is generated for each function in the hierarchy when synthesis completes and can be viewed in the solution reports folder. The worse case timing for the entire design is reported as the worst case in each function report. There is no need to review every report in the hierarchy.
If the timing violations are too severe to be further optimized and corrected by downstream processes, review the techniques for specifying an exact latency and specifying exact implementation cores before considering a faster target technology.