InTime version 1.5.11 is officially launched today. We haven't been describing our last few releases as we have been fine-tuning them based on customers' requirements. Today, we are proud to finally announce these improvements!
"Deep Dive" recipe
This recipe was born out of the differences in the results between InTime's "Default" recipe and its "Placement Seed /Extra opt" recipe. The "Default" recipe usually reaches an estimated local maxima (considered the best result so far) within five rounds. However, due to its exploratory nature, the effort required to find a different maxima may be another five rounds or more. This can be time-consuming depending on the compilation time of the design.
The purpose of the "Deep Dive" recipe is to examine a current crop of results and do an in-depth analysis of the local maxima and its surroundings, yielding about 10% improvement in results in a shorter amount of time.
Based on in-house tests and customers data, the "Deep dive" recipe provides a higher concentration of good results. The chart below shows that by using a cut-off of -50ns Total Negative Slack as the threshold for "good" results, the percentage of good results for "deep dive" is significantly higher -- around 8x better. As explained previously, "deep dive" only looks at the better results and attempts to find other results that are within range of the local maxima.
Using the same design, we also did a comparison with the "Placement Seeds" recipe. The chart below showing how the TNS results are distributed for the same design. While "Default" has a very wide spread of results up to -50,000ns, the spread of "Deep Dive" and "Seeds" is fairly small in comparison.
If we zoom in a bit more, we can see that the results distribution of "Deep Dive" is smaller than "Default" but wider than the distribution of the "Seeds" round. This reinforces the fact that while placement seeds are useful variations when you are close to meeting timing, the variation in timing results is much smaller.
Lastly, the "Deep Dive" recipe requires only 1 round of compilations, reducing the overall time required. The only requirement is that this recipe requires a few good results from one of the "Default" recipes, so this recipe cannot be used when InTime has not compiled the design before. Upon getting a better result from "Deep Dive", the usual "Placement Seed /Extra opt" recipe can then be applied to get an even better result.
Version control within InTime
One of the unfathomable mysteries for FPGA designers is "why do timing results differ when the same project is re-compiled without any changes?" For FPGA vendors, issues like this happen from time to time, with explanations such as here and here. Every InTime result has to be reproducible in the FPGA tool's environment. Some of the mitigating factors may be beyond our control, but with improvements on our end, sometimes they are! With built-in version control, InTime is able to keep a record of what has changed for your project, such as source files, constraints etc. This helps us determine why a result is not reproducible. Is it because of a change in the project? Did another colleague change an IP file? If you are having problems tracking different versions of your project, this new feature can help you manage changes much more efficiently.
In this release, InTime's version control feature is not turned on by default. You can turn it on when you run InTime by specifying the "-git" in the shell or in the shortcut.
After turning it on, you will notice that InTime will have a new column called "Snapshot ID". If there is a difference in your project, the Snapshot ID will be different as well.
For example, after making a change to your design, when you click "Start Recipe". InTime will detect the difference(s) and the screen below will appear. It shows what has changed since the last compilation. By clicking on "Accept Changes and Proceed", a new snapshot ID will be logged to reflect a difference between the two versions, and InTime will continue to run.
Showing the different types of slacks and FMax
Since the beginning of InTime, the tool only shows the "Worst Slack" for all the timing models. It can be "Setup" or "Hold" or any of the other slack components reported by the FPGA static timing analysis tools. "Setup" is usually the worst slack but this is not always the case. By showing all the different slacks, it becomes easier for users to select their "best" result. Another new piece of data that we present now is "Fmax". This can be a bit tricky as InTime does not know which clock you care the most about, so it can only pick the fastest one, or the one reported by the FPGA tools.
To check the Fmax that is reported, scroll down under "Results" and look for "Fmax Overview"
Automatically adjusted maximum run-time
Sometimes it is hard to determine the maximum run time for a design. If you set it to a value that is too short, a lot of the results will be timed out, and you will not get sufficient data points. If you set it for too long, you waste precious time waiting for that last one or two results to finish. (See the chart below) Typically at the end of a round, many InTime agents may be idling and waiting for the next job. It makes more sense to quickly move into the next round instead of waiting for the last one of two compilations to complete.
This new "Auto Maximum Run-time" feature allows InTime to determine the optimum run-time for you, at the end of each round. If more than 30% of your results are timing out, the run-time will automatically be increased by 1 hour. If your results are all generated much faster than your maximum run-time, it will take the longest run-time for the existing results, give an additional buffer of 1 hour, and set it as the new maximum run-time.
This feature is not turned on by default. You have to tick the checkbox in order to turn it on. Just ensure that for the 1st round, the run-time is more than sufficient to run for the 1st round. Subsequently, it automatically adjusts itself.
Thank you for reading! If you have any questions about the new features, please feel free to contact us at tellus@plunify.com. Comments are most welcome!