One of the most time-consuming elements of implementing an FPGA design is not often the design capture, but achieving the necessary timing performance. To achieve the required timing closure, we may need to adjust the design by inserting pipeline stages and using constraints to correctly define the clocks, their relationship, and even the location of logic elements.
Vivado has many capabilities which can be used to help us understand our design’s implementation as well as the challenges it can present in implementation. One of these tools is the Design Analysis Report which enables the user to understand the design challenges (e.g., congestion) and make changes to the design or constraints.
The Design Analysis Report can be generated with the implementation view opened in the GUI or via the TCL console. It will provide information on the following:
Timing – Provides information on the timing and physical characteristics of timing paths.
Complexity – Provides information on routing complexity and LUT distribution.
Congestion – Provides information on routing congestion.
Let’s take a look at running the report on an example design (e.g., my recent IR communication project). This project has a MicroBlaze processor, DDR memory interface, and a custom RTL module.
Using the Report Design Analysis dialog, we can configure the Timing analysis to provide only setup (max) or hold information (min) or both setup and hold (min_max).
We can also select the maximum number of paths for the timing report. In this example, I reported ten worst setup and hold paths. On the Timer Settings tab, if desired, we can select the interconnect timing, device speed grade, and multi-corner configuration.
One remarkably interesting option is to set the logic level distribution option in the timing. This option will report on the number of logic levels binned against the clock.
By clicking on the specific bin, we can open the timing paths and obtain more information on a specific timing path.
Reporting timing paths will provide detailed information on the timing paths with the selected number of logic levels.
To gain further information on a timing path, we can then generate more detailed timing reports on specific paths from a start to end point.
As would be expected, the timing report provides a wealth of information, including:
Path Requirements – Path requirements below 2 ns are difficult to meet especially on older devices. Path requirements below 4 ns must also be carefully considered.
Data Path – If the logic delay is greater than 50% of the total delay, the designer needs to examine the data path logic depth and cell type. Corrections to the logic delay require a modification of the RTL or synthesis options. If the net delay dominates the routing, the physical characteristics should be examined (e.g. high fan-out).
Logical Path – Checks for endpoints such as CLR, PRE, RDT and CE which are potentially high fan-out nets resulting from control structures. Checks that DSP and BRAM have output registers to improve timing performance.
Physical – Checks for crossing of IO columns or SLR boundaries which result in high net delay or large skew. This also checks for over aggressive placement restrictions caused by excessive floor planning.
Properties – Checks properties used in the design including LUT combining, which saves logic utilization but can also increase congestion.
The complexity analysis will report the rent exponent, average fan-out, and the distribution of leaf cells. If you are not familiar with the rent exponent, it is the relationship between the number of ports and cells of a netlist partition. In the Design Analysis Report, the rent exponent and the fan-out indicates the complexity of the design and potential for implementation problems.
If the rent exponent is below 0.65 and the fan-out is below 4, the design is considered low risk and implementation problems are not expected. Between 0.65 and 0.85 and a fan-out between 4 and 5, the complexity is considered high and the design may be difficult to place without congestion. A very high design complexity has a rent exponent above 0.85 and a fan-out about 5. In this situation the design can potentially fail during implementation.
In this example, the rent exponent is below 0.65 and fan-out is below 4. Therefore, the design should be expected to implement without any issue as was the case here.
The final element of the design analysis is the congestion report. This will show the congestion in the CLB tiles. Congestion can lead to timing issues when critical paths are in a congested area.
Congestion is reported in eight levels. Level 3 or less is not a concern unless the timing requirements are tight. Level 4 – 5 is likely to lead to issues in timing closure and additional techniques might be required (e.g., spread logic strategies).
If the congestion is greater than 6, the design is likely not to meet timing and may not implement.
Using the Design Analysis Report, we can explore areas of our design which may cause issues when we try to achieve timing closure by adjusting the RTL, constraints, or tool settings. The Design Analysis Report provides us with a gentle pointer in the right direction to ensure our efforts have the best results.
However, some of these issues can be implemented automatically by the Quality or Result Suggestions, which we will examine next time.
See My FPGA / SoC Projects: Adam Taylor on Hackster.io
Get the Code: ATaylorCEngFIET (Adam Taylor)