( ESNUG 572 Item 5 ) -------------------------------------------- [06/06/17]
Subject: Badru replies to Cooley's "Cheeky" question about Catapult "noise"
EDITOR'S NOTE: A year ago, Badru made muey mucho noise about his
"C-based design Vision" right before DAC'16. DAC'17 is in 4 weeks.
Whatever happened to his "Catapult vision"???? (Oops!) - John
From: [ Badru Agarwala of Mentor Calypto ]
Hi, John,
Why must you be so cheeky and mocking in your DeepChip commentary?
Did I wrong you in a past life?
Anyway, rather than stoop down to your level, I would like to run this email
as my rebuttal to your undeserved criticism of my Catapult "noise" from
last year before DAC'16. Please do not edit nor modify any of what I have
written in this email in any way. Publish this in DeepChip "as is".
- Badru Agarwala
Mentor Calypto Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: [ Badru Agarwala of Mentor Calypto ]
Hi, John,
It's true what they say... you can always count on time passing! It's been
12 months since I wrote to you about my High-Level Synthesis (HLS) vision.
A lot has happened in the last 12+ months...
We were acquired by Siemens and nobody died in the process, Trump is now our
president, Brexit became a reality, creepy clowns in the woods, the Chicago
Cubs finally their first World Series since 1908...
MENT Calypto Catapult single handedly gets #4 for Best of 2016
http://www.deepchip.com/items/dac16-04.html
... and our Catapult got #4 for Best of 2016, Catapult doubled its revenue,
and we have new customers -- just to name a few events of the past year.
Now, about my vision from last year...
BADRU'S HLS "VISION"
Expect to see:
- SoC designs mixing blocks of Verilog/SV with C/SystemC/C++.
Use RTL in blocks where it works best. Use HLS in other blocks
where it works best. HLS is best where architectural tradeoffs
are more important. RTL blocks for code reuse or where hand-
crafted aspects are needed. Design hierarchy will decide which
block is which -- and expect the Calypto HLS platform to support
mixing these blocks freely.
Warning: Amdahl's law still applies here. You need to have at
least 60% of your blocks in C/SystemC/C++ to get significant
design and verification speed-up. If you only do 10% of your
chip in C/SystemC/C++, it will not be sped up.
- new C-based HLS tools that are like RTL tools. These will be:
- Rules-based design checking (linting) to catch coding
violations in your C code.
- Formal checking in your C code.
- C-to-RTL equivalence checking (SLEC but better!)
- Ability to handle ECOs in your C code.
In addition, the RTL generated by HLS should seamlessly fit into
existing MENT/CDNS/SNPS RTL signoff flows so that none of the
productivity gained by HLS is lost.
- C-based HLS tools integrate to existing RTL verification flows.
- works with assertion-based methodologies
- works with functional coverage methodologies
- works with code coverage (such as line, branch,
and state)
And the reuse of HLS verification methodology in the RTL flow.
- Predictable verification closure metrics that are familiar to RTL
designers and that provide confidence that the design is verified
and confidence in the synthesis process itself. Compared to an
RTL flow, Catapult users today see a 30x-80x verification speed-up,
faster development, and debug with 6-10x fewer lines of code.
- C-based HLS tools will integrate with power reduction tools
to generate RTL that is highly power-optimized.
- These C-based HLS tools will have strong native debug and
visualization features to understand design violations,
changes, and coverage analysis.
And more importantly these C-based HLS analysis tools must mean the user
gets quality HLS results without being an expert.
- Badru Agarwala outlines his Big C HLS Vision for the next year...
I gave myself and my team an 18-month window to deliver the tools to complete
and support my HLS vision. I am happy to announce that we are on track! In
EDA, all the rage is self-driving cars and automation. The same can be said
for the hardware design flow.
We need to move from Verilog/VHDL RTL to HLS and I envision a self-driving
HLS flow so that any RTL engineer can design and verify their SOC blocks
in HLS. Within a few years, I believe 75% of the SoC blocks will be designed
using HLS.
THE COMPONENTS TO "SELF-DRIVING" HLS
A self-driving, high-level synthesis design flow needs the right combination
of front-end tools for design checking, coverage, and verification -- along
with a HLS tool that enables users to rapidly analyze and visualize the
different steps in the synthesis process to produce designs that are optimal
for area/performance/power.
Design analysis and visualization is about looking at the resulting RTL and
schematic from synthesis -- PLUS a step-by-step approach to understanding
each stage of the high-level synthesis process like debugging scheduling
and timing failures, area optimization, and resource sharing.
Cross-probing across all synthesis stages lets designers correlate the
C++/SystemC source with all the resources used to synthesize the design.
Scope-based filtering is sections of the design to be selected, with all
corresponding views (resource, schematic, RTL, etc.) filtered down to show
only the regions of interest, instead of having to dig through 100's of
pages of schematics or reports.
C-TO-RTL EQUIVALENCE CHECKING
Now users can be confident that their Catpult generated RTL matches their
orginal C++ design without having to worry about RTL simulation. They can
just verify your C++, then run SLEC_HLS, and they're done.
We've also demystified the formal debug process by adding SLEC-Advisor,
which guides users when the solvers are getting stuck on massively complex
designs with insight on how to modify their C++ code to get a full proof.
We've been stress testing SLEC-HLS extensively this past 12 months and have
used the Google VP9 CODEC designs as the test vehicle. We're getting over
85% out-of-box formal proof with full coverage reporting.
Instead of "All or nothing" proofs, we've also added a "Coverage" mode where
a user can look at what portion of C code is unreachable and what sections
of C code have not been fully verified with formal, allowing those portions
of their design to be focused on using Questa/VCS/Incisive RTL simulation.
CATAPULT DRCs
Historically, HLS designers used off-the-shelf C-based SW tools to test and
simulate their C++/SystemC designs for functional correctness. But these
tools can miss critical HW design bugs like: uninitialized memory reads,
out-of-bound array-accesses, and overflow/underflow problems. This is not
good.
We've seen customers spend days debugging HLS RTL only to find that their
C++ algorithm had a bug where they were unintentionally losing precision;
and their C++ testbench was simply not exercising the full dynamic range
of the algorithm to expose the bug. This loss-of-precision problem becomes
even more difficult to find when designs use bit-accurate fixed-point data
types that specify the number of integer and fractional bits in a variable:
Our Catapult C++ Design Checking uses use both static and formal property
checks to find most of these types of critical C++ bugs -- saving designers
days of debugging.
CATAPULT COVERAGE
One headache has been creating Verilog/VHDL RTL tests that close coverage on
machine-generated Catapult RTL. We've found that extensively testing in the
C++/SystemC domain, including closing coverage, virtually eliminates the need
for this RTL debug.
Another headache is current software tools, such as gcov, present their data
differently than RTL tools. To make matters worse, these off-the-shelf SW
tools are not "synthesis aware" -- which means they can't accurately measure
what hard HW designers call "coverage."
Our new Catapult C++/SystemC Code Coverage works by using same verification
metrics that RTL tools provide, bringing RTL coverage into the HLS world:
- support for algorithmic C and SystemC bit-accurate data types
- instance-based coverage
- understanding Synthesis Constraints that impact the RTL
- Unrolled/Rolled loops
- Inlined/Non-inlined functions
- support for both C++ and SystemC
- matches structural coverage from RTL simulation such as line, branch,
expression, and toggle
Bit-accurate data types confuse gcov. Making gcov generate false violations
for branch coverage and impossible to reliably identify coverage holes.
The new Catapult HLS Code Coverage is aware of bit-accurate data-types, and
write the coverage data into a coverage database that can be analyzed by
your downstream RTL coverage tools like Spyglass or Real Intent.
CATAPULT SUPPORTS MIXED LANGUAGES
What we've seen is that people are designing more of their blocksin HLS,
requiring support of both ANSI C++ and SystemC to accommodate their various
chip design styles. Catapult supports mixed abstractions (Algorithmic,
Transaction, Pin Accurate and Cycle Accurate) so everyone can share their
HLS IP. This is for the OSCI SystemC Synthesis Subset while at the same
time we've open-sourced our Algorithmic C++ (AC) Data Types to allow HLS
users to standardize on it.
CATAPULT LOW POWER
Our Catapult Low-Power HLS does built-in power estimation and optimization
to accurately measure power during the HLS development cycle. Having true
low-power HLS is unique to Catapult because with our PowerPro technology
integrated under the hood.
Catapult users can explore using accurate estimations of power and their
generated RTL will have deep sequential clock-gating optimizations
built-in. These optimizations are fully automatic and formally proven,
ensuring that designs predictably get the lowest power RTL possible, with
average power savings of 10 to 30% vs. rival HLS tool flows.
CATAPULT ECO FLOWS
Customers new to Catapult HLS often have requirements based on their older
existing corporate design flows. These requirements range from passing RTL
linting rules to satisfying RTL code coverage metrics.
Usually the last item in the list is support for ECOs. Even though the
likelihood of performing an ECO in an HLS design is very low (we've had
customers doing HLS that have never had to do an ECO), we recognized the
need for supporting an ECO flow to meet our customer's requirements.
Our new Catapult ECO provides an "Incremental" mode which allows users to
make a small combinational change in their C++/SystemC and to re-synthesize
only portions of their design affected by the changes.
Thus, a small change in the C++ translates to a small change in the RTL
netlist. The RTL netlist can then be used in a standard, back-end ECO
synthesis tool to produce a patch for incremental place and route.
---- ---- ---- ---- ---- ---- ----
YOU SHOULD SEE US AT DAC
This is where John will give me grief, but some of our key customers are
already using these new tools. I can't name them specifically... yet,
but their response has been great so far. To quote a large company
headquartered in the Bay Area, "This is exactly what we need!".
What I can say is at DAC'17 in Austin we'll have some great customer
presentations. STMicroelectronics will present on low-power HLS design
for car image sensors; a Stanford PhD from AMD will be on designing HW
accelerators using Catapult HLS; and SeeCubic on using Catapult HLS to
design glassesfree 3-D TV -- plus ARM on doing SLEC verification.
Come hear it straight from them. (booth 947)
- Badru Agarwala
Mentor Calypto Fremont, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
MENT Calypto Catapult single handedly gets #4 for Best of 2016
Calypto Badru says Sanjiv Kaul left due to "vision differences"
46 readers on Calypto, Gary Smith, Veloce, Ansys, SNPS C Compiler
Join
Index
Next->Item
|
|
