( ESNUG 481 Item 3 ) -------------------------------------------- [05/08/09]
Subject: ( ESNUG 480 #2 ) Brett warns of CatC/Synfora ANSI-C dead ends
> Legacy dictates that ANSI C/C++ is the right language for design because
> that's where most customers' algorithms start. Having to do an ugly
> rewrite into SystemC sucks. In addition, SystemC verification is slow
> (compared to C/C++) -- sorry Forte Cynthesizer; sorry Cadence C2S.
>
> - Vinod Kathail
> Synfora, Inc. Mountain View, CA
From: Brett Cline <brett=user domain=forteds not calm>
Hi, John,
I finally stopped laughing at Vinod's ridiculous portrayal of the high-level
synthesis (HLS) market long enough to respond. Isn't he Synfora's CTO? I
thought these technical guys are supposed to have some credibility. Wow!
I guess I was wrong.
The center of Vinod's argument is verification. Great idea and extremely
import but he's completely left out the dirty little secret that these
so-called "ANSI-C" synthesis tools have -- they will actually make your
verification problem WORSE! ANSI-C/C++ is a software programming
language which means that it has several specific problems for use without
significant modification in a hardware design flow.
- First problem: ANSI-C does not allow bit-accurate data types. This
means that your "ANSI-C simulation" will not accurately model the bit
widths in your hardware block. You are limited to data types like
char, int, etc. Wouldn't it matter if your bit width was limited to
10 bits and you were using a 32 or 64 bit int and an overflow
condition occurred? Even Mentor knows that ANSI-C isn't good enough
for synthesis because they have their own language (we'll call it
"MentorC") that adds bit accurate data types. Of course, these are
not standard and they certainly are not "ANSI-C."
- Second problem: There's no way to model control logic in ANSI-C. I'm
not talking about your basic "if, else, case" type of control. I'm
talking about control that involves timing. For instance, just
modeling a typical I/O protocol in ANSI-C is all but impossible.
There's no way to wait on a clock edge for something to happen;
something critical in accurately modeling a design. Their way makes
you stick on the interface later in the process with no testing...
but more on that later.
- Third problem: ANSI-C simulations cannot deal with concurrency. This
is a huge problem! Their marketing team (or CTO evidently) will tell
you how much faster "ANSI-C" is -- but it isn't simulating your entire
design -- only a single block serially. If you are designing a simple
filter this may not matter. But, for any real design the blocks must
interact and that must involve some concurrency semantics. And, since
ANSI-C can't model any sort of complex I/O -- you never get to
simulate your interfaces with your ANSI-C algorithm. Is that really
verification?
- Fourth problem: PICO and CatapultC are block level tools. On the
surface this doesn't seem like a problem but ultimately it is the real
killer. The RTL created for each block with an "ANSI-C" tool must be
stitched together by hand in RTL. This will be the first time the user
gets to simulate all of their blocks AND THE INTERFACES together. This
is basically pushing the verification problem back to RTL and provides
no benefit ultimately -- and worse yet, it causes a ton of problems.
I just came back from two weeks in Japan and Korea where we met with several
customers there who have attempted to use some of these "ANSI-C" tools and
ultimately failed. The main reason (there were several) was because the
increase in design and verification effort and time once they actually
reached RTL! The "ANSI-C" pitch makes it look very easy to get started; but
it is very difficult to actually finish.
SystemC has solved these problems already and done so in a standardized way.
With SystemC you can use all of your existing algorithms in an environment
that meets the requirements for hardware design mentioned above. Using our
Cynthesizer with SystemC handles your entire design, including control and
datapath, multi-clock, etc. from a chip or system level -- not just
individual blocks.
One final point to clear this up once and for all: SystemC's not a language.
It is a class library that extends ANSI-C++ in a standardized way. So, if
you can write C/C++ -- you can use the SystemC hardware features and the
dozens of tools that support SystemC.
So, I really do appreciate all of Vinod's apologies in his email to you
and, on behalf of the readers, we accept since he has left out some of the
important facts. Perhaps he's up for a "promotion" to marketing guy.
- Brett Cline
Forte Design Systems Acton, MA
Join
Index
Next->Item
|
|
