Subject: RE: Minutes of SV-Assertions Meeting - 7/9/02
From: Simon Davidmann (simond@co-design.com)
Date: Wed Jul 10 2002 - 09:17:38 PDT
At 02:58 PM 7/9/2002, Erich Marschner wrote:
>Tom,
>
>I'd like to clarify slightly some comments of mine that you recorded in
>the minutes of the meeting today.
>
>| Erich: Vassilios established guidelines to resolve process
>| for extending SV
>| Assertions. The guideline is that enhancements to SV for declarative
>| assertions should be compatible with FVTC committee. Motion for this
>| committee to support this guideline.
>
>I believe I said (or at least intended to say) that Vassilios is *in the
>process* of establishing guidelines in this area, and that *one of* the
>guidelines he has agreed to is that, wherever possible, extensions should
>be compatible with Sugar. This is one of about 5 or 6 guidelines, or
>"fundamentals", that have been discussed and agreed to.
To my knowledge it is committees that need to discuss and agree to things -
and I have not seen any minutes of any open Accellera committee where there
has been discussion and agreements. I have attended all the meetings. -
there may be some offline (out of committee, ie private) agreements taking
place - but it is this assertions committee and the formal committee where
decisions will be discussed and agreed to - and if you had said the above,
then I would have said the above...
Also - there was mention in the minutes by somebody of Sugar being
something it is not - Sugar is the chosen donation from which the formal
committee will then modify to come up with an Accellera property language.
Sugar is not the end - it is the potential beginning.
Simon
>| Erich: Compatability is a 2-way street.
>
>Here I was trying to say that changes on the Sugar side (to make it more
>compatible with System Verilog) are also possible. Indeed, we have just
>proposed such changes in the Sugar LRM subcommittee.
>
>| Erich: You need semantic compatability. Syntactic
>| compatability is a goal.
>
>This was in the context of trying to define "compatibility". What I
>actually said was that syntactic compatibility is a continuous spectrum
>(i.e., a question of degree), and that while we want to be as close as
>possible to the "perfectly compatible" end of that spectrum, if we make no
>syntax additions/changes at all (which would be "perfectly compatible"),
>then we would have accomplished no semantic extensions at all - so there
>is balancing act required. In summary, I think the "compatibility" issue
>comes down to this goal: we would like to add as much additional
>capability as possible, while making minimal extensions to the syntax, and
>with no syntactic conflicts.
>
>Regards,
>
>Erich
>
>-------------------------------------------
>Erich Marschner, Cadence Design Systems
>Senior Architect, Advanced Verification
>Phone: +1 410 750 6995 Email: erichm@cadence.com
>Vmail: +1 410 872 4369 Email: erichm@comcast.net
>
>| -----Original Message-----
>| From: Tom Fitzpatrick [mailto:fitz@co-design.com]
>| Sent: Tuesday, July 09, 2002 1:36 PM
>| To: assertion@eda.org
>| Subject: Minutes of SV-Assertions Meeting - 7/9/02
>|
>|
>| Attendance:
>| NOTE: The following list will be maintained to reflect
>| meeting attendance
>| for purposes of the "3/4" rule for voting priveleges.
>|
>| [x] David Lacey (HP, Chairman)
>| [x] Tom Fitzpatrick (Co-Design, Co-Chair)
>| [x] Jason Andrews (Axis)
>| [x] Roy Armoni (Intel)
>| [x] Gail Dagan (Intel)
>| [x] Simon Davidmann (Co-Design)
>| [x] Cindy Eisner (IBM)
>| [x] Peter Flake (Co-Design)
>| [x] Harry Foster (Verplex)
>| [x] Joseph Lu (Sun)
>| [x] Erich Marschner (Cadence)
>| [x] Steve Meier (Synopsys)
>| [x] Prakash Narain (Real Intent)
>| [x] Bassam Tabbara (Novas)
>| |
>| +- 7/9/02
>|
>| Introduction Discussion:
>| What should the agenda be?
>| What process should be followed to review/accept the
>| donation document?
>| Prakash: Donation document should be used as a resource for potential
>| functionality to be added to existing SystemVerilog
>| Harry: What do we want to accomplish in 3.1?
>| Prakash: This committee should agree on requirements, and
>| the donation may
>| be ammended/modified to make suggestions on how to meet requirements.
>| Steve: Synopsys is amenable to setting requirements first
>| Erich: Given the publicity in the past, he does not want to
>| accept the
>| document "as a resource" and have it publicized as being accepted.
>| Fitz: Committee should agree on mission statement.
>| Flake: Mission is to agree on requirements, and then
>| evaluate donation(s) to
>| see how well it/they fit the requirements and then decide
>| whether or not to
>| accept it.
>| Prakash: Assertions committee should not look at a full
>| formal language. We
>| should agree on requirements for SystemVerilog assertion
>| enhancements. Once
>| requirements are agreed on, then we need to agree on a
>| process to meet these
>| requirements.
>| Erich: Motion - Agree on requirements for enhancements to
>| SystemVerilog
>| Assertions, then to agree on process for meeting
>| requirements, which may
>| involve donations, and then proceed.
>| Prakash: Second
>| Motion passed unanimously.
>|
>| Erich: Vassilios established guidelines to resolve process
>| for extending SV
>| Assertions. The guideline is that enhancements to SV for declarative
>| assertions should be compatible with FVTC committee. Motion for this
>| committee to support this guideline.
>| Meier: We need to define what "compatability" means.
>| Simon: There was no requirement for FVTC language to be
>| Verilog compatible.
>| Erich: Simon's understanding is incorrect. Sugar2.0 is a
>| strong resource to
>| be used for meeting additional requirements.
>| Simon: The requirements should be met in this committee with language
>| extensions that are SystemVerilog/Verilog-compatible.
>| Erich: Compatability is a 2-way street.
>| Prakash: Extensions should be compatible with Sugar2.0.
>| Possibly make a
>| requirement to make SystemVerilog assertions compatiple with
>| Sugar and
>| define what compatiple will be later.
>| Simon: The agenda should include a discussion about what
>| "compatible" means.
>| Erich: You need semantic compatability. Syntactic
>| compatability is a goal.
>| Agree that we need to discuss this.
>| Harry: Let's move away from philosophical discussions and
>| begin discussing
>| requirements.
>|
>| Prakash agreed and restated that the requirements will help drive our
>| efforts and these issues can be worked out as part of the plan.
>|
>| Tom agreed moving on to requirements is the right thing.
>| This group needs
>| to work on improving and ehnacing SystemVerilog assertions. Being
>| compatiple for Sugar or any other language is more of a side
>| issue. <Tom
>| leaves>
>|
>| Prakash suggested writing a requirements document.
>| Previously went through
>| requirements item by item, then voted on entire document.
>| Erich agreed with
>| this approach.
>|
>| Prakash asked how to proceed in collecting requirements.
>| Harry suggested
>| collecting list of enhancements and make requirements off of
>| them. Erich
>| reminded of the idea to collect ideas on problems with existing
>| SystemVerilog assertions.
>|
>| Erich mentioned the FTVC also has a list of requirements for
>| those that wish
>| to review it.
>|
>| Simon asked what is our goal. A full-blow property
>| language? Or something
>| else? Harry thought a full-blow property language is not
>| practical as it
>| takes years to come up with. Prakash agreed. Erich asked
>| what is the
>| difference between the two as they don't seem as divergent
>| to him. Prakash
>| said we are generated a limited set of requiremnts of a full property
>| language.
>|
>| Erich suggested going through FVTC requirements and
>| determining which apply
>| to designers and SystemVerilog assertions. Harry noted
>| designers experience
>| may be limited right now (of OVL 30 elements, most designers
>| only use 6-8).
>| He said we don't want to limit the designers future now just
>| because they
>| don't have experience with rich property language.
>|
>| Simon: 2 observations. Consider of whether assertions in Sugar can be
>| simulated on the fly; also, FTVC requirements is very long
>| and hard to
>| understand at a first glance. Suggested Erich, being
>| familiar with them,
>| presents which requiremetns apply to SystemVerilog.
>|
>| ACTION ITEM: Erich will look at FTVC requirements over the
>| next few weeks
>| and present a summary the FTVC requirements and opinions on which are
>| applicable to SystemVerilog. He will work with Cindy on this.
>|
>| Harry asked Cindy how they teach Sugar. They don't really present
>| differently between designers and formal folks. Cindy
>| thought presenting a
>| subset of the Sugar requirements may not be the best.
>| Although they are
>| very detailed, but they are in groups and can be addressed
>| from an overview.
>| So the presentation should include all requirements, plus
>| Cindy and Erich's
>| opinions on which apply the best.
>|
>| Cindy suggested presented a summary of the FVTC requirement
>| versus a subset.
>|
>| What is overall schedule? Still uncertain. SystemVerilog
>| 3.1 is slated for
>| March, 2003 so we need to work back from that date. David
>| will look for
>| more info here and send it out.
>|
>| <tom back>
>|
>| MOTION: All proposed requirements must be submmitted to the Assertion
>| Committee by July 31. Presented by Harry. Prakash second.
>| Pass unanimously.
>|
>| Erich mentioned Adam K's concern of recognizing overlapping
>| seqeunces. This
>| is an ĉxample of a hole in SystemVerilog assertion 3.0.
>| Peter asked if we
>| need an errata document to address
>|
>| David will send out a link to all appropriate documents (original
>| requirements, SystemVerilog 3.0 spec). Harry will sent out
>| link to FVTC
>| spec.
>|
>| Overall schedule:
>| Requirements proposals by 7/31.
>| Need more information on SystemVerilog 3.1 schedule to
>| establish other
>| milestones.
>| Erich: Requirements should be provided as requirements, not
>| specific syntax
>| proposals.
>|
>| Next Meeting:
>| Date: Thursday, 8/1
>| Time: 12-2pm EDT, 9-11am PDT.
>| Conference call info to follow.
>|
>| Thanks,
>| -Tom
>|
>|
>| -------------------------------------------------------------
>| --------------
>| Tom Fitzpatrick Director of Technical Marketing
>| fitz@co-design.com Co-Design Automation, Inc.
>| Work: (978)448-8797 Fax: (561)594-3946
>| Cell: (978)337-7641
>| -------------------------------------------------------------
>| --------------
>|
>|
This archive was generated by hypermail 2b28 : Wed Jul 10 2002 - 09:27:14 PDT