( ESNUG 480 Item 6 ) -------------------------------------------- [03/06/09]
Subject: ( ESNUG 477 #3 ) A hesitant RTL designer trys out CatapultC design
> We first looked at CatapultC in 2003, but it was still fairly immature
> back then. We started using it on production designs almost 3 years ago;
> it is now a robust and mature tool. We're using it to make production
> chips directly from our C++ algorithms.
From: [ Kryten of the Red Dwarf ]
Hi, John,
Please have me and my company remain anonymous in this letter.
We've been using CatapultC for C-to-RTL synthesis for about 4 months on a
pilot project in the area of wireless short range communications. 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.
Our biggest concerns before moving to CatapultC were:
- Concern about the quality of a block produced automatically by C
synthesis and how I would integrate it in a larger design executed
with standard hand-written RTL digital and mixed signal flow. CatC
did fine. I have details below.
- I feared I would have to write "C-as-RTL", which is what you have to
do with SystemC. (This was not the case for CatapultC. You can work
almost directly in algorithmic C and get it to RTL.)
- Concern about long term product availability, support and roadmap.
This is extremely important if we invest in writing synthesizable-C
rather than an RTL library of functions. We cannot risk that our
C synth tool would be no longer supported in 2 years later; it
would be a disaster for our future chips.
The original reason we chose CatapultC synthesis instead of hand-coding our
RTL was a shortage of RTL designers!!!
Besides that (which really is a company issue) we like the idea of having a
pure design flow that goes from Matlab to RTL via C with a lot of code
reuse. (i.e. from algorithmic design/modeling to hardware development.)
CatapultC and Matlab/C database used the exact same source files. We just
integrate the RTL generated by Catapult for a specific IP into our larger
design which then follows our standard production/prototyping flow. CatC's
"interface synthesis" gives us the option of several handshake mechanisms
at the block interfaces thus allowing a easy connection to external IPs.
RTL, Catapult C, SystemC, and C++:
When you hand-write RTL, you need to decide upfront if your implementation
is serial, parallel or pipelined and any modification to such structure
usually implies a heavy redesign. When you write C/C++ for Catapult, you
normally don't care about that because in C synthesis you'll be able to
choose different structures, etc. and then compare the relative results.
It was important to us that we were not limited in C/C++ styles when coding
our algorithmic C. Turns out putting our code into a synthesizable form for
CatapultC was quite straightforward. We used standard C/C++ syntaxes with
most limitations imposed were about handling of design hierarchy. This is
supposed to work better in the new rev of CatC, but I can't confirm it is.
Catapult supposedly has SystemC extensions for verification, but we haven't
tried them yet.
Quality of Results:
An important measure of CatC maturity was its C versus 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. From what we've seen
is if your C is correct your generated RTL will be correct.
Since I used the CatC "power" and "area" switches on a new production design
(instead of a test case) I don't have any hard data comparing CatapultC's
final power and area results vs. our hand written RTL for the same block,
but we were able to meet our design goals. I need to use the tool more
extensively to get a sense of how C coding style impacts design optimization
and which the code structures will actually be synthesized.
The ability to map certain HW blocks to pre-synthesized "operators" from a
lib of custom components is convenient and helped reduce runtime.
Where CatapultC Needs Help:
- CatC currently supports only one level of hierarchy. Mentor claims
this will be increased in future releases. Also, CatC has limitations
on multi-rate designs.
- The CatapultC GUI is reasonable, but it needs more functions and to
run faster.
- What's allowed as constraints on pre-synthesized "operators" is very
basic. Mentor needs to extend this concept to more complex functions.
- The Catapult runtime error messages were crafted by the same
people who create IRS accounting documentation; they make sense
to the CatC developers but not to living, breathing HW designers.
- Their technical documentation is poorly organized.
- It would be great for Catapult to have "low-power" as a design goal
in addition to "area" and "speed"!
- We've found that even though our RTL can be cross-probed to our
source C, it is not always easy to trace back the bug directly from
a RTL simulation analysis. We can cross-probe C vs. RTL but since
the RTL is automatically generated, it's not easy to understand what
really happens "beyond the IO ports". So we tend to go back to our
C environment, simulate in the same conditions in which the RTL
faulted and then find/solve the bug in C. Complicated!
- We normally verify our RTL simulation output against Matlab. I've
heard something about a Matlab flow in the latest version of Catapult,
but have not tried it yet.
Catapult Strengths:
An impressive design and redesign time from algorithm to silicon.
I do not have a set of benchmarks against hand-coded RTL, but am favorably
impressed by the runtime. For 30K-40K gates, it takes CatapultC about
20-30 minutes to generate new RTL after I modify the C code. We can eval
different architectural options (component reuse, throughput, etc.) or
even implement a complex algorithmic redesign in a day or two.
I expect this would take us at least one week for manual RTL creation.
Mentor's technical support is very competent. They understand our issues
and always provide answers round the clock.
We plan to continue using CatapultC for our future developments.
- [ Kryten of the Red Dwarf ]
Join
Index
Next->Item
|
|
