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

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
<http://www.mailscanner.info/> , 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
<http://www.mailscanner.info/> , and is
                believed to be clean.

        --
        This message has been scanned for viruses and
        dangerous content by MailScanner <http://www.mailscanner.info/>
, and is
        believed to be clean.

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.