( DAC'19 Item 3a ) ------------------------------------------------ [02/20/20]
Subject: Real Intent Meridian CDC & Verix CDC tools take Best of 2019 #3a
SINGLE MODE CDC STILL ROLLING: As the #3 for Best of 2019, the users gave
the single mode Real Intent Meridian CDC high marks for two things:
1. Fast run time -- making it more likely designers will actually run
it regularly as part of their standard design process.
"My IP has always completed in under 30 minutes"
"Since Meridian CDC's runtime is fast, it is straightforward
for us to trace our RTL and constraint changes."
2. Noise reduction. Since reviewing all violations/warnings to find
the actual errors can be the biggest time sink for static signoff,
finding ways to reduce this review time without missing errors
is a BIG deal.
"Meridian CDC as less noise, i.e. more actual errors found vs.
the number of warnings given."
"We prefer Meridian CDC. From what we've lived through, it
generates a lot less noise than Spyglass does."
"Real Intent has commands to help identify a specific symptom
causing the noise, so Meridian CDC can then tune its analysis
to report fewer violations."
BUT MULTIMODE CDC IS WAKING UP: In 2019, I talked about the new importance
of multimode CDC in my DAC'19 Cheesy Must See List.
But the users only seemed to cite Real Intent Verix CDC as the "Best of"
for 2019 for multimode.
"Running serial runs for each mode is very time and machine-
resource consuming -- and can potentially miss some real
errors -- such as glitches during dynamic switching from one
clock to another, etc. So we use Verix CDC to multimode
verify our clock related CDC issues."
Plus one user even had benchmark data:
"Our design sizes range from 10 million to 50 million gates.
We had it analyze from 2 to 3 functional modes at the same
time. Verix CDC runtime (to report on all modes) ranged
from 1 hour to 3 hours."
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
QUESTION ASKED:
Q: "What were the 3 or 4 most INTERESTING specific EDA tools
you've seen this year? WHY did they interest you?"
---- ---- ---- ---- ---- ---- ----
REAL INTENT VERIX CDC (for multimode)
Real Intent Verix CDC multimode sign-off does CDC when your design has
multiple clocks that reach a single flop.
Many of our designs require support for different modes, in particular
our SoCs. It's very important we make sure our design doesn't have
CDC violations for any of these modes. You must define multiple clocks
to model it correctly.
General CDC analysis
- Our SoCs have a mixed set of components (e.g. processors,
memory, graphics and various other I/O peripherals...) that
work at different frequencies and interact heavily with each
other.
- You end up with multiple clock domains, and the clock domain
crossings are mostly asynchronous.
- We must verify that they all function correctly to avoid
design failures and silicon re-spins due to issues such as
incorrect or missing synchronization, glitches, or
structurally unsafe crossings.
Multimode CDC analysis:
- A single SoC we make must often serve different market segments.
This increases the number of modes, which adds even more CDC
complexity -- these CDC failures are hard to detect in silicon
and/or using simulation.
- Running serial runs for each mode is very time and machine-
resource consuming -- and can potentially miss some real
errors -- such as glitches during dynamic switching from one
clock to another, etc.
So we use Verix CDC to multimode verify our clock related CDC issues.
Verix CDC works at both RTL and netlist level.
1. Only requires one setup for your entire multimode CDC analysis.
You provide your design spec in SDC and Tcl as input.
2. Analyzes all modes simultaneously so that all possible scenarios
to be covered are in a single run. (vs. running the modes
serially "under-the-hood" like other tools).
3. Creates one debug report without error duplication, ie. it reports
only 1 error-per-design for issues that occur in multiple modes.
4. Analyzes your design intelligently to avoid reporting clock domain
crossings that cannot occur. (i.e. lower noise)
5. Analyzes design specifications for consistency and correctness.
It analyzes all error-type glitches and correlation losses in a
multimode context -- not just for crossings.
6. Verifies all paths that cannot be verified for CDC using static
timing analysis because they are asynchronous.
7. Combines CDC functional analysis and static timing principals into
one model. This even allows us to use our Genus static timing
analysis constraints for CDC verification.
8. Has options where users can provide clock design information to
improve the analysis.
Verix CDC Performance
We ran Verix CDC on multiple designs on a single core:
- Our design sizes range from 10 million to 50 million gates
(equivalent NAND2 gate count as reported by Verix CDC).
- We had it analyze 2 to 3 functional modes at the same time.
- Verix CDC runtime (to report on all modes) ranged from
1 hour to 3 hours.
We have a formal clock domain crossing sign-off methodology. Part of
it we use both Verix CDC and Meridian CDC -- each one for a different
purpose.
- We use Real Intent Meridian CDC (single mode) for RTL sub units,
which generally have a single clock and are independently
synthesizable.
- We use Real Intent Verix CDC (multimode) for bigger designs
which have lot more clocks and modes. At both netlist and RTL
level.
I would recommend Verix multimode CDC. It's two strengths are the
ease of use of single setup for multimode, and very good debug.
---- ---- ---- ---- ---- ---- ----
We like the Verix multimode CDC.
---- ---- ---- ---- ---- ---- ----
Looking at Verix CDC.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
REAL INTENT MERIDIAN CDC (for single mode)
Meridian CDC is our clock domain crossing sign-off tool for tape out.
It's easy to set up and its performance is amazing.
- We had a nearly 45+ M gate design complete in 6 hours.
- Since the runtime is fast, it is fairly straightforward
to trace our RTL and constraint changes.
- Meridian CDC can do hierarchical CDC, but because it's
runtime is so fast, we don't need to use it.
We use Meridian CDC for our top-level design. We usually start running
it when our constraints reach around 90% completeness.
Overall, I am confident in the results for "CDC sign-off" once all the
reported violations are clean.
I also use Meridian to CDC lint my constraints. For example:
- I fix setup rule (S rule) violations to generate a reliable
and qualified CDC report. At this step, I usually can see
constraint issues like missing or conflicting information.
- Then, the next step is to cleanup our W rule violations.
Meridian CDC captures certain checks that other tools can't. E.g.
catching S rule errors in our constraints is especially useful.
The tool organizes the violations in priority order, which is very
useful.
- I review the S rule Errors/Warnings and then fix them
concurrently.
- I also usually review CLK_GROUP and BLACK_BOX; and then
clean the W rule violations.
Real Intent also has pruned schematic views, which is helpful as it
makes it easier to identify where issues come from.
Overall, Meridian CDC's strong points are easy setup, very fast run
time, and it's good for checking design changes.
Plus, their AE support is immediate -- I can always get a response
within 24 hours.
---- ---- ---- ---- ---- ---- ----
Real Intent Meridian CDC
We use it to make sure that all our data paths cross from one clock
domain to another safely, so there are no glitches or consequences
in the receiving domain.
Our group has used only Meridian CDC for several years after evaluating
it against another CDC tool. Since then, other sites at our company
have compared it with that other CDC tool and still chosen Real Intent.
Based on the eval, they determined that Meridian CDC:
- Is as fast or faster that rival CDC tool
- Has less noise, i.e. more actual errors found vs. the
number of warnings given
OUR CDC SIGN-OFF METHODOLOGY
We run Meridian CDC at the RTL level. Our fundamental process is:
1. Meridian CDC takes in the top-level design, interprets and
analyzes it.
2. The tool then generates an environment file. The environment
file is the tool's interpretation of your root clock and
derived clocks, along with the signals associated with those
clocks.
3. The user can then ensure the environment file is correct, and
modify it as needed.
4. Meridian also reviews all the clock domains and ensures that
your designers have used the proper coding technique when a
data path crosses from one domain to another. You must code
your RTL in a way to ensure the gates can properly receive
the data.
5. After Meridian CDC analyzes your design with the environment
file, it produces a report, organized by:
a. Definite errors
b. Warnings (e.g. the area has some unsafe crossings
requiring further investigation)
c. Review (e.g. the tool thinks that everything is ok,
but you can review to verify)
6. Our users review the errors & fix them. For example, there
may be a warning due to the design or with the environment
file, which define groups that go together, and thus would
have a safe crossing.
7. We then make updates or waivers and run Meridian CDC again,
until our design is clean.
It's best to run CDC early when possible.
Our methodology is to run Meridian CDC early -- ideally as soon as our
design framework is up.
- After we run it through CDC checks, we compile the RTL, and
run it through mild simulation and P&R.
- These early CDC checks can influence some of our design
decisions.
As we then add pieces, such as the high-speed serial interface, we run
it through Meridian CDC again, which updates the environment file and
points out new CDC errors and warnings. Since we already ran the tool
earlier, we've already addressed the earlier issues, so there is less
to look at.
Some designs are better suited than others for this. For example, if
your clocks are so embedded in your low-level components that you can
bring them in later.
This methodology applies to both FPGA and ASIC designs.
- It's critical for ASICs, as you do not get a second chance.
- However, as designs get bigger, FPGA designs also need this
more, as it's more efficient and shortens the integration
time when you catch problems early.
Run hierarchical CDC analysis when reusing IP --
We typically only run Meridian CDC at the top level. However, this
is design dependent.
For designs where we have more IP reuse, our designers run Meridian
CDC on their blocks, and we then reuse the CDC information for the
block at top levels. Meridian CDC will retain those associations.
REAL INTENT MERIDIAN CDC FEATURES
Capacity & Runtime for Sign-Off
Our typical CDC sign-off runtime ranges from 1 minutes up to 10 minutes,
depending on the number of clocks.
80K LUT - 6.5 min
3K LUT - 1.0 min
Noise Level Improves with Designer Experience
Real Intent has continued to evolve Meridian CDC. It's hard to
quantify, but its noise level is reasonable. The "other" CDC tool
had so much noise, that it's so overwhelming to find the actual
errors mixed in; and you can miss them.
One key thing that contributes to noise is your designers not having
good code.
- Because Meridian CDC gives coding feedback, it influences our
designers to code properly over time.
- Thus, this aspect of our noise level has definitely gone down.
The Meridian's coding feedback can also be useful feedback for new
designers.
GUI & Debug
We run our initial CDC analysis steps through the command line
interview, then use the GUI for reports
Real Intent's debug is very good. CDC sign-off needs human interaction,
and with Real Intent's "iDebug", you can:
- Look at the RTL source of the CDC error, or view it
schematically. (They are linked.)
- View the transmitting clock & register, the receiving clock &
register, along with any logic in between that could
potentially be a problem.
- Double click to expand the schematic to look at next register
Meridian CDC does a good job and targets the CDC issues we look for.
The noise level is reasonable, and it has helped us to identify very
hard to find bugs in hardware.
---- ---- ---- ---- ---- ---- ----
We use Real Intent Meridian CDC to check our IP for cross domain clock
violations.
- We use it for all our IP before RTL freeze.
- We also run it for partition level and for chip level.
We run Meridian CDC as a part of project-level regression every week.
After each IP unit level, the IP designer ramps up Meridian CDC, runs
the regression, and gets a weekly report.
I'm happy with it's performance -- it's pretty fast.
Our flow uses hierarchical runs both for our partition and chip-level
runs. We only use hierarchical runs on our IP if the IP is too big to
fit in a ~30 minutes flat run. My IP has always completed in under
30 minutes, so I haven't personally had to use it.
Real Intent has a Meridian CDC feature where they organize the
violations in a priority order.
It is a useful function, that works pretty well. I'd like even more
added to it: In certain cases, Real Intent will include multiple
violation types in one group. We would like the tool to split the
violation into separate groups, so that it easier for the person who
debugs it to do "divide and conquer". We'd also like to have the most
important item for each violation highlighted -- if it's technically
feasible.
I would recommend Meridian CDC. It has proved to be an efficient/fast
tool, and Real Intent has good customer support.
---- ---- ---- ---- ---- ---- ----
I'd recommend Real Intent Meridian CDC for clock domain crossing
analysis -- the tool is fast.
We use it for CDC analysis and sign-off. Our methodology is to:
- Run Meridian CDC on our design modules at our "code is
complete" milestones.
- Re-run it when we change any relevant RTL elements.
- Run it for our final milestone (RTL freeze) sign-off
Meridian CDC's performance was good -- running ~3M gates took about
30 minutes.
For noise reduction, Real Intent has commands to identify a specific
symptom causing the noise, so Meridian CDC can then tune its analysis
to report fewer violations. It's useful & we've applied for certain
cases. Needs improvement: For some cases we had problem identifying
the cause of the noise. We'd like Real Intent to do more work on
this capability.
Another useful feature is that Real Intent organizes the CDC violations
in a priority order, with errors listed before warnings, plus the errors
listed in priority order.
---- ---- ---- ---- ---- ---- ----
Real Intent Meridian CDC
We run Meridian CDC both on our individual modules as well as on our
top-level design.
We start our clock domain crossing sign-off step with Meridian CDC
during our final project stage -- after our design is stable. And we
run it again when we change our RTL.
Finally, we run CDC sign-off after final project freeze -- together
with our other sign-off tools.
Meridian CDC strengths:
- Real Intent organizes the violations, such as listing errors
before warnings. This is helpful. (Though it's not perfect,
as some "warnings" can be more critical than the "errors".)
- Meridian CDC's pruned schematic views are also useful for
debug.
Meridian CDC weaknesses:
- To make our review process easier, we want Real Intent to
reduce the number of irrelevant violations, or to be able to
configure CDC such way it won't display the irrelevant
violations.
- Speed up some GUI tasks -- for example, using the GUI to
specify waivers took us more time than running the tool.
Real Intent gives us good customer support.
---- ---- ---- ---- ---- ---- ----
Meridian CDC is something my guys use all day, every day.
---- ---- ---- ---- ---- ---- ----
I'd put the Real Intent CDC tools in the top 3.
---- ---- ---- ---- ---- ---- ----
We prefer Meridian CDC. From what we've lived through, it
generates a lot less noise than Spyglass does.
---- ---- ---- ---- ---- ---- ----
Related Articles
Real Intent Meridian CDC & Verix CDC tools take Best of 2019 #3a
Ascent Lint less noisy vs. SNPS Spyglass makes Best of 2019 #3b
Real Intent Meridian RDC has 20X less noise gets Best of 2019 #3c
Real Intent's AutoFormal *formal* linting makes Best of 2019 #3d
Join
Index
Next->Item
|
|
