[P1800] lrm encryption problems

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
Date: Tue Feb 01 2005 - 06:58:46 PST

I need resolution of these issues.

Shalom

--
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

attached mail follows:


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
Received on Tue Feb 1 06:59:03 2005

This archive was generated by hypermail 2.1.8 : Tue Feb 01 2005 - 06:59:06 PST