( ESNUG 480 Item 2 ) -------------------------------------------- [04/01/09]
Subject: ( ESNUG 479 #4 ) Synfora PICO vs. CatapultC/Cynthesizer/CtoSilicon
> A total of 820 engineers responded, and below is what they told us. Since
> they could pick 2 answers, the total is ~200% rather than 100%.
>
> "What are the 2 biggest reasons to use High Level Synthesis?"
>
> Faster time to RTL : ######################## 64%
> Faster verification time : ################## 49%
> Fewer engineering resources : ############ 31%
> Fewer Bugs : ####### 19%
> RTL better than hand-coded : ##### 14%
> Faster ECO implementation : ### 8%
> Better product differentiation : ### 7%
> Other : ## 4%
>
> The results? Almost 2/3rds (64%) recognized that high level synthesis
> will get to RTL code faster.
From: Vinod Kathail <vinod.kathail=user domain=synfora hot mom>
Hi John,
Like Shawn's CatapultC users, our PICO Extreme users have also indicated
that verification is an important part of their C synthesis flow. They tell
us that synthesized IP has fewer bugs than hand-written RTL. For example,
in a joint tutorial I did with ST at DAC last year, ST stated that they
found 5 bugs in a design done using PICO whereas they found 30 bugs in a
hand-written RTL design of a similar complexity.
Also, users like that having C as their combined design and verification
language means running simulation is fast and virtually free. That is, it
helps cuts back on needing more of those pricy VCS/NC-Sim/ModelSim licenses!
Just to clarify, our Synfora Pico Extreme competes directly with Mentor's
CatapultC, Forte's Cynthesizer, and Cadence's C-to-Silicon tools. For us,
"synthesis" is taking ANSI C and converting it to Verilog RTL. (To get to
a gates, you must run our RTL through Design Compiler, RTL Compiler, or
Blast Create.) Our big claim to fame is that PICO can do some amazing
architectural optimizations at the C level on complex, multi-block designs.
Here's also what our users told us:
1.) Power, Performance and Area (PPA) are equally important.
2.) Hierachical Capacity is everything. It turns out mixing synthesized
RTL with your system can be a source of bugs, and so our users
want PICO to synthesize as large a design as possible. The plus
is you get better PPA because if PICO has visibility over a larger
context, it can find and exploit more optimizations.
- PICO is the only tool with Recursive System Composition (RSC),
which allows its compiler to manage arbitrary levels of
hierarchy in a design. The user can specify a procedure as
a building block, and the compiler will build it as a separate
module. We call these blocks TCAB's; Tightly Coupled Accelerator
Blocks. The compiler will then automatically allocate and
schedule TCABs at the next level of hierarchy. (This is a very
intuitive and familiar design style to hardware designers.)
- PICO also has some advanced parallelization abilities based on
decades of research at HP Labs. It can automatically extract
the correct multi-threaded hardware from single-threaded C
application in order to meet your target performance.
As far as we know, no other C/SystemC synthesis tool on the market
can do either of this. Mentor's CatapultC allows you to build block
level designs, and then allows you to stitch them together using
their "SL" product. This limits your designs to a single level of
hierarchy. Also, as far as we know, CatapultC has no inter-block
parallelization and optimization capabilities.
SystemC-based tools like Cadence C-to-Silicon and Forte Cynthesizer,
on the other hand, rely on the designer to explicitly express block
interaction using constructs provided by SystemC.
3. You must automate everything - the tools must do most of the work for
the user. Here's what PICO does automatically, which I believe
CatpultC, C-to-Silicon, Cynthesizer can't do.
- PICO has a "C linting" phase to automatically detect common errors
like bit-width overflow, uninitialized variables and out-of-bounds
array access. I believe the other C synth tools make you debug
these data errors at the RTL level, which is very time consuming.
- There are certain aspects of the design that you cannot verify at
the C level e.g., the impact of internal stall cycles on the final
result. So we added "perturbation checking" at the RTL level,
which automatically extends test vectors to verify that internal
stall cycles don't affect your result. The user doesn't have to
do anything. It's automatic!
- Users can explore the performance of their design with alternate
FIFO sizes and memory porting in PICO. This lets them do tradeoffs
between design size and performance. Again this can be very time
consuming to do manually, and I don't think Mentor/Forte/Cadence
does this.
John, our customers have told us that they want a C synth tool that does BIG
designs. Having a Mentor two-pass block-level/system-level approach means
that verification is messed up plus you never get system-level optimizations.
(Sorry CatC.)
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.
The acid test is to take a real world design like a motion estimation engine
or a multi-standard video Deblocking filter and see who is left standing.
It'll be PICO.
- Vinod Kathail
Synfora, Inc. Mountain View, CA
Join
Index
Next->Item
|
|
