Subject: RE: Minutes of SV-Assertions Meeting - 7/9/02
From: Simon Davidmann (simond@co-design.com)
Date: Thu Jul 11 2002 - 08:00:01 PDT
> The committee has met since then and confirmed that Sugar 2.0 would be
> submitted to the Accellera Board for approval, as is, without modifications.
Erich - I was not aware of that meeting, and have not received any minutes
of said meeting, please can you forward to me the minutes of the formal
committee meeting where the committee voted to accept Sugar 2.0 as is.
Thanx.
Simon
At 10:57 AM 7/10/2002, Erich Marschner wrote:
>Simon,
>
>| 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...
>
>First, I do not disagree with your statement.
>
>Yes, there have been some meetings outside of the System Verilog committee
>and subcommittees, specifically focused on developing guidelines for
>moving forward in the System Verilog Assertions space. These meetings
>have been run by Vassilios, and they were mentioned in the last System
>Verilog (or Verilog++, or whatever) meeting on June 5 - here's the section
>of the minutes (your notes, I believe) that mentions them, albeit in passing:
>
> >> sugar/DAS compatibility will be done by the chairs of the committees
> >> direction and focus on direction.... and then requirements (Tom
> >> will co-ordinate)
>
>But again, I don't disagree with your overall point about decision
>making. If you have an issue about separate, "offline" meetings outside
>the System Verilog subcommittees, please take that up with Vassilios, not
>me. In any case, I retracted the motion I attempted to make.
>
>| 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.
>
>It is clear from this that you haven't been following the FVTC very
>closely. In July 2001 - at the one FVTC meeting you attended - the
>committee adopted a process in which 2 of the 4 candidate languages would
>be selected, then *both* of the remaining candidates would be modified by
>their respective design teams to meet the requirements, and finally *one*
>of the modified languages would be selected. Following that process,
>Sugar 2.0 was created in early 2002 as a modification of the originally
>donated Sugar 1.0, and then in April 2002 it was selected as the final
>language. The committee has met since then and confirmed that Sugar 2.0
>would be submitted to the Accellera Board for approval, as is, without
>modifications.
>
>The only issue remaining is that the definition of Sugar 2.0 needs to be
>recast into IEEE standard LRM form. This is occurring now. I should
>note that the Sugar 2.0 document itself (upon which the final selection
>was based) is quite complete, including formal semantics for all the
>constructs as well as tutorial information. Creating the standard form
>LRM is essentially a matter of rearranging the existing information; no
>language design changes are involved.
>
>Any further changes to Sugar will be considered after the Sugar 2.0 LRM is
>completed and (hopefully) approved by the Accellera Board. In my opinion,
>any further changes are likely to be very minor in any case.
>
>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
>
>|
>| 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 : Thu Jul 11 2002 - 08:45:37 PDT