[sv-champions] Re: Encryption proposal

Hi, Steven.

I have not looked seriously at the encryption proposal in the past.
Only over the last day or two did I look at it more carefully, though
still only rather quickly, and I have a number of concerns.

First, the proposal to add a `pragma compiler directive to section 19 has
to be able to stand on its own, without any connection to encryption.
Strictly speaking, this is more properly in the scope of the regular BTF,
rather than the BTF-IP.

This concerns me, because although your minutes say that it was shown to
the BTF, there is no record of any serious detailed discussion in the
BTF minutes. Did the BTF get a detailed proposal and discuss it?
I fear this part did not get a thorough review for consistency with
other parts of the Verilog LRM.

Some of my specific concerns:

I refer to the document filed in the SV DB as 314. It is labelled
CDN P1364e/D2.

First, there is no description of the motivation or justification of
`pragma or the envisioned typical use models. That is, if I just read
this, I don't understand why you need `pragma.

Example: You want 'protect'? So define `protect and `endprotect. Why
'`pragma protect'?

Jay Lawrence originally proposed `pragma in BTF 430. I speculate that
it was the source of this part of the proposal. But Jay's discussion
included a description of the need for and use of `pragma which is
missing here but needed. Ditto for why non-recognized pragmas should
be ignored instead of creating warnings or errors.

(It's still not clear to me why 'protect' should be a pragma instead of
a regular compiler directive, though...)

(Also, it is still not clear that unrecognized directives should not
generate at least a warning, which could help spotting mis-spelled
directives.)

The first sentence describes `pragma as 'a structured specification'.
Excuse me, but that is a meaningless buzz-phrase, at least without
a further explanation or at least an example. What makes it different
from other directives?

Speaking of examples, this section definitely needs an example, preferably
more than one.

Regarding the syntax, it is not clear whether or where white space may
or may not appear in the form 'keyword=value' or within constant_expression.

And it is not clear what operands and operators may appear in
constant_expression in this context. I had wanted to propose extensions
to the preprocessing capabilities of Verilog by adding some CPP and Verilog
pre-processor directives like '`if <expression>' and `for, but I got stuck
on this very point, and I saw it was not possible to get to a solid formal
specification within the deadline.

19.10.1 should be titled something like 'reset, resetall' instead of
'Standard Pragmas'. (Aren't you proposing that 'protect' be a standard
pragma as well?)

Examples are badly needed.

The first sentence in 19.10.1 is very confusing, because you have not yet
said that the 'affected pragmas' appear as keywords of the reset pragma.

Moving on to Section 28, the question about where white space may and may
not appear is common to many of the items in this section.

The syntaxes should appear as, instead of 'begin', as '`pragma protect begin'.

28.3.2 Description should be 28.3.2.2.

28.3.9.2 references other standards. They must be properly referenced,
probably in Annex H.

28.3.11.2 and 28.3.21.2 reference a bunch of Encryption and Digest algorithms.
All need to be properly referenced.

By the way, is support of encryption to be mandatory for compliance to
1364-2005? I'm not sure how much support there will be for that among the
balloters.

Annex I mentions Verilog-XL. I'm not sure you can do that, even if the Annex
is only normative.

Annex I refers to 'the following pragmas', whereas in 28, they are called
'pragma_keywords'. The distinction between pragma, pragma name, and pragma
keyword is important.

As you can see, I think this still needs work.
I think there are still too many open issues.

Sorry if I sounded a bit harsh.

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