RE: [sv-ec] RE: SystemVerilog Strategy, Plans and Proposal to address issues


Subject: RE: [sv-ec] RE: SystemVerilog Strategy, Plans and Proposal to address issues
From: Bernard Deadman (bdeadman@sdvinc.com)
Date: Tue Dec 17 2002 - 08:51:46 PST


Hi Jay,

It's refreshing to see such a lucid explanation.

My absolute conviction is both users and vendors need SystemVerilog to be
complete and accurate, much more than they need strict adherence to some
arbitrary, self-imposed, egotistical "deadline" associated with a Trade Show.

I would also comment that 25+ years of project management has honed an
instinct that suggests the DAC 2003 deadline was missed long ago and by a
country mile.

I would also comment that the control (is this the correct term for a
voluntary group?) of the OVA donation and its incorporation into
SystemVerilog Assertions was comprehensively botched. I was told:

>From: Vassilios.Gerousis@infineon.com
>Date: Tue, 18 Jun 2002 08:30:41 +0200
>
> As far as I am concerned Sugar will continue. Synopsys will
> provide special extensions for Sugar. Harry Foster will call a meeting to
> specifically consider this extension. This is part of the plans. The VFV
> committee will decide to accept or reject these extensions. But at least,
> Accellera can manage to unify the industry, rather than having two
> standards competing in the industry prior to DAC.

***HOW MUCH OF THIS HAPPENED????**** When did the consultation with the
VFV committee take place? What extensions were proposed for Sugar? It
seems what has been forced into SystemVerilog has had to be dumbed down to
the lowest common denominator in the name of making something (anything?)
viable within the proclaimed timescales, while still leaking the problem
you describe as the need for a "verification phase". No criticism should
be implied of the members VFV who are helping SV_AC (Harry, Erich, Cindy
etc.) who appear to have been operating with not one, but both hands tied
behind their backs!

The *BIG* problem is the assertions may have been unified, *BUT* this has
been accomplished by reducing them so far as to make them PATHETICALLY
INADEQUATE for any verification task I have in mind.

Interestingly the VFV group went through the requirements process you
describe, though it also generated about 70 samples assertions / properties
in the four contender languages. An interesting, though almost certainly
frustrating, exercise would be to go back and try to re-code those in
SystemVerilog.

Similarly I note Kevin's comments on borrowing more OO aspects of C++ to
regularize SystemVerilog. Another thing I've learned over the years is
there almost inevitably comes a time in every project where you have to
acknowledge you've made a mistake. It's the point where you've stuck on
the fourth Band-Aid and the blood's still leaking out. Recognizing that
early, and taking the correct remedial action rather than blundering on
into a brick wall is one of the hallmarks of good Project Management.

I confess I've also never heard of anything so ludicrous as throwing every
crazy idea in the LRM and tossing out in an un-coordinated fashion those
you can't get to work in an arbitrary time. It's a solution that's barely
worthy of the Marx Brothers - at least they had glorious timing!

Having followed the email traffic and read the draft LRM, my sense is, as
you suggest, you've come to a point in this project where you need to stop,
take a deep breath, reject all the politics, figure out the real
requirements, and take a structured approach to getting a good, clean,
compact, reliable language. This doesn't have to take more than a few
months, doing so will ultimately yield the best language in the shortest
possible time, and will restore credibility to a process that's
disintegrated into a comedy of errors.

I believe in the ability of the individuals within the SystemVerilog
committees to deliver a good result, but above all I believe they need to
be freed from arbitrary decisions and helped, coordinated and guided to do
the professional job of which they are more than capable, in a measure
fashion. If the language shows up at DAC 2004 but is right, it will be far
more valuable than a second rate delivery in 2003 that needs fix after fix
after fix after clarification after clarification, and which ends up being
comprehensively ignored.

Good luck!

Bernard

====================================================================
SDV Inc. 9111 Jollyville Rd, Suite 102, Austin, TX 78759 USA
Phone: (512) 231-9806 xt 101 FAX: (512) 231-9807 Mobile: (512)
431-5126
Email: bdeadman@sdvinc.com Website: www.sdvinc.com



This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 09:02:58 PST