Re: IEEE 1364-2005 Encryption draft with consensus changes

From: Shalom.Bresticker@freescale.com
Date: Sun Jan 16 2005 - 23:31:56 PST

  • Next message: Shalom.Bresticker@freescale.com: "Re: IEEE 1364-2005 Encryption draft with consensus changes"

    Hi,

    I took a break for a few days from looking at the encryption proposal,
    and even before, I was mostly looking at it from an editor's point of
    view.

    I looked at it a little this more and found that a few of my previous
    reservations have not been resolved and I found a few more problems as
    well.

    0. Editorial note: In accordance with IEEE style rules, I will add a new
    subclause 28.1 titled 'General' at the beginning of Clause 28, which will
    contain the introductory text. All the other subclauses 28.n will be
    bumped by 1 to be 28.(n+1). This is so that if someone wants to refer to
    that introductory text, he will be able to say what subclause it is in.

    1. Unclearness as to what is transformed in encryption.

    Encryption envelopes are defined as being enclosed by the begin-end
    pragma expressions. 28.1 (existing numbering) says that encryption process
    transforms encryption envelopes. 28.1.1 goes even farther and says that
    source text not in an encryption envelope is not modified.

    Yet the example on the following pages shows that the `pragma protect
    directives preceding the encryption envelope are transformed, their
    order is changed, and what preceded the encryption envelope is now
    inside the decryption envelope.

    I'm not saying it is wrong, but it is very unclear.

    2. The end of the 3rd paragraph in 28 says that the 'end' pragma
    expression is associated with the most recent unclosed 'begin' pragma
    expression. This seems to imply that 'begin' pragma expressions may be
    nested. Yet 28.3.1.2 says that nesting is illegal.

    3. 28.1.1 says "Verilog tools THAT provide encryption services...".
    There are similar expressions elsewhere. If encryption support is
    required by the proposed standard, such an expression, implying optionality,
    is out of place.

    If support is intended to be optional, the LRM has to say so explicitly.
    Either way, the language needs to be consistent.

    4. At the end of the example preceding 28.1.2, there is a directive

    `pragma reset protected

    Since the pragma name is 'protect' should that be

    `pragma reset protect ?

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

    This archive was generated by hypermail 2.1.4 : Sun Jan 16 2005 - 23:15:52 PST and
    sponsored by Boyd Technology, Inc.