( ESNUG 586 Item 2 ) ---------------------------------------------- [04/18/19]
Subject: User benchmarks Prakash's Meridian RDC vs. his in-house RDC tool
SEIZING SIGNOFF: I have to tip my hat to Prakash Narain, founder and
CEO of Real Intent, for stepping up his game against Synopsys Spyglass
ever since Aart bought Atrenta. ...
... but Prakash has pushed his company to be more of a "must-have
signoff tools you gotta have" company -- or at least he's getting that
reputation with user comments about his new multimode CDC signoff
(Verix CDC) and his newish RDC signoff (Meridian RDC) tools.
- "Real Intent smacks SNPS CDC & RDC signoff as #3 Best of 2018"
http://www.deepchip.com/items/dac18-03.html
From: [Aquaman]
Hi, John,
I liked your "Best of 2018" data -- especially where you mentioned Prakash's
Real Intent. We recently did a 6-month eval of his Meridian RDC (reset
domain crossing) sign-off tool, as part of our own build vs. buy decision.
Our conclusion was that Meridian RDC was superior to our own internal RDC tool.
Below are details of our findings.
REAL INTENT MERIDIAN RDC OVERVIEW
Meridian RDC's main value is finding metastability issues/bugs across reset
domains. It also helps detect reset glitches and reset correlation issues
across domains. Its inputs and outputs are:
Inputs
- RTL or gate-level netlists
- Clock & Reset constraint definitions
- Reset relationship definitions (used to mark "safe" crossings)
Outputs
- Database, which can be used to load our debug/schematic viewers
- Reports with violations on set up, reset domain crossing domain
violations (metastability issues), and reset quality check
(possible glitches & correlations.)
- Two reports types -- either text or graphic
We use Meridian RDC at both unit and chip levels. The 'unit' level can be
one or multiple blocks. The 'chip' level usually contains IP clusters,
i.e. several IP grouped together in a large physical block with timing
interdependencies -- but is not necessarily full chip.
---- ---- ---- ---- ---- ---- ----
MERIDIAN RDC RUNTIME
Below is some benchmark data, to give you a sense of the tool's runtime.
Unit and/or Cluster size Meridian RDC runtime
------------------------ ----------------------
Small = 200K gates 5-30 minutes
Medium = 10-14M gates 1.5 hours
Cluster = 85M gates 12 hours <-- overnight run
The largest size we've run through it is 85 Million gates. Real Intent
claims a much larger capacity, but the lion's share of our RDC issues are
at the unit (1 M to 7 M gate) and cluster (20 M to 40 M gate) level.
MERIDIAN RDC TOTAL TURNAROUND TIME
Regarding initial set up, Meridian RDC runs out-of-the-box. But it took our
team about 5 days to be productive.
Real silicon sequencing is much more complex and nuanced than just turning
something on and off. Thus, an additional step in the set-up is building in
design-specific understanding so that Meridian RDC can properly identify
problem areas. For example, reset sequencing, clock, and reset domains. It
can also differ depending on whether the designer is running on a piece of
IP they didn't design in the first place.
The times below include set up, product run-time, plus our analysis until
signoff was complete -- keep in mind this is NOT run-time -- it's the total
time it took us to get to complete signoff.
Unit Level:
- IP design with ~1 million gates, 4 or fewer domains 1/2 day
- 50 M gates with 20 domains 3 days
Chip Level:
- multiple Clusters totaling over 900 M gates and
over 150 clock and over 150 reset sub-domains 4 weeks
- We also ran Meridian RDC to identify inter-unit violations.
- Set up greatly depends on reset & clock domain complexity.
We also use Meridian CDC for our clock domain crossing signoff. The two
tools have a very similar look and feel, and their inputs overlap.
The Meridian CDC inputs are RTL or netlist case, and the clock & reset
constraint definitions. Then the additional RDC inputs are reset
relationship definitions used to mark safe crossings.
---- ---- ---- ---- ---- ---- ----
MERIDIAN RDC KEY FEATURES
First, Meridian RDC does an automated initial set up, where it extracts all
the resets and reset domains. This is a good starting point and has some
value; then you specify additional design intent.
It then performs RDC analysis --you can define what you want listed in the
report with warnings and violations, including metastability problems, e.g.
verifying that the "asynchronous resets crossing reset domains will not
cause metastability" when the resets are activated or de-activated
The tool will also tell you:
- The number of paths in the design that had safe crossings due to
proper clock gating.
- The number of meta-stable crossing cases with issues due to
deprecated partial asynchronous domain handling in RTL.
- Anything related to soft resets that needed to be flushed out.
Real Intent's GUI/navigation is definitely good for identifying your RDC
violations -- it's much better than just text reports.
It has schematics for pinpointing violations by showing the path from the
source flop to the destination flop, as well as a visual tracing. You can
also filter for specific violations during debug.
---- ---- ---- ---- ---- ---- ----
METASTABILITY ISSUES WITH RESETS AND ASYNCHRONOUS CLOCKS
The main senario to catch identifying metastability problems arising from
any software or low power resets.
- With asynchronous clocks, when you start the reset, it turns into
many paths. If one of the follow-on flops is not reset, it can
create metastability problem. If the flop has a problem, it can
leak into something, or it can be masked.
- A sequential element is like a flop. With simulation it reverts
to a 0 or a 1; however, in silicon, if the input is variable, the
output can take a while -- even take a full cycle -- to settle to
zero or one. That "X" can cause a timing error.
At my company we have many IP teams and many reset crossings, so there are
many potential violations.
The first thing we must do is to filter out the real violations vs. the
false positives.
We had built our own internal Reset Domain Crossing tool. The difficulty
with our in-house tool is we would generate a report, and it was a lot of
work for our designers to filter through the report results, trace through
the design, look at the sequencing, and see if a specific path would cause
a metastability problem.
Meridian RDC worked out well for us here.
First, its low-noise reports was a positive. We saw 10x to 800x fewer false
violations with Meridian RDC than our in-house tool. Filtering by the
designers is always a judgment call, but the more violations your engineers
must filter through, the more likely they are to miss something.
In one extreme case, the number of endpoint violations were:
Tool Violations
---- ----------
Meridian RDC 5,000
Our internal tool 4,000,000 <-- this was difficult for our
designers to check completely
Second, Meridian RDC ran more checks, and uncovered more additional issues
for our unit level prototypes than our internal tool did.
---- ---- ---- ---- ---- ---- ----
TWO MERIDIAN RDC GOTCHAS
So far, the two improvements we'd like Real intent to make are:
1) Generate assertions to check correlation of the reset domain
relationship and constraints; and
2) In the visual view, we'd like them to mirror the source code
with path tracing.
As we go to the cluster level, we expect to have additional requests for
improvements.
---- ---- ---- ---- ---- ---- ----
CONCLUSION: METASTABILITY SCARES US
We plan to use Meridian RDC as our reset domain crossing signoff tool to
catch functional issues and bugs.
In particular, we fear that metastability problems can corrupt some states
and could cause a chip to fail.
- This is a missing element in functional simulation -- it doesn't
deal with metastability or timing errors.
- With static timing analysis (PrimeTime and Tempus) the biggest
problem is that resets are temporal, not static. An STA tool might
catch it, but it would also inaccurately flag millions more.
- Meridian RDC focuses our team to have a much higher chance of finding
these metastability problems.
Being a small company, Real Intent's technical support is very strong - they
usually respond to any requests within a day. (Although the problem is not
necessarily fixed by then.) For example, had an issue with analysis of one
unit where the runtime was nearly 48 hours. Real Intent fixed it within
5 days, and got it to run in only 1.5 hours.
Real Intent solves a big scary metastability problem for us.
- [Aquaman]
---- ---- ---- ---- ---- ---- ----
Related Articles:
Real Intent smacks Synopsys CDC & RDC signoff as #3 "Best of 2018"
Real Intent trounces Synopsys Atrenta as the #6 "Best of" for 2017
Real Intent and Blue Pearl get #2 overall for Best EDA of 2016
Join
Index
Next->Item
|
|
