Grant (and Juergen),

By way of full disclosure to other readers, I run marketing at Bluespec.

I wanted to comment on two items: 1. Juergen’s view; and 2. The comments that Grant has heard from some people questioning whether Bluespec is highe enough to be ESL Synthesis.

On the first item, I think Juergen makes an interesting point. Customers seemed to be concerned with overall chip development/verification and software readiness. Unless C-RTL blocks are the longest pole in a chip schedule tent by a material amount, then accelerating them is not going to materially impact overall chip development (though local portions may improve). And, I’m not sure how C->RTL synthesis improves software development.

We need high-level synthesis that supports both algorithmic and complex control IP and SOC interconnect. Atomic transactions can enable this.

To the second point as to whether Bluespec is as high-level as other ESL solutions, I think the answer depends on how you define abstraction:

* If you define high-level as writing in a sequential language, then no we are not high-level. With Bluespec, design is done explicitly in parallel. Does something have to be sequential to be high-level?

* If you define high-level as expressing solely function and not architecture, then we are not high-level. Though if that were your definition then there is no high-level design today. Every high-level tool requires architectural guidance for synthesis.

Bluespec is based on atomic transactions. Atomic transactions are not part of C/C++, which have no way to express concurrency, or SystemC, which offers a similar model to RTL for concurrency. Both RTL and SystemC require low-level, detailed manual control over shared resources.

Atomic transactions allow us to raise the level of abstraction for both control and algorithmic IP.

And, Bluespec allows a degree of parameterization that is both very powerful and synthesizable. It allows one to parameterize on feature and architecture — and most importantly, have the control logic automatically generated for them.

These two unique capabilities often make Bluespec designs significantly shorter than those written in C/C++/SystemC. An HD-quality H.264 decoder was written in fewer than 10,000 lines of code. At DAC, I had a video engineer experienced in C->RTL synthesis ask me over an over again — “How so short?” An arbiter for a network processor was written in 1/14th the lines of code of a Verilog one. I don’t measure abstractness by lines of code, but it can be a proxy.

If you want to see a really cool example of what general purpose high-level synthesis is capable of, please take a look at this year’s MEMOCODE Codesign Contest results at http://rijndael.ece.vt.edu/memocontest08/everybodywins/#results. How did the winning team do this? They did the whole design for the FPGA in hardware and did it in three weeks (despite splitting it across three people). And, they skipped system level simulation and integrated directly on the FPGA. I’d be happy to send the paper describing the winning solution to anyone that contacts me at Bluespec (gharper@bluespec.com).

There are a lot of voices in the EDA world stating that the only answer is C, despite years and years of commercial and research efforts demonstrating that automatic parallelization are not a general solution. The software industry has all but abandoned automatic parallelization — in favor of applications explicitly written in parallel. Why is the EDA industry pushing it so hard?

Here are some interesting reads:

Tim Mattson of Intel on writing parallel software versus auto-parallelization: http://www.eda.org/edps/slides/par-prog-doing-it-right-epc-hardcopy.pdf

Winner of this year’s Pistilli Award for Women in EDA on whether behavioral synthesis (as classically defined by automatic parallelization, ed.) will ever succeed:

http://www.scdsource.com/experts.php?id=201&page=1

A quote from Akash Deshpande, CTO of system design at ARC: “Automatic parallelization? Forget about it, at least for performance-critical applications”

Finally, from Tim Sweeney, famous video game designer at
Epic Games [Unreal, Gears Of War, … on Xbox 360, PlayStation 3, ...]:

“C++ is ill-equipped for concurrency”

[ on Shared State Concurrency programming ]
“This is hard! … There must be a better way!”

There are also a couple of other points potentially in favour of ESL synthesis:
- a reduction in risk. It would need to be measured, but having a significantly shorter and more understandable, algorithmically oriented input format for the synthesis may allow its quality to be improved vs. RTL.
- an improvement in verification - by using the input to ESL synthesis, or a byproduct of the synthesis tool, as a golden model for the block (as you pointed out in your original post). If you can get high level./fast models of processors, buses, memories etc. then having the same for the HW blocks will allow virtual platform models to be created and used.
- possibly better Quality of Results (QoR) for these blocks due to more design space exploration. (this is more arguable, although I have seen some comparisons at a DATE conference last year that seemed to indicate equivalent or better QoR is possible much of the time).
- potentially greater reuse of the resulting block in follow-on derivative designs - in the same way that RTL synthesis had better reuse than gate level designs, having an algorithm captured in an ESL synthesis form may make it easier to reuse with or without change in future designs.

All these potential benefits may make the value proposition more compelling. Nevertheless, the ESL synthesis vendors need to keep working to demonstrate and prove these values to a somewhat skeptical design commmunity.

It is also possible that new technology may allow ESL synthesis to break out of the datapath/dataflow niche. Bluespec talks in this way about their atomic transaction based flow.

One of your statements sparked my interest: “Still, the main niche for ESL synthesis seems to be to generate datapath/dataflow hardware blocks, …”.
Now how compelling and how much of a value proposition is that really?
I mean, how much time do you really save in a multi-month ASIC or SoC design project by using an ESL synthesis tool to so the synthesis for some datapath hardware blocks? 1%? 5%?
Doesn’t ESL synthesis needs a more compelling value proposition to become more mainstream?

I agree that many of the companies in ESL synthesis are hoping that the verification benefits (using either the synthesis input, in C/C++/SystemC/another dialect; or a special output from the synthesis tools, such as a “wrapped” or interfaced version of the input files) of using much faster verification models than RTL synthesis inputs allow will be enough of a benefit to warrant additional user interest in ESL syntehsis.

This also depends on their tools achieving near equivalent or better quality of results than using RTL synthesis. Still, the main niche for ESL synthesis seems to be to generate datapath/dataflow hardware blocks, often in image and signal processing areas, much like the earlier generations of behavioural synthesis tools.

In terms of eventual profitability - it probably depends on the number of vendors. There may be enough business for 2 or 3 at most, and counting both announced and unannounced tools that I know of, there are at least 6 or 7 vendors either in the market or contemplating a move into it. That seems too many to sustain the likely business. Just an opinion, of course.

Thanks for commenting. More comments welcome!
Grant

Yes, ESL, or high-level synthesis is around for a long time, over 10 years, already. Many companies have tried themselves on it, usually with mixed results and success.

I have some doubts that the implementation aspects of ESL synthesis are compelling enough to finally lead to a breakthrough and wide adoption. On the other hand, one could argue that the “side benefit” of much faster verification coule bring that breakthrough.

I would be interested to hear your and others opinion on, not the technical feasibility, but on the business side of ESL synthesis - will it ever be profitable?