( DAC'20 Item 03a ) ----------------------------------------------- [05/21/21]
Subject: Real Intent low noise/multimode Meridian RDC gets Best of 2020 #3a
PRAKASH'S BRANIAC STRATEGY: I tip my hat to him. It's taken a lot of clever
technology moves by Prakash Narain (Real Intent CEO) to consistantly stay
two steps ahead of Synopsys Spyglass in static sign-off -- especially given
Synopsys' enormous sales force and all-you-can-eat pricing deals.
The result? Using customer input as a proxy, Real Intent's customer base
has been going strong for the past 5 years with user word count being up
1.5X this year (2020) after being up 2.5X the prior year (2019).
User word count for Real Intent in "Best of" Reports
2020 : :######################################### 8,240
2019 : :########################### 5,300
2018 : :########### 2,140 words
2017 : :####### 1,360
2016 : :####### 1,350
That's looking at Real Intent overall.
Next, here is what's "big" for Real Intent specifically this year ...
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
NAILING RDC THIS YEAR: Last year (2019), 8 users talked up how Meridian RDC
had "25x less noisy reports" and was "7x faster" than Synopsys SpyGlass RDC
in Best of 2019 #3c.
This year I see 19 users talking up Real Intent RDC in some way. And what's
attracting these users to Meridian RDC this year?
LESS NOISY RESET REPORTS
"Meridian RDCs reports (are) much simpler to go through. 9x fewer
false violations [than SpyGlass] makes for a more efficient debug
process for us." (ESNUG 590 #2)
"Real Intent Meridian RDC caught all errors -- and reported only
4% of the # of violations compared with the other commercial
RDC tool." (DAC19 #3c)
FAST SIMULTANEOUS RESET SCENARIO RUNS
"The Meridian RDC runtime was 3x to 4x faster than the Spyglass RDC
runtime for the same design."
"Meridian RDC automatically runs all our scenarios in parallel.
Without this 'multi-scenario' feature, we'd have to run RDC analysis
sequentially for each scenario, which would take more manual effort
and more time. It generates one consolidated report as to which
conditions are and are not being met, which minimizes our review
time."
ASSERTIONS FOR RESET FOR OTHER TOOLS
"Meridian RDC also generates assertions to debug issues later using
formal (JasperGold, OneSpin, VC Formal) or simulator (VCS, Xcellium,
Questa). They recently started generating them in SVA format, but
we haven't tried it yet."
FEAR OF GETTING BURNED BY RDC ISSUES
"Before we bought Meridian RDC, we had a chip with a post-silicon bug
because we didn't have any way to do worthwhile RDC verification, so
we missed an RDC issue that could have cost us to repair.
Another time on a different SoC, we thought all our reset domains were
synchronous, but then Meridian RDC caught a 3rd-party IP that had an
asynchronous reset -- that we didn't verify and nor did the vendor.
By chance, we lucked out. That could have caused a chip killing bug,
but it didn't.
After two close calls, mgmt made it a requirement and Meridian RDC is
now part of our sign-off before all tapeouts."
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
QUESTION ASKED:
Q: "What were the 3 or 4 most INTERESTING specific EDA tools
you've seen in 2020? WHY did they interest you?"
---- ---- ---- ---- ---- ---- ----
Real Intent Meridian RDC
Compared Meridian RDC vs. SpyGlass RDC. Purchased Meridian RDC.
We have a few power domains with asynchronous resets. We needed a reset
domain crossing (RDC) sign-off tool to make sure the reset domain
crossings are handled correctly and won't trigger any metastability.
Our purchase criteria were:
1. Full accuracy/coverage. If there is a problem, RDC sign-off
must find it; otherwise, silicon is bad and that's a disaster.
2. Low noise. If the tool's reports have too much noise ("false
alarms"), we must hand mark a lot of violations/warnings as
OK. If there are too many to mark, engineers get tired and
may end up marking actual errors as false alarms.
Our decision was based on:
- Our engineers' recommendation, from their prior SpyGlass
experience, is that right now Real Intent is the best in
the industry, and that Real Intent's static signoff has
much cleaner, lower noise violation reports.
- This evaluation passed our small test case. We doubt
that it'll be wrong for our larger designs, but if it
is we'll be writing you back, John.
We will begin using Meridian RDC on a production design in the next few
weeks; the tool will be part of signoff for our top-level RTL before we
send it to our synthesis and PnR backend.
---- ---- ---- ---- ---- ---- ----
I nominate Real Intent's Meridian RDC because it's in our signoff
flow. We like it can run multiple RDC scenarios simultaneously.
Our designs have several 10's of reset scenarios. An example is:
"There must be a control signal to make reset domain crossing safe
when a reset asserts."
All we do is specify the reset scenarios we want to analyze, and
Meridian RDC automatically:
- Runs all our scenarios in parallel. Without this
"multi-scenario" feature, we'd have to run RDC analysis
sequentially for each scenario, which would take more
manual effort and more time.
- Generates one consolidated report showing which
conditions are and are not being met, which minimizes
our engineer's review time.
---- ---- ---- ---- ---- ---- ----
Meridian RDC from Real Intent is much more powerful than our prior VCS
reset simulations backed up by manual checks. We primarily run Meridian
RDC at the block level and where two blocks communicate. For example,
we mightrun it to analyze the boundary between our power management
controller and our main core.
Our team members like that Meridian RDC creates low noise reports.
That is it's # of violations vs actual errors doesn't have a lot of
false violations that our engineers must chase down. My guys also like
that Meridian RDC did not require a lot of configuration settings nor
training -- it didn't take much engineering effort to get useful reports.
How RDC/CDC Issues Mess With Each Other
CDC issues occur during a crossing between clock events. It can take
sort of an "aha moment" to realize that even though a reset can occur
within the same clock domain, the asynchronous reset assertion is still
an asynchronous event that can cause design issues when one reset domain
asserts and the other does not.
The resets only assert once, so the probability of reset design issues
is much lower than for a clock domain crossing, which for GHz frequency
may occur a billion times per second. In contrast, reset domain
crossing may occur only once an hour, once a day, or once a week.
So, the probabilities do go down for RDC issues. But they are still
present and a problem that must be dealt with.
Synchronous Resets vs Asynchronous Resets
Modern chips have a lot of reset domains. This is due to more complex
SoCs with different controllers doing complicated power management
schemes, as well as security management schemes, I/O connections, and
configurations.
To minimize our exposure to RDC issues from all the crossings, we often
implement synchronous resets. However, we also use asynchronous resets
for certain modules of our design.
- We have a large design database and a lot of different design
styles with different reset requirements.
- Avoiding asynchronous resets adds some complexity, as there
must be a clock present to clear out the asserted state.
Conclusion
Waiting for post-silicon lab testing to characterize/analyze any RDC
issues is too expensive and too late.
So we use Meridian RDC to rigorously test for reset + clock issues at
the pre-silicon level at identified boundaries -- so that we have
confidence before going into silicon.
---- ---- ---- ---- ---- ---- ----
We use Meridian RDC for reset domain crossing sign-off of our SoCs.
Meridian RDC supports hierarchical design. So, we can run it at the
block level, and then at the top-level. However, we wait to run RDC
sign-off once our top-level design is stable, and just black box any
blocks where we are sure there are no asynchronous resets.
Meridian RDC's top-level runs are pretty good. We use it to:
- make sure reset paths don't have glitches.
- make sure there are no combinational loops on the reset.
- make sure no path reconvergence after synchronization happens;
and if there is no way to avoid that convergence, to make sure
that they don't lead to functional issues.
Meridian RDC uses the same iDebug debugger that Meridian CDC uses.
The nice thing is we can see the schematic for the RDC violation, plus
we have the option to annotate VCD files for signal values.
Meridian RDC also generates assertions to debug issues later using
formal (JasperGold, OneSpin, VC Formal) or simulator (VCS, Xcellium,
Questa). They recently started generating them in SVA format, but
we haven't tried it yet.
We run both CDC and RDC to Avoid Metastability
Clock domain crossings (CDC) are not the only reason a signal becomes
asynchronous with respect to the destination clock domain.
In a sequential design, if the reset of the source register is different
from the reset of the destination register you can have a reset domain
crossing problem -- i.e. even if it is the same clock domain -- if the
source flop makes an asynchronous transition to a reset state, the reset
assertion can happen inside the setup and hold window of the destination
flop and cause a metastability issue.
So, we need both CDC and RDC verification to make sure there are no
metastability issues in the design.
To make matters worse, our designs have a lot of peripherals, memories,
and I/O components with resets coming from *different* sources that
could be running at *different* clock frequencies. We also have
power-off resets, and software-based resets.
Before we bought Meridian RDC, we had a chip with a post-silicon bug
because we didn't have any way to do worthwhile RDC verification, so
we missed an RDC issue that could have cost us to repair.
Another time on a different SoC, we thought all our reset domains were
synchronous, but then Meridian RDC caught a 3rd-party IP that had an
asynchronous reset -- that we didn't verify and nor did the vendor.
By chance, we lucked out. That could have caused a chip killing bug,
but it didn't.
After two close calls, mgmt made it a requirement and Meridian RDC is
now part of our sign-off before all tapeouts.
---- ---- ---- ---- ---- ---- ----
We added Real Intent RDC to our signoff this year.
---- ---- ---- ---- ---- ---- ----
Meridian RDC
---- ---- ---- ---- ---- ---- ----
VCS, Meridian RDC, JasperGold, Palladium
---- ---- ---- ---- ---- ---- ----
For RDC we're looking at Real Intent vs. Atrenta
---- ---- ---- ---- ---- ---- ----
Use RI for CDC and RDC.
---- ---- ---- ---- ---- ---- ----
Reset bit us last year. Now use Real Intent RDC.
---- ---- ---- ---- ---- ---- ----
Like the speed-up in Real Intent RDC this year.
I have to give Prakash credit for that.
---- ---- ---- ---- ---- ---- ----
Real Intent CDC and RDC is integral to our signoff.
---- ---- ---- ---- ---- ---- ----
We like the Real Intent signoff tools because they run faster and
with MUCH less noise.
---- ---- ---- ---- ---- ---- ----
Meridian Reset stuff
---- ---- ---- ---- ---- ---- ----
Real Intent Meridian
---- ---- ---- ---- ---- ---- ----
Our in-house benchmark found for RDC last year, Real Intent was
~4x faster and used ~1/4th the memory that Spyglass did.
---- ---- ---- ---- ---- ---- ----
Fewer false warnings with Meridian for our reset work
---- ---- ---- ---- ---- ---- ----
The fact that Real Intent did 1 complete run instead of lots of
little runs for RDC sold us on it. Our time is valuable.
---- ---- ---- ---- ---- ---- ----
Reset issues have become as much a pain in the a$$ as clock issues
have always been. We let Prakash take care of both for us.
---- ---- ---- ---- ---- ---- ----
Related Articles
User kicks out Synopsys SpyGlass RDC for Real Intent Meridian RDC
Prakash's gotchas of serial mode vs. true multimode static sign-off
Real Intent Meridian CDC & Verix CDC tools take Best of 2019 #3a
Real Intent smacks Synopsys CDC & RDC signoff as #3 "Best of 2018"
Real Intent, OneSpin, Indago and the Atrenta-SNPS buyout concerns
Join
Index
Next->Item
|
|
