At the beginning of 2017, we published an article about running "seeds" in Vivado - Who Says You Can’t Use Random Seeds In Vivado? Although Vivado does not support the "placement cost table" feature, InTime has a feature called "Placement Exploration", which enables similar behavior without any impact on functionality. In this post, we are going to showcase results from customer designs, understand the impact of this placement recipe and how it can help you.
What is "Placement Exploration" recipe?
To recap for our users and for new readers, Placement Exploration is a strategy to randomize non-critical register location. This enables Vivado to explore more opportunities, apply difference placement and routing calculations to give different results without changing the design functionality.
How this works
This recipe requires the design to have some non-critical cells (cells have met timing path) and some unused slices in the targeted device. The more unused slices in the design, the more combinations of the run can be created, hence increase the randomization and possibilities of getting better results.
If the requirements are not fulfilled, user will get following error when running the recipe:
In this case, you might need to review the design to see if there are no false path (for the InTime version before 2.2.1) or a low number of available free slice for the device. If it is due to no false path, you might want to check whether false path can be set for the design. To understand how to use this recipe, please refer to the application note here.
The Yummy Parts: Results from Real Designs
Project 1
- Device: xcvu190
- TNS (ns) : -5841.436
- WNS (ns): -0.725
- WHS (ns): 0.016
- CLB Utilization (%): 80.15
- Run Time: 04:46
| Job | TNS (ns) | WNS (ns) | WHS (ns) | CLB Utilization (%) | Run Time |
| hotstart | -3811.77 | -0.417 | 0.016 | 86.32 | 08:28 |
| placement | -1124.92 | -0.237 | 0.016 | 78.27 | 09:26 |
The design was optimized in 2 rounds. Each round has between 20-30 compilations and results. For placement exploration, we will pick the best WNS result from the previous round, in this case, -0.417ns and set it as the "parent" for exploration. In the chart (log) below, you can see that as a result of the "seed" effect, the WNS has a wide distribution of values. The median is -0.694ns and for the best WNS result, it is a huge 0.457ns difference. If you compare the best WNS result from the placement exploration with the previous round, the WNS improvement is a hefty 43%.
Figure 1: TNS box plot
Figure 2: WNS box plot
Project 2:
- Device: xcvu190-flgb2104
- TNS (ns) : -10229.035
- WNS (ns): -1.203
- WHS (ns): 0.016
- CLB Utilization (%): 75.71
- Run Time: 04:33
| Job | TNS (ns) | WNS (ns) | WHS (ns) | CLB Utilization (%) | Run Time |
| hotstart | -2899.34 | -0.404 | 0.016 | 75.88 | 07:57 |
| placement | -770.995 | -0.187 | 0.016 | 67.5 | 09:08 |
Similar to project 1, there were 2 rounds of optimization. In the first round, the aim is to get the best WNS. Using the best WNS result (-0.404) of the previous round, we ran a round of placement exploration. Based on the results of the placement exploration, the median is -0.512ns. The best result is -0.187ns and is a 325ps or a whopping 53% improvement over the original parent result.
Figure 3: Project 2 TNS
Figure 4: Project 2 WNS
Takeaways
The results speak for themselves. If you are battling with that final 300ps, you might want to think about using this method for that milestone or deadline.
The last thing you need to remember is that it takes computing power and run time to do these extra runs. The best way to do this is to use the cloud either via your own cloud provider or register an account at Plunify Cloud. If you are interested to try InTime, please send us a request here.