( ESNUG 488 Item 3 ) -------------------------------------------- [03/01/11]
From: [ Beetlejuice ]
Subject: A user's first look at Zocalo Zazz and Bird Dog SVA verification
Hi John,
We spoke on the phone about a week ago. Please publish this anonymously.
I manage a processor verification team for a major SOC provider. Assertion
Based Verification (ABV) has been a core component of our verification
methodology for a long time. We are familiar with both its capabilities
and limitations. A couple of areas where we continue to struggle with are
assertion debug and getting our design team to adopt assertion development
wholeheartedly.
We became interested in Zocalo at the 2010 DAC, intrigued by the areas their
Zazz tool is advertised to address: identifying assertion candidate signals,
facilitating assertion creation, and assertion metrics.
System Verilog problems:
We began an informal evaluation of Zazz in September 2010. We started our
evaluation by testing scalability to determine if Zazz could handle our
design database -- about 350,000 lines of RTL.
Zocalo tried to load in our current design for this test and immediately
experienced tool issues. Our design employs a variety of System Verilog
constructs which Zazz had not encountered before. The Zocalo folks worked
through tool bugs over the next few weeks, ultimately enabling our design
database to load successfully in about 2 minutes.
Bird Dog so-so:
We spent some time examining the signals highlighted by its Bird Dog,
which uses a heuristic to propose good assertion candidates. In our case
the signals identified were largely either obvious candidates or were so
ubiquitous and basic to the design (e.g. reset) that a malfunction would
be immediately apparent. The Bird Dog heuristic process is interesting
and may well have value in other contexts, but didn't impress us strongly
in this eval.
Zazz strengths:
During the course of this evaluation we created 17 assertions using Zazz.
Our design already included a large number of assertions, but it was the
ability of Zazz to easily develop checks for complex scenarios that we
appreciated.
The Visual SVA utility, for graphical assertion creation, is a highlight
of the Zazz. It enabled the development of sophisticated SVAs which let
us create structures more complicated and powerful than we would have coded
by hand. Historically, assertions we have created by hand averaged 3 or 4
terms. Assertions we created using Zazz had anywhere from 10 to 20 terms,
averaging about 13 terms.
Folks on our logic design team, who generally aren't expert in SVA syntax,
were very happy with the graphical utility (and I was happy to have the
assertions they created using it). The graphical representation of their
assertions was very useful for reviewing as well.
Our team could look at the graphics view and quickly determine if they
agreed on the design intent that assertion reflected. Modifications could
be made and debugged quickly.
Local Variables:
Another powerful feature supported by Zazz is the use of local variables.
Our processor is pipelined and multi-threaded and most assertions checked
behavior across pipeline stages. Local variables allowed us to capture
a thread ID and use it throughout the assertion to associate signals across
pipeline stages with that thread ID. This straightforward local variable
syntax replaced about 12 lines of code per signal, previously used to
synchronize the signals across the pipeline stages.
We were also able to create assertions which included procedural functions.
This allowed us to leverage the temporal nature of assertions, where
previously we would have had to check this type of functionality using
60 or more lines of procedural code. See the example referenced below.
Assertion debug is also a strong point for Zazz. We usually debug within
our VCS simulation environment, which can be difficult even for simple
assertions. In our case a core-level simulation can run anywhere from
1 to 3 hours. With additional time for analysis, assertion debug can be
very time consuming.
With Zazz, debug in an auto-generated testbench is completely independent
of the simulation environment. For all the assertions we created, with
Zazz we could compile and display waveforms within 2 minutes.
Because of the late stage of our design, the functionality of our block
was already well wrung-out. However, one of the assertions we developed
using Zazz did identify a design anomaly, which fortunately does not
result in a functional error but is something that we will address in
future versions.
We have not yet spent any time examining the assertion metrics provided
by Zazz, and therefore don't have any comments with respect to that feature.
The assertions developed using Zazz can be incorporated directly into a
testbench without any ongoing requirement for license or access to Zazz.
The assertions we developed are now an integral part of our Synopsys VCS
verification environment. The verification engineer associated with this
block continues to create and expand the use of Zazz to assess the
capabilities as his time permits. These include the use of function
calls and local variables and interaction with the testbench as part of
the assertions being developed.
Conclusion:
The Zazz Visual SVA's are much more complex than hand-generated assertions.
Talking 3 or 4 terms vs. 10 to 20 terms. The Zazz graphical representation
of SVA assertions makes it much easier for an engineer who didn't originally
create the assertions to pick them up, understand, and debug them.
The Zocalo Bird Dog feature has promise, but it didn't help us ID any
signals of interest in this eval. We also can't speak to Zazz assertion
metrics because we didn't have time to look at them.
- [ Beetlejuice ]
Join
Index
Next->Item
|
|
