{"id":3446,"date":"2018-07-07T04:31:34","date_gmt":"2018-07-07T04:31:34","guid":{"rendered":"https:\/\/support.plunify.com\/en\/?p=3446"},"modified":"2018-08-28T03:22:15","modified_gmt":"2018-08-28T03:22:15","slug":"fast-predictable-fpga-timing-optimization","status":"publish","type":"post","link":"https:\/\/support.plunify.com\/en\/2018\/07\/07\/fast-predictable-fpga-timing-optimization\/","title":{"rendered":"Tactics For Fast, Predictable FPGA Timing Optimization"},"content":{"rendered":"

It is the start of a brand new day.\u00a0You come to the office, open up a medical imaging design that met timing the day before and finds that a bugfix made by someone else has led to timing failures.<\/p>\n

In the demanding world of high-performance FPGA design, there is no free lunch.<\/p>\n

We take pains to understand the target device architecture in order to write the appropriate RTL and integrate suitable IP blocks. Subsequently, we craft the design constraints carefully so that synthesis and implementation understand our timing intent well. Finally, we spend time exploring helpful switches in the FPGA tools to converge on a good result.<\/p>\n

It would be really nice to have this hard work pay off for all subsequent design iterations, wouldn't it?<\/p>\n

However, minor design changes can suddenly degrade performance, especially for heavily-utilized or congested designs. There is considerable complexity in FPGA synthesis and implementation that the tools have to navigate - a non-trivial task.<\/p>\n

How can you ensure that results are more predictable?<\/h2>\n

The solution we proposed is simple.<\/p>\n

Find sets of known-good parameters that are tuned for your design and are likely to yield similar performance across modifications.<\/strong><\/p>\n

A proven method with roots in Machine Learning is to develop an understanding of how design characteristics, FPGA tool parameters and performance statistics are correlated.<\/p>\n

    \n
  1. Gather relevant design characteristics e.g. logic levels, utilization percentages, etc.<\/li>\n
  2. Generate sets of synthesis and implementation parameters based on experience and history of results for this design<\/li>\n
  3. Compile all parameter sets<\/li>\n
  4. Analyze results and correlate them to the parameters<\/li>\n
  5. Reuse good parameters for subsequent design changes<\/li>\n<\/ol>\n

    This might sound daunting but that is what we built. Plunify's InTime<\/a> software is used to train a database and optimize the design at the same time. Let's look at two customer designs used in office automation and medical imaging respectively.<\/p>\n

    Real-World Case Study #1 - Project Cyclone (Office Automation)<\/h2>\n

    \"office<\/p>\n

    This design has 70% logic utilization and meets timing in 1 out of 20 placement seed builds, which leaves a little too much to random chance for the designer's comfort.\u00a0Steps 1-5 above are executed with 20 sets of parameters per iteration until the timing is met.<\/p>\n

    In Figure 1 below, each revision refers to a different version of the RTL.
    \nThe Y-axis shows the number of builds taken to meet timing.<\/p>\n

    \"predictable_timing_closure_cyclonev\"
    \nFigure 1: Builds to timing closure vs. design revision (Project C)<\/p>\n

    The initial optimization took 61 builds before timing was met. Subsequent optimization attempts after design changes (Rev 1, Rev 2, and so on) took dramatically fewer builds because the good build parameters found for Revision 1 were reused.<\/p>\n

    Real-World Case Study #2 -\u00a0Project Zynq (Medical Imaging)<\/h2>\n

    \"Medical-Devices\"<\/p>\n

    Smaller than the previous design, this one has 40% utilization and meets timing via a sweep of implementation tool directives.
    \nInTime is used to find good build parameters in anticipation of design changes.<\/p>\n

    \"predictable_timing_closure_zynq\"
    \nFigure 2: Builds to timing closure per design revision (Project Z)<\/p>\n

    InTime took 77 builds to meet timing for the first revision. This number dropped significantly after that as the successful parameters were applied to subsequent revisions.<\/p>\n

    In Revision 2 and 3, the best synthesis parameters found for Revision 1 were used for synthesis, then InTime was used to explore the implementation parameters.<\/p><\/blockquote>\n

    This is an approach we highlight in our timing closure methodology<\/a>.<\/p>\n

    Conclusion<\/h3>\n
      \n
    1. \u00a0The number of compilations needed per revision will still vary, as seen in the charts above. This is dependent on the extent of design changes and how well the Machine Learning database was trained.<\/li>\n
    2. Armed with sets of known-good parameters, the turnaround time for performance optimization becomes a lot more consistent.<\/li>\n<\/ol>\n

      To find out more about InTime, request for a free evaluation here<\/a>.<\/p>\n

      References:<\/b><\/p>\n