( ESNUG 583 Item 2 ) ---------------------------------------------- [05/24/18]
Subject: Prakash leaks SimFix X-pessimism tool replying to Dan Joyce GLS
WARNING: RTL simulations treat X's very optimistically, while gates
treat them very pessimistically. Lately simulators have added an
X-propagation mode that causes the RTL simulation to propagate X's
more like gates, with the benefit of running at RTL speeds on much
easier to debug RTL code. Use these new X-pessimistic RTL sims
wherever you can. It'll run 6x to 24x faster than GLS.
RTL simulations gobble X's from uninitialized SRAMs as well. Since
most SRAMs do not auto-initialize, bugs of this type need to be
identified, and this can be done before GLS with x-propagation.
- from Dan Joyce's 29 gate-level simulation tips (pt 2)
From: [ Angry Engineer #3 ]
This is in regards to Dan Joyce's letter in ESNUG 569 #3
Gatesims are not worth the effort. Debugging all the X's in our gate
tests was a huge effort. We had X's everywhere. Someone finally added
some code into our DFF library model that turned X's into random values,
and the X's cleared up. Then our tests just hung. No time progressing.
So we debugged it to a live-lock in the DUT, but it was because we had
initialized to a value that caused a ring oscillator to be enabled.
We added a force to kill that, and half our tests were failing. These
were not even back annotated timing gate tests.
We spent weeks debugging those tests and needed help from the designers.
It was impossible to debug, so we punted and taped out.
Chip came back and worked fine.
Chasing X's was a big runaround for nothing.
- [ Angry Engineer #3 ]
http://www.deepchip.com/items/0574-01.html
From: [ Prakash Narain of Real Intent ]
Hi, John,
It is obvious from the responses to Dan Joyce's write-up that gate level
simulations (GLS) are hard to do -- and X-pessimism is the main culprit.
I was impressed there were 157 positive responses to Dan's GLS articles,
and only 21 negative responses, and of those 21 negative responses, only
a couple disputed that some GLS is always needed.
First off, Dan Joyce is right. We are seeing GLS in active use and as an
integral sign-off step at design houses, for some of the reasons Dan has
discussed relating to failures that cannot be detected in RTL.
Secondly, we're also seeing low power requirements are causing some very
intrusive modifications to the design flow and driving up the need for GLS.
X-Pessimism causes X's in netlist gate simulation on nets that that would
have had a known value in real hardware. For example, in the mux shown
below, if the mux control signal is a X value, and both data inputs are
the value 1, the output becomes a X in simulation.
X-Pessimism causes false fails in simulation
In real hardware, the X is either a 0 or 1 value, and the output in real
hardware is 1 in either case.
Cascade Problems. These pessimistic X's then propagate downstream through
the netlist logic to cause even more X-Pessimism. Eventually the simulation
fails and you have to figure out (painfully!) what triggered all the X's!
Tracing X's to their source Verilog and determining how to fix them is a
nightmare. You have to rerun simulations with waveforms turned on and then
trace through a sea of unfamiliar gates - which takes forever. This is
the unnecessary debug of false failures that engineers hate, because it will
never happen in real hardware. Moreover, once you find the culprit, you
have to then figure out how to fix it accurately so that the fix behaves as
real hardware would behave.
---- ---- ---- ---- ---- ---- ----
Expensive Resets. A common way to eliminate pessimism is to randomly reset
everything in simulation, but as Angry Engineer #3 [in the quote above]
pointed out, it can cause false failures that have to be debugged as well.
Angry Engineer #4 says to Dan Joyce: "Chasing X's is a fools' errand. Just
reset everything and be done with it." Angry Engineers #6 and #7 also
suggest resetting all flops.
But as Angry Engineer #1 states: "Automatically adding RESET to everything
that VCS Xprop doesn't like causes excessive power/size use in our design".
This is consistent with what we also hear from our customers. This reset
sensitivity may be EDA tool specific, but nonetheless, not everyone has
the luxury to simply add resets everywhere.
Synthesis Traps. Interesting too is synthesis tools like Design Compiler and
Genus RTL can optimize your synchronous reset logic, combining it with the
non-reset logic -- and generate a gate-level netlist that is X-pessimistic.
So while one might think that adding synchronous resets everywhere will help
eliminate X's in RTL, in reality it can worsen the problem in GLS. Some
synthesis tools have switches to avoid the problem by not optimizing the
reset logic, but that fix comes at the cost of area, timing, and power.
---- ---- ---- ---- ---- ---- ----
Skipping GLS is risky but doing GLS is hard! For the past 5 years, I've had
my R&D at Real Intent work the X-pessimism problem ... so after 10 man-years
writing 3 million lines of C++ source code, I'm using this opportunity to
announce our new Verix SimFix tool that automatically and mathematically
fixes pessimistic X's in simulation. The key to its success is its ease of
use, accuracy, and low overhead in simulations.
SimFix pre-processes your design, using mathematical techniques to identify
potential pessimistic conditions in the design, and notes the correct value
under those conditions. It then generates auxiliary SimPortal files that,
when used in simulation, will monitor the simulation and fix X-pessimism
when it occurs.
Size Matters. One thing you'll notice for large designs is your simulation
runtime overhead of X-pessimism correction is often either sometimes slower
or sometimes faster than your earlier X-inaccurate runs!
This was a real surprise for people when they saw faster runtimes. This was
because those X1X1X1X1 oscillations disappear when you fix the X-pessimism.
(Less events == faster Verilog simulations.)
With SimFix, your GLS will have no false passes or false failures because
the mathematical analysis guarantees X-accuracy. It forces the value that
is expected in real hardware. Only when the X is real, then SimFix will
propagate the real X.
Common Problem. Our SimFix has static analysis built in. Here's an example
(above). Our experience has been it's very common for designs to have more
than 90% of their nodes vulnerable to X-pessimism.
It's Hierarchical! To enable SoC-scale GLS, the mathematically intensive
static X-pessimism analysis is done at block-level (~10 - ~20 M gates per
block), and is independent of the testbench. Correction files from the
block-level are then easily incorporated into your top-level simulations.
Your gate-level simulation is performed at full chip using these files.
This hierarchical flow scales to meet the needs of your future designs.
For your simulation compiles, our SimPortal architecture is VPI-based. The
X-pessimism correction information is in data files to minimize your sim
compile time. It also has runtime and messaging controls that can be
tweaked at simulation time.
---- ---- ---- ---- ---- ---- ----
What makes SimFix practical is that the simulation overhead is marginal.
Also, minimal design knowledge is required. This means the tool can be
run by the verification engineer, instead of requiring a Formal expert to
use it.
We've beta tested SimFix across a mix of different styles of designs, and
have seen it to be effective on 200M+ gate designs. We are continuing this
qualification across additional design styles.
Expect to see SimFix -- plus some other new tools -- at our Real Intent DAC
booth in San Francisco this year!
- Prakash Narain
Real Intent, Inc. Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
|
Prakash Narain has 26 years experience doing EDA at IBM, chip architecture at AMD, and verification for UltraSPARC IIi at Sun Microsystems. He founded Real Intent in 1999 and has the infamous Andy Bechtolsheim as an early investor. Rumor has it Prakash secretly craves peanut M&M's chocolate candy.
|
Related Articles
---- ---- ---- ---- ---- ---- ----
Related Articles
Real Intent trounces Synopsys Atrenta as the #6 "Best of" for 2017
Prakash and Anirudh spar on Real Intent Linting vs. Jasper Formal
One user's quickie eval of Real Intent AutoFormal and Ascent Lint
Real Intent and Blue Pearl get #2 overall for Best EDA of 2016
Join
Index
Next->Item
|
|
