Taken for Granted

ESL, embedded processors, and more

Hammers and Nails

Filed under: Uncategorized — September 17, 2008 @ 8:05 pm

I am sure everyone knows the old saying “When all you have is a hammer, everything looks like a nail.” This is a natural tendency of everyone with a solution to a problem: to assume that their solution is one fit for every problem. I was reminded of this when I read two interesting posts on the DAC Ezine: Sunil Ashtaputre of Synofora on “Algorithmic Synthesis: the “Killer App” for broad ESL deployment”, and Mike Meredith of Forte Design Systems on “ESL Synthesis Innovation: the importance of choosing the right technology”.

Georges de la Tour, St. Joseph, the Carpenter, 1640s (the Louvre)

The columns by Sunil and Mike are both interesting, but both take a bit of a narrow view of ESL and ESL synthesis. Algorithms described by C can be more than a front-end for hardware-oriented ESL synthesis – they can be used automatically or manually to configure a processor that is precisely tuned to the particular algorithm, and may give performance 10-100X faster and energy consumption 70-90% less than running this algorithm on a standard fixed Instruction Set Architecture (ISA) processor. These methods are now well proven in many different applications.

And when Mike Meredith talks about ESL or High-Level Synthesis methods, he talks about a variety of input methods, among other differences, and cites:

Input approaches include SystemC, C, C++, ARM object code, graphical methods and proprietary languages such as Haste, nML, TIE, BSV, Matlab, SystemRDL, and LISA.

However, he is not really comparing apples and apples here. Input languages such as nML, TIE, and LISA are used to describe the instruction sets or parts of the instruction sets, and other characteristics, of processors, often to be generated via an automated processor generation flow. These may be fairly generic in their instruction set, or highly application specific. Although some automated processor generation tools will take a C program as input and generate a configured, extended, application specific processor (ASIP) as an output, this is an alternative to classical High-Level synthesis, not really comparable to hardware-oriented HLS. Among other differences, any of the generated processors is usually able to run any C code, even C code vastly different from the C code that may have been used to configure the processor.

It’s good to compare different approaches to implementing functionality defined in C/C++ or other high level languages in an application oriented way, but it is important to remember that the different methods on offer represent different points in a pretty wide tradeoff space. And one person’s apple is another person’s orange!


Vincent Van Gogh, Still Life with Fruit (The Art Institute of Chicago)


  1. Steve Leibson:

    Grant and I are in complete agreement and have double-teamed on this topic. My response is here: http://www.edn.com/blog/980000298/post/680033468.html

  2. Sunil Ashtaputre:

    Designers are building application-specific custom hardware, they have been doing it for many years, and they will continue do it for many years into the future. Configurable processors do have a place for some types of designs. But the killer-app for ESL is synthesis of the application-specific hardware. RTL Synthesis became a $400M market, and enabled markets like Power Analysis, Physical Synthesis, RTL Verification, RTL Linting, Equivalence Checking, etc worth > $1B. HLS is on the verge of repeating this at the next higher level of abstraction

  3. Grant Martin:

    Sunil, thanks for your comment. I think (as I also commented on in Steve’s blog, in response to your note) that it remains to be proven what the ESL “killer apps” will be. Right now, there is growth and steady progress in both Virtual Platforms/Prototype and High Level Synthesis, but neither looks to me, based on current evidence, as likely to overtake the RTL Synthesis and RTL design toolset in terms of revenues – at least, not until some very far future at which point the whole industry may be different. There is too little evidence in the public domain at this time to be talking about killer apps for ESL, in my book.

    Best, Grant

  4. Jakob Engblom:

    If I understand the argument correctly, the idea here is that a customized processor is an alternative way to go from “piece of C code that is important” to “something that runs in a chip in a product”.

    The alternatives are:

    1. Take C, manually convert to HDL.

    2. Take C, automatically convert to HDL (the synthesis idea).

    3. Take C, run on some processor core that you already have (RISC or MCU or DSP or whatever).

    4. Take C, and create a more or less heavily customized processor to run on, with a fair amount of automatic tool support (Tensilica approach).

    5. Take C, and a tool like LISA, and design a custom processor to run the code faster. Essentially a manual version of 4.

    6. Take C, look at algorithm, inventory existing IP blocks to to solve the problem. Or subproblem. And recode the C to use these blocks.

    N. Take any of the above, and replace “C” with assembly (CriticalBlue), UML, Matlab/Labview, ML, Excel, etc.

    In some sense, you would say that ESL should cover all these ways to getting from algorithm to some kind of hardware and help you find at least as a decent path (“optimal” is too strong a word, I would say anything that works even a single order of magnitude faster than a fairly general processor running a program would considered OK).

    So the debate is really about the scope of ESL? I can see all the approaches above having merit in some project and some point in time.

    I might well be that the true ESL breakthrough comes at a completely different place than the chips. Board-level and system-level design seems even more important currently. Chips you can always buy, physical design and software you have to do yourself to create a distinct total product.


  5. Grant Martin:

    Jakob, that is a good summary of many of the ways of taking function into an implementation. The book I wrote with Brian Bailey and Andrew Piziali and a host of contributors: ESL Design and Verification (Elsevier Morgan Kaufmann, 2007) goes into several of these alternatives when reviewing ESL synthesis. Also, the dialogue on this blog a while back on Design Space Exploration, pointing to Frank Schirrmeisters blog, is an interesting one that also goes into the many ways of implementing functions.

  6. Mike Meredith:

    Grant, I don’t disagree with your points at all. I’m sorry I was misunderstood. I didn’t intend to take a narrow view of ESL synthesis at all, indeed, my purpose in listing all the various languages etc was to take a broad perspective on the “higher abstraction than RTL” implementation space and point out that there’s a lot of innovation going on right now.

    My other point was not to insist that there was only one correct answer (although marketing hyperbole may have gotten the better of me). My point was that these blooms of innovation create a lot of interesting options, and are generally (always?) followed by a period of consolidation in which users sort out what the important use models are and which approaches serve those use models best.

    In general, I think the long-term tradeoff that users will make in deciding how to implement new functionality is performance+power vs flexibility (ie programmability).

    There’s definitely a place for implementation of a new function as software-only and as hardware-only and given the huge gap in performance+power between these two I expect there’s a place for a hybrid approach, which I take Tensilica’s offering to be.

    There’s clearly room for more than one approach in this (broadly defined) space, but I counted 16 companies offering some kind of “higher abstraction than RTL” implementation approach at DAC. Some of these are going to fall by the wayside because they don’t hit a big enough sweet spot to command a long-term place in the market.

  7. Grant Martin:

    Mike, Thanks for your comments and welcome to the discussion (more comments from you are always welcome, on any of the ideas that I raise, so please feel free to chime in at any time). You have raised some interesting additional points – interestingly, we have found the use of ASIPs to often combine flexibility (programmability) with sufficiently high performance and sufficiently low energy consumption that the hybrid approaches are indeed very attractive – especially in many dataplane processing domains.

    Your count of 16 companies offering higher abstractions at DAC is also interesting. I agree that they are all unlikely to survive – although I certainly hope a number of them do, because designers find their offerings worthwhile.

    Thanks again,

  8. Taken for Granted » Breaking out of the ESL box:

    [...] of ESL, covering more than the typical narrow focus on ESL synthesis that is often the norm (as I wrote about last fall).   He also discusses virtual prototyping, software-related aspects, and mentions [...]

  9. Leibson’s Law » Blog Archive » Is Algorithmic Synthesis the One True ESL Path? A Clue: No:

    [...] path to ESL (electronic system level) design. T’ain’t so. As my friend Grant wrote: I am sure everyone knows the old saying “When all you have is a hammer, everything looks like … In this blog entry, I’m going to take a crack at making the argument that there are at least [...]

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>