The persistence of ESL synthesis
Many people are familiar with Salvador Dali’s painting, The Persistence of Memory:
When I look at developments in ESL, I sometimes think of the painting and its title. Some of the old ideas in ESL must be good ones because they keep coming back. ESL synthesis, for example, has now been through at least two or three generations. In fact, to many people, ESL = ESL synthesis (or behavioural synthesis, or high-level synthesis). We have seen some recent activity in this area - for example, Celoxica got out of ESL synthesis to focus on FPGA-based accelerators for high performance computing applications, and moved its technology and team to Catalytic, forming Agility Design Solutions. At the recent Electronic Design Process Workshop, I saw Rishiyur Nikhil, CTO of Bluespec, give a talk on Parallel Atomic Transactions in the Bluespec synthesis approach. I’ve heard some people comment that they don’t really consider Bluespec (using System Verilog and some particular constructs to express their atomic transactions) to be “high-level” enough to be ESL synthesis. Most ESL synthesis tools use C/C++/SystemC or other dialects of C as inputs. However, the atomic transaction semantic used by Bluespec is definitely more abstract than the normal way people write HDL for RTL synthesis, so I think we can count it as among the family of recent high level synthesis approaches.
It was therefore interesting to read on the wire this morning of a new high level synthesis company called Fastpath Logic, with what they say on their very minimalist and unfinished web site is new ESL technology based on a new input language Chip Specification Language (CSL) for “chip and verification infrastructure generation”. They describe this task as being different from, and complementary to, the creation of the algorithm implementation (which has been the focus of most ESL synthesis up till now). It will be interesting to see exactly what is entailed in CSL, and what the interface generation will provide, and how it will complement the use of RTL or other ESL synthesis approaches for algorithm implementation. No doubt more will be revealed by the time the Design Automation Conference (DAC) rolls around in Anaheim June 12-18. I don’t see Fastpath Logic on the list of exhibitors as of today (April 24, 2008) but perhaps someone from there will be wandering the DAC floor and people may run into them.
Hope springs eternal in the ESL arena….
8 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
April 29th, 2008 @ 5:00 pm
Hi Grant, good and interesting topic.
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?
April 29th, 2008 @ 6:06 pm
Juergen, thanks for the comments.
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
April 30th, 2008 @ 2:01 pm
I was talking to a colleague today about DAC 2008, and we together looked at the programme for one of its workshops, being held at DAC in Anaheim on Sunday June 8, 2008, from 8:30 to 5:30. This is the workshop on High-level Synthesis: Back to the Future (URL: http://www.dac.com/events/eventdetails.aspx?id=77-155), which has many of the ESL synthesis vendors presenting and perhaps new ones giving posters and demos - well worth a look-in for anyone wanting a broad snapshot of the state of current ESL synthesis. If I count up the vendors presenting here plus others I know of, I get a minimum of 110companies: Bluespec, AutoESL, Mentor, ChipVision, Forte, Synfora, NEC, Synplicity, Agility Design, Xilinx) with announced products in this area (probably more), and at least 2 more working in their backrooms on products that I have heard of. That make 12 companies, and I am sure there are more. This is a pretty crowded field!
April 30th, 2008 @ 7:20 pm
Thank for your additional feedback and insight.
I agree that is is a very crowded field right now and still very little total available money for which all these companies are competing about.
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?
April 30th, 2008 @ 7:37 pm
Juergen, an interesting point. However, I would say ESL synthesis may be compelling even if it does not save much effort in a big ASIC or SoC design project for datapath hardware blocks. First, given reuse (which has increased for big SoCs to sometimes the 70-90% level according to some reasonable surveys I have seen), the amount of new hardware logic may be reasonably small, and if they are amenable to ESL synthesis, then even if only 5% of the effort is saved overall, it may be more like 25% of the new HW design effort. HW designers and SW writers are not interchangeable, so this may still be significant in terms of the HW design budget. This may be especially true in large media, image processing and signal processing SoCs or ASICs where this niche is playing out.
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.
June 13th, 2008 @ 11:35 pm
#
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!”
June 14th, 2008 @ 11:50 am
George, many thanks for adding to the debate. There was a full day workshop on DAC at Sunday on High level synthesis (I referred to above) that I had heard was fully packed out and in fact, more people wanted to come to than the room accommodated. My own commitments elsewhere did not allow me to attend, but I also heard from others that they think there is solid new interest in high level synthesis and what is being accomplished there. I hope more users of the various tools and approaches (which certainly includes Bluespec in my book, as I mentioned in the first post) will report on their experiences.
Grant
July 14th, 2008 @ 2:03 pm
[...] Forte Cynthesizer, Synfora, Bluespec, AutoESL, and others in the high-level synthesis field, which is relatively crowded at this [...]