( DAC'20 Item 03b ) ----------------------------------------------- [05/21/21]
Subject: Users choosing Meridian CDC over Spyglass CDC is Best of 2020 #3b
MERIDIAN CDC BEATS SPYGLASS CDC: Hands-on users this year once again chose
Prakash's Real Intent Meridian CDC over Aart's Synopsys SpyGlass CDC.
"We recently purchased Meridian CDC from Real Intent, after comparing
it with Synopsys SpyGlass CDC."
"Real Intent CDC is the best clock domain crossing verification tool
I've tried; we use it to make sure that our clock domain crossings
don't cause any problems."
"We've been using Meridian CDC for a few years. However, we also
did an evaluation again last year. Synopsys came back to us and
said they'd improved Spyglass, so it was a much better tool now. So,
we came up with the metrics important to us -- and again Meridian CDC
beat Spyglass in most categories. So, we stayed with Meridian CDC."
"Real Intent's debug was much better than SpyGlass, including being
able to see the schematics. Synopsys is trying to use Verdi to do
this, but Real Intent was still better for debugging CDC issues."
Where Prakash beats Spyglass in CDC are hierarchy, low noise, and debug.
CDC Hierarchy with Accuracy
"We were able to run the entire design without any black boxing and
it took us only about 5 hours to finish. To get a sense of the
impact of using Meridian CDC's hierarchical flow: for my previous
generation of this chip, I had to black box 2/3rds of my blocks to
be able to run the top-level flat (i.e., without hierarchy)."
Low Noise CDC Violation Reports
"We injected artificial errors, and Meridian CDC reported them
all -- and without much noise."
"Compared to Spyglass CDC, I figure Meridian CDC had roughly 1/10th
the number of violations had for the same design. Real Intent
was a lot less noisy in it's violations reports."
Root Cause Debug
"The tool's schematic viewer made it easier to find the errors
and their root causes, e.g., the viewer shows the clock domains
in different colors. This meant we could spend more time on
quality debugging and fixing the clock domain crossing problems."
And one engineer's bottom line was on usability:
"Our team was able to ramp up quickly with Real Intent Meridian CDC.
We were new to the tool when we started our project, yet we got
good quality CDC analysis results within the first 2 weeks."
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
QUESTION ASKED:
Q: "What were the 3 or 4 most INTERESTING specific EDA tools
you've seen in 2020? WHY did they interest you?"
---- ---- ---- ---- ---- ---- ----
We recently purchased Meridian CDC from Real Intent, after comparing it
with Synopsys SpyGlass CDC.
Our chip has over 20 clocks throughout. We need to be sure our signals
crossing different the clock domains are handled correctly so we don't
have metastable states wrecking our design.
Meridian CDC worked well for the code sample example we tested it on.
- We injected artificial errors, and Meridian CDC reported them
all -- and without much noise.
- For the Meridian report warnings that were not actually bugs or
errors, we could see the reason they were flagged. In some
cases, we could tweak a knob to silence those warning types in
the CDC report.
Meridian CDC ran fast for our test case. We plan to use it at the
block-level first, and then for CDC sign-off at the top level.
We haven't run it on our larger chip yet -- it is not very large, so
accuracy and low noise are our highest priorities.
---- ---- ---- ---- ---- ---- ----
Real Intent CDC is the best clock tool I've tried; we use it to make
sure our clock domain crossings aren't causing problems.
Meridian CDC's main inputs are:
- The RTL or netlist design we want to verify.
- Constraints defining the clock domain for each input, along
with clock descriptions.
- Design-specific constraints. For example, if there is a signal
that is quasi-static and doesn't change, it's fine to not have
a CDC synchronizer. (What I like here about Meridian CDC is
that we can basically specify any constraints SVAs will allow.)
- Design-specific waivers. If there are some CDC violations that
we know are safe we can just waive them instead of fixing them.
The output report shows our CDC violations. For example:
- Missing synchronizers for asynchronous clock domain crossing,
including the location. This is the main check we use it for.
- Other iffy CDC failures. One simple example would be if our
signals converge after synchronization, which could be a CDC
protocol issue.
So, we run Meridian CDC, read the report, and then fix the design or
waive the failures. We then repeat this procedure until every failure
is gone and the report is clean.
We've been using Meridian CDC for a few years. However, we also did
an evaluation again last year. Synopsys came back to us and said
they'd improved Spyglass, so it was a much better tool now. So, we
identified several metrics that are important to us:
1. Performance. This was the most important one.
2. Ease of setup. We wanted to make sure that it's easy to do
the setup.
3. Supporting CDC constraints and libraries
4. Debug
5. Completeness. We wanted to make sure no CDC issue is missed.
[This could be the first one]
Meridian CDC beat Spyglass in most categories:
- Meridian CDC's runtime performance was somewhat better.
- Real Intent's set up was somewhat easier.
- Meridian CDC generally worked better for RTL. For netlist,
SpyGlass was generally better -- SpyGlass had better support
for the Synopsys library format.
- Real Intent's debug was much better than SpyGlass, including
being able to see the schematics. Synopsys is trying to use
Verdi, but Real Intent was still better to debug CDC issues.
Our conclusion: We stayed with Meridian CDC.
---- ---- ---- ---- ---- ---- ----
We use Real Intent for its hierarchical CDC top-level runs.
We run Meridian CDC flat at the block-level, and the performance is
good.
Meridian CDC has a hierarchical flow that we can use to meet the
capacity requirements for our top-level design. The setup was easy.
For example, for a top-level design connecting ten blocks:
- We first run Meridian CDC on every block; it automatically
generates a database with a model for each block (i.e., 10
models). Each model contains all information relevant to
clock domain crossing.
- Then before we do a hierarchical top-level run, we make sure
the clock domains are defined for the input and output of
every block. We also point to the model for each block, so
that at the top level the hierarchical Meridian CDC models
are connected to the rest of the design.
- We then run Meridian CDC on this top-level design instead of
the flat design.
- With this approach, we were able to get the quick runtime
needed to run the entire top-level design, while also keeping
the accuracy
We were able to run the entire design without any black boxing and it
took us only about 5 hours to finish. To get a sense of the impact of
using Meridian CDC's hierarchical flow: For my previous generation
of this chip, I had to black box 2/3rds of my blocks to be able to run
the top-level flat (i.e., without hierarchy).
When a block has a failure, I run Real Intent's iDebug for the block
that has an issue. It only takes one command to start iDebug from
Meridian CDC.
Debug
We like how easy it is to fire up iDebug. What I usually use:
- When CDC shows a failure, iDebug will show the schematic; we
can trace the schematic and to see what is causing that issue,
e.g., a missing constraint or a missing synchronizer.
- We can add waivers as on the fly inside iDebug (can't do that
in Verdi) to see which violations remain, until we're done
with our waivers.
- We can also dump all the waivers into a TcL format in iDebug
and bring that into our main run instead of manually writing
them.
---- ---- ---- ---- ---- ---- ----
Our Real Intent CDC static sign-off is always before JasperGold CDC
formal.
To resolve our clock domain crossing issues, we first make sure the
static checks are correct. (Our CDC static checks are our default
that we must run first to avoid missing any issues.)
There are a lot of checks that CDC static tools do that that formal
does not. For example, there is no way for JasperGold or OneSpin to
know if there is a missing synchronizer for every crossing. In a
recent chip, we had 16 static rules that we care about that neither
JasperGold nor OneSpin could check. Only Real Intent could.
We only run JasperGold after all the static CDC checks are fixed or
waived and we want to verify that there are no functional CDC
issues. We only have a few categories in formal verification that we
care about, e.g.
1) missing data, such as making sure that every transition on
the source domain will be captured in the destination domain.
2) data coherency, e.g., if two or more signals go through two
independent synchronizers, and then converge. This is fine
if only one of the signals can change at the same time. If
more than one signal changes at the same cycle, then we will
have a coherency issue.
Meridian CDC will always report converging signals as a potential issue,
but there is no way for a static check to confirm if the signals are
gray encoded, so the next step is to run formal verification.
Which is why we're long standing Real Intent CDC users.
---- ---- ---- ---- ---- ---- ----
Meridian CDC is part of our signoff flow.
Real Intent's AE support is great. It's one of their biggest strengths.
---- ---- ---- ---- ---- ---- ----
Real Intent Meridian CDC
Our team was able to ramp up quickly with Real Intent Meridian CDC.
We were new to the tool when we started our project, yet we got good
quality CDC analysis results within the first 2 weeks.
- Meridian CDC had simple scripts, adding constraints and waivers
was intuitive, and the iteration cycles were short.
- The tool's schematic viewer made it easier to find the errors
and their root causes, e.g., the viewer shows the clock domains
in different colors. This meant we could spend more time on
quality debugging and fixing the clock domain crossing problems.
- We had IP blocks from outside 3rd party vendors that had to be
checked properly with low noise in our CDC runs. Meridian CDC
handled them very well.
- Meridian CDC's ability to filter violations was key to us being
able to quickly identify the design errors.
Real Intent CDC also scaled well with the high number of layers in our
design.
---- ---- ---- ---- ---- ---- ----
We view CDC as a required signoff check with Meridian CDC as our signoff
tool of choice.
We have to get CDC right at the static check level. Not at the formal
ABV tool level or dynamic simulation level; but during static checks.
It's critical for us -- we have lots of clocks, lots of crossings and
large opportunity to construct faulty crossings. An early static tool
like Meridian CDC is critical for our designers using our design style.
We LOVE Hierarchical CDC
Real Intent has a hierarchical flow CDC. This is important for us.
When a design has different partition levels, there are often a lot of
design weaknesses *between* those partitions. It's not always easy to
assign ownership -- one engineer runs it on one partition, another
runs it on another partition -- is inviting trouble! So, it's important
that Meridian CDC runs at the next level between partitions.
A hierarchical flow lets us make sure all the handoffs and assumptions
and constraints for each of the blocks are maintained and correct all
the way up to the top-level. Meridian CDC does that very well; we've
been working Real Intent a long time as they developed & improved this.
We LOVE Local Formal CDC
This is another area where Real Intent does a good job.
In my experience, JasperGold formal ABV has a lot of promise, but it
requires a requires a lot of guidance for CDC issues. We do not have
enough constraints to exclusively use formal ABV to rule out all of
the clock domain crossings issues in our design.
Further, when we throw our designs at a formal verification tool, be it
JasperGold, or OneSpin, or Questa Formal or VC Formal -- it always
blows up due to capacity and runtime limits -- and cannot converge.
Meridian CDC's compromise of using 'local formal' (in addition to its
static checks) allows us to identify paths that are that are absolute
failures, as well as point to paths that may be problematic.
For us, Real Intent CDC has been an excellent compromise in terms of
runtime/capacity/turnaround time and getting feedback versus trying to
apply warm bodies and requirements to do a full formal analysis.
We LOVE iDebug
For the paths that should be investigated, sometimes the problem is
obvious once it has been identified. E.g., a missing synchronizer or
an accidental use of a synchronizer. We find and fix those quickly.
For the violations that Meridian CDC reports that the designer thought
was actually correct, the iDebug schematic viewer comes in handy.
Sometimes the tool just helps us get out of our "local minima" as to
where we think the issue may be.
---- ---- ---- ---- ---- ---- ----
We run Meridian CDC analysis early.
I believe that everyone kind of pushes "Shift Left". It's a powerful
concept and it works.
As soon as our designers have a lint-clean design (using Ascent Lint),
we like them to do clock domain crossing verification. There's no
reason to delay, and to get to get issues out of the way sooner.
Any time you can fix CDC issues up front vs. down the line is helpful.
Our RTL designers know what good clock domain crossings are, but they're
not tool experts. So, we designate a couple of engineers to help refine
the clock methodology, to make sure that there are good checks enabled
to avoid escapes, and make sure we bridge the translation between what
a designer's knowledge on the space vs. how the Real Intent CDC tool
reports the information.
There is some value of not doing a large amount of clock domain crossing
analysis work until we at least have code that's functionally correct,
and want to make sure what we have that's functionally correct is also
actually structurally/CDC correct.
When our designer makes an RTL change, we will typically want them to
run Meridian CDC again, just as a design change would require a full
suite of regressions. There are places where we are not going to find
CDC failures in simulation - especially in a zero-delay simulation.
---- ---- ---- ---- ---- ---- ----
Meridian CDC
We use it in our sign-off flow.
The tool finds CDC issues, either in a block internal design or when the
blocks are integrated together into a large SoC. We then use the
reported violations to add required synchronizers and improve the
synthesis constraints.
We use it at both the block-level and chip level.
Block-level CDC checking
- We prefer to solve CDC issues in small scale -- our block
designer will usually run the block-level CDC as they are
familiar with all its clock relations and considerations.
- It's only required primarily for blocks which uses more
than one clock. For blocks with only one clock domain,
a CDC run is a redundant check.
Chip-level CDC checking
- Is a MUST -- it requires more knowledge of the full chip
functionality.
- We detect the majority of CDC issues running Meridian CDC
at this level.
Hierarchy
I recommend Meridian CDC's hierarchical flow to analyze and best solve
these issues most easily.
- Once the block-level issues are solved or waived, we convert
the block into a gray-box, and run chip-level checks where only
the block interface will be checked against the rest of the
chip.
- Even if we run it without gray-boxes, our block-level waivers
can be re-used at the chip level so there is no need for us to
re-analyze the same issues again.
Speed/Capacity
I have not run into any capacity or performance issues with the tool,
even in large SoC designs when running in hierarchical mode. Why?
Combining block-level and chip-level checks -- we use the black-box
or gray-box methodology to reduce the design size as needed.
Low Noise Reporting
Meridian CDC typically reports each CDC issue only one time. There are
a relatively small number of issues which violate more than one rule;
the tool reports these issues under all the violated rules -- solving
our CDC issues simultaneously resolves several reported errors.
iDebug
I've used both the schematic and source-code iDebug options with
Meridian CDC. It allows me to back trace the reported issues to
the root cause. For each error-type iDebug includes an explanation
of the reported issues -- including examples of possible causes for
each specific violation. Good stuff.
Tool inputs that we feed Meridian CDC:
- Design modules -- RTL only, we've never fed it gates so we
can't speak to that.
- Behavior models and lib definitions for hard-macros -- to allow
the tool a full understanding how the clocks and signals driven
by our design are used inside the hard macro
- Clock and Reset definitions -- to get the dependencies between
these critical functions
- Input & Outputs relations to the specified clocks.
- Constraints -- to get the relation between the different clocks
which co-exist in the design
- Case-analysis definitions -- MUX selection, signals stability
relative clocks -- to allow focusing on specific test conditions.
- Special synchronizers definitions -- to allow the tool to
understand the special designed circuits used to handle CDC
design.
I recommend Meridian CDC. (Since I don't use other CDC tools, I can't
give a comparison)
---- ---- ---- ---- ---- ---- ----
Compared to Spyglass CDC, I figure Meridian CDC had roughly 1/10th
the number of violations had for the same design. Real Intent
was a lot less noisy in it's violations reports.
---- ---- ---- ---- ---- ---- ----
We're looking at switching over from Meridian to Verix for CDC,
but it's not a cheap upgrade.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
SYNOPSYS SPYGLASS CDC USER COMMENTS
---- ---- ---- ---- ---- ---- ----
We've used Spyglass CDC for years.
It works pretty well catching our CDC issues.
---- ---- ---- ---- ---- ---- ----
Veridi plus Spyglass plus Spyglass CDC.
---- ---- ---- ---- ---- ---- ----
Spyglass CDC should be in that list.
Years ago, it caught a clocking error that would have cost us dearly
so since then we've stuck with it.
---- ---- ---- ---- ---- ---- ----
VCS
Spyglass lint
Spyglass CDC
PrimeTime
Design Compiler NXP
---- ---- ---- ---- ---- ---- ----
Spyglass CDC
---- ---- ---- ---- ---- ---- ----
For our netlists, we use VC Spyglass CDC.
For our RTL, we use Meridian CDC.
---- ---- ---- ---- ---- ---- ----
Our local SNPS sales guys says we should give VC Spyglass CDC
a close look. Not sure if we will or not. To save money, my
company believes in if it ain't broke, don't fix it.
---- ---- ---- ---- ---- ---- ----
Related Articles
Real Intent low noise/multimode Meridian RDC gets the Best of 2020 #3a
Users choosing Meridian CDC over Spyglass CDC gets the Best of 2020 #3b
Real Intent Verix CDC true multimode analysis gets the Best of 2020 #3c
Ascent Lint "designer intent" and pre-submit gets the Best of EDA #3d
Join
Index
Next->Item
|
|
