( ESNUG 481 Item 10 ) ------------------------------------------- [05/08/09]
Subject: ( ESNUG 480 #2 ) Mentor tells Synfora get CatC facts straight
> Just to clarify, our Synfora Pico Extreme competes directly with Mentor's
> CatapultC, Forte's Cynthesizer, and Cadence's C-to-Silicon tools. ...
> ... Our big claim to fame is that PICO can do some amazing architectural
> optimizations at the C level on complex, multi-block designs.
>
> - Vinod Kathail
> Synfora, Inc. Mountain View, CA
From: Bryan Bowyer <bryan_bowyer=user domain=mentor not calm>
Hi John,
After reading through Vinod's ESNUG letter, it occurred to me that he missed
his calling as a career politician. Along these lines, I have taken the
liberty of modeling a "Fact Check" like how CNN did during the recent US
Presidential debates.
> PICO is the only tool w/ 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... The compiler will then automatically
> allocate and schedule TCABs at the next level of hierarchy.
>
> ... no other C/SystemC synthesis tool on the market can do this.
FALSE. While Synfora's TCAB functionality is an attractive feature, it is
false to say the Catapult C does not manage arbitrary levels of hierarchy.
Hierarchy is fundamental to C synthesis; CatC has supported it for years.
Catapult users can specify a "procedure" as a building block. Catapult
consumes sequential C++ and interactively allows users to split the design
into hierarchy. Any function, loop or even scope can be pushed into a level
of hierarchy without any changes to the C++ source. Furthermore, Catapult
carefully inserts synchronization into the hierarchy to maintain sequential
equivalence with the C++ source, while still allowing system-level
pipelining and parallelism.
Here's a specific example of CatapultC's hierarchy provided by Slumdog
Billionaire in ESNUG 481 #7:
"I used Catapult hierarchy in one of my designs, primarily to model 2 blocks
running concurrently. I used its ac_channels for data transfer between the
blocks. Ac_channels lets the one block know when the data is available from
another block as their outputs may not be present for each clock cycle."
"CatapultC also allows you to use hierarchy to optimize and debug. In this
bottom up approach, you can restrict the scope of the design while Catapult
optimizes/balances your area and throughput requirements. This helps to
isolate the blocks so you can adjust latency to first output and area
requirements on a block-by-block basis. That helps us in integrating these
cores with top level design."
> 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.
>
> ... no other C/SystemC synthesis tool on the market can do this.
FALSE. High-level synthesis tools have been building parallel hardware
from sequential sources for decades. I'm only aware of a few of them that
support single-threaded C, but Catapult is one of them.
> Mentor's CatapultC allows you to build block level designs, and then
> allows you to stitch them together using their "SL" product.
FALSE. Vinod is incorrectly describing a Catapult flow and capabilities.
Catapult C supports both a top-down flow, where a multi-block design is
synthesized in a single pass, as well as a bottom-up flow, where previously
synthesized units can be scheduled in a larger design. This lets designers
integrate legacy RTL in addition to Catapult-synthesized RTL.
Additionally, Vinod's use of the term "stitching" greatly understates the
functionality. CatC users write an ANSI C++ source consisting of function
calls, loops and scopes, sharing data through C++ variables. This data
flow implies the connections between the multiple blocks.
> CatapultC has no inter-block parallelization & optimization capabilities.
FALSE. Catapult generates multi-block parallel hardware with distributed
control. This allows blocks to run in parallel and the sub-system to be
pipelined. Catapult also supports inter-block IO optimization through our
"Channel Synthesis" technology.
> Here's what PICO does automatically, which I believe Mentor CatapultC,
> Cadence C-to-Silicon, Forte 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.
FALSE. Vinod "believes" wrongly again. CatapultC provides C++ source
linting, such as detecting out-of-bounds array accesses. In addition,
Catapult's source is standard C++ meaning users can leverage off-the-shelf
tools such as Purify, Valgrind, Microsoft Visual C++, for a full range of
C++ linting.
Vinod is blaming other tools for not having Synfora's flaws. Synfora's
source code requires pragmas to model bit-widths. As such, Synfora makes
functional changes (i.e. bit-widths) during synthesis which means their RTL
output will not match the original C, resulting in the need for Synfora to
perform additional linting checks
In contrast, with Catapult, designers use off-the-shelf bit-accurate
datatypes (ac_datatypes or sc_datatypes) that will simulate bit-accurate and
"numerically correct". The net result is the Catapult users verify bit
accurate behavior at the C++ source while Synfora users cannot verify bit
accuracy until after they go through Synfora's proprietary compiler.
> Here's what PICO does automatically, which I believe Mentor CatapultC,
> Cadence C-to-Silicon, Forte Cynthesizer can't do. ...
>
> 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.
> 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!
FALSE. Catapult also provides a mechanism to automatically inject wait
cycles in the design as part of the SCVerify flow. The main difference is
that Catapult gives the user more control over the timing and length of the
wait statements.
> 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.
FALSE. With Catapult, users can change FIFO sizes, memory mapping or target
memory hardware without changing the C source.
> 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.)
FALSE. First, Catapult's users are doing BIG multi-block designs. Here is
one from Captain America in ESNUG 477 #3:
"We do our designs hierarchically where we define IP blocks first, then
integrate them. For example, our design may have 5 blocks and we want to
connect them without worrying about detailed timing. With CatC, we use AC
channel to construct the channels and connect the blocks... This is
especially useful for multi-rate design, where our blocks are running at
different clock speeds."
Second, one of CatapultC's major advantages is its strength in verification;
which I discuss below when I address Vinod's comments on source languages.
Third, Catapult does do system-level optimizations. For example, we have
channels between blocks, and we will optimize the communication between them
based on the rate at which the blocks run. This type of optimization is
mandatory to yielding good results.
> ... in a joint tutorial I did with ST at DAC last year, ST stated 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.
TRUE. But my jaw dropped when Vinod admitted 5 bugs. In 300+ ASICs built
with Catapult, I'm only aware of one single ECO, and it was caused by a
functional error in the C++ source, not Catapult. From Kryten of the Red
Dwarf in ESNUG 480 #6:
"An important measure of Catapult C maturity was its C vs RTL equivalence.
We had no issues here. Every time our RTL behaved badly, it turned out to
be bugs in our C source and not in Catapult C synthesis."
And from Slumdog Billionaire in ESNUG 481 #7:
"I haven't run any problems with the functional correctness of Cat's
C-to-RTL translation, which is exactly how a high level synthesis tool
should work."
The survey results which Mentor's Shawn McCloud discussed in ESNUG 479 #4
highlighted the designer community's high expectation for verification
improvements through the adoption of C synthesis. But it essential for your
readers to understand that this verification productivity can only be
achieved if 1) the input source can be exhaustively verified and 2) your
synthesis tool preserves this verified behavior in the RTL.
As I discuss below, not all languages provide this same efficiency.
> Legacy dictates that ANSI C/C++ is the right language for design because
> that's where most customers' algorithms start.
MISLEADING. I'm sure Vinod would like to lump ANSI C and ANSI C++ into the
same bucket but doing so would completely ignore all the drawbacks of C and
the advantages of C++.
Synfora uses ANSI C as their source code while our Catapult C uses ANSI C++.
There is a big difference.
Synfora is forcing designers into a very limited language and coding style.
It is possible to use plain C; if you have the patience to write more lines
of code than you really need and if you are willing to live with cluttered
& poorly reusable design source code. But verification of the input source
becomes more difficult and there is more chance of errors due to the
inefficiencies, so it's no surprise that bugs slip through with Synfora.
One of the best known merits of C++ is the support for classes and object-
oriented programming. C++ offers many other valuable additions such as
operator overloading or templates. All those features enable abstraction,
code compactness and code reusability through generic programming. The net
result of using C++ instead of C is that users achieve a more abstract,
reusable and easily verifiable source code.
All of Vinod's comments aside, the bottom line is real user results; about
getting to FULLY-VERIFIED RTL substantially faster than hand-coded design.
Kryten of the Red Dwarf in ESNUG 480 #6: "This was our first experience in
C level design, yet we were able tape-out our first test block in 40% less
time than we would have needed with our usual RTL flow. The entire project
from designing C to fully verified RTL took only about 6 weeks with CatC.
In contrast, manually creating and verifying a similar sized block in RTL
(30K-40K gates) took us about 10 weeks."
Slumdog Billionaire in ESNUG 481 #7: "It took me about 2.5 months to create
my first fully verified decoder. In contrast, hand coding a decoder in
VHDL would have taken 6 months, roughly a 60% savings in TTM."
I'm all for chest thumping (I am, after all, in Marketing), but even career
politicians have a higher true/false ratio than Vinod did in his ESNUG post!
- Bryan Bowyer
Mentor Graphics Wilsonville, OR
Join
Index
|
|
