Re: [sv-bc] Wrong example in protected envelope

From: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Date: Fri Jan 22 2010 - 00:01:38 PST
OK,
I have filed a Mantis 2948 for tracking the issue.
Regards
Surya


-------- Original Message  --------
Subject: Re:[sv-bc] Wrong example in protected envelope
From: Shields, John <John_Shields@mentor.com>
To: Steven J. Dovich <dovich@cadence.com>, sv-bc@eda.org, ip-encrypt@eda.org
Cc: "Lutz, Roger" <RogerL@Model.com>, "Bresticker, Shalom" <shalom.bresticker@intel.com>, "Surya Pratik Saha" <spsaha@cal.interrasystems.com>, "Sourasis Das" <sourasis@cal.interrasystems.com>
Date: Friday, January 22, 2010 12:59:05 AM
Hi All,
 
We have also looked at this.  There is a reason the multiline version is illegal and the other can be handled.  It has to do with the conflicting sequencing requirement that defines the start of the content of data block, which is immediately after the data block pragma.  The SV LRM is problematic in its specification, yet has great desire to allow all the possible shorthand expression of information possible.  P1735 can clarify this, but I really think the encryption portion of the SV LRM needs a serious rewrite for clarity.
 
Regards, John


From: owner-ip-encrypt@eda.org [mailto:owner-ip-encrypt@eda.org] On Behalf Of Steven J. Dovich
Sent: Thursday, January 21, 2010 11:20 AM
To: sv-bc@eda.org; ip-encrypt@eda.org
Cc: Lutz, Roger; Bresticker, Shalom; Surya Pratik Saha; Sourasis Das
Subject: Re: [sv-bc] Wrong example in protected envelope

I would like to refer this issue to P1735 for a recommendation. Syntax consistency with VHDL also needs to be addressed if changes are made and that is best handled from P1735.

/sjd


On 1/21/2010 2:09 PM, Roger Lutz - MTI wrote:
If the LRM example is missing a comma, where:
`pragma protect data_block encoding=(enctype="raw", bytes=190)

becomes:
`pragma protect data_block, encoding=(enctype="raw", bytes=190)

then this should be the same as saying:
`pragma protect data_block
`pragma protect encoding=(enctype="raw", bytes=190)

which is illegal.  I am basing this on the Overview section (sec. 34.2), where it states
that "Interpretation of protected envelopes shall not be altered based on whether the
sequence of pragma expressions occurs in a single protect pragma directive or in a
sequence of protect pragma directives.".

Shouldn't the example look like:
`pragma protect encoding=(enctype="raw", bytes=190), data_block

Regards,
Roger

Bresticker, Shalom wrote:
I agree, though I would say that the tool is lenient and not necessarily that it is a bug.
 
In addition:
 
1. In Syntax 22-8, in the first production:

pragma ::=
   
`pragma pragma_name [ pragma_expression { , pragma_expression } ]

the curly brackets should not be red.
 
 
2. Also in 34.3.1, in the following lines:

`pragma protect encoding=(enctype="raw")
`pragma protect data_method="x-caesar", data_keyname="rot13", begin


"enctype" and "data_keyname" should be bold.
 
Thanks,
Shalom

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surya Pratik Saha
Sent: Thursday, January 21, 2010 6:28 AM
To: sv-bc@eda.org
Cc: Sourasis Das
Subject: [sv-bc] Wrong example in protected envelope

Hi,
In SV 2009 LRM, there is an example in "section 34.3.1 Encryption"

`pragma protect data_block encoding=(enctype="raw", bytes=190)

Please note, a comma ',' is missing in between 'data_block' and 'encloding' keyword. But as per the BNF stated in "22.11 `pragma", the comma ',' is must. One standard tool passes the case though. Can we assume that is a bug in the tool and LRM needs a correction here. Please clarify, if required I can then file a Mantis.
-- 
Regards
Surya
    

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
  

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri Jan 22 00:02:42 2010

This archive was generated by hypermail 2.1.8 : Fri Jan 22 2010 - 00:02:55 PST