It’s a done deal.
OK, maybe not done, but getting done. It’s the long tail, the asymptote, the 20% that takes 80% of the effort.
Put simply, it’s mature. Or -ing.
Having just announced a new Blue Book (more on that in a minute) and incorporation into TSMC’s Reference Flow 11, Mentor is heralding the coming of age of electronic system-level (ESL) design aka High-Level Synthesis (HLS) aka C-to-RTL, most notably in the embodiment of their Catapult C tool. Taken at face value, and given the sketchy history of this technology, this is actually a big deal. However, there are others that may have reason to say, “Not so fast!” It remains to be seen whether there is consensus on this fact.
First, what does it mean for “tools” or “methodologies” to become mature? This generally means that the major technology developments necessary to make a technology useful are in place; further work involves refinements. A debatable corollary to that would be that it’s no longer an interesting technology to work on since the cool stuff has been done.
Maturity might also suggest that various purveyors into the market have more or less the same capabilities and compete more on subtle technology differences like quality of results (QoR) or tool performance. It could even suggest that pricing becomes a more important component of the sale, although maturity isn’t exactly the same as commoditization.
If true, this has been a long time coming. The most widely recognized of the early C hardware synthesis efforts was Handel-C, developed in the latter ‘90s at Oxford and commercialized by Celoxica. (Which was, ironically, renamed from ESL: Embedded Solutions, Ltd.) Most of the focus was on FPGAs. Handel-C was seen as a nifty little language at the time, but it never really hit its stride as a serious methodology for a number of reasons, including the fact that much of the parallelization was done by hand and annotated into the code itself. It also didn’t address the untimed-C problem, which was a bigger prize.
Moving into the early 2000s, there were a number of tools burbling about, from big companies and small, all trying to address the same vexing problems. The one that seemed to reach escape velocity more than the others was Mentor’s Catapult C (which, coincidentally, now benefits from the legacy of Handel-C via its purchase of the C synthesis assets of Agility, erstwhile Catalytic, who bought Celoxica). And yet, C-to-RTL seemed forever doomed to be one of those technologies that never quite lived up to hopes and expectations. HLS has left in its wake smoking piles of disappointment as promise after promise of designs simplified went unmet.
As the dust settled and various pretenders to the crown found other things to do, the most notable survivors were Mentor, Impulse-C (focusing on streaming C), and Synfora. And then, just to shake things up, AutoESL showed up. And, lest we forget, Cadence also has also fielded a C-to-Silicon product (although you mostly don’t hear as much about it – unless you write an article without mentioning it). CriticalBlue also synthesizes coprocessors from software to hang off the microprocessor bus.
It’s hard to tell how much anyone is selling since all of these businesses are either captive divisions or privately held companies, none of which must disclose their results. However, given size and rumblings, it wouldn’t be surprising to find Catapult C as the current front-runner (although early rumors of AutoESL’s success are also bullish).
But this is all market stuff, for the most part. What are the signs that Mentor sees that tells them that the technology is mature? Well, first off, it makes a good story – not to take anything away from the tool, but we must remain aware that this is a marketing message that plays to Mentor’s advantage, given the fact that they’ve survived a bruising history.
Plugging the holes
But let’s run with it and test the evidence. One of the first signs that a technology is not mature is the fact that gaping holes remain in the methodologies it enables. Mentor points to the history of its own capabilities with Catapult C. At the beginning, C synthesis was possible only for blocks of algorithmic C. Filters are probably the best example of the kind of circuit that it addressed.
So you could do a filter, but then you had to manually stitch the filter into the rest of the system. Gaping hole. After some work targeting wireless and video applications, they worked on allowing multiple blocks, but still, it was all algorithm-centric. Said differently, you could design the dataflow but not the control flow using C. Gaping hole.
Then they addressed control flows. And since then, they’ve addressed optimization for low power as well as performance (a prior parametric gaping hole). And, as far as C was concerned, that’s where it ended. C++ is part of the deal, and the hardware embodiment of C++ is SystemC (or, said another way, SystemC isn’t C; it’s just an HDL that looks like C). Having addressed that, they’re basically announcing “Mission Accomplished” (which history suggests might be risky).
None of this speaks to how well they address all of these capabilities (customers make that judgment), but, on these terms, you could say that they’ve plugged all the holes with respect to C/C++. But if you take HLS to be more than C (as does Synopsys) and to include any high-level language, then M (MATLAB) is missing. (Ironically, Synopsys is the only of the three majors to cover M with its Synphony HLS tool, even though it’s the only one of the three biggest not to cover C.)
Mentor claims that the industry has settled on two standard languages, C/C++ and SystemC, but the Mathworks might have other thoughts on that (as would a not insignificant number of engineers). It could also be argued that M is supported by M-to-C conversion prior to C-to-RTL conversion; that argument would likely be rebutted in terms of the likely quality of results given two steps instead of one.
Another piece of evidence Mentor points to is the fact that they have a big ecosystem – it’s not just a few companies toiling valiantly against the tide. And TSMC has now blessed ESL in its Reference Flow 11.
And, as far as Mentor is concerned, ongoing work is now focused on refinements like getting more efficient results in less time. This takes things into the tweaking phase, the same reason that place and route and FPGA tools never completely stagnate. They may not be adding major new capabilities, but they’re trying to do things faster and better.
Finally, Mentor has debuted, with great fanfare, a new HLS methodology book: they call it the High-Level Synthesis Blue Book. (Where I came from, bluebooks were small and blank and never evoked good times.) Having had the good fortune to be afforded a glimpse into the contents, it seems to be a pretty good treatment of a topic learned from experience. The author, Michael Fingeroff, is one of their technical marketing engineers and has apparently been deeply steeped in this by helping customers figure this stuff out.
It starts by making clear what this is all about: style. Which is one of HLS’s weaknesses. It’s not about writing C, it’s about writing it in a way that lets the tool know what to do. The focus claims to be on C++, although many of the examples are just straight C (which is, technically, legal C++). You get an education on the hardware-related things that don’t come in your standard C programming class: bit-accurate types, loop unrolling and pipelining, scheduling, memory, hierarchical design; it finishes up with coverage of the poster children of HLS, the venerable filter and the FFT.
How this relates to the maturity question is the fact that all of this methodology took years to evolve. This stuff wasn’t easy and it wasn’t clean, and engineers had to figure out the best ways to do things. This is Mentor’s (or Mr. Fingeroff’s) compilation of those best practices. Interestingly, in my scan of the obvious areas, including the introduction by Mentor’s Thomas Bollaert, there is no specific mention of Catapult C. The only catch is the fact that coding style tends to depend very highly on the tool being used. There are undoubtedly many things in this book that are universal; there are probably others that work well only if run on the Mentor tool.
So is HLS mature? Or maturing? I think there’s some merit to the claim if you restrict the conversation to C/C++. Yes, there is a new player, but much of AutoESL’s messaging centers around QoR, which supports the general maturity thesis. And, from a hardware designer’s standpoint, you could argue that all of the major holes have been closed.
There’s even been benchmarking by BDTi – something that external arbiters tend to wade into only once nature has eliminated the weakest from competition. It focused on FPGAs rather than SoCs, and it was as much a look at workflow as results, but that itself speaks to some level of stability.
There’s only one remaining giant, gaping, humongous hole. And it’s one everyone agrees on: even though you can design hardware with C, you have to be a hardware engineer. This is not for software engineers. And most believe it never will be. So you can conveniently exclude that hole and say, “We’re done.” But there are those that secretly covet the ability to allow software designers to create efficient hardware without becoming hardware experts. It’ll be a wide open game if that happens.
So perhaps it’s fair to say that HLS has more to do and that it hasn’t reached retirement age yet, but that it’s old enough to enroll in AARP, which, despite its name, lets in remarkably young people (giving it much more dues revenue and political heft). In which case, its first issue of Modern Maturity may already be on its way.