Wednesday, October 7, 2015

"A Brief History of InTime" - Overview of past projects

An evaluation customer made an interesting comment recently.

Due to the rigorous nature of InTime's approach, we'd often get comments like, "You mean this takes 100 compilations more than usual?!" This time it was, "I need to evaluate InTime more as it met timing too quickly." It felt like a compliment hidden within a complaint, or vice versa! We're just happy that they put in the time and effort to evaluate InTime and it gave them good results.

I actually think that the two pieces of feedback mean the same thing -- that there is a lack of understanding the software, not so much in terms of how it works, but in realizing how much potential this approach has. As engineers and innovators, we take a lot of pride in creation. Most of the time, competent FPGA designers come with a whole bag of techniques and tricks in their repertoire. They can solve most problems using their understanding of the RTL and architecture.  As one partner puts it "We felt like we'd lost if we started working with the settings (of the FPGA tools)." It was almost as if any approach not involving RTL changes bordered on cheating.

It is not cheating! Like it or not, you are already using default values for the settings in every design whether you realize it or not; it's just that when your design doesn't meet timing or doesn't fit into the target device, the defaults have not helped. The question to ask then, is how much can the settings help in your particular design?

Can InTime's approach really solve the problems you are seeing? It is true that using the optimal group of settings might not enable you to hit that performance target. However, it is undeniable that using the right ones right from the start will get you more quickly to a better result. Let us look at various customer designs and their results using InTime below:

The full details can be found at this URL.

The various charts show three different metrics, TNS, WS(Worst Slack) and Area, across various customer designs -- color-coded to differentiate between customers. We highlight the left-most cell in green if there is at least 80% improvement over the original score, whether it is TNS, WS or Area. 100% improvement means we have met timing. Grey indicates less than 80% improvement and red is less than 50% improvement. N.A means that the original timing scores are not captured in the dataset.

Here is what was observed for successful cases:

1. Planning and Coding Guidelines

If you plan carefully and practice FPGA-optimized coding guidelines, it is easy to get InTime to produce the results. (One of the cases in red is due to asynchronous design issues. The other did too few compilation runs.) Xilinx has published detailed coding guidelines to help in this area.

2. Starting Timing Scores
This might seem obvious but a higher initial TNS score makes it harder to close timing than a lower one! From our data, the average cutoff TNS is -6000ns. Anything below -6000ns is possible in general. So far InTime has not closed timing on designs with initial TNS values that are worse than -6000ns. If your design is still beyond this threshold, for example, at an earlier stage of the design flow, InTime is still helpful because it points out significant critical paths that you should tackle first. For the record, the "worst" TNS we've encountered was a whopping -60,000ns!

Although we don't have sufficient data to justify some observations, there are some other interesting snippets of note. For instance, a bit of floorplanning seems helpful -- in general, a post-floorplanned design converges faster (fewer number of compilations required, more successful results). Also, there are definitely correlations between using older and newer FPGA tool versions.

One last thing to mention here: The charts and analytics are made possible by a collective crowd-sourced effort from our customers and partners. By sharing InTime data with us, they help further improve our analytics. If you are planning to evaluate InTime in future, please help by sharing with us your InTime data.

Let us know if you have any questions. Thanks for reading!

Wednesday, April 22, 2015

Cool stuff! DIY FPGA-based HDMI ambient lighting

Once in a while we come across cool stuff like this! Have fun!

Check them out: Zero Characters Left: DIY FPGA-based HDMI ambient lighting

"Ambient lighting is a technique that creates light effects around the television that correspond to the video content. It has been pioneered by Philips under the brand Ambilight. In this project we will create a basic FPGA-based ambient lighting system that reads the video signal over HDMI. This means we are not limited to computer output. We can use it together with DVD players, video game consoles, etc."

Wednesday, February 18, 2015

Long live the Tabula in us

News of Tabula's closure was naturally a big thing to people in the industry.

For years, Tabula had been the shiny, young FPGA company with lots of talent and funding. Not that Tabula stayed a startup for long, given the considerable resources that it amassed.

Many former colleagues had gone over to Tabula over the years, and probably a lot of engineering and managerial talent from every FPGA company as well. I didn't know any of the executives, but whenever I popped by to catch up with old friends, certainly measured optimism was always in the air.

The FPGAs they had developed seemed revolutionary and promised much in terms of innovation and performance improvements. The device architecture was exciting and against a backdrop of waning semiconductor hardware startup activities, Tabula was a welcome ray of hope, a daring adventure.
The Stylus software sounded every bit as challenging and fun to implement - for example, I've always been intrigued by how one can debug something running in four-dimensional space.

FPGA customers are a passionate, demanding group of people who want good software, hardware, IP and support. Evaluation boards, reference designs and application notes are just some of the things that designers look for to be persuaded of a particular FPGA device family's benefits. On top of that, the economics have to make sense for the consumer as well as the supplier. For a younger FPGA vendor, creating all that from scratch and competing with established vendors could not have been an easy task.

Tabula fought the good fight - we salute you.