Shalom is correct.
The P1800 WG handles both SV and Verilog.
Thanks,
--- Johny.
Shalom.Bresticker@freescale.com
Sent by: owner-ieee1800@eda.org
01/27/2005 09:36 PM
Please respond to
Shalom.Bresticker
To
a.ickowicz@ieee.org
cc
n.humenick@ieee.org, "Fitzpatrick, Tom" <tom_fitzpatrick@mentorg.com>,
ieee1800@eda.org
Subject
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 ProprietaryReceived on Fri Jan 28 07:10:24 2005
This archive was generated by hypermail 2.1.8 : Fri Jan 28 2005 - 07:10:46 PST