Re: [P1800] SystemVerilog WG Unapproved Meeting Minutes Posted

Hi, Andy.

There is no P1364 WG.

There is only the SystemVerilog WG, which is handling both the P1800
and P1364 standards.

Till now, Noelle has been IEEE's liason to this WG and has been fully
aware of the balloting schedule.

Shalom

On Thu, 27 Jan 2005 a.ickowicz@ieee.org wrote:

>
> Hi Shalom,
>
> To my knowledge, the IEEE P1364 Working Group has yet to request Mandatory
> Editorial Coordination from IEEE Standards Publishing Staff. If this is
> indeed the case, the request and upload of draft can be done via the
> request form found at the following URL:
>
> http://standards.ieee.org/resources/development/balloting/pre-ballot.html
>
> If such a request has already been made, please let me know.
>
> Thanks and Best Regards,
> Andy
>
> Andrew Ickowicz
> Program Manager, Technical Program Development
> IEEE Standards Activities
> Phone: +1 732 562 3810
> Email: a.ickowicz@ieee.org
> Check out our website at http://standards.ieee.org
>
>
>
> Noelle Humenick
> To: Shalom.Bresticker@freescale.com
> 01/27/2005 02:13 cc: shalom@fil.ea.freescale.net, Andrew Ickowicz/STDS/STAFF/US/IEEE@IEEE
> PM Subject: Re: [P1800] SystemVerilog WG Unapproved Meeting Minutes Posted(Document
> link: Andrew Ickowicz)
>
>
>
>
> 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 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 Proprietary