The notion of a self-driving or autonomous vehicle is firmly embedded in the collective consciousness; we've come quite a way since the days when such things were the stuff of science fiction. Now everyone knows what a self-driving car is, and quite possible has seen one in action on nearby roads.
In search of timing closure...
But has anyone heard of a self-driving FPGA tool?
The need for one is articulated nicely in this recent EE Journal article by Kevin Morris. Previously, the calls for a more automated, more intuitive FPGA tool may have arisen more from an ease of use perspective, but now, I believe that it is more a question of how to close timing faster, how to increase system performance via tools that work unobtrusively, efficiently while you focus on more important design-related tasks.
Well, look no further than our very own InTime tool as a starting point. InTime is a design optimiser precisely designed to work on your FPGA design in the background while you focus on the truly important parts of the design. Just like how a self-driving car takes care of choosing the best route to your destination instead of choosing the destination. As mentioned in the article cited above, of course we as designers need all the knobs and fine control provided by the synthesis and place-and-route tools -- that requirement doesn't change. But sometimes, increasingly so, all we'd like to do is to "get from here to a spot just on the other side of the parking lot." without having to "take a space shuttle."
InTime will open your FPGA project as is, and start running when you hit the "Start Recipe" button -- that's it. The tool first reads your existing design's timing, utilisation and power estimation results (or re-compile if necessary), and then runs multiple instances of synthesis and place-&-route with different tool knobs to "drive" the design towards timing closure, all in the background. Think of it as starting InTime before you leave the office and coming back in the morning to see results.
Unlike self-driving cars, the most dramatic consequences that can occur from using InTime are limited to resource overfits and perhaps pointed glances from the IT department about an increase in machine resource usage (more efficient usage of servers, if I may add) resulting from running multiple compilations at the same time. To alleviate this, InTime kills jobs automatically past a certain runtime that you can specify.
InTime is not a cure-all, of course, but given enough compilations, 99% of the time it always improves design performance.
One frequently-mentioned aspect of self-driving vehicles is the machine learning. When presented with new data, the system will learn from it to avoid future pitfalls and further optimise the route(s) using the terrain as a reference. Similarly, InTime will encounter failing results as it tries different, sometimes aggressive, combinations of parameters. However, not a single compile cycle is wasted in this process as the tool actually builds a "design brain" within your company / firewall that is used to generate parameters as it chugs along. As your internal design brain grows steadily, the time to design closure will decrease.
InTime can certainly be considered a self-driving FPGA tool, and has been autonomously optimising customer designs since 2014. Care to take it for a spin (http://www.plunify.com/en/evalregister.php)?
Sources:
http://www.eejournal.com/archives/articles/20161110-fpgatools/, Kevin Morris, EE Journal, Nov 9, 2016