FYI.
K
>From: owner-sv-champions@eda.org
>Date: Mon, 20 Dec 2004 20:52:40 -0800 (PST)
>X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-champions@eda.org using -f
>To: sv-champions-approval@eda.org
>Subject: BOUNCE sv-champions@eda.org: Non-member submission from ["Steven J. Dovich" <dovich@cadence.com>]
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
> on server.eda.org
>X-Virus-Status: Clean
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-pstn-settings: 1 (0.1500:0.1500) gt3 gt2 gt1 r p m c
>X-pstn-addresses: from <owner-sv-champions@eda.org> [582/17]
>
>>From pieper Mon Dec 20 20:51:57 2004
>Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
> by server.eda.org (8.12.10/8.12.0.Beta7) with ESMTP id iBL4puKB010010;
> Mon, 20 Dec 2004 20:51:56 -0800 (PST)
>Received: from gda.cadence.com (gda.Cadence.COM [158.140.106.10])
> by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id UAA10470;
> Mon, 20 Dec 2004 20:51:07 -0800 (PST)
>Received: from cadence.com (madison [158.140.102.194])
> by gda.cadence.com (8.10.1/8.8.5) with ESMTP id iBL4ppv04705;
> Mon, 20 Dec 2004 23:51:51 -0500 (EST)
>Message-ID: <41C7ABE7.8050901@cadence.com>
>Date: Mon, 20 Dec 2004 23:51:51 -0500
>From: "Steven J. Dovich" <dovich@cadence.com>
>Organization: Cadence Design Systems, Chelmsford MA
>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: btf-ip@boyd.com, btf <btf@boyd.com>, ieee1800@server.eda.org,
> sv-champions@server.eda.org
>CC: Shalom.Bresticker@freescale.com, Surrendra.Dudani@synopsys.com,
> Steven.McMaster@synopsys.com
>Subject: Reviewer feedback for Encryption proposal
>Content-Type: multipart/mixed;
> boundary="------------000700040807050407090303"
>X-Received: By mailgate.Cadence.COM as UAA10470 at Mon Dec 20 20:51:07 2004
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
> on server.eda.org
>X-Virus-Status: Clean
>
>This is a multi-part message in MIME format.
>--------------000700040807050407090303
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>
>Here are the messages recieved as input for the Encryption Review.
>Please read them through carefully to determine what changes if any
>are being requested. In the Wednesday meeting we will review these
>comments and determine the appropriate disposition for each requested
>change.
>
>For those who have indicated that they are unable to attend, please
>forward comments and recommendations for dispositioning to the
>btf-ip@boyd.com reflector.
>
>/sjd
>
>--------------000700040807050407090303
>Content-Type: message/rfc822;
> name="enc01.eml.eml"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="enc01.eml.eml"
>
>Replied: Thu, 09 Dec 2004 18:01:57 -0500
>Replied: Shalom.Bresticker@freescale.com
>Replied: btf-ip@boyd.com
>Replied: btf@boyd.com
>Replied: sv-champions@eda.org
>Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
> by gda.cadence.com (8.10.1/8.8.5) with SMTP id iB9LP7v11820
> for <dovich@gda.cadence.com>; Thu, 9 Dec 2004 16:25:07 -0500 (EST)
>Received: from isvw3.cadence.com (isvw3.cadence.com [158.140.2.61])
> by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id NAA01929
> for <dovich@gda.cadence.com>; Thu, 9 Dec 2004 13:24:26 -0800 (PST)
>Received: from isvw3.cadence.com (localhost [127.0.0.1])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with ESMTP id iB9LP6O01877
> for <dovich@gda.cadence.com>; Thu, 9 Dec 2004 13:25:06 -0800 (PST)
>X-Authentication-Warning: isvw3.cadence.com: iscan owned process doing -bs
>Received: from psmtp.com (exprod6mx122.postini.com [64.18.1.114])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with SMTP id iB9LP4301717;
> Thu, 9 Dec 2004 13:25:05 -0800 (PST)
>Received: from source ([198.145.255.50]) by exprod6mx122.postini.com ([64.18.5.10]) with SMTP;
> Thu, 09 Dec 2004 13:25:04 PST
>Received: from wa.boyd.com (wa.boyd.com [127.0.0.1])
> by wa.boyd.com (8.12.8/8.12.8) with ESMTP id iB9LB3Kk022805
> for <lst1tf-list@wa.boyd.com>; Thu, 9 Dec 2004 13:11:03 -0800
>Received: (from mdom@localhost)
> by wa.boyd.com (8.12.8/8.12.8/Submit) id iB9LB2oC022794
> for lst1tf-list; Thu, 9 Dec 2004 13:11:02 -0800
>Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8])
> by wa.boyd.com (8.12.8/8.12.8) with ESMTP id iB9LB0Kk022778;
> Thu, 9 Dec 2004 13:11:01 -0800
>Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136])
> by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iB9LQaNi017620;
> Thu, 9 Dec 2004 14:26:36 -0700 (MST)
>Received: from lnx22.fil.ea.freescale.net ([223.75.95.22])
> by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id iB9LOsx3020323;
> Thu, 9 Dec 2004 15:24:55 -0600
>Received: from eagle.fil.ea.freescale.net (eagle [223.131.95.41])
> by lnx22.fil.ea.freescale.net (8.12.11/8.12.11) with ESMTP id iB9LO0Kk013233;
> Thu, 9 Dec 2004 23:24:11 +0200
>Received: from localhost (shalom@localhost)
> by eagle.fil.ea.freescale.net (8.11.7+Sun/8.11.7) with ESMTP id iB9LNdn09956;
> Thu, 9 Dec 2004 23:23:49 +0200 (IST)
>X-Authentication-Warning: eagle.fil.ea.freescale.net: shalom owned process doing -bs
>Date: Thu, 9 Dec 2004 23:23:39 +0200 (IST)
>From: Shalom.Bresticker@freescale.com
>Reply-To: Shalom.Bresticker@freescale.com
>To: "Steven J. Dovich" <dovich>
>cc: btf-ip@boyd.com, btf@boyd.com, sv-champions@eda.org
>Subject: Re: Encryption proposal
>In-Reply-To: <200412081956.iB8JuZqX004371@lethe.tiac.net>
>Message-ID: <Pine.GSO.4.10.10412092226330.9113-100000@eagle>
>MIME-Version: 1.0
>Sender: owner-btf@boyd.com
>Precedence: bulk
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-Received: By mailgate.Cadence.COM as NAA01929 at Thu Dec 9 13:24:26 2004
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>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
>
>
>
>
>--------------000700040807050407090303
>Content-Type: message/rfc822;
> name="enc02 .eml.eml"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="enc02 .eml.eml"
>
>Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
> by gda.cadence.com (8.10.1/8.8.5) with SMTP id iBBI58v27600
> for <dovich@gda.cadence.com>; Sat, 11 Dec 2004 13:05:08 -0500 (EST)
>Received: from isvw3.cadence.com (isvw3.cadence.com [158.140.2.61])
> by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id KAA17572
> for <dovich@gda.cadence.com>; Sat, 11 Dec 2004 10:04:25 -0800 (PST)
>From: Shalom.Bresticker@freescale.com
>Received: from isvw3.cadence.com (localhost [127.0.0.1])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with ESMTP id iBBI53U09290
> for <dovich@gda.cadence.com>; Sat, 11 Dec 2004 10:05:03 -0800 (PST)
>X-Authentication-Warning: isvw3.cadence.com: iscan owned process doing -bs
>Received: from psmtp.com (exprod6mx117.postini.com [64.18.1.109])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with SMTP id iBBI4x309156
> for <dovich@cadence.com>; Sat, 11 Dec 2004 10:05:02 -0800 (PST)
>Received: from source ([192.88.158.102]) by exprod6mx117.postini.com ([64.18.5.10]) with SMTP;
> Sat, 11 Dec 2004 10:04:59 PST
>Received: from az33smr01.freescale.net (az33smr01 [10.64.34.199])
> by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id iBBI9oLn001334;
> Sat, 11 Dec 2004 11:09:50 -0700 (MST)
>Received: from lnx22.fil.ea.freescale.net ([223.75.95.22])
> by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id iBBI8pLR024461;
> Sat, 11 Dec 2004 12:08:52 -0600 (CST)
>Received: from eagle.fil.ea.freescale.net (eagle [223.131.95.41])
> by lnx22.fil.ea.freescale.net (8.12.11/8.12.11) with ESMTP id iBBI4n5D012665;
> Sat, 11 Dec 2004 20:04:50 +0200
>Received: from localhost (shalom@localhost)
> by eagle.fil.ea.freescale.net (8.11.7+Sun/8.11.7) with ESMTP id iBBI4ns09832;
> Sat, 11 Dec 2004 20:04:49 +0200 (IST)
>X-Authentication-Warning: eagle.fil.ea.freescale.net: shalom owned process doing -bs
>Date: Sat, 11 Dec 2004 20:04:49 +0200 (IST)
>Sender: shalom@fil.ea.freescale.net
>Reply-To: Shalom.Bresticker@freescale.com
>To: "Steven J. Dovich" <dovich>
>cc: btf-ip@boyd.com, btf@boyd.com, tom_fitzpatrick@mentorg.com,
> sv-champions@eda.org
>Subject: Re: Encryption proposal
>In-Reply-To: <200412092301.iB9N1umD006198@lethe.tiac.net>
>Message-ID: <Pine.GSO.4.10.10412111907450.9167-100000@eagle>
>MIME-Version: 1.0
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c
>X-pstn-addresses: from <Shalom.Bresticker@freescale.com> [173/4]
>X-Received: By mailgate.Cadence.COM as KAA17572 at Sat Dec 11 10:04:25 2004
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Hi, Steve.
>
>
>On Thu, 9 Dec 2004, Steven J. Dovich wrote:
>
>> Shalom,
>>
>> Thanks for your feedback. It would have been useful to have it
>> earlier in the process.
>
>Unfortunately, my time has been too limited to be involved in everything.
>And my expertise (and interest, frankly) in encryption is also limited.
>Nor have I been able to participate much in the BTF meetings due to the
>late hour in my time zone.
>
>
>> > 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.
>>
>> While the Encryption committee was a subcommittee of the BTF, I
>> attended those meetings to report and request guidance. I specifically
>> requested that the BTF handle the pragma definition since that was
>> more properly within their domain of expertise. I was given guidance
>> and directed to handle the language issues in the Encryption committee.
>
>Still, it is unfortunate that it was ont reviewed by the BTF.
>
>
>> The resulting proposal for the `pragma directive is responsive to
>> the specific comments I recieved in the BTF meeting. It is also
>> the result of choices made by the Encryption committee with respect
>> to dealing with existing non-standard directives.
>>
>>
>> > 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'?
>>
>> Because `protect and `endprotect are existing non-standard directives
>> that are reasonably widely deployed with differing semantics and
>> interpretation. The committee felt it invited less confusion to
>> use different directives for this new standard encryption scheme.
>>
>> Other directive names were discussed, and there was a conscious
>> choice to specify a general extension mechanism that would solve
>> the problem at hand, and also be useful for future extension by
>> implementors and standards committees.
>
>`protect is just an example.
>`pragma is a general mechanism. It needs to be justified and the use model
>described. Many tools defined their own directives. For example, Verilog-XL
>defined `accelerate. You should show why this method of extending
>directives is not adequate.
>
>You should also show how the `pragma mechanism could help avoid conflicts
>between private extensions. For example, if two different tools will define
>"`pragma accelerate", then I still have a problem.
>
>
>> > 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.)
>
>This issue still requires a discussion.
>
>
>> BTF 430 was not the seed, though this idea has been floating around
>> in conversations for a while. In comparison with BTF 430, the grammar
>> for the directive has been extended to better support the specification of
>> pragma names like 'protect'.
>>
>> > 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.
>>
>> Examples would certainly be in character for this standard. But I
>> think that they can't be allowed to imply specification that is not
>> actually there in the normative text. If the text is incomplete
>> we need to address that. If it is complete but obtuse, then that
>> is a different problem that we can word-smith around.
>
>The minute that the actual pragma is not defined by the LRM,
>there is no problem in giving an abstract example, even with meaningless
>names. It certainly does not imply that the example is normative.
>
>It is like the example of user-defined functions in 10.3.5.
>
>Without an example, it is not clear how to use `pragma.
>
>You could even use 'protect' as an example.
>
>
>> > 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.
>>
>> I would agree that this aspect requires some degree of interpretation.
>
>For example, if the argument list is "1 -2", is that one constant_expression
>("1-2") or two (1 and -2)?
>
>
>> > 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.
>>
>> The choice of constant_expression was intended to be a connection to
>> the BNF in Annex A. If there is some subtle reason why that would be
>> inappropriate in the directive context, then this issue should be
>> revisited.
>
>Are all types of constants allowed? based, sized, etc?
>What are the sizing and signing rules?
>Are they the same as in Verilog text?
>Parameters are presumably not allowed.
>What about "constant system functions" (see enhancements BTF-387 and 390)?
>
>
>> > 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?)
>>
>> No objection. I consider this an editorial perogative, though the
>> Working Group seems to want purview over these issues.
>>
>> > Examples are badly needed.
>>
>> See answer above.
>
>It took me several reading to understand the intended syntax.
>An example is essential.
>
>
>> > 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.
>>
>> Is this fixable by re-ordering the sentences in the paragraph or
>> is the problem deeper than that?
>
>Probably re-ordering and minor rewording is enough.
>
>
>> > 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.
>>
>> See answer above.
>>
>> > The syntaxes should appear as, instead of 'begin', as '`pragma protect begin'.
>>
>> They appear in isolation because they describe the requirements on
>> the specific pragma keyword that is associated with the 'protect'
>> pragma name. With a complete directive, that is by nature an example,
>> as the intent is to permit compositing of adjacent protect pragma
>> directives. For example:
>>
>> `pragma protect begin
>> `pragma protect author="IEEE"
>> `pragma protect data_method=rsa
>>
>> can be also represented as:
>>
>> `pragma protect begin author="IEEE" data_method=rsa
>>
>> Both forms have identical interpretation (clause 28 para 2).
>> Since 28.3 describes the pragma keywords for 'protect' it only
>> gives the syntax for the pragma keyword being described.
>
>Good point. Such an example would be very helpful.
>
>Note that the paragraph before 28.1 says that expressions preceding
>begin 'are designated as envelope keywords', whereas expressions following
>begin are 'content keywords'. But then 28.2 is titled 'Envelope directives',
>which implies that they have to precede 'begin'.
>
>
>> > 28.3.2 Description should be 28.3.2.2.
>>
>> Uncaught typo, thanks for spotting it.
>>
>> > 28.3.9.2 references other standards. They must be properly referenced,
>> > probably in Annex H.
>>
>> No objection. The normative references are provided.
>
>The IETF references need to be done in the proper format, with the required
>information. It should not be the editor's job to obtain this information.
>
>
>> > 28.3.11.2 and 28.3.21.2 reference a bunch of Encryption and Digest algorithms.
>> > All need to be properly referenced.
>>
>> We spent considerable time trying to find a normative reference
>> for the entire list. The fallback of local specification needs
>> appropriate normative references to these algorithms.
>
>I don't understand what you mean by this.
>Some of these names I know, many I don't (Blowfish and Serpent, for example).
>You have to supply references for them.
>
>
>> > 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.
>>
>> I think the text implies it is mandatory. I don't think this is a
>> show-stopper though. The Encryption committee is not the right
>> forum for that decision. That is a policy decision that is ultimately
>> in the hands of the ballot group. We took one reasonable approach
>> and are prepared to alter the policy if so requested by the Working
>> Group or the Ballot Group.
>
>I think it kills the last chance of anyone doing a 'hobbyist' implementation
>of the language.
>
>
>> > 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.
>>
>> Annex I is not at the quality level that I am comfortable with.
>> I raised the option of omitting it from the approved proposal. The
>> Encryption committee felt that there was critical informative
>> content regarding use models that would otherwise be missing and
>> voted to include it.
>
>My issues remain.
>
>
>> > As you can see, I think this still needs work.
>> > I think there are still too many open issues.
>>
>> The degree of open issues and questions is a matter for the Working
>> group to establish consensus on. We could continue to polish, but
>> this was an item of substantial interest to the Working Group, which
>> the Encryption committee has done their best to deliver in the
>> time frame requested.
>>
>> The proposal is substantially improved over the donation. I fully
>> expect to deal with additional changes in ballot, because there is
>> a related effort in the VHDL committee that we need to coordinate
>> with. They started from an equivalent donation and are discussing
>> changes. I have provided them with this proposal and requested
>> their current document in return. It would not be useful to industry
>> if incompatible schemes are standardized.
>>
>> The Mantis "Encryption" category is where I expect to accumulate and
>> address remaining issues and errata. The Encryption committee will
>> be working through those issues as they are posted in an effort to
>> accumulate corrections and clarifications for the next opportunity
>> to amend the draft.
>
>The question is whether to send to ballot something which we know needs
>more work.
>
>Thanks,
>Shalom
>
>
>>
>> > Sorry if I sounded a bit harsh.
>>
>> You will have to try a lot harder. I still have a standing death
>> threat over a compromise I successfully brokered between three
>> working groups in IEEE POSIX effort.
>>
>>
>> I hope my response is helpful in working through the proposal.
>>
>> /sjd
>>
>
>--
>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
>
>
>
>
>
>
>--------------000700040807050407090303
>Content-Type: message/rfc822;
> name="enc03.eml.eml"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="enc03.eml.eml"
>
>Received: from mx-sanjose.cadence.com (mx-sanjose [158.140.2.60])
> by gda.cadence.com (8.10.1/8.8.5) with SMTP id iBFN8jv16183
> for <dovich@gda.cadence.com>; Wed, 15 Dec 2004 18:08:45 -0500 (EST)
>Received: from psmtp.com (localhost [127.0.0.1])
> by mx-sanjose.cadence.com (8.12.9/8.12.9) with SMTP id iBFN8iT0027704
> for <dovich@cadence.com>; Wed, 15 Dec 2004 15:08:44 -0800 (PST)
>Received: from source ([198.182.44.80]) by exprod6mx10.postini.com ([64.18.5.10]) with SMTP;
> Wed, 15 Dec 2004 15:08:44 PST
>Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170])
> by kiruna.synopsys.com (Postfix) with ESMTP id B288BFA43
> for <dovich@cadence.com>; Wed, 15 Dec 2004 15:08:24 -0800 (PST)
>Received: from us03-mail-2.synopsys.com (localhost [127.0.0.1])
> by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id PAA23690
> for <dovich@cadence.com>; Wed, 15 Dec 2004 15:08:43 -0800 (PST)
>Received: from localhost (localhost [127.0.0.1])
> by us03-mail-2.synopsys.com (Postfix) with SMTP id 0A2D455A
> for <dovich@cadence.com>; Wed, 15 Dec 2004 15:08:42 -0800 (PST)
>Received: from stevenmd800 (unknown [10.4.31.109])
> by us03-mail-2.synopsys.com (Postfix) with ESMTP id 490A155A;
> Wed, 15 Dec 2004 15:08:37 -0800 (PST)
>Reply-To: <Steven.McMaster@synopsys.com>
>From: "Steven McMaster" <Steven.McMaster@synopsys.com>
>To: "'Steven J. Dovich'" <dovich>
>Subject: FW: Review of Encryption proposal scheduled for Wed 12/22 at 1500 UTC
>Date: Wed, 15 Dec 2004 15:10:36 -0800
>Organization: Synopsys, Inc
>Message-ID: <03db01c4e2fb$48f6f7b0$6d1f040a@internal.synopsys.com>
>MIME-Version: 1.0
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook, Build 10.0.4510
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c
>X-pstn-addresses: from <Steven.McMaster@synopsys.com> [173/4]
>X-Received: By mx-sanjose.cadence.com as iBFN8iT0027704 at Wed Dec 15 15:08:44 2004
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by gda.cadence.com id iBFN8jv16183
>Content-Type: text/plain;
> charset="us-ascii"
>
>I plan to attend.
>
>Since things are going back to committee, can you recall why the runtime license reverted to just returning an integer?
>A corollary question I have is why the success is a 0 and the failure is non-zero.
>
>I remember having discussions about making the licensing more complex, etc., and I'm thinking the conclusion was that if
>we wanted something more complex we should just implement it on our own -- i.e., in our own library call, etc., hidden
>inside the encrypted code. Is this the underlying assumption here, that nothing prevents us from encrypting our own call
>that has more complex return values, etc.?
>
>If this is correct, then I'd propose we get rid of the runtime_license pragma and replace it with an indication about
>"user responsibility for runtime licensing". The current proposal isn't really going to be safe. We shouldn't even be
>recommending it.
>
>If this is incorrect, then we need to rethink the return parameter, etc., for this pragma. It just doesn't provide
>enough safety.
>
>-----Original Message-----
>From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On Behalf Of Steven J. Dovich
>Sent: Wednesday, December 15, 2004 2:39 PM
>To: btf-ip@boyd.com; btf@boyd.com; etf@boyd.com; sv-cc@eda.org; sv-bc@eda.org; sv-ec@eda.org; sv-ac@eda.org;
>ieee1800@eda.org
>Subject: Review of Encryption proposal scheduled for Wed 12/22 at 1500 UTC
>
>
>The P1800 Working group has referred the Encryption proposal back to the Committee to review the concerns of various
>parties who are now looking at the proposal for the first time.
>
>The Encryption committee will meet to review and address those concerns at our December 22 meeting. The agenda and call
>information is attached. Please notify me if you will be attending so that I can make provision for additional call-in
>ports if needed.
>
>The proposal under consideration can be found in Mantis item 314 in PDF format. Those with concerns should send them to
>me (you may also cc the <btf-ip@boyd.com> reflector) by Monday 12/20 for consideration at the meeting. I will aggregate
>all the issues and forward them to all submitters and to the btf-ip reflector.
>
>Reviewers, please be as concrete as possible in describing the nature of the issues you are noting. Use section and
>paragraph numbers to pinpoint the areas you are commenting on. That will permit us to sort comments and issues for
>effective review in the meeting. Please include some indication of the sort of resolution that will satisfy your
>concerns.
>
>
>/sjd
>
>
>
>Agenda for Encryption group meeting - 22-Dec-2004 at 1100 US/Eastern
>
>
>
>When: Wednesday, Dec 22, 2004
> 11:00 am - 12:00 pm US-Eastern (1500 UTC)
>
>Phone Conf: 866-700-8779
> 210-839-5678 for international access
>Passcode: 879814
>Leader: Steven J. Dovich <dovich@cadence.com>
>
>
>1) Approve the agenda
>
>2) Review of patent policy
>
> http://standards.ieee.org/board/pat/pat-slideset.ppt
>
>3) Review of minutes
>
>4) Discussion of reviewer concerns and issues
>
>5) Other business
>
>6) Action Item assignments
>
>7) Adjourn
>
>
>
>
>
>--------------000700040807050407090303
>Content-Type: message/rfc822;
> name="enc04.eml.eml"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="enc04.eml.eml"
>
>Replied: Fri, 17 Dec 2004 15:15:35 -0500
>Replied: Surrendra Dudani <Surrendra.Dudani@synopsys.com>
>Replied: karen Pieper <Karen.Pieper@synopsys.com>
>Replied: Oz.Levia@synopsys.com
>Replied: vberman@cadence.com
>Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
> by gda.cadence.com (8.10.1/8.8.5) with SMTP id iBHGfXv21799
> for <dovich@gda.cadence.com>; Fri, 17 Dec 2004 11:41:33 -0500 (EST)
>Received: from isvw3.cadence.com (isvw3.cadence.com [158.140.2.61])
> by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id IAA03354
> for <dovich@gda.cadence.com>; Fri, 17 Dec 2004 08:40:45 -0800 (PST)
>Received: from isvw3.cadence.com (localhost [127.0.0.1])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with ESMTP id iBHGfGg06866
> for <dovich@gda.cadence.com>; Fri, 17 Dec 2004 08:41:16 -0800 (PST)
>X-Authentication-Warning: isvw3.cadence.com: iscan owned process doing -bs
>Received: from psmtp.com (exprod6mx118.postini.com [64.18.1.110])
> by isvw3.cadence.com (8.11.6+Sun/8.11.6) with SMTP id iBHGfF306820
> for <dovich@cadence.com>; Fri, 17 Dec 2004 08:41:15 -0800 (PST)
>Received: from source ([198.182.60.75]) by exprod6mx118.postini.com ([64.18.5.10]) with SMTP;
> Fri, 17 Dec 2004 11:41:15 EST
>Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170])
> by vaxjo.synopsys.com (Postfix) with ESMTP id 6854DDEEA
> for <dovich@cadence.com>; Fri, 17 Dec 2004 08:41:14 -0800 (PST)
>Received: from us04.synopsys.com (localhost [127.0.0.1])
> by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id IAA23533
> for <dovich@cadence.com>; Fri, 17 Dec 2004 08:41:13 -0800 (PST)
>Received: from localhost (localhost [127.0.0.1])
> by us04.synopsys.com (Postfix) with SMTP id 5DEEF5AF
> for <dovich@cadence.com>; Fri, 17 Dec 2004 11:41:12 -0500 (EST)
>Received: from dudani-c400.synopsys.com (dhcp-146-225-131-59.synopsys.com [146.225.131.59])
> by us04.synopsys.com (Postfix) with ESMTP id 085366A3;
> Fri, 17 Dec 2004 11:41:02 -0500 (EST)
>Message-Id: <5.1.0.14.2.20041217113118.03759ab8@us04.synopsys.com>
>X-Sender: dudani@us04.synopsys.com
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Fri, 17 Dec 2004 11:41:02 -0500
>To: "Steven J. Dovich" <dovich>
>From: Surrendra Dudani <Surrendra.Dudani@synopsys.com>
>Subject: Re: [sv-cc] Review of Encryption proposal scheduled for Wed
> 12/22 at 1500 UTC
>Cc: karen Pieper <Karen.Pieper@synopsys.com>, Oz.Levia@synopsys.com
>In-Reply-To: <200412152239.iBFMd0Wm008887@lethe.tiac.net>
>Mime-Version: 1.0
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c
>X-pstn-addresses: from <Surrendra.Dudani@synopsys.COM> [173/4]
>X-Received: By mailgate.Cadence.COM as IAA03354 at Fri Dec 17 08:40:45 2004
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
><div class="moz-text-flowed" style="font-family: -moz-fixed">Hi Steven,
>Please note the feedback after reviewing the encryption proposal:
>
>1) The proposal is very complex for what it is supposed to define
>2) Absence of examples
>3) The proposal is weak primarily in the following areas :
> -- It leaves the burden of implementing a number of encryption
>algorithms to the EDA tool vendor.
> -- List of algorithms in Page-16
> -- There is a concern that software containing certain encryption
>algorithms cannot be shipped to certain nations
> -- The licensing mechanism is extremely weak
> -- The IP-provider's shared object needs to be loaded for license
>check only. This is extremely easy to work-around
> -- It does not define how to encrypt/license 'derivative' code, for
>example RTL code generated by an assertion-RTL translator
> 4) The generality and the role of pragma construct in future "compile
>directive" type of functionality.
>
>Surrendra
>At 05:39 PM 12/15/2004 -0500, you wrote:
>>The P1800 Working group has referred the Encryption proposal back to
>>the Committee to review the concerns of various parties who are now
>>looking at the proposal for the first time.
>>
>>The Encryption committee will meet to review and address those
>>concerns at our December 22 meeting. The agenda and call information
>>is attached. Please notify me if you will be attending so that I
>>can make provision for additional call-in ports if needed.
>>
>>The proposal under consideration can be found in Mantis item 314
>>in PDF format. Those with concerns should send them to me (you
>>may also cc the <btf-ip@boyd.com> reflector) by Monday 12/20
>>for consideration at the meeting. I will aggregate all the issues
>>and forward them to all submitters and to the btf-ip reflector.
>>
>>Reviewers, please be as concrete as possible in describing the
>>nature of the issues you are noting. Use section and paragraph
>>numbers to pinpoint the areas you are commenting on. That will
>>permit us to sort comments and issues for effective review in the
>>meeting. Please include some indication of the sort of resolution
>>that will satisfy your concerns.
>>
>>
>>/sjd
>>
>>
>>
>>Agenda for Encryption group meeting - 22-Dec-2004 at 1100 US/Eastern
>>
>>
>>
>>When: Wednesday, Dec 22, 2004
>> 11:00 am - 12:00 pm US-Eastern (1500 UTC)
>>
>>Phone Conf: 866-700-8779
>> 210-839-5678 for international access
>>Passcode: 879814
>>Leader: Steven J. Dovich <dovich@cadence.com>
>>
>>
>>1) Approve the agenda
>>
>>2) Review of patent policy
>>
>> http://standards.ieee.org/board/pat/pat-slideset.ppt
>>
>>3) Review of minutes
>>
>>4) Discussion of reviewer concerns and issues
>>
>>5) Other business
>>
>>6) Action Item assignments
>>
>>7) Adjourn
>
>
>
>**********************************************
>Surrendra A. Dudani
>Synopsys, Inc.
>377 Simarano Drive, Suite 300
>Marlboro, MA 01752
>
>Tel: 508-263-8072
>Fax: 508-263-8123
>email: Surrendra.Dudani@synopsys.com
>**********************************************
>
>
>
></div>
>
>--------------000700040807050407090303
>Content-Type: message/rfc822;
> name="enc05.eml.eml"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="enc05.eml.eml"
>
>Received: from mx-sanjose.cadence.com (mx-sanjose [158.140.2.60])
> by gda.cadence.com (8.10.1/8.8.5) with SMTP id iBKJhKv10984
> for <dovich@gda.cadence.com>; Mon, 20 Dec 2004 14:43:20 -0500 (EST)
>Received: from psmtp.com (localhost [127.0.0.1])
> by mx-sanjose.cadence.com (8.12.9/8.12.9) with SMTP id iBKJhJe4021307;
> Mon, 20 Dec 2004 11:43:19 -0800 (PST)
>Received: from source ([198.145.255.50]) (using TLSv1) by exprod6mx113.postini.com ([64.18.5.10]) with SMTP;
> Mon, 20 Dec 2004 14:43:18 EST
>Received: from wa.boyd.com (wa.boyd.com [127.0.0.1])
> by wa.boyd.com (8.12.8/8.12.8) with ESMTP id iBKJSVKk017752
> for <lst1tf-list@wa.boyd.com>; Mon, 20 Dec 2004 11:28:31 -0800
>Received: (from mdom@localhost)
> by wa.boyd.com (8.12.8/8.12.8/Submit) id iBKJSUhK017742
> for lst1tf-list; Mon, 20 Dec 2004 11:28:30 -0800
>Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103])
> by wa.boyd.com (8.12.8/8.12.8) with ESMTP id iBKJSSKk017725;
> Mon, 20 Dec 2004 11:28:29 -0800
>Received: from az33smr02.freescale.net (az33smr02 [10.64.34.200])
> by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id iBKJlKTc021387;
> Mon, 20 Dec 2004 12:47:20 -0700 (MST)
>Received: from lnx22.fil.ea.freescale.net ([223.75.95.22])
> by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id iBKJkKBL008630;
> Mon, 20 Dec 2004 13:46:21 -0600 (CST)
>Received: from eagle.fil.ea.freescale.net (eagle [223.131.95.41])
> by lnx22.fil.ea.freescale.net (8.12.11/8.12.11) with ESMTP id iBKJh6Hn011528;
> Mon, 20 Dec 2004 21:43:06 +0200
>Received: from localhost (shalom@localhost)
> by eagle.fil.ea.freescale.net (8.11.7+Sun/8.11.7) with ESMTP id iBKJh2W16275;
> Mon, 20 Dec 2004 21:43:05 +0200 (IST)
>X-Authentication-Warning: eagle.fil.ea.freescale.net: shalom owned process doing -bs
>Date: Mon, 20 Dec 2004 21:43:02 +0200 (IST)
>From: Shalom.Bresticker@freescale.com
>Reply-To: Shalom.Bresticker@freescale.com
>To: "Steven J. Dovich" <dovich>
>cc: btf-ip@boyd.com, btf@boyd.com
>Subject: Re: Review of Encryption proposal scheduled for Wed 12/22 at 1500
> UTC
>In-Reply-To: <200412152239.iBFMd0Wm008887@lethe.tiac.net>
>Message-ID: <Pine.GSO.4.10.10412202123090.15578-100000@eagle>
>MIME-Version: 1.0
>Sender: owner-btf@boyd.com
>Precedence: bulk
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )
>X-Received: By mx-sanjose.cadence.com as iBKJhJe4021307 at Mon Dec 20 11:43:19 2004
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>I have not had much time, but I looked at a little more of this and found a
>few more unclear points.
>
>The introduction to 28 says that an encryption envelope begins with a
>'begin' pragma expression. 28.1 says that encryption transforms encryption
>envelopes. So does 28.1.1. But 28.1.1 also says that encryption transforms
>encryption envelope pragma expressions. Yet the introduction to 28 calls
>pragma expressions which precede 'begin' as 'envelope' keywords, whereas
>pragma expressions which follow 'begin' are called 'content' keywords.
>There seems to be an inconsistent use of 'envelope' as an adjective.
>
>(In the 3rd paragraph of 28, line 4, "occurs a the point" should be
>"occurs at the point".)
>
>28.1.1 refers to a 'session' key. What is a session?
>
>28.1.1 and 28.1.2 refer to 'tools that provide encryption services' and
>'tools that support decrypting compilation'. This sounds like such
>support is optional, not required. Is that the intent?
>
>The table in 28.2 lists 'data_decrypt_key' as 'specifies the session key
>for data encryption'. That formulation is very confusing, using both terms,
>decrypion and encryption. Same for digest_decrypt_key. 28.3.14.2 describes
>it as the 'encoded value of the key that will decrypt the data_block.'
>This describes it as a decryption key, not an encryption key.
>
>Finally, as I stated previously, I think it is not good that an entire
>18-page section does nothave a single example in it.
>
>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
>
>
>
>
>--------------000700040807050407090303--
Received on Tue Dec 21 08:45:58 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2004 - 08:45:59 PST