Subject: Re: [sv-bc] Minutes and status from 2/24/03 SV-BC meeting
From: Dave Rich (David.Rich@synopsys.com)
Date: Tue Feb 25 2003 - 07:18:40 PST
Hey, I didn't think you thought I was serious about assigning all those
action items to me after I had to leave the meeting early to attend
DVCon! :-)
Anyways, I will see what I can do.
Dave
Karen Pieper wrote:
> Hi, all,
>
> I've attached the open issues, minutes of the 2/24 meeting, and
> open action items from today's
> meeting.
>
> Enjoy!
>
> K
>
>------------------------------------------------------------------------
>
>
>Minutes of the 2/24/03 Meeting of the SV-BC.
>
>This is my list of attendees and voting status. Please submit corrections to johny.srouji@intel.com:
>
>(_aaaaaaaa________) Johny Srouji (Intel) *
>(_aaaaa__aaa_aaaaa) Cliff Cummings (Sunburst Design) *
>(____a___aaaaaaaaa) David Smith (Synopsys)
>(aaaaaaaaaaaaaaaaa) Karen Pieper (Synopsys) *
>(_aaaaaaaaaaaaaa_a) Kevin Cameron (NSC) *
>(aaa_a_aaaaaaaaa_a) Steven Sharp (Cadence)
>(___a___aaaaa_aaa_) Dennis Brophy (Model Technology)
>(______a__a___aaaa) Tom Fitzpatrick (Co_Design)
>(aaaaa_aaaaaa____a) Gord Vreugdenhil (Synopsys) *
>(aaaaaaaaaaaa_____) Brad Pierce (Synopsys) *
>(aaaaaaaaa_a____aa) Francoise Martinolle (Cadence) *
>(_aaaaa_aa_______a) Don Mills (LCDM Engineering) *
>(_________aa__aa__) Mike McNamara (Verisity)
>(___________aaaaaa) Stefen Boyd (Boyd Technology)
>(______a_____aa___) Medi Mohtashemi (Synopsys)
>(____________aa___) Paul Graham (Cadence)
>(______a_____aaaaa) Peter Flake (Co_Design)
>(____________aaaa_) Simon Davidmann (Co_Design)
>(____________aa__a) Heath Chambers (HMC)
>(_____________aaa_) Dave Kelf (Co_Design)
>(__a_a_a_______aaa) Vasisilios Gerousis (Seimens)
>(_aaaaa_a_________) Dan Jacobi (Intel) *
>(______a__________) Stuart Swan (Cadence)
>(______a__________) Adam Krolnick
>(aa_aaaa__________) David Rich (Synopsys) *
>(______a__________) Yong Xiao (Synopsys)
>(_aaaa_a__________) Jay Lawrence (Cadence) *
>(aaaa__a__________) Matt Maidment (Intel)
>(______a__________) Wolfgang Keil (Synopsys)
>(_____a___________) Alec F. Stanculescu (Fintronic)
>
>* indicates eligible to vote on consensus issues
>
>** SV-BC BNF meeting on 01/29/03 was not taken into account for attendance.
>
>Minutes of the 2/3/03 Meeting
> Dave moves that we accept the minutes. Gord seconds. No opposed. No abstain. Passes.
>
>The following list of proposals passed by the recent email vote:
>SV-BC20 Typedef and generate issues http://www.eda.org/sv-bc/hm/0061.html
>SV-BC29 Need bits to real and real to bits http://www.eda.org/sv-bc/hm/0293.html
>SV-BC2 Time Precision and timescale http://www.eda.org/sv-bc/hm/0326.html
>SV-BC58 Slices of unpacked arrays http://www.eda.org/sv-bc/hm/0331.html
>SV-BC10b-1 Mascarading descriptions for VCD http://www.eda.org/sv-bc/hm/0380.html
>SV-BC62a Simpler decl of unpacked struct lits http://www.eda.org/sv-bc/hm/0382.html
>SV-BC68 BNF Issues http://www.eda.org/sv-bc/hm/0404.html
>SV-BC60 Modport syntax issues http://www.eda.org/sv-bc/hm/0410.html
>SV-BC18h,i logic variable issues http://www.eda.org/sv-bc/hm/0415.html
>SV-BC77 BNF in alignment with IEEE http://www.eda.org/sv-bc/hm/0417.html
>SV-BC8-5 Issues with time data type
>SV-BC12 Constant exprs; difference among decls
>SV-BC16f Issue with extern forkjoin task http://www.eda.org/sv-bc/hm/0422.html
>SV-BC66 Update BNF to reflect ETF changes http://www.eda.org/sv-bc/hm/0433.html
>SV-BC45 Dynamic checking of enums is expensive http://www.eda.org/sv-bc/hm/0434.html
>SV-BC67 () after interface instantiation needed http://www.eda.org/sv-bc/hm/0435.html
>SV-BC35 Task port declarations in BNF http://www.eda.org/sv-bc/hm/0445.html
>SV-BC34a Multiple namespaces exist http://www.eda.org/sv-bc/hm/0446.html
>SV-BC19-17a signed function declarations (BNF)
>SV-BC62b Packed array of packed structs http://www.eda.org/sv-bc/hm/0454.html
>
>Review of upcoming meetings, all using the same phone number
> F2F: February 27th, 1:00-3:00 pm PST
> Tele-Call: March 3rd, 9:00-11:00 am PST
> Tele-Call: March 17th, 9:00-11:00 am PST
> Tele-Call: March 31st, 9:00-11:00 am PST
> Tele-Call: April 14th, 9:00-11:00 am PST
>
>Email vote non-passed issues:
>
> Gord will extend the wording for SVBC21-1,2,3
>
> SV-BC5 It is not in our camp to make a proposal, but we should approve it before the CC
> completely approves it. Action item for Karen and Johny to ensure that the CC proposal
> for unpacked struct layout is presented to this committee. CC needs to come up with a
> proposal, or BC needs to strike the waffle words that talk about C compiler compatibility.
>
> SV-BC65: Dave will address wording issues, and SV-BC62c.
>
>Open action items:
>
>(SV-BC4) Dennis (Keith Gover (Model Tech) to make a proposal on DSM. With Dave
> Roberts at Cadence.
> * Dave Roberts indicates that Synopsys published a paper, so no action
> required?
>
>(SV-BC7c) Steven will develop language to clarify the meaning of type "matching"
> in structural literals.
>
>(SV-BC7e) Dave to propose.
>
>(SV-BC8-7) Stu will implement the global replacement of masked with 4-state and
> unmasked with 2-state.
> * It wasn't fixed in the current draft.
>
>(SV-BC10b, 10b-2, 10b-3) Gord to see if a member of the VCS team will write up
> VCD descriptions for all types.
> Karen moves that we delay other VCD issue to the next revision. Dave
> seconds. No opposed. Steven abstains. Passes.
>
>(SV-BC18, SV-BC21?) Gord will make a proposal to describe the granularity of error
> checking on logic types in the presence of mixed continuous and
> procedural assignments. (SV-BC21 proposal the same?)
> * Gord will figure out where to put a note about the resolution being
> owned for @* in the ETF. Gord will communicate the ETF resolution.
>
>(SV-BC18f, g) Dave Rich will propose language reflecting the straw poll
> results from the 1/22/03 meeting on these issues
>
>(SV-BC19-12) Dave to unify proposals P-0468, P-0404, P-477
>
>(SV-BC19-60) Dan to drive a solution to remaining issues in his document
>
>(SV-BC26-2) Gord to propose for %z and %u on new datatypes
>
>(SV-BC31) Steven will either make a proposal or close this issue on whether
> or not there is interface trimming.
> Karen moves that we close this issue. Dave seconds. No opposed.
> No abstain. Passes.
>
>(SV-BC32) Peter will propose a naming for interface objects on ports so that
> back annotation is possible. Karen to check with Peter for status,
> perhaps addressing it at the face-to-face.
>
>(SV-BC62c) Dave will propose language expanding ?: to work on unpacked
> data.
>
>
>Open issues:
>
>SV-BC36: Dave moves that we close the issue. Karen seconds. No opposed. No abstain.
> Passes.
>
>40-1, 40-2 To move to SV-EC. Karen to send mail to move these issues to the SV-EC.
>
>42-1: The defacto standard allows bit select on integer, but 2001 does not "allow" it. This
> issue should be fixed in IEEE 2001 first.
> Karen moves that we delay this until 3.2. Dave seconds. No opposed. No abstain.
> Passes.
>
>42-5 through 10: Closed as duplicates of 18 f,g,h,i
>
>42-11: Karen will make a proposal that integrates changes from the VSG.
>
>SV_BC75: Unnamed scopes require clarification that allow hierarchical reference within them.
> A new issue was opened. Dave to propose.
>
>42-13: Removed by deletion of changed keyword
>
>42-15: Hierarchical names are allowed currently. Gord moves we close this. Brad seconds.
> No opposed. No abstain. Passes.
>
>42-16: Dave should answer the question as to whether always_latch is different from always_comb
> in terms of the implicit sensitivity list in the presence of functions.
>
>42-19: What is the official name of implicitly instantiated modules? Some wording is needed to
> say what it's name is: both the name of the module and $root.name of the module, etc.
> There are no volunteers to make a proposal.
>
>42-21: Addressed by Peter's timeunit proposal.
>
>42-22: Addressed by Peter's timeunit proposal.
>
>42-23, 24: Dave needs to clarify that parameters, nets, interfaces, global nets, etc are also
> allowed as a part of .*. Matt thinks that allowing global net accesses is not intuitive.
>
>42-30: Are the comments wrong, or does there need to be normative text? Dave to assess.
>
>42-32: signed both before and after the type declaration. Karen to contact Stu to see if he
> wants to make the proposal. It could be useful for Direct C interface so there could
> be one header file?
>
>SV-BC76: If there are nested modules that are not instantiated, are they instantiated in top?
> in the current module? elsewhere?
>
>
>
>
>------------------------------------------------------------------------
>
>
>(SV-BC4) Dennis (Keith Gover (Model Tech) to make a proposal on DSM. With Dave
> Roberts at Cadence.
> * Dave Roberts indicates that Synopsys published a paper, so no action
> required?
>
>(SV-BC7c) Steven will develop language to clarify the meaning of type "matching"
> in structural literals.
>
>(SV-BC7e) Dave to propose.
>
>(SV-BC8-7) Stu will implement the global replacement of masked with 4-state and
> unmasked with 2-state.
> * It wasn't fixed in the current draft.
>
>(SV-BC18, SV-BC21?) Gord will make a proposal to describe the granularity of error
> checking on logic types in the presence of mixed continuous and
> procedural assignments. (SV-BC21 proposal the same?)
> * Gord will figure out where to put a note about the resolution being
> owned for @* in the ETF. Gord will communicate the ETF resolution.
>
>(SV-BC18f, g) Dave Rich will propose language reflecting the straw poll
> results from the 1/22/03 meeting on these issues
>
>(SV-BC19-12) Dave to unify proposals P-0468, P-0404, P-477
>
>(SV-BC19-60) Dan to drive a solution to remaining issues in his document
>
>(SV-BC26-2) Gord to propose for %z and %u on new datatypes
>
>(SV-BC32) Peter will propose a naming for interface objects on ports so that
> back annotation is possible. Karen to check with Peter or status
> face-to-face.
>
>(SV-BC42-11) Karen to propose an integration with VSG changes.
>
>(SV-BC42-16) Dave to answer whether always_latch is indeed different from
> always_comb sensitity with respect to functions.
>
>(SV-BC42-30) Dave to assess if there is really an issue here.
>
>(SV-BC42-32) Karen to contact Stu to see if he wants to make a proposal.
> Also, to contact the CC to see if they want to expand the language
> in this direction.
>(SV-BC42-23,24) Dave to clarify if parameters, nets, interfaces, global
> nets, etc are also allowed as part of .*.
>
>(SV-BC62c) Dave will propose language expanding ?: to work on unpacked
> data.
>
>(SV-BC75) Dave to propose some language describing hierarchical reference
> within unnamed blocks. Is it allowed, if so, how? If not,
> it needs to be indicated.
>
>(SV-BC76) Dave to make a ruling as to whether or not nested modules that
> are not instantiated appear in $root.
>
>
> ------------------------------------------------------------------------
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Tue Feb 25 2003 - 07:19:24 PST