There's a new post worth reading for anyone
interested in the current state of high-level synthesis (HLS).
http://www.deepchip.com/items/0479-04.html, apparently posted by Mentor.
The article highlighted the results
of a worldwide survey that asked 1500+
engineers their reasons for considering/using HLS. 800+ engineers responded,
overwhelmingly citing "faster time to RTL" and "faster verification" as the top
two reasons. This is
excellent news for everyone with a stake in the HLS technology market. These
results clearly support the notion that HLS is a rapidly emerging market with a
promising future. The article claims that use of ANSI-C/C++ (vs.
SystemC) makes Catapult-C inherently superior to other SystemC HLS
In my view, this went too far, to
the point of being misleading...If you were to ask EDA industry
folks/customers who have known me a long time, whether SteveS tells the truth,
you'd probably get a smile and the comment "maybe a little too often". I have a
reputation for being pretty frank (whether I'm wrong or right) and more than
once have gotten in "hot water" because of that. So, for whatever it's worth,
let me tell you what I really think.
While for a limited subset of (i.e.
datapath-logic intensive) designs the
arguments have some merit, as design-complexity increases and/or
control-logic is added, the potential advantages of C/C++ become significantly
outweighed by SystemC's natural support for hierarchy, concurrency, resets,
timing, etc. These latter characteristics are essential when trying to specify
any functionality that is targeting hardware. In fact, across numerous customer benchmarks, without mentioning numbers, CtoS fared EXTREMELY well, and you can deduce what
'extremely well' means. For highly datapath-intensive
designs (e.g. FIR filters, FFTs) CtoS area/timing results were right on-par with
Catapult-C. While for control-intensive, or mixed control-datapath designs,
CtoS results were always superior.
The problem is, in marketing Catapult-C, there seems to be running a
Fear-Uncertainty-Doubt "FUD" campaign against SystemC, and it's customers/users
who will suffer most from that. For example, claiming SystemC
requires designing at a lower abstraction than C++ is misleading. The article
neglects to mention that SystemC is a *superset*
(rather than a subset) of C++. For datapath code, CtoS (and probably other
SystemC HLS tools as well) uses the exact same untimed, high-abstraction C/C++
as Catapult-C. Moreover, CtoS (and probably other
SystemC HLS tools) allow designers to add the necessary SystemC constructs in
order to specify the hierarchy, concurrency, timing information, resets, etc.
which are essential for any complex, multi-state, designs. Contrary to the article's assertions about SystemC HLS
tools, CtoS does not require (or even recommend) low-abstraction code or
hard-coded timing unless dictated by the protocol. CtoS prefers that
designers enter information at the highest level of abstraction possible,
because that allows CtoS maximum flexibility to move logic around for better
resource sharing, area-power-timing optimization, and IP
Every customer considering an
investment in HLS to realize productivity and IP reuse gains ought to care a lot
about this. Given the current economic climate, customers are under intense
pressure to increase designer productivity, automate IP reuse, and
HLS is receiving a lot of interest. Adopting HLS requires not only a major
investment in HLS tools, but also in teaching engineers new design skills and
methodologies. Prospective HLS customers have a lot
to consider in deciding what HLS solution to adopt.
I honestly believe CtoS is the best
HLS technology on the market today, but I want customers/users to
judge for themselves. My hope is by pointing out FUD such as this, I can help
customers make informed decisions and select the best HLS technology for *their*
needs. If once in a while customers decide to pick an HLS tool other than CtoS,
that's OK. Variety, choices are good for customers...but I'm confident that
enough will! ;-)