( ESNUG 590 Item 02 ) --------------------------------------------- [03/26/21]
Subject: User kicks out Synopsys SpyGlass RDC for Real Intent Meridian RDC
"Our prior commercial RDC tool had a noisy report, with ~20X more
violations than Meridian RDC. Our designers spend a lot of time
just reviewing the false violations."
"Real Intent Meridian RDC took only 1-2 days to comprehensively
verify all our reset domain crossing issues... Our prior
commercial RDC tool took ~ 2 weeks."
- Real Intent RDC has 20X less noise is Best of 2019 #3c
From: [Sonic the Hedgehog]
Please keep my name and company anonymous on this, John.
We recently evaled Meridian RDC and added it into our production design
sign-off flow to replace SpyGlass RDC. Our chips have multiple reset
domains with different resets happening asynchronously -- so our designs
can have horrendous reset domain crossing issues causing metastability,
glitches, and other functional problems. And since our designs run faster
and faster, reset domain crossing issues are more likely to come up.
Because of our eval (which I'm sharing with you here) our digital designers
now use Meridian RDC instead of SpyGlass RDC to do all our static checks
for reset domain crossings.
Our RDC tool eval criteria were:
1. Coverage -- we definitely do not want to miss any issues. So,
the RDC sign-off tool must report all the possible problems.
Missing one RDC issue meant that tool FAILS the eval.
2. Noise -- we don't want to deal with too many false positives as
they consume a lot of designer time to process. The more noisy
a tool is, the more we dislike it -- because noise requires our
engineers to *hand* add more error-prone waivers.
3. Ease of Use -- if configuring the tool is too complicated, our
engineers can mess up when they in setting constraints, and the
tools can become useless.
4. Self-Checking -- When using a reset domain crossing sign-off tool,
engineers must describe specific scenarios. When they do this,
they can make wrong assumptions (or just make manual errors) when
describing them. So, one of our criteria was a good self-checking
mechanism.
Meridian RDC vs. SpyGlass RDC evaluation results
We had been using Synopsys Spyglass RDC before we switched to Meridian RDC,
so here's how they compsre:
1. Coverage
Meridian RDC and SpyGlass RDC both caught all the errors, so we
considered both to have 100% coverage. (Because we previously
used Spyglass RDC, we had good data -- and could compare all the
violation reports for both tools.)
2. Noise
Unlike SpyGlass RDC, Meridian RDC's engine is specifically customized
for RDC. It's more advanced from my point of view (vs SpyGlass),
as this means that Meridian RDC can take advantage of more precise
scenarios and constraints from our designers.
The result is that the Meridian RDC violation reports have 2x-9x
less noise as SpyGlass RDC does.
This makes Meridian RDCs reports much simpler to go through. 9x fewer
false violations makes for a more efficient debug process for us.
[ Editor's Note: That's big. To put this 9x in perspective, if I
have a 5 million gate block, with Meridian RDC it spits out 400
violations needing human checking which takes 1 full day plus
2 pots of coffee to go through.
But with SpyGlass RDC it can spit out up to 9 x 400 == 3,600
violations needing human checking, which takes 3 to 4 full days
plus 6 to 8 pots of coffee to go through! Ugh! - John ]
Real Intent
Meridian RDC
|
Synopsys
SpyGlass RDC
|
5 million gates
400 RDC violations
1 full day
2 pots of coffee
|
5 million gates
3,600 RDC violations
3 to 4 full days
6 to 8 pots of coffee
|
|
|
3. Ease of Use
Meridian RDC's GUI and debug are easy to use. Plus, the initial
setup is quick -- we were able to start running it on production
blocks in a few days.
While Real Intent's RDC customized engine seriously (9x less)
reduces violation report noise -- while maintaining full accuracy/
coverage -- it requires our engineers to write more design-specific
constraints during set up.
This step takes a few days before we start using the tool, but the
9x noise reduction is definitely worth the investment. Also, the
Real Intent AEs helped us learn how to best describe certain
scenarios for Meridian RDC.
4. Self-Checking
When we run Meridian RDC, it automatically writes assertions that
can be used in simulation or formal tools. This allows debugging
to determine whether any unexpected design behavior is due to
incorrect scenarios/constraints -- or from other design errors.
Real Intent has recently added having Meridian RDC generate the
assertions in System Verilog Assertion (SVA) format to be
compatible with commercial simulators like VCS/Excelium/Questa,
as well as commercial formal tools such as JasperGold. Otherwise
someone has to hand write them all -- a huge time savings.
I have not yet tested out their SVA assertions yet.
5. Performance/Runtime
Although performance was not part of our evaluation criteria,
it's worth noting that Meridian RDC's runtime is fast.
The Meridian RDC runtime was 3x to 4x faster than the Spyglass RDC
runtime for the same design.
My project had several million gates, with high complexity.
Meridian RDC typically took only 10 minutes to give me the
analysis results for a sequential depth of 5. A sequential
depth of 5 means it analyzed the impact of the metastable
value propagated through 5 levels of sequential elements
(e.g., latches, flip flops ...).
---- ---- ---- ---- ---- ---- ----
How Meridian RDC works
Meridian RDC does reset domain crossing checks using static methods because
RDC issues are not easy for find with simulation and STA.
NOTE: Meridian RDC is a completely different tool from Meridian CDC. It has
very different custom engine for RDC issues that CDC tools lack. You can
use Meridian RDC without having Meridian CDC. (We only use Meridian RDC.)
Meridian RDC can be used at a block-level or top-level. Since most of our
blocks only have one reset, so we only run it at the top-level.
Meridian RDC takes in:
- our design (RTL or gate netlists),
- our specification (in template or GUI) which includes our reset
definitions, and
- our design constraints.
It then:
- Compiles our design, applies all the constraints, and then
automatically extracts the reset domains.
- Checks across the different reset domains for RDC issues,
e.g. to see if metastability occurred or propagated.
It takes only few days to be productive, then our designers write more
constraints to tune them. Like other complex design tasks, it can take us
several weeks to iterate and find and fix all the issues.
---- ---- ---- ---- ---- ---- ----
What Meridian RDC Looks For
The fundamental RDC concerns that Meridian RDC analyzes are:
- When asynchronous resets are activated or deactivated, do they
cause metastability?
Otherwise, if the asynchronous resets propagate from one domain
to another domain with different timing, the propagation could
cause metastability, which can lead to design failure.
- Are reconverging synchronized resets functionally correlated?
When two events propagate from one reset, and there is a timing
relationship between them; when both paths function correctly, the
timing between the events is stable and expected.
However, when software resets are asserted or de-asserted, they
can create behavior that can lead to convergence issues, where
the flop being driven goes to an unexpected state. This can cause
incorrect functional behavior.
- Are asynchronous resets glitch-free?
Because everything is asynchronous, your design can have multiple
sources toggling at different times -- this may result in the
design having a glitch at the clock edge that could cause some
functional issues.
For example, there could be a small pulse of one that could be
captured by the destination, and for one cycle the destination
will get a value of one. It's not a metastability, but a
deterministic state with an intermediate wrong state/value.
The failure is not due to a timing violation, it is because of
functional glitch.
Following its analysis, Meridian RDC reports on:
- The number of safe HW crossing paths due to propagation
- The number of metastable HW crossing cases with issues due
to deprecated partial asynchronous domain handling
- Anything related to software-controlled resets that needed to be
flushed out.
---- ---- ---- ---- ---- ---- ----
Debug
We are happy with Meridian RDC's iDebug GUI. What I like:
- Schematics that pinpoint the violations. This is a very useful
and the GUI is good. It displays a schematic of the violation;
we clearly see the logic in schematic view and then pop out the
Verilog/VHDL source code for that same logic.
- We can easily apply filters to view a specific set of violations.
For example, if we care only about a block A, the tool will only
show violations for Block A. It also will automatically filter
for a particular reset scenario.
---- ---- ---- ---- ---- ---- ----
Why Asynchronous (vs Synchronous) Resets
With asynchronous resets, all the logic start states are deterministic.
For synchronous resets, it takes a couple of clock cycles to propagate
to all the logic.
This means that if we limited our designers to using only synchronous
resets to try to avoid RDC issues, the results will be:
- Lower Performance. It requires our design to provide all the
clocks stably for multiple cycles, which adds time.
- Higher Area. The gate count is also higher.
- More complex physical design. The physical design burden is
greater due to the need to synchronize all the reset paths.
So, our designers use asynchronous resets for better performance, better
area, plus it makes PnR easier.
---- ---- ---- ---- ---- ---- ----
I recommend Meridian RDC. It's in our sign-off. Meridian's strength is
its customized RDC engine that catches all of our RDC issues 4X faster
with 9X lower noise; plus it has a good debugger/GUI.
- [Sonic the Hedgehog]
---- ---- ---- ---- ---- ---- ----
Related Articles:
User benchmarks Prakash's Meridian RDC vs. his in-house RDC tool
Real Intent Meridian RDC has 20X less noise gets Best of 2019 #3c
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
|
|
