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.
Why High-speed Interfaces?
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 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.
The designer is playing “whack a mole” with the worst critical path, affecting his productivity.
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. By trying to solve critical path one-by-one, the designer is playing “whack a mole” with the worst critical path, affecting his productivity.
Why Use InTime
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 is particularly useful here because it can optimize the design without modifying the RTL. 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.
Results
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%.
Original WNS: -2.946ns, TNS: -30.092ns. Met timing.
In the second example, the customer was able to meet the target timing within 3 InTime iterations.
WNS: -1.482ns to -0.035ps; TNS: -1278ns to -0.134ns
Final Word
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.