[sv-bc] RE: [sv-ac] Precedence between sequence operator and property operator

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Wed Nov 25 2009 - 13:14:44 PST
<forwarding bounced email from John Havlicek>

-------- Original Message --------
Subject: RE: [sv-ac] Precedence between sequence operator and property operator
Date: Wed, 25 Nov 2009 06:14:24 -0700
From: "Havlicek John-R8AAAU" <r8aaau@freescale.com>
To: "Surya Pratik Saha" <spsaha@cal.interrasystems.com>,
         <sv-bc@server.eda.org>, "sv-ac@server.eda.org" <sv-ac@server.eda.org>
Cc: "Adhip Das" <adhip@cal.interrasystems.com>


Hi Surya:

My opinion is that your example should parse as

    (not c) |-> e

and then fail compilation.  My rationale is the operator precedence that
you cite.

The tools may be favoring not(c |-> e) because it is the only legal
interpretation of the example.  They may have switches to enforce more
severe parsing and compilation criteria.

J.H.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Surya Pratik Saha
Sent: Wednesday, November 25, 2009 6:21 AM
To: sv-bc@eda.org; sv-ac@server.eda.org
Cc: Adhip Das
Subject: [sv-ac] Precedence between sequence operator and property
operator

Hi,
Please consider the following case:
module m1(input clk,e,c);
     assert property (@(posedge clk) not c |-> e); endmodule

Should it be parsed as ((not c) |->e) and give an error as (not c) is a
property expression which is not allowed in LHS of |->, or should it be
parsed as (not (c |->e))?

I have seen Table 16-3 (SV 2009 draft 7a) where precedence of property
and sequence operators are given. So according to that it should be
parsed as ((not c) |->e) as 'not' has higher precedence than |->. But
some standard simulators pass the case. So I want to understand is it a
bug in those tools or I misunderstood something.

-- 
Regards
Surya



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Nov 25 13:15:47 2009

This archive was generated by hypermail 2.1.8 : Wed Nov 25 2009 - 13:17:41 PST