Date: Sun Jan 16 2005 - 23:31:56 PST
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
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
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 188.8.131.52 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 ?
-- 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
sponsored by Boyd Technology, Inc.