Re: IEEE 1364-2005 Encryption draft with consensus changes

From: Steven J. Dovich (dovich@cadence.com)
Date: Mon Jan 17 2005 - 13:46:20 PST

  • Next message: Steven J. Dovich: "Re: IEEE 1364-2005 Encryption draft with consensus changes"

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

    I will include these on the agenda for the Encryption meeting this
    week. My responses are noted below.

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

    Thanks.

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

    I think we need an "unless otherwise specified" qualifier on that
    assertion that "text outside the encryption envelope is not modified".
    The documentation for the specific pragma_keywords does at least attempt
    to specify certain items that need to be moved into the data_block.

    We can discuss further on Wednesday.

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

    While not wrong, it does create confusion for those who infer nesting
    and miss the proscription in 28.3.1.2.

    We can look at whether this merits further word-smithing.

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

    At least one view of the conformance requirements expects encryption
    services to be supplied in a different (and dedicated purpose) tool,
    which is not required to do more than recognize the envelope regions
    and transform encryption envelopes into decryption envelopes.

    I believe the intent is to allow both that architecture, and one where
    a simulator could have a processing mode that encrypted. Hence the
    phrasing to apply requirements to tools which "performed encryption".

    We should discuss this on Wednesday, to determine if there is a
    better phrasing that captures that intention.

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

    That is a typographical error, and may be corrected editorially as
    stated above.

    /sjd

    This archive was generated by hypermail 2.1.4 : Mon Jan 17 2005 - 13:30:12 PST and
    sponsored by Boyd Technology, Inc.