-- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary ---------- Forwarded message ---------- Date: Thu, 27 Jan 2005 14:13:18 -0500 From: n.humenick@ieee.org To: Shalom.Bresticker@freescale.com Cc: shalom@fil.ea.freescale.net, a.ickowicz@ieee.org Subject: Re: [P1800] SystemVerilog WG Unapproved Meeting Minutes Posted Shalom: You should direct future inquiries regarding P1364 to the staff liaison for this project, Andy Ickowicz. Thanks, Noelle -- Noelle D. Humenick Coordinating Program Manager IEEE Standards n.humenick@ieee.org PH: +1 732 562 3818; FX: +1 732 562 1571 http://standards.ieee.org/ The Institute of Electrical and Electronics Engineers, Inc. 445 Hoes Lane, PO Box 1331, Piscataway, NJ 08855-1331 USA *************************************** Shalom.Bresticker@fr eescale.com To: n.humenick@ieee.org Sent by: cc: shalom@fil.ea.freesc Subject: Re: [P1800] SystemVerilog WG Unapproved Meeting Minutes Posted ale.net 01/27/2005 02:09 PM Please respond to Shalom.Bresticker So when does this 30 day period end? Shalom On Wed, 26 Jan 2005 n.humenick@ieee.org wrote: > > Hi Shalom: > > Regarding your question on editorial coordination for P1364, you should > note that, as an unfunded project, the editorial coordination process for > P1364 can take up to 30 days, subject to the work load of the IEEE editors. > Of course we will put in a nudge for the project, but you need to be > prepared for the possibility that the coordination will not come through > before the 30-day mark. > > Thanks, > Noelle > > -- > > > Noelle D. Humenick > Coordinating Program Manager > IEEE Standards > n.humenick@ieee.org > PH: +1 732 562 3818; FX: +1 732 562 1571 > http://standards.ieee.org/ > > The Institute of Electrical and Electronics Engineers, Inc. > 445 Hoes Lane, PO Box 1331, Piscataway, NJ 08855-1331 USA > > *************************************** > > > > Shalom.Bresticker@fr > eescale.com To: "Brophy, Dennis" <dennisb@model.com> > Sent by: cc: ieee1800@eda.org > owner-ieee1800@eda.o Subject: Re: [P1800] SystemVerilog WG Unapproved Meeting Minutes Posted > rg > > > 01/26/2005 09:28 AM > Please respond to > Shalom.Bresticker > > > > > > > Sorry I did not make the meeting today. I woke up late. > > Comments: > > In the member roster, Karen Pieper is listed both under Accellera and > under Synopsys. > > Also, the list under "Present" does not correspond to the list under > 26-Jan-05. Johny does not appear either. > > Schedule issue: The following technical issues require resolution > for the P1364 LRM: > > Encryption: > ==================== START ENCRYPTION ISSUES============================ > > e) Conflicting text where 'end' pragma expression is associated > > with the most recent unclosed 'begin' pragma expression, but > > 28.3.1.2 says that nesting is illegal. > > > > f) Is Encryption optional or not? See text saying "Verilog tools > > THAT provide encryption services". > > > > + Need to address support for encryption services in the > > simulator and also as a separate non-simulation tool. Perhaps > > distiguishing requirements for encryption vs decryption. > > > > h) Do we need line-wrapping text to ease formatting of the example > > and for user convenience. > > > > + appropriate text can be copied from `define if needed > > > > i) example is missing required "feature" argument > > > > + Steven to update example for Shalom > > > 1. About transforming protect pragma directives during encryption: > > The example shows how the directives preceding the encryption envelope > (i.e., preceding the begin keyword) are transformed and/or moved. > > In this example, the directives came immediately before the envelope. > > What happens if the directives are far away, many lines before the > encryption envelope? > > What happens if they are even in a different file? > > What happens if the directives are followed by more than one > encryption envelope? > > Are the answers to these in the current text? > > > 2. 28.1.2 (now 28.2.2) says that decryption occurs "in a manner similar to > and at a translation phase consistent with that of macro substitution". > > The phrases "in a manner similar to" and "at a translation phase consistent > with" are ambiguous? > > Is decryption substitution done before, together with, or after macro > substitution? > > Similarly, when is encryption done? > > > 3. "Should" is used a number of times. "Should" means "is recommended > that". Please check that that is the intended meaning everywhere it > appears. > > > 4. 28.2 (now 28.3) is "Envelope Directives": This is a term which is not > used anywhere else, and is thus ambiguous. > > Further, the intro to this clause says that pragma expressions PRECEDING > begin or begin_protected are called 'envelope keywords' where those > after those keywords are 'CONTENT keywords'. > > A similar question applies to the name of the following subclause which > is called 'Envelope encoding keywords': What does it refer to and what not? > > > 5. Table 28-1 contains: > > data_decrypt_key Specifies the data encryption session key > digest_decrypt_key Specifies the digest encryption session key > > >From the text in 28.3.14 and 28.3.20, it seems that these are > decryption keys, not encryption keys? > > > 6. Need to clarify allowing white space in pragma expressions. > ==================== END ENCRYPTION ISSUES============================ > > SV-CC/PTF: > > > You need to give me a final resolution about issues 040 and 313. > > Note about 040 that splitting the section into 4 parts will again cause > Stu to > > have to redo all the cross-references from 1800 to 1364. > > > > > Item 040: diagram for parameter is missing > > > Item 313: PTF 296: Generate stmts will need change made in VPI > > ======================================================================= > > On classification of balloters: > > I think Mentor, Synplicity and Fintronices should be Producer. > > I think Infineon, Broadcom, Sunburst, and ARM should be User. > > > On editorial coordination: > > I am not getting any comments from IEEE. > Is anyone looking at the P1364 draft? > > Thanks, > Shalom > > > On Tue, 25 Jan 2005, Brophy, Dennis wrote: > > > Please see > > < http://www.eda-twiki.org/sv-ieee1800/Meetings/2005/January/1-26-05MeetingMinu > > tesUnapproved.pdf> for a copy of the unapproved meeting minutes of the > > IEEE SystemVerilog Working Group meeting held 26 January 2005. Please > > send any corrections to me that need to be made. > > > > Regards, > > > > Dennis > > > > -- > Shalom Bresticker Shalom.Bresticker @freescale.com > Design & Verification Methodology Tel: +972 9 9522268 > Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 > > [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary > > > > > > -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential ProprietaryReceived on Thu Jan 27 19:31:02 2005
This archive was generated by hypermail 2.1.8 : Thu Jan 27 2005 - 19:31:15 PST