( ESNUG 491 Item 6 ) -------------------------------------------- [05/12/11]
From: [ The Man in the Iron Mask ]
Subject: A BRCM case-study on NextOp BugScope assertion synthesis at DVclub
Hi John,
Please keep me anon.
I went to a DVClub lunch meeting in Milpitas with 120 engineers on April 26
where two companies presented case studies. Here's my first of two reports.
Jing Li of Broadcom presented on NextOp BugScope assertion synthesis.
Jing said that overall Broadcom has issues with enforcing hand-written
assertion based verification (ABV) in company. They encouraged designers to
write assertions, but had problems with learning the SVA language and
mastering coding assertions. Plus manually-written assertions often do not
match designer's intent exactly, and debugging the assertions required
simulation cycles and is time consuming. Finally, Broadcom had no good
measurement of the assertion quality or how many were sufficient.
Broadcom deployed NextOp BugScope assertion synthesis; which automatically
generated properties; which the designers then review to decide if they are
- assertions (to help with block integration) or
- coverage holes (to define the signoff criteria).
Broadcom said the properties generated by BugScope:
- Improved the quality of block-level verification, and it helped
find corner cases and late stage and post-silicon bugs missed in
Broadcom's traditional flow.
- Provided good functional coverage with increased visibility.
- Are high quality, with low noise ratio. On average, BugScope
provides 1 property per 20 lines RTL
- The property review provides an excellent way to do design review.
Jing showed this diagram of the BugScope Use Model:
Broadcom's verification flow With BugScope worked like this:
- Block testing. Broadcom runs BugScope and uses the synthesized cover
properties for sign-off. Broadcom then integrates BugScope-generated
assertions into:
- Component testing to validate the block assumptions and
get better visibility.
- Chip Testing for better observability with zero cost.
- Emulation of the assertions are used for debug and they
collect coverage with cover properties
As for results with BugScope, Broadcom found bugs in most blocks that
couldn't be found before. Some bugs were found during property review,
i.e. classifying assertions improved component/chip/emulation visibility.
Jing then gave examples of some bugs they found using BugScope:
- Bug #1: Found from reviewing the property alone.
@r_max_sc>=r_max_sc
The property was a flag that they never rest r_max_sc except for
a hard reset.
- Bug #2: Coverage property found a corner case bug.
cover (sop && sopmh)
Property showed a coverage hole, and when the coverage was added,
they found a bug.
- Bug #3: Assertions gave better emulation debug. Broadcom knew they
had a problem and could reproduce it in emulation, but they couldn't
locate the source, even after 2 weeks of debug. BugScope property
clean_cnt<=19
was used as emulation trigger and found the bug in 2 hours.
- Bug #4: Coverage property revealed bypass bug. BugScope property
valid_c6 & valid_c7 & index_c6 == index_c7 |-> data_c6 == data_c7
showed a functional coverage hole and a bug in the bypass logic.
Broadcom said BugScope had these gotchas:
- Outputting cross-module properties is a pain.
- needs a GUI tool to support more refined classification rules.
- It's slow when there are a large number of instances; performance
is linear to number of instances per module
Jing said the overall investment in NextOp BugScope was worth it, based on
the number and quality of design bugs that Broadcom found using the tool.
The main cost isn't money, but the designer time required to review and
classify the BugScope properties; however, they reuse the classified
assertions at all levels upward for 'free,' and signing off with BugScope
increased Broadcom's verification confidence.
- [ The Man in the Iron Mask ]
Join
Index
Next->Item
|
|
