( ESNUG 580 Item 5 ) ---------------------------------------------- [03/16/18]
Subject: 157 positive and 21 negative comments on Dan Joyce's GLS post
A WHOLE LOT OF APPLAUSE: Whenever I publish anything on DeepChip, I get a
peppered with short replies from the readers that I call "snarkies".
Why I call them "snarkies" is they're usually often just short quick 5 to 7
word replies about whatever is being emailed out that day. That's to be
expected when you send out email to 52,000 engineers. They're going reply.
And they're usually a conflicting mix of replies.
But when Dan Joyce, a consultant at Correct Design in Austin, published his
16 bug types plus his 29 tips (45 points in all) dissertation ...
Dan Joyce's 16 bug types only found with gate-level simulation
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 1)
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 2)
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 3)
about the importance of still doing Gate-Level Simulation (GLS) in a world
of LEC and STA -- it got back 157 positive reader snarkies like:
"Wow! This is good!"
"Dan Joyce wrote the Bible on GLS. Well done."
"This is a good read, John. Thanks for publishing it."
"I'm showing this to my management."
"From Dan's post, it's clear we have to add back GLS to our
sign-off process."
"Yes!"
"Looks like this will be my reading assignment over lunch."
"Good."
"I plan to bring up gate simulation in our next stand-up."
"Home run."
For comparison, a typical DeepChip story gets 10, maybe 20, positive reader
snarkies. Joyce getting 157 positives was big! It might be a record.
I usually don't bother publishing positive snarkies because -- other than
the author -- I assume most engineers honestly don't care to see all these
"praise" snarkies every time a DeepChip email story goes out.
But I do think everyone would want to see where 21 HW engineers had disagreed
with what an article was saying. So here they are.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
Tip 13: Find those Gate Bugs easier and sooner in RTL Simulation
You can use X-propagation in RTL simulation to find GLS bugs. Anything
that helps to find bugs in RTL instead of GLS is a win. GLS finds bugs
late in the design process -- where they are much more expensive to
debug and fix at that time.
- from Dan Joyce's 29 gate-level simulation tips (pt 2)
From: [ Angry Engineer #1 ]
Dan Joyce's post on gatesims says to use VCS Xprop in RTL simulations to
find all of our RESET bugs before synthesis. We had a big problem with
that tool. We were simulating with VCS Xprop and found a case of X's from
a non-resetable DFF propagating throughout all of our logic.
When we told the designer, he said it would not propagate because of the
way the logic was was designed.
So to prove it was a real bug, we set the DFF to 1, and ran regressions
and we set it to 0 and ran regressions. All tests passed in both cases.
So there is no problem with this design! It's a VCS Xprop error!
Automatically adding RESETS to everything VCS Xprop doesn't like will cause
excessive power / size use in our design where it is not really an issue.
- [ Angry Engineer #1 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #2 ]
We've not had good luck with VCS Xprop.
- [ Angry Engineer #2 ]
---- ---- ---- ---- ---- ---- ----
Tip 13 A: Finding Reset Initialization Bugs in RTL Simulation
Many designs reduce size and power by using non-resetable DFFs in
their data paths. Occasionally non-resetable DFFs are accidentally
used for control logic -- and since in the real silicon these DFFs
come out of power-on into either 0 or 1 randomly, these reset-init
bugs can really be chip-killer bugs.
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 ]
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 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #4 ]
Chasing X's is a fool's errand. Just reset everything and be done with it.
- [ Angry Engineer #4 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #5 ]
Talk to the Real Intent guys. They're very knowledgable about X's and they
will catch it in the RTL stage.
- [ Angry Engineer #5 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #6 ]
Simple. Just never reset to X.
- [ Angry Engineer #6 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #7 ]
Silicon is cheap. Design so you always reset to a known "0" or "1" and
be done with it. Having your engineers trying to determine if X's are
handled neither optomistically nor pessimistically is a waste of their
brainpower and skills.
- [ Angry Engineer #7 ]
---- ---- ---- ---- ---- ---- ----
I couldn't make that DVcon'17 conference, but I found it disturbing to see
how many HW design & verification engineers were nonchalantly drinking
the Jonestown Kool-Aid that formal tools and much faster emulation boxes are
going to replace old school Verilog/VHDL RTL software simulators in chip
design -- and especially with that truly dangerous notion of not bothering
to do gate-level simulations at all -- or even considering just dropping
timing from their Gatesims altogether.
If I was there at that DVcon, I would have been seriously fighting the
urge to shout down those engineers thinking of skipping gate-level sims.
- from The 16 bug types only found with gate-level simulation
From: [ Angry Engineer #8 ]
I have never seen any chip house with the time to do all this stuff just for
simulating gates. I want to work for whoever Dan Joyce works for so I can
get that much free time for one small task.
If you put half this effort he's asking for into your design in the first
place, you wouldn't need gate simulation at all.
- [ Angry Engineer #8 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #9 ]
Real engineers don't need all this GLS crap. We never put that much effort
into gatesims. Does Dan Joyce really expect us to run gates on 18 different
netlists?! We pull it all together at the last minute and get it passing
and tapeout.
We have some crazy days around tapeout, but we always get it running.
I've never seen anyone put together this much effort to get gates passing.
Seems like some people have more time on their hands than we do.
- [ Angry Engineer #9 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #10 ]
We give our gate simulation to the worst engineer in the building. I think
our boss uses GLS to make people quit. Everyone hates it. There HAS to be
a better way to live your life than running gates!
- [ Angry Engineer #10 ]
---- ---- ---- ---- ---- ---- ----
Tip 17: It's Easier to Archive each Netlist
At some point it will be necessary to checkin your GLS changes.
Usually RTL verification teams do not tolerate "`ifdef GLS"
splattered all over their testbench. If you check your GLS changes
into the Master Repository, this GLS stuff will go into the Master
Repository testbench code.
Makes an additional set of "temp `ifdefs" as well. You have to update
to the Master Repository Branch to checkin to it -- which breaks GLS
on this Netlist because it pulls in changes that don't match that now
very old Gate Netlist. These must be "temp ifdef'ed" as well to allow
the GLS tests to pass. So then two sets of "`ifdefs" are polluting
the Master Branch of the repository.
Instead, it is possible to keep the GLS branch separate from the
Master - see the diagram above. Never merge back nor checkin to
the Master. Keep the GLS Repository Branch as a parallel branch
that pulls from Master every new netlist to update testbench and
chip RTL, but never merge back. Tag the last checkin of each
netlist as an archive. Only after tapeout you merge back.
- from Dan Joyce's 29 gate-level simulation tips (pt 3)
From: [ Angry Engineer #11 ]
Dan Joyce's Tip #17 showed a separate branch of the repository for gate
simulation - never merging back into the main, or at least not until after
tapeout. Our manager REALLY did NOT like the idea of having a separate
branch of GIT for running Gates. It looks like a maintenance headache.
We have enough trouble with one GIT branch.
- [ Angry Engineer #11 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #12 ]
Your chip is in a GIT repository with 300 little branches.
What could possibly go wrong?
- [ Angry Engineer #12 ]
---- ---- ---- ---- ---- ---- ----
DAN JOYCE'S 16 BUG TYPES ONLY FOUND BY GATE-LEVEL SIMULATION
The following lists 16 chip design bugs that can only be found cheaply
by using GLS. Keep in mind, I'm in gate-sims. This is at the tail end
of the project where the design team tells me "this chip is ready! We're
good to go!"; and then I've caught least 1 of these chip-killer bugs
after that point.
- from The 16 bug types only found with gate-level simulation
From: [ Angry Engineer #13 ]
Dan Joyce says that gates simulation is the only cheap way to find these
16 bug types.
Emulation finds many of these bugs. Most large chips today are being
emulated already. I counted at least 10 of the 16 types of bugs listed
are also found by emulation:
- #1 Timing
- #2 Linting
- #3 BFM-masked
- #7 ifdef
- #8 Dynamic Freq Change
- #9 Multi-Cycle Path
- #10 Force/Release
- #14 Delta-Delay Race
- #15 LEC Holes
- #16 LEC Waivers
In addition emulation finds SW/HW issues, and real world performance issues,
that gatesims will never find because the performance of gate simulation is
just way to slow to ever boot code.
- [ Angry Engineer #13 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #14 ]
My local Cadence rep says he can detect all 16 of those bug types without
having to use gatesims.
- [ Angry Engineer #14 ]
---- ---- ---- ---- ---- ---- ----
Tip #19: In order of priority:
GLS Test Goal #1: No False Fails
Your tests must check for correctness in a way that is not brittle.
It has to be robust. You must be able to change clock frequencies
and skew stimulation on your GLS without causing the test to flag a
failure incorrectly. Chasing down these False Fails is very costly
and can quickly make GLS not cost-effective.
GLS Test Goal #2: No False Passes
Obviously a False Pass could allow a bug to get into silicon. You
need to know that if you get a GLS PASS on a test, that test really
did a complete enough check that you *know* the logic is working
as required. You have to know that PASS means it actually PASSED.
- from Dan Joyce's 29 gate-level simulation tips (pt 3)
From: [ Angry Engineer #15 ]
In his GLS Test Goal #1 and #2 he states that he would rather have false
passes than false fails. I could not disagree more strongly on this point.
As a verification engineer, I will always be more concerned about a false
pass that can let a bug into silicon than about false fails that are really
just making more work - hire more people if you need to.
- [ Angry Engineer #15 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #16 ]
False passes, like my ex-wife, will give you SERIOUS PROBLEMS.
Both are BAD IDEAS.
- [ Angry Engineer #16 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #17 ]
False fails are just part of life. Joyce is going to spend waaaaaay too
many man-hours if he's trying to craft a verification methodology with
absolutely zero false fails.
But for a consultant is there such a thing as too many man-hours?
- [ Angry Engineer #17 ]
---- ---- ---- ---- ---- ---- ----
Tip #19: GLS BFM tests
These are Monitor checking tests that use BFMs mixed in with your
GLS to stimulate and check correctness. These tests are easier to
write and debug than assembly hex code driven tests because they're
usually leveraged from your earlier RTL regression.
The catch is that they require Cross Module References (forces and
probes) into your DUT -- which is very tricky with Gate Simulation.
Your gate netlist must preserve all of the signals to be probed and
forced in each version, or there must be a mapping file for each
netlist that can be easily used to connect the signals to the
testbench.
- from Dan Joyce's 29 gate-level simulation tips (pt 3)
From: [ Angry Engineer #18 ]
Dan Joyce recommends BFM driven gates simulation in Tips #19 and #20. These
are a nightmare to get working. And clocking blocks in interfaces are one
of the most frustrating things I have ever worked with.
I don't know how he ever got this working unless it was an academic project.
- [ Angry Engineer #18 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #19 ]
"Hey! Let's mix BFM's with gate-level simulations!"
"Sure! Why not!?"
- [ Angry Engineer #19 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #20 ]
BFMs are not gate friendly.
- [ Angry Engineer #20 ]
---- ---- ---- ---- ---- ---- ----
From: [ Angry Engineer #21 ]
The gross timing levels of BFMs are not compatible with the fine granularity
of gate-level timing.
- [ Angry Engineer #21 ]
---- ---- ---- ---- ---- ---- ----
Related Articles
Dan Joyce's 16 bug types only found with gate-level simulation
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 1)
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 2)
Dan Joyce's 29 cost-effective gate-level simulation tips (pt 3)
Join
Index
Next->Item
|
