If you have ever had any interest at all in high-level synthesis (HLS), then you have probably wondered about the quality of results (QoR) that they produce. Do they produce implementations that are as good as the best RTL engineers? You can go to the HLS vendors (Cadence, Mentor, Synopsys, Forte, Synfora, AutoESL) and they will show you results that say they produce better results in a shorter period of time. But can you believe them? How much of this is hype and how much reality? How much of that comes from the fact that they know the tools inside out and backwards or have optimized the tools to produce impressive results on a few benchmarks? Then we can throw into the mix questions about the usability of the tools. What kinds of skills do you need to have, to be able to use the tools effectively? We here a lot about the use of HLS in chip design but what about FPGAs? It just seems that there are so many questions that most companies decide it is too much work to decide if this would be good for their bottom line or not.

Then we have to think about a completely different set of users as well. What about the software developers who have been using DSPs for years? They now face a migration to multi-processor systems that will require some new skills on their part. Would it be beneficial for them to start thinking about hardware implementations instead? What do the performance/cost tradeoffs look like?

Over the past couple of years, I have had the pleasure to get close to almost every tool in this area, either through fundamentals courses, company analysis for VCs or book writing. In the process of writing my last book (ESL Models and their Application) and the current one, that has not been formally announced yet, I have been getting fairly close to a couple of HLS tools so I had started to form some of my own opinions about this class of tools, but I do not have the time to perform complete analysis of them, neither do I have the applications domain skills necessary to test them out will really complex designs typical of those being built into designs these days.

I recently had the opportunity to talk to Jeff Bier of BDTi and Tom Hill from Xilinx about a new program they have been running to answer some to these questions in a more controlled manner than I have been capable of. While everyone will probably be familiar with Xilinx, you may not know the other players quite as well. BDTi is a independent technology analyst firm that focuses on embedded processing technologies. In 2007 they published an analysis of the capabilities of FPGAs for DSP applications and one of their conclusions was that ease of use was a key obstacle for wider adoption, even though it represented a 25X cost/performance advantage.

Now BDTi has launched a program with a couple of HSL tool vendors (Synfora and AutoESL have both completed certification with this program) to see if the inclusion of high-level synthesis will significantly change those results. Other vendors are also seeking to get certification, but not announced at this time.

So there are two potential groups of users for these tools. The first group are defined as hardware aware developers. They would normally write algorithms in C code but are also aware of concepts such as pipelining. These are not traditional RTL developers and have no knowledge of VHDL or Verilog. BDTi wished to evaluate how easy it was for them to use such a flow and how much effort it would take to get an optimal solution. The second group were DSP software developers without any real knowledge of hardware implementation, but understand the role of pipelines, memory structures etc.

The evaluation was multi-staged in that it included both a self evaluation by the vendors for provided benchmarks and evaluation within BDTi. The benchmarks included a pixel based motion analysis system and a DQPSK baseband receiver. These examples were chosen because they are non trivial from a control perspective. They were also looking at many implementation points, such as fastest frame rates, smallest area of the FPGA used etc.

So what were the results? The conclusion was mixed, but in a rather unexpected way. First the good news. HLS is as good as hand crafted RTL. HLS is 30X better than a DSP. HLS tools are very usable – and even comparable to DSP software tools. Now the bad news. The flows do not insulate the users from the backend FPGA flows and this is the weakness in the flows. This is primarily because there is no clean handoff between the tools that would enable the backend to be run without significant effort and knowledge. BDTi concluded that for DSP engineers this would present a significant barrier such that they would require a dedicated backend person to complete the processes for them.

Figure 1. HLS QoR is 30X better than a DSP

They found that a similar total time was necessary for an HLS design as compared to a DSP implementation. Surprisingly, code had to be modified more for the DSP implementation than for HLS! For DSP, some pieces generally had to be rewritten in assembler. One third of total effort in DSP implementation was spent reducing memory access bottlenecks.

In interviews that BDTi held with users of the vendors HLS solutions, they also suggest consistent gains of about 2X in design productivity, somewhat less than most vendors had been claiming, but in addition a 4X gain in verification.

Their summary results are shown below.

Synfora also provided me with some of their individual results and thoughts on the process. In figure 5 below we can see their individual results that compare to the figure 1 chart from BDTi. Synfora believed that BDTi had produced realistic benchmarks, but at the same time thought that many of their customers were doing significantly larger designs so wondered if scalability might be an issue with some tools

------------------------------------------------
Brian Bailey – keeping you covered