Page 58

EETE DEC 2013

HLS is dead, long live HLS? Time for a revolution By Matthieu Wipliez If you pay atte ntion, you will find that there is something a bit amusing regarding the marketing of High-Level Synthesis (HLS) solutions for C/C++/SystemC. For years, each time an EDA company created a new HLS tool, it claimed that it was better than the ones before, that HLS was finally “ready for prime time”, that it now had “unique quality of result”, or was bringing at last a “10-fold improvement in productivity”. Of course there is often little actual evidence to substantiate these claims. How could there be? After all, you can replace a king by another one as much as you want, it will not make monarchy any better an idea. Now, let us make one thing clear: HLS vendors are correct in saying that the complexity of chips is increasing dramatically. Moore’s law is still going strong and is expected to continue to do so for almost ten years (and as always who knows what will happen in ten years?). This means that while designing whole chips at RTL entirely by hand from scratch is still possible, it is no longer profitable to do it, as it will require far too much manpower. Semiconductor companies did not switch to HLS though, they have instead turned to using IP (Intellectual Property) cores in a “divide and conquer” manner so they do not have to design huge amounts of new silicon over and over. That worked fine until the complexity of IP started to increase too much: there are always more protocols or standards to support, and there is a very real limit to the number of engineers that can work in parallel on a hardware design, after which the critical path from specification to silicon cannot be reduced further if you keep using RTL. So we must infer that semiconductor companies “We’re tired of the HLS monarchy: it is time for a revolution in hardware design” will have to turn to HLS. But what HLS? First we have HLS of C/ C++ code. What is the benefit of using C or C++ languages? That software engineers can describe hardware? Granted, they may well be able to describe hardware at the so-called algorithmic level of description with ‘for’ loops and arrays, but this is only good for regular DSP algorithms (filters, FFT, etc.). Of course, high performance often require them to annotate their code with very hardware-related directives. How does that benefit anybody? And what about any other design but DSP? What is the other benefit of using C or C++? That hardware designers can use pointers to exchange data between entities? Another very popular trend is HLS of SystemC code. It does solve a few problems compared to starting from C/C++. SystemC includes the notions of entities, ports, channels, etc. It still shares the problems inherent to the algorithmic level of description: for instance, compiler optimizations can make it very difficult to predict the scheduling of an untimed description, which does not help interacting with a cycle-accurate implementation; changes at the source level can also result in dramatic changes in the generated design, making ECO troublesome. The advantage of SystemC is that it allows the description of lower-level and/or more control-oriented algorithms, in other words if the algorithmic level of description does not give useful performance (which is very probable when dealing with anything other than DSP), or is not appropriate (e.g. when implementing communication protocols) one can resort to RTL coding in SystemC. In addition to being about as natural as string manipulation in Verilog, we can wonder how “high-level” this really is. And again, this is without taking the steep learning curve of the C++-based (seriously, C++ again?) language/framework. The truth is that High-Level Synthesis of C/C++/SystemC is not, and by its very nature, can never be satisfying outside of the DSP world. If you are willing to use something other than C/C++/SystemC there are some interesting HLS tools out there, but many are limited by the complexity of the language they use. Truth is that as hardware designers, we need, and deserve, more. Matthieu Wipliez is CTO at Synflow - www.synflow.com - he can be reached at matthieu.wipliez@synflow.com Publisher André Rousselot +32 27400053 andre.rousselot@eetimes.be Editor-in-Chief Julien Happich +33 169819476 julien.happich@eetimes.be EDITORS Nick Flaherty +44 7710236368 nick.flaherty@eetimes.be Christoph Hammerschmidt +49 8944450209 chammerschmidt@gmx.net Peter Clarke +44 776 786 55 93 peter.clarke@eetimes.be Paul Buckley +44 1962866460 paul@activewords.co.uk Jean-Pierre Joosting +44 7800548133 jean-pierre.joosting@eetimes.be Circulation & Finance Luc Desimpel luc.desimpel@eetimes.be Advertising Production & Reprints Lydia Gijsegom lydia.gijsegom@eetimes.be Art Manager Jean-Paul Speliers Acounting Ricardo Pinto Ferreira Regional Advertising Representatives Contact information at: http://www.electronics-eetimes.com/en/ about/sales-contacts.html European Business Press SA 7 Avenue Reine Astrid 1310 La Hulpe Tel: +32 (0)2 740 00 50 european Fax: +32 (0)2 740 00 59 business press www.electronics-eetimes.com VAT Registration: BE 461.357.437 RPM: Brussels Company Number: 0461357437 © 2013 E.B.P. SA ELECTRONIC ENGINEERING TIMES EUROPE is published 11 times in 2013 by European Business Press SA, 7 Avenue Reine Astrid, 1310 La Hulpe, Belgium Tel: +32-2-740 00 50 Fax: +32-2-740 00 59 email: info@eetimes.be. VAT Registration: BE 461.357.437. RPM: Nivelles. Volume 15, Issue 11 EE Times P 304128 It is is free to qualified engineers and managers involved in engineering decisions – see: http://www.electronics-eetimes.com/subscribe Copyright 2013 by European Business Press SA. All rights reserved. P 304128 50 Electronic Engineering Times Europe December 2013 www.electronics-eetimes.com


EETE DEC 2013
To see the actual publication please follow the link above