The Wiretap Intercept No. 110908
opinions and skeptical speculations too small to fit into an Industry Gadfly column
Subject: ChipVision developer agrees C synth is like teaching a dog to dance

> Why is C-based HLS limited to being a point tool in a niche market?
>
> It's not a good approach to complex, general-purpose hardware IP and
> SoC design.  When designs fall within its sweet spot (i.e. simple
> loop-and-array-based algorithms like IFFTs/FIR Filters/etc), it can have
> impressive results.
>
> But, C-synthesis fundamentally struggles, and often fails, when it comes
> to more complex, data-dependent algorithms like the new adaptive wireless
> algorithms, Reed-Solomon, Viterbi, H.264, compression, encryption; and
> especially for memory subsystems/caches/controllers, DMAs, bus protocols,
> networking interfaces, network-on-chips, interconnects, arbiters, CPUs,
> controllers, etc.
>
>     - George Harper of Bluespec, Inc.
>       http://www.deepchip.com/wiretap/110827.html


From: Andrew Stevens [formerly of ChipVision]

Hi John,

Having personally written the C synthesis scheme and operation scheduler for
'PowerOpt' at the now sadly defunct ChipVision (and I 'nearly' worked on
Catapult C at Mentor - hi Shawn!) I'd like to add some further comments on
the Mentor/Calypto deal.

C SYNTHESIS IS A KLUDGE

George Harper's remarks are well observed.   However, the problems are not
really related to particular styles of algorithm.  For example, the sweet
spot for later versions of my PowerOpt was, if anything, in relatively
control-intensive designs.  Some of the problems with C/C++ and SystemC
synthesis are, alas, more fundamental: C/C++ and SystemC themselves.

To put it bluntly: C/C++ are rotten languages for describing parallel
computation of any kind and SystemC is a kludge!

C and C++ deeply embed an essentially single-threaded shared-memory
computational model.  Despite many C/C++-based efforts, it is no surprise
that multi-threaded programming has only become mainstream with the
availability of programming languages (e.g. Java, C#) in which both the
language itself and the standard runtime environment are based on a
well-defined multi-threaded model of computation.  Programming micro-
and thread-level parallelism for hardware designs is even more of a
stretch for those poor old, accidental and unintentional, universal
work-horses C and C++!

As for SystemC... well, like training a dog to dance, it is surprising to
see how far you can get building a programming language using C++ template
libraries and a co-routine library!   In the end, however, there's a limit
to what can be achieved...

Finally, just as system/embedded software is C-centric world, hardware
design revolves around Verilog/VHDL.   Adding a 2nd/3rd design language;
*especially* one with a massive semantic 'impedance mismatch' like C++,
can never be a really satisfactory solution.  Stuff that should be
simple becomes fraught with complexity.

THE MENTOR CALYPTO DEAL

When all is said and done a behavioral synthesizer is basically just an
optimizing/parallelizing compiler, comparable in complexity to a modern
high-end vectorizing / parallelizing compiler for conventional CPUs.

As with super-fancy compilers, there IS an alternative to paying the
license fee: programming directly at a lower level.  As we used to say
in ChipVision it's "the outsourcing option".  This places a hard ceiling
on the price customers can be expected to pay per year/seat.  Given that
the (very real) gains are partly offset through frictional losses (some
inherent, some C related) this ceiling is not terribly high!

From the perspective of a high-cost/high-margin EDA supplier the way forward
is clear.  You have add more value by doing stuff that's hard to do well in
RTL.   Power optimization - the path we followed at ChipVision - was one
obvious possibility.  This is very likely a key factor in the Calypto swap.

Another route to adding value, complicated by SystemC's messiness but
possible, is seamless integration into ESL flows.

GARY'S ESL & HLS

Despite the problems I personally still see behavioral synthesis' time has
come.  RTL design, like programming in Fortran IV, is hard to beat.  But,
executed properly, a higher level approach can reduce effort and design
complexity and, in mature implementations, will produce objectively better
results.

Perhaps the next step in the continued development of SystemVerilog might
be some well-chosen extensions to allow clean integration of behaviorally
synthesized elements.  They is *almost* enough there already...

AN INTERESTING FREE ALTERNATIVE

Question: What if gcc or LLVM appeared with a characterization-driven
scheduler and a Verilog backend?  A good-enough 80% solution to produce
basic synthesizeable RTL available 'free'.

Now that might give many project leaders an interesting alternative ...

Certainly, for $100K per year per seat you want it to make the coffee
and kiss the backend lead.  Free software where you (might) pay some
support EUR/$ only if/when you decide to actually keep the results on
the other hand...

C++ compilers used to be expensive products laboriously sold and
licensed by high-margin / high-cost suppliers too.

    - Andrew Stevens
      formerly of ChipVision                     Finsing, Germany

  Editor's Note: Before it went out of business, ChipVision used to
  specialize in selling C-based power optimization tools.  - John

      An archive of prior intercepts       Next intercept       To reply or send a story to John

 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)