Hi, Looking at the minutes of AC on 4/14/05, it says #266: The proposal by Cliff was reviewed. Unanimous approval. Also, a few days back I sent an email to Karen with some comments (see attached), one is similar to that raised by John. Best regards, ed > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of Bassam Tabbara > Sent: Wednesday, May 04, 2005 6:13 PM > To: cliffc@sunburst-design.com > Cc: sv-ac@eda.org > Subject: RE: [sv-ac] Issue #266 - Rev 5 > > > Hi Cliff, > > As I recall in AC, many of us reviewed your comments in Rev4 and they > looked fine (modulo John's input below), I forget if someone had an > action item to relay this somehow and apparently you did not hear from > AC.... Faisal/Ed, did you want to comment ? > > Thx. > -Bassam. > > -- > Dr. Bassam Tabbara > Architect, R&D > Novas Software Inc. > (408) 467-7893 > > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of John > Havlicek > Sent: Wednesday, May 04, 2005 9:23 AM > To: cliffc@sunburst-design.com > Cc: sv-bc@eda.org; sv-ec@eda.org; sv-ac@eda.org; sv-cc@eda.org; > tom_fitzpatrick@mentorg.com > Subject: Re: [sv-ac] Issue #266 - Rev 5 > > Cliff: > > I have looked over your proposed changes for Section 18, and they all > look fine to me. I did think that in the last of them > (18.15) it might > be better to change > > This applies to both pre-existing names as well as instance names > introduced by other {\bf bind} statements; and the latter situation > will occur if the design contains more than one instance of a > module containing a {\bf bind} statement. > > to > > This applies to both pre-existing names as well as instance names > introduced by other {\bf bind} statements. The latter situation > will occur if the design contains more than one instance of a > module containing a {\bf bind} statement. > > Best regards, > > John H. > > > X-Authentication-Warning: server.eda.org: majordom set sender to > > owner-sv-ac@eda.org using -f > > X-Sender: cliffc@mail.sunburst-design.com > > Date: Tue, 03 May 2005 09:29:10 -0700 > > From: "Clifford E. Cummings" <cliffc@sunburst-design.com> > > Cc: Tom Fitzpatrick <tom_fitzpatrick@mentorg.com> > > X-Virus-Status: Clean > > Sender: owner-sv-ac@eda.org > > > > --=====================_149026298==_ > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > Subject: Issue #266 - Version 5 - May 3, 2005 > > > > We have passed Issue #266 in the following committees: > > SV-BC > > SV-EC > > > > I have not received definitive feedback from the following > committees: > > SV-AC > > SV-CC (SV-CC action items below) > > > > The Champions Committee will have one last opportunity to make > > additional changes before passing the proposed resolution on to the > > SystemVerilog main committee. > > > > Regards - Cliff > > > > ---------------------------------------------------- > > Cliff Cummings - Sunburst Design, Inc. > > 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 > > Phone: 503-641-8446 / FAX: 503-641-8486 > cliffc@sunburst-design.com / > > www.sunburst-design.com Expert Verilog, SystemVerilog, > Synthesis and > > Verification Training > > > > >
attached mail follows:
Hello Karen, I have examined the proposed changes in Chapter 18 and Appendix H. They do not impact on the meaning and are just of editorial nature. The following adjustments may be considered, however: 18.11.2: Change: In this example, an asserted signal here implies a value of low. to: In this example, an asserted signal implies a value of low. 18.15, 2nd occurrence: Change: This applies to both pre-existing names as well as instance names introduced by other bind statements; and the latter situation will occur if the design contains more than one instance of a module containing a bind statement. To: This applies to both pre-existing names as well as instance names introduced by other bind statements. The latter situation will occur if the design contains more than one instance of a module containing a bind statement. Best regards, ed > -----Original Message----- > From: Karen Pieper [mailto:pieper@synopsys.COM] > Sent: Tuesday, May 03, 2005 12:55 PM > To: edcerny@synopsys.COM > Subject: Fwd: [sv-bc] Issue #266 - Rev 5 > > Ed, > > Can you review and indicate if you think the AC would > have any issues with Cliff's proposal? Also, can you > indicate if you think the changes are just editorial so that > Stu can make them without potentially impacting meaning in > the LRM? I'd suggest just looking at the AC chapters. > > Thanks, > > K > > >X-Authentication-Warning: server.eda.org: majordom set > sender to owner-sv-bc@eda.org using -f > >X-Sender: cliffc@mail.sunburst-design.com > >X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 > >Date: Tue, 03 May 2005 09:29:10 -0700 > >To: sv-bc@eda.org, sv-ec@eda.org, sv-ac@eda.org, sv-cc@eda.org > >From: "Clifford E. Cummings" <cliffc@sunburst-design.com> > >Subject: [sv-bc] Issue #266 - Rev 5 > >Cc: Tom Fitzpatrick <tom_fitzpatrick@mentorg.com> > >X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on > server.eda.org > >X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on > server.eda.org > >X-Virus-Status: Clean > >Sender: owner-sv-bc@eda.org > >X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 > M:97.0232 C:98.7678 ) > > > >Subject: Issue #266 - Version 5 - May 3, 2005 > > > >We have passed Issue #266 in the following committees: > >SV-BC > >SV-EC > > > >I have not received definitive feedback from the following > committees: > >SV-AC > >SV-CC (SV-CC action items below) > > > >The Champions Committee will have one last opportunity to > make additional changes before passing the proposed > resolution on to the SystemVerilog main committee. > > > >Regards - Cliff > > > >---------------------------------------------------- > >Cliff Cummings - Sunburst Design, Inc. > >14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 > >Phone: 503-641-8446 / FAX: 503-641-8486 > >cliffc@sunburst-design.com / www.sunburst-design.com > >Expert Verilog, SystemVerilog, Synthesis and Verification Training > > > > > > >Received on Thu May 5 04:27:09 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 04:27:25 PDT