FPGA Timing Closure for Congested Test & Measurement Designs - A Machine Learning Solution

FPGAs are widely used in the Test and Measurement (T&M) industry for their capabilities in high-speed signal processing, high precision data processing, and general design flexibility. As market demand for faster and more precise instrumentation increases, T&M FPGA designs also become more complex and more challenging in terms of timing closure – directly impacting Time-to-Market.

This article discusses how a new design optimization approach known as the InTime Timing Closure Methodology was recently used to increase the FMax, as well as to optimize and close timing for five large, routing-congested T&M designs within a week. Based on machine learning, this new approach is baked into the InTime design optimization software tool.

Design Background

Device: Xilinx Virtex Ultrascale xcvu190

Although FPGA resource utilization was relatively low, numerous SLR crossings and high routing congestion make it difficult to reduce the number of failing paths in these designs. The estimated routing congestion for one of the T&M designs:

INFO: [Route 35-449] Initial Estimated Congestion
|           | Global Congestion | Long Congestion   | Short Congestion  |
|           |___________________|___________________|___________________|
| Direction | Size   | % Tiles  | Size   | % Tiles  | Size   | % Tiles  |
|      NORTH|   64x64|      3.53|   32x32|      6.04|   64x64|      6.29|
|      SOUTH|   64x64|      6.64|   64x64|      8.08|   64x64|      8.43|
|       EAST|   32x32|      2.41|   16x16|      1.85|   32x32|      6.72|
|       WEST|   64x64|      4.26|   32x32|      2.92| 128x128|     14.73|

Before & After InTime Optimization

Here are the FMax Improvements.  You can see that there are between 23% to 79.7% improvements in FMax using this method.



Project Name WNS (Before) WNS (After) TNS (Before) TNS (After) WNS Improvements TNS
FMax (Before) FMax (After)
A -0.854 -0.217 -16961.285 -582.23 74.59% 96.57% 298.15 368.05
B -0.984 -0.141 -9496.21 -127.48 85.67% 98.66% 287.03 378.64
C -1.593 -0.063 -1972.426 -6.406 96.05% 99.68% 244.32 390.17
D -1.679 -0.043 -21123.871 -0.137 97.44% 100.00% 239.29 393.24
E -2.0 -0.006 -72974.359 -0.006 99.70% 100.00% 222.22 399.04

* Rounded up to 3 decimal places

Massive Productivity Gain – Results in 6 days

Although not all designs closed timing, this approach can significantly increase the FMax and improve the timing results in an automated fashion. The builds were accelerated through cloud computing (AWS) and the entire optimization process was driven by the InTime software. All five designs were optimized at the same time in only six days. Compared to solely focusing on iterative improvements, this represents a massive productivity gain for the entire organization.

  • Actual Wait Time: 1.32 to 6.24 days
  • Average Cloud Hours / Project: 957 hours
  • Server Type: 4 CPU, 31 Gb RAM

How to optimize routing-congested designs – InTime Timing Closure Methodology

Under the InTime Timing Closure Methodology, the build process is no longer a one-designer-to-one-machine operation. Instead, it is a systematic series of calculated steps done by one or many designers on multiple build machines. From the resulting analysis, InTime deduces and recommends sets of good build parameters aimed at improving design performance.

Explore Build Parameters

Routing congestion was a significant bottleneck for the five projects mentioned above. With this in mind, one approach was to explore relevant synthesis build parameters on all the designs. As this is a machine learning-driven software, multiple builds were necessary to generate data points for analysis. InTime is able to leverage on the compute resources in the cloud, running up to 200 servers concurrently for 12 hours, massively accelerating turnaround and time to results.

InTime learning cycle - FPGA timing closure

Note: In Vivado, there are more than 30 build parameters, making up more than 1 billion different combinations. A classic brute-force approach will not work and will be terribly inefficient. At the other end of the spectrum, using a traditional iterative “change RTL, Build again and Repeat” is too time-consuming.

Fortunately, cloud computing has commoditized compute power into CPU-hours, and through InTime’s disciplined process and methodology, InTime is able to converge onto good results efficiently. It takes between 26 to 414 builds to achieve the results shown above. Comparing with more than 1 billion combinations, this is a tiny number. This is possible as InTime runs with a trained database that accumulates all the previous analysis from a diverse pool of designs.

Optimize Placement

Another key to optimizing a routing-congested design is to ensure good design placement. InTime has a “Placement Exploration” strategy akin to the old “Cost Tables” for ISE or Seed Sweep approach. This strategy is extremely effective for designs with negative slacks in the hundreds of picoseconds. It does not affect functionality and is safe and easy to use for timing closure.

Will this work for your design? Minimizing Risk and Increasing Chances of Meeting Timing

If you are uncertain about whether this approach will work for your design, you are more than welcome to take a free evaluation of InTime.

Please refer to the methodology guide section on results convergence. There are specific guidelines to check the likelihood of meeting timing for any design in general. Additionally, other tips such as how to reduce turnaround time for your builds may be helpful.

The other alternative is to consider InTime Service. InTime Service is a completely risk-free approach where Plunify helps you to ascertain if the design can be optimized to your requirements.

For more information about InTime, please subscribe to our blog at https://blog.plunify.com or contact us at tellus@plunify.com.  A copy of the methodology guide can be downloaded here.