{"id":26100,"date":"2019-03-04T05:43:43","date_gmt":"2019-03-04T05:43:43","guid":{"rendered":"https:\/\/support.plunify.com\/en\/?p=26100"},"modified":"2021-06-03T02:20:16","modified_gmt":"2021-06-03T02:20:16","slug":"when-ip-cores-go-bad","status":"publish","type":"post","link":"https:\/\/support.plunify.com\/en\/2019\/03\/04\/when-ip-cores-go-bad\/","title":{"rendered":"When IP Cores Go Bad"},"content":{"rendered":"

Many of us use 3rd-party IP to accelerate our development process and time-to-market. While IP reuse is certainly helpful, we see customers who are encountering timing and performance issues because of integration challenges. This problem becomes more apparent with design involving high-speed interfaces.<\/p>\n

Why High-speed Interfaces?<\/h2>\n

\"\"Many of these problems have to do with designs using high-speed interfaces. Usually, the initial designs were created few years back with the inclusion of a key 3rd<\/sup> party IP. For a particular customer, the design itself is a host controller tester. It was able to fulfill performance targets determined by standards of those times. Fast forward to 2019, it started facing performance issues with the latest high-speed standards, e.g. USB 3.1 Gen1 to 3.1 Gen 2 is a 2x increase in performance. While the team is more than capable of changing their own design, it is only limited to the parts of the design where they had worked on directly. Changing the IP was an unknown task involving extra cycles of re-development, testing, and verification.<\/p>\n

\n

The designer is playing \u201cwhack a mole\u201d with the worst critical path, affecting his productivity.<\/p>\n<\/blockquote>\n

The second case involves a design that is being prototyped on board (with multiple Xilinx Virtex VU440). For prototyping, the frequency of the design is not as important. Usually, it lowered to ensure the design always meet timing. However, in this case, there is a need to achieve certain timing performance because a USB 3.x interface was being verified. Doing major changes to the design at the prototyping level is usually not ideal and discouraged unless it is absolutely necessary.\u00a0 By trying to solve critical path one-by-one, the designer is playing \u201cwhack a mole\u201d with the worst critical path, affecting his productivity.<\/p>\n

Why Use InTime<\/h2>\n

The common factor in both cases is that the design uses IP for high-speed interfaces but the IP was not amenable to modification. InTime<\/a> is particularly useful here because it can optimize the design without<\/span> modifying the RTL.\u00a0 It determines the best parameters for synthesis, place & route through exploration (repeated trial & error). However, as the possible combinations of parameters are far too many to brute-force, InTime uses a mix of FPGA design rules and Machine Learning to narrow down the search space and converge on good parameters quickly.<\/p>\n

Results<\/h2>\n

In the first case study shown here, in less than a week, the customer was able to increase the design's FMax from 120Mhz to 150Mhz and finally to 170Mhz, which is their target frequency. You can see that their utilization increased a few percentage points to 80%.<\/p>\n

\"Design

Original WNS: -2.946ns, TNS: -30.092ns. Met timing.<\/p><\/div>\n

In the second example, the customer was able to meet the target timing within 3 InTime iterations.<\/p>\n

\"Design

WNS: -1.482ns to -0.035ps; TNS: -1278ns to -0.134ns<\/p><\/div>\n

Final Word<\/h3>\n

Design exploration is a powerful optimization technique that can be used in conditions where changing RTL is not feasible. Extracting maximum performance out of your design is all about using your design tool to the fullest. To find out more about InTime, please go to https:\/\/www.plunify.com\/en\/intime<\/a>.<\/p>\n

Subscribe to Plunify Blog<\/h3>\n

<\/h2>\n
\n\t\t\t\t

Enter your email address and have the latest insights on FPGA, cloud and Machine Learning delivered straight to your inbox.<\/p>\n<\/div>

\n

\n \n \n \n \n\t\t\t\t\t\t