{"id":3111,"date":"2018-03-20T09:02:27","date_gmt":"2018-03-20T09:02:27","guid":{"rendered":"https:\/\/support.plunify.com\/en\/?p=3111"},"modified":"2018-08-28T03:23:38","modified_gmt":"2018-08-28T03:23:38","slug":"how-to-reduce-your-build-time-by-50","status":"publish","type":"post","link":"https:\/\/support.plunify.com\/en\/2018\/03\/20\/how-to-reduce-your-build-time-by-50\/","title":{"rendered":"How To Reduce Your FPGA Build Time By 50%"},"content":{"rendered":"

The New InTime<\/h2>\n

Since day one, every customer has been hoping that we can magically reduce their designs' compile times. Sadly, (and for the umpteenth time!) we can't - that is still the domain of the FPGA tool makers.\u00a0 However, what we as users can do, is learn how to quickly abandon builds with poor results and thus save time.<\/p>\n

The key is to use timing estimates. This is how to do it with the InTime software.<\/p>\n

Progressive Estimation Accuracy<\/h2>\n

Back in 2015, I remember reading a \"Club Vivado\" presentation<\/a> that mentioned \"Progress Estimation Accuracy<\/em>\" on slide 6. The bullet seemed innocuous yet was telling in its brevity:<\/p>\n

\"As stages progress from pre-synth to final route \u201csignoff\u201d<\/em>\"<\/p><\/blockquote>\n

Our interpretation is it implied that the estimated timing summary reported by Vivado would get more and more accurate as it went from synthesis to routing. That does sound pretty intuitive and logical, right? The idea is that with good timing estimates, you can roughly know how well (or not) the design's timing is doing. For example, a difference in post-synthesis estimates after an RTL change can mean that, \"Okay, that RTL change worsened timing by -0.5ns in Worst Slack after synthesis, so I probably should stop compiling and fix the RTL first.\"<\/p>\n

How do we use similar observations to further reduce our build times?<\/p>\n

Understanding Timing Estimates<\/h2>\n

To understand how timing estimates behave, we use a project targeting a\u00a0xcvu190 device<\/a> as an example.<\/p>\n

\"xcvu190\"<\/p>\n

This 2-million CLB flip-flop device is not a small one. The design itself clocks -1.5ns off the target period and we use InTime <\/a>to optimize it. Each compilation typically takes up to 12 hours.<\/p>\n

Timing Estimates Snapshot<\/h3>\n

The following chart shows a snapshot of the timing estimates for 14 out of 35 builds of this project. These 35 builds were generated by the Explorer recipe in InTime and go through synthesis all the way to routing as usual. Each time Vivado can report timing estimates, InTime captures the data and collates it.<\/p>\n

\"estimates\"<\/p>\n

The X-axis enumerates all the timing estimates and the Y-axis shows the Worst Negative Slack (WNS). Some builds have more data points as they use different compiler settings, like \"-directive Explore\" or additional iterative optimization steps.<\/p>\n

You will immediately notice 2 patterns.<\/p>\n

    \n
  1. There are noticeable troughs - 2 bigger and 1 smaller (usually).<\/strong>
    \nA dip in WNS indicates a worsening timing estimate. (Note: The 2 initial dips are actually due to duplicate logging lines<\/span> in the reports caused by how InTime runs Vivado, so treat them as the same data-point).\u00a0The initial dip usually happens after placement and improves after a \"replication\" phase. Based on our data, if the hold timing seems poor, the trough is generally deeper. (Xilinx or some tool expert out there can probably explain this better)<\/li>\n
  2. Timing estimates mostly improved as the compilation progressed, except for that 1 build.<\/strong>
    \nNotice that \"explore_25\" is the outlier. Despite 'recovering' from the initial troughs, it just got worse and worse. For the rest, the lines trend upwards.<\/li>\n<\/ol>\n

    Where and when to stop a build<\/h3>\n

    Here comes the interesting part; Based on the chart below, it seems like post-placement values are good indicators of eventual timing performance. Tracing individual \"explorer_N\" data-points, you can see how post-placement timing estimates started off badly, as indicated by the blue arrows. They improved gradually and became the results marked by the red arrows. The orange arrows show the best performing build. The chart shows clearly that you need a good post-placement estimate to consistently predict the final outcome. The key here is consistency<\/strong><\/span>.<\/p>\n

    \"estimates_wns_improve\"<\/p>\n

    Therefore you can adopt a strategy of stopping a build if it fails a certain WNS or Total Negative Slack (TNS) threshold - shaving almost 50% off your build time in many cases<\/span><\/strong>! That means getting to run 2x the number of compilations within the same period of time. It also means that InTime is able to learn and explore twice the number of settings. Everything becomes 2x more effective for you.<\/p>\n

    How about estimates at other stages?<\/h3>\n

    Why not save even more time by using earlier timing estimates, like post-synthesis ones? Intuitively, post-synthesis timing estimates are inaccurate. We compare the numbers as shown in the table below.<\/p>\n

    The first row contains post-synthesis estimates; however, 8 out of 14 results actually have the same WNS values, rendering post-synthesis timing estimates rather meaningless as a predictor of final timing performance. In fact, explorer_1's estimate starts out worse than that of its counterparts and eventually ends up better. When we add build time to the overall consideration, post-placement estimates seem like the best point to decide if a build should be terminated.<\/p>\n

    \"synthesis_estimates\"<\/p>\n

    Reduce build time\u00a0in InTime<\/h2>\n

    If you are running multiple builds (using InTime to get the best settings), the post-placement timing estimate is a great indicator to stop builds early and re-allocate precious resources to other builds. The latest version of InTime provides new Flow Properties labeled, \"Stop A Run When Post-Place Timing is Bad<\/strong>\" (below). By enabling this option, you can specify TNS and WNS value in nanoseconds and InTime will stop the build if its post-placement timing estimate is worse than either of these values.<\/p>\n

    \"intime_properties\"<\/p>\n

    What values to specify depends on your design (the project in this article used a WNS cutoff of -2.5ns) You can create simple scripts to collate post-placement timing estimates and obtain a good idea of what the cutoffs for your designs should be.\u00a0This new feature is released in the new version with the latest patch. If you are using the earlier 2.5 release, please upgrade to the latest one to enjoy this feature. Feel free to reach out to us to discuss how to get the most mileage out of it.<\/p>\n

    #InTimeDelivers<\/h2>\n

    By tracking how each build is performing with timing estimates, we are able to make decisions on whether to stop the build or let it continue. This saves time, money and achieves our 3-7 days\u00a0commitment\u00a0for turnaround time (See InTime Service<\/a>). Using this method, InTime has close up to -2ns of WNS.<\/p>\n

    I am sure many designers out there have interesting experiences dealing with early indicators of timing performance. Let us know about your experiences. Is post-placement timing a good indicator?<\/p>\n

    Other Vivado related articles:<\/p>\n

    InTime’s Whitepaper in Xilinx Acceleration Zone – Full Article<\/a><\/p><\/blockquote>\n