( ESNUG 419 Item 8 ) -------------------------------------------- [10/08/03]

Subject: Three Users Trip Reports About This Year's DVcon'03 Conference

> As usual, I'm putting together a collectively written Trip Report of
> user impressions of the recent DVcon'03 conference.  In that vein, I'd
> like to ask you to please forward me a copy of the trip report you
> wrote for that conference.
>
>     - John Cooley
>       the ESNUG guy


From: David Bishop <david.bishop=user  domain=kodak got calm>

Oh, yah.

DVCon 2003 trip report - David Bishop

Overall, System Verilog is big (at least according to Synopsys).  Lots of
stuff on assertion languages, which are now starting to jell.

Key Note:  Aart De Geus (CEO Synopsys) is at it again.  8 years ago he said
that Verilog was a dead or dying language.  Now he is saying the same thing
about VHDL.  Why?  He is putting some big money behind System Verilog (which
he purchased).  He just doesn't seem to realize that FPGAs are taking over
the market, and most of them are done with VHDL.

Aart may be repeating history here and killing off a good thing just like
what happened with him, GE and Calma years ago.

System Verilog looks like something good.  If it ever gets deterministic,
it might even be worth looking into, but not at Synopsys's prices.

VHDL-200x is taking off.  I plan to be a part of this.  They are finally
fixing some of the odd syntax issues in VHDL.

    - David Bishop
      Eastman Kodak                              Rochester, NY

         ----    ----    ----    ----    ----    ----   ----

From: Dan Joyce <dan.joyce=user  domain=hp got calm>

Hi, John,

Here is my trip report from DVCon-2003.

Design and Verification Conference is centered on HDLs (Verilog, VHDL)
and HVLs (VERA, Specman, TestBuilder) and how to make them more
productive so the ASIC design and Verification process can be more
efficient. There were 38 papers with 30 minute presentations of each.
There were also 3 panels, a key-note speech by Synopsys CEO Aart de
Geus, and a luncheon with a talk about System-C. Finally on Wednesday
there were some tutorials. There was also an exhibit hall with a limited
number of EDA vendors hawking their wares. This trip report will discuss
some of the papers and presentations that we thought were of potential
use either to our group in the near term, or to the EDA industry, and
hence to our group in the long term.


Panel 2 Verilog and Assertions - Do they Mix?

Moderator - Cliff Cummings

This was a panel discussion that included 5 EDA vendors and one user.

Assertions seem to be the "hype" of the moment for the EDA industry. One
big thing going on right now is that Synopsys bought Co-Design and their
SuperLog language. SuperLog is the result of the Verilog standards
committee (pushed by the simulation tool vendors) dragging their heels
for so long to implement some changes to the Verilog language. There was
a "Birds of a Feather" panel at this conference in '96 that came up with
a list of the 5 most needed improvements to the language, and a bunch of
others. 8 years later, the big two simulators have done very little in
implementing these. CoDesign realized that would take a start-up to
finally do it, and they (Phil Moorby and others) created a new simulator
that simulates the extended Verilog (Verilog-2001) plus a whole lot more
(C++ -like constructs). Now Synopsys has bought them and are putting
these features into their VCS tool, adding assertions and calling it all
"System Verilog". Synopsys is pushing to get "System Verilog" finalized
for submission to IEEE standardization by June, 2003. One of the big
issues in System Verilog is whether or not assertions will be defined as
part of the standard, and if so how. System Verilog seems to be adopting
the standard from the OVA (OVL? Sugar?) done by Harry Foster.
The big discussion at this panel seemed to be whether or not the OVA
style assertions being pushed by Synopsys, and BTW pushed by Harry
Foster who now works for Verplex, should be a part of the IEEE standard.
It seemed that the panel members lined up as you would expect from their
affiliations.

I am amazed at the amount of hype around assertions right now. It seems
to be a new enough concept that EDA companies think they can get lots of
traction with it. Everyone talked about assertions - I even slipped it
into my paper and talk ;). From my point of view, anyone starting to use
assertions who is not doing code coverage should re-evaluate their
priorities. Code Coverage analysis is more cost effective because you
get a great insight into your design and verification without having to
write any assertions - less effort, more instrumentation faster. The
code coverage tools automatically instrument the design in a very
powerful way and give a really useful feedback to the verification team.
Assertions and Functional Coverage are the next tools on the priority
list below code coverage - and are about the same level of usefulness. I
see them as very similar in capabilities, cost of implementation and
benefit of use. Assertions say "this should never happen in my design
when running regressions" and functional coverage says "This should
happen at least once in the regressions". They are basically VERY
POWERFUL COMMENTS. All three of these tools should get used because they
add to the cost-effectiveness of most design processes - assuming bugs
are very expensive. In the case of FPGAs where bugs are not so
expensive, code coverage may be enough.


Panel 3 Is EDA a Safe Investment?

Moderator - John Cooley

This was a panel composed entirely of CEOs and Venture capitalists. The
discussion centered on whether or not EDA companies  - especially
start-ups - were a good investment. It was generally agreed that most
VCs are avoiding EDA like the plague right now - and many people in the
room think this may be a good thing due to the way VCs affect an EDA
startup. VC's goals are for a huge win and they really don't want a
mildly profitable company because they cannot sell it. Finally it was
decided that there are a few good VCs, and they were the ones with more
reasonable goals.
The next interesting discussion had to do with the fact that the big 3
EDA companies (Synopsys, Cadence and Mentor) are presently "giving away"
licenses of their tools to get market share in a tough economy. The
question was "How can startups compete with the 800 lb. gorillas giving
free stuff?". The answer was that the startups had to have such an
incredibly more powerful tool that people will be willing to pay for it.

Very entertaining and informational.


Keynote Address Aart de Geus - Chairman and CEO of Synopsys

Design for Verification

Aart started by showing some graphs of Moore's law and how hard our job
has become to keep up with the number of gates chip vendors are letting
us put on a chip (straight line going up and to the right - showing
gates per chip). Under that line was a see-sawing line almost keeping up
with the straight line, showing how Verification techniques have tried
to keep up with Moore's law. Every few years a change in the way we do
things would help us almost catch up to Moore's law, but then would
flatten out and we would fall behind again. Aart basically is selling
"System Verilog" as the next big change to the Verification game. This
is because it will tie together all the tools of the past with some of
the future: SuperLog for the RTL of the design, VERA-lite for the
testbench, OVA style assertions, VCM for coverage, Direct-C to connect
C++ models, SystemC for architectural modeling, ... and I cannot
remember what else. This looks to be the Synopsys sales pitch for a
while.

One thing he said that surprised many of us was that it sounded like he
was not going to be building all these capabilities into a VHDL flow
like he was for the Verilog toolset. There are going to be capabilities
to simulate legacy VHDL along with the new stuff, but it seemed like the
VHDL tools of Synopsys were not going to be supported in the same way as
the Verilog tools. VHDL users are NOT going to be happy about this.


Papers and Presentations

1.3 Using Assertion Based Verification to Verify Clock Domain
    Crossing Signals by Chris Kwok of 0-In

This is a paper presenting the 0-In Clock Crossing detection and
Assertion generation tool (Checklist - really a part of their Lint
tool). This looks like a VERY useful tool for us - especially since we
already use 0-In for assertions (Check only). This tool will analyze
your design looking for possible problems in the way you implemented
asynchronous clock crossings. It puts all clock crossings into one of
three categories:

  1) Everything OK.
  2) Possible problems depending on the stimulus.
  3) Definite problem.

For category 2) "Possible problems depending on the stimulus" they
automatically insert assertions that will fire if that part of the design is
put into a scenario where problems will occur (non-deterministic behavior).

For years we have been asking vendors to provide us with a tool that will
just find asynchronous clock crossings. We have developed an internal tool
using Spyglass that we use now, but it is not nearly as capable as this
tool seems to be. (I think Spyglass also has a new tool that does parts of
this, but we have not used that yet.) We recently did a chip with 38
asynchronous interfaces, and it took a lot of analysis and simulation to
verify. This tool apparently tracks the signals after crossing the
asynchronous boundary to see if they re-converge and could cause problems.
This is a level of analysis we were not even thinking to ask for.

If it really works as advertised, we may really want this one.


1.5 Achieving Determinism in System Verilog 3.1
    by Phil Moorby (inventor of Verilog)

Phil gave a very interesting presentation on the problem of non-determinism
in the Verilog simulators of today. A while back all the simulation vendors
told us to remove the #1's and #0's in our non-blocking assigns (<=) for
implementing Dffs -- to speed up the simulation. There have been lots of
problems with non-determinism since (maybe even before, but we got the
problems when we took out the #0's -- especially when the simulators try to
deal with gates -- like vendor RAM models where the clock goes through some
gates).  Anyway, Phil showed how they are adding two more stages to the
simulation of every clock cycle to fix this problem. I can't remember this
exactly -- no paper in the CD handout, but something like 5 stages are being
turned into 7.  Someone asked Phil if this would slow down the simulation
further, and he said something like "From what we can tell, No."  -- uh...


3.1 The Case for Verification Languages by Gabe Moretti

I thought this was going to be a rah, rah for VERA and Specman, but
turned into a rah, rah for VHDL. He said VHDL was a classic example of a
better technical solution, but a failure at marketing. He does not like
System Verilog because it is too monolithic.


4.6 The IEEE Verilog-2001 Simulation and Synthesis Tool Scoreboard
    by Cliff Cummings

This was a report on what "IEEE Verilog-2001 Verilog features" the
different simulation and synthesis tools CLAIM to support. But in
addition, Cliff actually created a test design and simulation and
checked to see if they really did implement the features they claim to
support. He also found several bugs in the way they implemented some
stuff. The paper gives a scoreboard of things that work and those that
don't - and which ones matter.
Good paper. Already using it.


4.7 System Verilog 3.1, It's what the DAVEs in your company asked for.
    by Stu Sutherland

Very interesting presentation. At first I thought this would just be a
sales pitch for System Verilog, but he did not seem to follow Synopsys
party line perfectly. DAVE, from the title, stands for Design And
Verification Engineer. Stu talked about how in the old days, Verilog
(and VHDL) design and verification were done in the same language - the
language the DUT (Design Under Test) was written in. Verilog actually
stands for VERification LOGic. The same person could know one language
and easily design and do his own testing. Then Hardware Verification
Languages (HVLs) came to be, and the same person rarely could do both -
without learning two complex languages. This split up the Design and
Verification teams and led to lots of throwing stuff over the wall. Now,
System Verilog brings the designer and verification engineer back
together because they can use the same language.

I understand that System Verilog is all about making several different
Synopsys tools work more seamlessly together, but I am still not
convinced that it's not just a fancy wrapper around all these existing
tools. Maybe it will cause Synopsys to do a good job of making them work
together seamlessly. Time will tell.


5.1 The Shotgun Approach to Verification - Don't Shoot Blind-folded
    by Chuck Mangan

This was a very good paper and presentation on Functional Verification.
This is the process of writing high level coverage statements and either
putting them in your code or your testbench. These statements get
tracked by a code coverage tool and let you know if your regression
suite achieved certain conditions that either your Design or
Verification team says need to be simulated. 

We use some Functional Verification, but plan to do more in this area.
The hard part is getting the hand-written conditions written, and making
sure they are good ones. We have a process where the design engineer
gives the Verification team a list of Verification goals in the logic's
Internal Spec. We try to get those translated into Functional
Verification statements so our code coverage tool will automatically
track them for us. Without this automated way to track simulation, we
have to look at the regression suite and try to figure out if these
things happened - hard to do and very prone to errors.



There were some very interesting conversations in the lunches, hallways
and terminals at the airport. Winning best paper really gives you the
ability to talk to some cool folks. Here are some quick excerpts:

Talking with Phil Moorby and Cliff Cummings. Cliff and I were telling
Phil we would like a Verilog-lite that would allow designers with very
large DUTs to simulate at much higher speeds. The restrictions would be
a more limited Verilog coding style (probably synthesizable Verilog
would be OK), and cycle accuracy only (all clocks in the simulation
would be an exact divide down of some single highest frequency clock).
The simulation footprint would be much smaller than present Verilog
simulators, and would allow the simulation speed to be much higher WITH
VERY LARGE DESIGNS. This tool would be able to dump to a waveform file,
but would not be able to simulate with timing. However, the Verilog
would be synthesizable and WOULD be able to simulate with full timing on
a VCS or NC-Verilog simulator. This would give the benefits of my, Rob
Stets (Compaq at the time), and Andreas Nowatzyk's C++ paper from the
HDLCon 2001 conference; but it would not have the problem of being a
different language with the accompanying lack of a mature toolset.

Talked to a couple guys from Cadence at their booth in the Exhibit hall.
I was interested in the TestBuilder tool since I had read a favorable
analysis of this C++ test bench language from another paper. However,
they said very little about TestBuilder and actually pointed me to the
Synopsys booth, telling me I should learn about System Verilog and
SystemC. WOW, did not expect that.

    - Dan Joyce
      Hewlett-Packard                            Austin, TX

         ----    ----    ----    ----    ----    ----   ----

From: David Black <dcblack=user  domain=eklectICally got calm>

Hi, John,

Here's my impression of DVCon 2003.

ATTENDANCE

Don't know the actual numbers. Perhaps 250 in attendance at any one time;
although, with people coming and going attendance may have been higher on
the books.  Most folks appeared to be either EDA vendors or consultants.
There were also a good number of folks looking for jobs.  Most common
exchange at DVCon:

      Question: "How is Business?"
         Reply: "Business is lousy!!"


EXHIBITORS

Vendors seemed to be in fewer numbers than previous years. Empty booths
were evident. The big three: Mentor, Cadence & Synopsys were present
with Mentor making the loudest noise (literally). Noticeably absent was
Get2Chip.

Many of the companies represented verification and assertions. This
conference could have been renamed AssertionCon given all the hoopla
about assertions. Sure assertion technology is important, but it
should be old news by now.


@HDL Inc - non-descript name. Assertion based checking. Combining formal
verification with vector based approaches. A little of everything?

0-In Design Automation - discussing their assertion based technology.

Aldec Inc - working with Summit for SystemC solution

Cadence Design Systems Inc - pushing their verification solutions.
Interesting combination of hardware acceleration and SystemC simulation.

Consultants Corner - seven represented however interest was low.

EDAtoolsCafe.com - absent

Future Design Automation - Interesting ANSI C Behavoiral Compiler
(moving towards SystemC)

Kluwer Academic Publishers - a new version of Janick Bergeron's book
on Verification.

Mentor Graphics Corp - a bit of everything. Pushing acceleration.

Novas Software Inc - makers of Debussy add a verifiction assertion tool

Real Intent - formal verification assertion tool

Synopsys Inc - pushing SystemVerilog, Vera, OVA, a new integrated
simulation core and System Studio. Pushing System Verilog more than SystemC.

TNI-Valiosys - HDL2SystemC tool among others. Company focus unclear.

Verisity Design Inc - HVL touting their ability to work with any/all
simulators (even SystemC). Wants to appear opensource, but in reality is
proprietary.

Veritools Inc - very low cost waveform viewers with lots of extras.
Continues to be upgraded.

Verplex Systems Inc - formal verification in spades.


SESSIONS

None of the papers wowed us. Not that there weren't good papers, but
nothing good enough to be considered part of the bible. Everything was
evolutionary... no big bang here.


Session 2.1 Architecture Modeling of ARM based SoC using C

Starting before SystemC was available, these guys used ANSI C to
create a simulation environment. Interesting success story, but a lot
of work just for verification. Would use SystemC now.


Session 2.2 10 Million Gate ASIC Design Using Hierarchical Layout
            Style and Behavioral C Synthesis with SoC Test Strategy.

Really two parts of a single project. First, a presentation on using an
in-house ANSI C modeling technique (was unaware of SystemC). Second,
addressed back-end physical layout issues including DFT and hierarchical
layout.


Session 2.3 Verification of an SoC Subsystem using Multiple Environments

Authors used a variety of modeling techniques including FPGA's to verify
their design (even booted VxWorks). Did not correlate various approaches
against each other; however, the design was successful.

[NOTE: I participated in a project that simulated a PowerPC running with
SystemC and booted VxWorks with up to 180k ips. Interesting technology
to debug software before the design team is done.]


Session 2.4 The Impact of Synthesis on Design Closure by Steve Carlson
            of Get2Chip Inc.

A presentation on using SystemC for architectural exploration and design
closure.


Session 2.5 Why You or Your Replacement will use SystemC for System Design
            by Brett Cline of Forte Design Systems

Demonstrated some results for a new SystemC synthesis tool (not yet
released). Very interesting and promising. Perhaps higher level synthesis
will make a comeback now that more expressive languages are available.
Verilog and VHDL just don't have the power to express really high levels
of abstraction.


Session 2.6 My SLDL is Better than Yours (A Tale of SystemC in 3 Parts)
            Eric Aardoom, Analog Devices

How to take better advantage of the C++ nature of SystemC including: Object
Oriented Programming, Generic Programming, and Aspect Oriented
Programming styles. Very good paper if the presentation was a bit too
crowded. Well worth reading if you use SystemC. There was a really cool
concept for encoding finite state machines using an OO paradigm. Compact
readable syntax with a lot of flexibility.


Session 3.1 The Case for Verification Languages

An academic exploration of whether new languages are needed for
verification. Concluded that the HVL's did provide some benefits, but also
VHDL users are not taking advantage of what they already have. Also, an
interesting chart comparing the relative reach of these languages. Yawn...


Session 3.2 Creating Useful Coding Guidelines for a Verification Environment

A case study in using coding guidelines. Very practical. Only 36 rules
with very good results. Now if we could just convince more engineers to
take this to heart.


Session 3.3 HDL and C/C++ Design Productivity in a Mixed Language Environment

How Mentor solves the problem of SystemC running with Verilog/VHDL. A unified
user interface with performance analysis.


Session 3.4 Unified HDL Methodology Eases FPGA-to-ASIC Migrations by Jill
            Wilker of Chip Express

Things that need to be considered if you eventually wish to migrate from
an FPGA to an ASIC. Coding guidelines. RTL constraints, package, memory
and IP issues, clock and reset management, power management, and DFT.
Very good.


Session 3.5 Curing Schizophrenic Tendencies in MultiLevel System Design
            by Kamal Hashmi, SpiraTech Ltd.

Not the intent, but very good anecdotal information supporting the
case for design abstraction.

* 1.5K lines of code for Architectural Design
* 8K lines of Behavioral Code
* 100K lines of RTL
* 10+ million gates for the final design


Session 3.6 Installing Functional Coverage Metrics into VHDL Verification
            Simulations by Michael McKinney

A scheme with minimal touching the code & no other tools than vanilla VHDL.


Session 5.2 Audit your Design to Determine and Even Reduce the Amount of
            Random Testing Needed by Dan Joyce, Hewlett-Packard

Applying random stimulus can lead to long simulations due to too many
variables. When you design large state machines, keep the number of
inputs and outputs under control.


Session 5.3 Patterns in Verification: Software Engineering Meets
            Testbench Development, Sun Microsystems

How to decompose a verification environment down into objects to
create a manageable system.


Panel 3: Is EDA a Safe Investment?

Very entertaining discussion of EDA economics. Another attendee
commented that this was the only interesting panel session! Moderated
very well [GRIN]. Seemed to be a lot of comments about the high
prices, lack of innovation and lack of service from the big three.

    - David Black
      EklectICally Consulting                    Austin, TX


 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)