( ESNUG 577 Item 1 ) ---------------------------------------------- [10/20/17]
Subject: Dan Joyce on Verdi, Avery SimXACT, VCS XPROP, Anirudh vs. Prakash
If you compare the number of hands-on tool users, the number of frontend
functional verification guys very easily outnumbers the relatively fewer
numbers backend DRC/LVS physical verification guys. I don't have any data,
but I would not be surprised to learn the frontend verif users outnumbered
their backend equivalents by a ratio of 10 to 1.
So to be blunt, *this* is what your #1 Must See should have been:
Breker TrekSoC, Cadence Perspec, and Mentor inFact on their Portable
Stimulus tools.
- from Cliff on PSS, Real Intent, CDC, HLS, Fishtail, IP
From: [ Dan Joyce of Correct Designs ]
Hi, John,
I suspect that it's not smart for one consultant to point out how another
consultant is correct. Especially publically. But Cliff Cummings is right.
You messed up by not making Portable Stimulus tools the #1 Must See for the
DAC'17 in Austin.
And seeing Anirudh and Sawicki on stage arguing over Pegasus (ESNUG 576 #1)
was fun to watch -- but as a functional verification engineer, DRC tool
fights aren't all that important to me...
Anyway, here's three things that Cliff Cummings missed at this DAC.
1) Cliff missed that Synopsys Verdi has a Hot New Trace Driver Function
For years I have wanted Synopsys Verdi to trace through interfaces
and clocking blocks better (or at all). I believe one of the
reasons designers don't delve into the testbench anymore is due to
this simple lack of functionality in our wave favorite viewer.
I am religiously Verdi, and I believe "Trace Driver" is extremely
important and influential to how people work.
I was told that Synopsys has been working for some time on a better
tracing mechanism that will finally take us reliably through interfaces
and clocking blocks into the testbench tasks, functions, sequences,
drivers, etc.
After DAC, I tried this new feature on Verdi 2017.03. It is awesome.
Not perfect, still beta, but I am moving to Verdi 2017.03 for all of
my Gate-Level Simulation (GLS) work even though the rest of the team
hasn't yet.
Using this new Verdi, I was able to trace a signal change on my DUT
input through an interface and clocking block and into a class in a
UVM package.
Previously my method was to "grep -r" my whole work area and hope I
found all the possible culprits, then add a $display and recompile and
rerun. The other option is interactive debug although if tracing
through interfaces does not work, this won't help either.
What year is this? Are we still debugging with prints???
2) Prakash Narain and Anirudh went at it at the DAC Troublemaker Panel
Interesting to hear Anirudh bragging about utilizing his CDNS formal
team for his Cadence LINT tool development -- while Prakash banged
away at Anirudh about signal-to-noise ratio. I even wrote about this
problem earlier before DAC in an ESNUG post:
"Linting Bugs. Lint tools like Real Intent or Spyglass look
at your source Verilog/SystemVerilog/VHDL RTL code that produces
bad gates. The bad news is that some lint tools (I won't say
which ones) have a signal-to-noise ratio that produce too many
warnings that need to be reviewed and waived by hand. The
human error of waiving the wrong lint warning makes a difference
between RTL and gate functionality. And worst, LEC will not
find these waivered bugs since LEC starts with the same
wrong gate functionality."
- Dan Joyce's 16 bugs only found w/ gate-level simulation
LINT is a big deal to me because I run gatesims. LINT is one of the
3 tools that need to be top notch to keep from finding problems in
gates (which should never happen) or worse in silicon. Those tools
are LINT, LEC, STA.
The issue for me on LINT is signal-to-noise ratio, so I was really glad
to hear Prakash hammer Anirudh on this.
But I'm focused on basic LINT - will my RTL produce gates that function
the same as the RTL??? There are new-fangled LINT tools that look for
Clock Domain Crossing issues, etc.
That is where I could see a formal team come up with something really
interesting. BUT don't break the basic function of LINT. And that
means give me a simple LINT tool that checks the synthesizability of
my RTL with a good signal to noise ratio so my designers don't miss
an important LINT error because it was buried in a pile of crap.
Then and only then you can start messing with more complex issues.
I know, I know, they can charge more for the cool new stuff...
I did talk with Prakash at the Real Intent booth after the show, and
he understandably spent most of the time talking about the new cool
stuff. But at least he understands signal-to-noise.
3) Cliff Missed Out on the Avery SimXACT plus the VCS XPROP "hole"
Although Cliff gave a throw-away comment about Avery IP, he totally
missed out on covering the Avery tool called SimXACT that I have used
recently.
It is intended to help identify X-init bugs in gate netlists. This
has to do with the X-pessimism in gate simulation -- which is one of
the biggest pains with gates.
There are many cases where X's that are left behind in non-resetable
latches, flops, and RAMs (like "reg1" here) will propagate X to "reg2"
in the gatesims when they would not do so in RTL or in silicon.
But there are other cases in a design where they do not propagate in
RTL, but they DO in silicon -- real silicon bugs. Separating the real
from the bogus has always been a real challenge. Often people spend
so much time on this one issue, they never get to the other 15 types
of bugs found in gates. (See ESNUG 569 #1)
My old methodology was to initialize all the latches, flops and RAMs
at time 0 to either all 0's, all 1's or random. Then run regressions
many times with random. This does not work well because we would
always find some X-init bugs when we first ran gates. Note: gates
with timing is not needed for this check. Then we started using VCS
XPROP and is was fantastic.
Now we're finding these X-init problems in RTL!!! Bugs were found
much earlier, and were found in RTL sims which are easier to debug.
Avery SimXACT runs on a gate netlist, so when it sees an X propagating,
it uses its XOPT FORMAL tool to look at the logic and determine if the
X is from gate X-pessimism, or if it is a real problem.
The most common issue SimXACT helped with was recombinant X's. An
easy example of this is when a MUX is implemented as a AND-OR (3 NANDS
actually) with the select input inverted on one AND and not inverted on
the other.
When both IN1 and IN2 inputs are the same and the SEL is X, the output
OUT should be the same as IN1 and IN2. But because the MUX is
implemented as 3 separate NAND gates, the first stage effective ORs
sees two X's when the inputs are both 1. SimXACT finds things like
this and deals with them.
I found SimXACT useful in showing others how much effort it would take
if we still tried to fix every X in gatesims by hand. SimXACT ran for
days finding 1,000's of cases where recombinant X's were causing the
gatesims to propagate X's that would not be a problem in silicon.
WATCH OUT FOR THE VCS XPROP "HOLE"!
But when I told Avery the fact that we use VCS XPROP at the RTL stage,
it meant we didn't really need to run the costly SimXACT on our gates.
That's when the Avery developer told me about a hole in VCS XPROP that
bit one of their customers.
If a vector or RAM is being written with an index that is X, VCS XPROP
does not propagate the X. This is bad. I talked about the beauty
of VCS XPROP in my Gatesims post (ESNUG 569 #3), but now I have to add
a big fat caveat. We are now looking at our logic for any cases where
we use this logic in our RTL. And I am running SimXACT. I hate that
I have to run an extra tool like Avery SimXACT to catch stuff that VCS
XPROP should be catching.
Note: there are at least 16 different types of bugs to be found with
gatesims (ESNUG 569 #1), and X-init bugs are easily less than half of
the ones found. And X-init bugs are often ones that can be worked
around with a simple SW fix. Timing bugs are still the most common,
and most deadly. (In fact, the one X-init bug in my career that bit
me -- that is, got into silicon -- was easily fixed with a second
reset of its logic. While a timing bug that was found before tapeout
on that same chip -- which was only found because we prioritized it
over X-init bugs -- would have had no fix!)
I really hate how much time I have to devote to chasing X's, so I'm
hoping the VCS XPROP R&D folks have an easy workaround for this hole.
And I hope I don't find anything real with SimXACT.
OK, now that I've found 3 tech holes that Cliff Cummings missed in *his*
DAC'17 trip report, as a rival verification consultant my work here is done.
- Dan Joyce
Correct Designs, Inc. Austin, TX
---- ---- ---- ---- ---- ---- ----
|
Dan Joyce works as a verification consultant at Correct Designs in Austin, TX. When he's not listening to his wife bitterly complain about Trump, he likes to nap. "I love napping!" Non-robots can reach him at <user=danj domain=correctdesigns not calm>
|
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
|
|
