Experience using 0-in tools

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.13, Item 14.0)

From: Anonymous

We have been using 0-In since last October (2001). I would like to
share the experience we had on 0-In Check and 0-In Search.

We have a very rich verification infrastructure with lots of legacy
tools, environment and testbenches. With minimal effort, we integrated
0-In Check into our simulation environment without any external help.

Using 0-In Check in simulation is similar to writing verilog monitors
manually. Of course writing 0-In assertion directives are much
quicker. In our environment, we have just 1 person developing 0-In
checkers independently, while the new and legacy verilog monitors are
developed by a lot of people at different time.

The checkers are developed independent of the monitors. We have found
several bugs in our design using both 0-In Check and 0-In Search,
including bugs in our verification environment that had been missed
previously.

As mentioned, these predefined checker directives greatly simplify the
effort of developing monitors. We choose to put all the 0-In checker
directives into a single control file. The concise format makes the
checker source file fast and easy to understand. It is indeed a good
document for reference.

Although we use 0-In check extensively, it is the dynamic formal 0-In
Search strategy that initially drew us to 0-In. We have run 0-In
Search on several "tricky" blocks, and did find several tough
bugs. 0-In Search tends to find bugs that are missed by
simulation. 0-In Check helps to find bugs that can be caught by
simulation.

We continue refining checkers and accumulating more experience with
0-In Search. The complex checkers such as outstanding_id are perfect
for describing constraints, while the target checkers are better for
"temporal locality". By "temporal locality", I mean the assertion can
assert right away when things are going wrong. For example, if an ID
is dropped, fifo can detect it very fast by checking the dequeue order
while outstanding_id can not detect it until the id is illegally
re-used or time-out.

In summary, we have found 0-In Assertion-based verification
methodology is very productive for verification.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.14, Item 1.0)

From: Vasu Ganti

As a reader and as one who works in EDA, I can smell a marketing
document from a mile away! If I needed to find out about 0-In, I would
have read their datasheet or gone to their web site.

What was "Anonymous (from a large non-EDA company)" thinking? There is
no real data in here, is there? Just another marketing thingy.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.14, Item 1.1)

From: ravi

we use 0-in in our methodology with VCS and TestBuilder on linux
platforms. My experience is in only checkers, not search.

1. Assertions are easy enough to write and don't disrupt any flow.

2. Some assertions make it easy to write complex rules. (multi-clock
fifos, memory accesses, data consumption etc.).

3. Though the others (majority) are easy enough to write, locale
awareness of zeroin helps eliminate some effort

4. The design community (13) people took to writing assertions very
quickly and generated thousands of assertions in a few weeks.

5. 0-in consumes close to 10% of our simulation time, but localizes
problems to give us back some of it.

6. The stuff is not bug free. We have had 4 problems fixed by 0in. It
is done usually within the week.

7. The final user interface is mostly good with some weird quirks. (no
runtime switch, to turn off assertions for example). Some stat
generation takes quite a while to generate unless you suppress
it. The ccl compiler deviates a little from VCS (multiple wire
declarations are OK with VCS but not 0-in) and so on.

Final verdict, good stuff.

Room for improvement: Assertions are too targeted and isolated. We
need to be able to write assertions that understand more than wires
and nets. For example I should be able to specify that all outputs of
a module must be driven without specifying individual ports. I should
be able to write high level FSM assertions.

Some stuff should be default. They have a ccl and a s(smart)ccl. The
sccl is not the default causing compile time inefficiencies.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.14, Item 14.0)

From: Stuart Sutherland

The deadline for proposing papers for the Design and Verification
Languages Conference and Exhibition (DVCon) is at hand!!! The last
day to submit proposals is October 15, 2002!

DVCon 2003 will be held February 24-26, 2003 at the DoubleTree Hotel
in San Jose, California.

DVCon is the new name for the popular HDLCon conference, which will
celebrating its 12th anniversary session in 2003. The conference
began as the Open Verilog International Conference, and then merged
with the VHDL International Conference to become the International HDL
Conference. HDLCon's scope may have started with Verilog and VHDL,
but the conference scope has evolved as new languages have emerged,
such as VERA, E and SystemC. The new Design and Verification
Languages Conference name, DVCon for short, reflects this evolution of
the conference scope.

DVCon provides an excellent and exciting forum for design engineers,
verification engineers, EDA professionals, university researchers, and
industry pundits to assemble and exchange ideas through papers,
panels, tutorials and vendor exhibits. As the program chair, I would
like to invite Verification Guild readers to contribute proposals for
any of the following types of presentations:

o Technical papers on using Hardware Description Languages (HDLs)
o Technical papers on using Hardware Verification Languages (HVLs)
o In-depth tutorials on design and verification techniques
o Educational panels on trends in design and verification

Your active participation in DVCon will provide you and your company
with industry-wide recognition. You and other engineers will benefit
from exchanging information with your papers. All paper presenters,
tutorial presenters, and panel moderators will receive complimentary
full conference registration (approximately a $450 value).

Details on submitting a paper, tutorial or panel proposal, along with
suggested topics, can be found on the Design and Verification
Conference web page, at http://www.dvcon.org/dvccfp.pdf

The deadline to submit a proposal is Tuesday, October 15, 2002!

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.15, Item 4.0)

From: Vasu Ganti

What I want readers to get away from this exchange is that assertion
based verification is too broad a concept to be attributed to any one
EDA vendor! In general, assertion monitors are great for increasing
the observability of design intent. Whether users deploy display
monitors or system tasks or plain "$display", they are looking at only
half the debug effort. Assertions in Verilog or VHDL are easier to
adopt since there's no proprietary language to be learnt and these can
also be targeted by various verification methodologies.

It will be interesting if readers' can post their ROI data regarding
use of assertions in their flows.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 3.15, Item 4.1)

From: Jeff Li

Some user reports can be heavily "influenced" by EDA marketing. For
example, "With minimal effort, we integrated 0-In Check ..." suggests
that the author did not personally work on the integration.

I get information from such reports by reading between lines. One way
to do so is to find the differences between the reports and the real
marketing documents.

0-in must have recommended the checker writing to all designers, but
Anonymous reported only 1 person writing checkers. This person was
probably not one of the designers because he decided to put checkers
in a separate control file. Why did most people stay away from writing
checkers? Why did many people even bother to write monitors at the
same time when checkers are much easier to write? Why was 0-in Search
used not as extensively as 0-in Check was(though 0-in Search was more
attractive in the beginning)? Perhaps the author forgot to indicate
that the experience was supposed to be a limited experiment. Then why
did the author fail to say whether more people would write checkers
next time?

It is also interesting that Ravi's experience did not involve 0-in
Search. Was anything wrong with 0-in Search? It is harder to read
between lines in a more balanced reports like Ravi's.

Among many responses to marketing presentations, some reports of user
experiences are also found at http://www.deepchip.com/posts/dac02.html
(in addition to the one from Anonymous):

"We brought in Real Intent with a flourish of excitement about it
replacing simulations. What's actually happened is we use Implied
Intent as a super Lint tool, and no one goes to the trouble of writing
the assertions to use Express Intent. Designers indicate that Express
Intent is hard to use or not applicable to "real" designs."

- [ An Anon Engineer ]

"We've looked at Averant in the past and we like their tool, but
again we can not get any designers to step up and use these tools."

- [ An Anon Engineer ]

"We had a home-brew version of Ketchum. Concept is really good. It
finds things like gated clocks, bad clock crossings early."

- John Webster of Intel

The only thing I learned from these is that designers do not like
writing verification code. This is why "Implied Intent" is
popular. The oldest formal verifiers of "Implied Intent" are probably
the ones announced by Chrysalis just before it was merged into Avant!
(http://www.eetimes.com/story/OEG19990412S0017) and they are still
listed as 3 years ago
(http://www.synopsys.com/products/avmrg/product_flow/modeling_simulation.html). Why
does nobody talk about these Chrysalis tools lately?

The positive parts of the experience reports are helpful. At least
they confirm the messages in the marketing documents. The negative
parts of these reports are the most interesting because they are not
available from any other sources.