Re: [sv-ac] FW: Possible SV 3.1a LRM error?

From: <vhdlcohen_at_.....>
Date: Sat Sep 10 2005 - 14:55:47 PDT
Ed,
You mistyped the closing parenthesis at the end x=0.   SHould be:
(`true, x = 0) ##0
(!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);

BTW, this whole page has several errors, now that I look at it more 
carefully,  below is the WAS, and then the SHOULD BE:
I alternated the parentheses within a sequence and an expression.
----------------------------------------------
WAS  (current LRM)
sequence data_check;
int x;
a ##1 !a, x = data_in ##1 !b[*0:$] ##1 b && (data_out == x);
endsequence
property data_check_p
int x;
a ##1 !a, x = data_in |=> !b[*0:$] ##1 b && (data_out == x);
endproperty

sequence rep_v;
int x;
?true,x = 0 ##0
(!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);
endsequence

sequence sub_seq1;
int v1;
a ##1 !a, v1 = data_in ##1 !b[*0:$] ##1 b && (data_out == v1);
endsequence
sequence seq1;

sequence sub_seq3(lv);
int lv; // illegal since lv is a formal argument
a ##1 !a, lv = data_in ##1 !b[*0:$] ##1 b && (data_out == lv);
endsequence
---------------------------------
SHOULD BE (NEEDS UPDATE)

sequence data_check;
int x;
(a ##1 !a, x = data_in) ##1 !b[*0:$] ##1 b && (data_out == x);
endsequence

property data_check_p
int x;
a ##1 (!a, x = data_in) |=> !b[*0:$] ##1 b && (data_out == x);
endproperty

sequence rep_v;
int x;
(?true,x = 0) ##0
(!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);
endsequence

sequence sub_seq1;
int v1;
a ##1 (!a, v1 = data_in) ##1 !b[*0:$] ##1 b && (data_out == v1);
endsequence
sequence seq1;

sequence sub_seq3(lv);
int lv; // illegal since lv is a formal argument
(a ##1 !a, lv = data_in) ##1 !b[*0:$] ##1 b && (data_out == lv);
endsequence




Ben

-----Original Message-----
From: Eduard Cerny <Eduard.Cerny@synopsys.com>
To: vhdlcohen@aol.com; Eduard.Cerny@synopsys.COM; 
stuart@sutherland-hdl.com; sv-ac@eda.org
Cc: Susan.Sien@synopsys.COM
Sent: Sat, 10 Sep 2005 14:34:54 -0700
Subject: RE: [sv-ac] FW: Possible SV 3.1a LRM error?

  Ben,
I guess I missed that one. Can Stu make the (simple) correction?
(`true, x = 0, ##0
(!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);

Thanks,
ed


> -----Original Message-----
> From: vhdlcohen@aol.com [mailto:vhdlcohen@aol.com]
> Sent: Saturday, September 10, 2005 1:39 PM
> To: Eduard.Cerny@synopsys.COM; stuart@sutherland-hdl.com;
> sv-ac@eda.org
> Cc: Susan.Sien@synopsys.COM
> Subject: Re: [sv-ac] FW: Possible SV 3.1a LRM error?
>
>
> Ed,
> The example on page 225 shows:
> sequence rep_v;
> int x;
> ?true,x = 0 ##0
> (!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);
> endsequence
>
> The "?true,x = 0" is missing the parentheses. Thus, the The
> examples do
> NOT conform
> to the requirement for the assignment to loval variables.
> Ben
>
>
> -----Original Message-----
> From: Eduard Cerny <Eduard.Cerny@synopsys.com>
> To: vhdlcohen@aol.com; stuart@sutherland-hdl.com; sv-ac@eda.org
> Cc: Susan Sien <Susan.Sien@synopsys.com>
> Sent: Sat, 10 Sep 2005 08:44:25 -0700
> Subject: RE: [sv-ac] FW: Possible SV 3.1a LRM error?
>
>    Hi,
>
> It seems to me that perhaps the sentence is not too clear about where
> the parentheses should be. If I look at version P1800 Draft 6, the
> syntax is:
>
> sequence_expr ::=
> ...
> | ( expression_or_dist {, sequence_match_item } ) [ boolean_abbrev ]
> | ( sequence_expr {, sequence_match_item} ) [ sequence_abbrev ]
> ...
> sequence_match_item ::=
> operator_assignment
> | inc_or_dec_expression
> | subroutine_call
>
> There, sequence_expr does not require parentheses, but what
> is required
> are the parentheses over the entire combination. The examples
> do conform
> to that as far as I can tell.
>
> Best regards,
>
> ed
>
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of vhdlcohen@aol.com
> > Sent: Friday, September 09, 2005 1:38 PM
> > To: stuart@sutherland-hdl.com; sv-ac@eda.org
> > Subject: Re: [sv-ac] FW: Possible SV 3.1a LRM error?
> >
> > Susan and Stuart,
> > Yes, some of the examples are in error.  Below is what I got with
> > QuestaSim:
> > module temp;
> > `define true 1
> > logic a, b, c;
> > int data_out, data;
> >
> > sequence rep_v;
> > int x;
> > // `true, x = 0 ##0  // compilation error
> > (`true, x = 0) ##0  // OK
> > (!a [* 0:$] ##1 a, x = x+data)[*4] ##1 b ##1 c && (data_out == x);
> > endsequence
> >
> > endmodule : temp
> > The "  `true, x = 0 ##0  " is in error per LRM since there are no
> > parentheses
> > --------------------------------------------------------------
> > -----------
> > -
> > Ben Cohen Trainer, Consultant, Publisher (310) 721-4830
> > http://www.vhdlcohen.com/  ben_ f rom _abv-sva.org
> > * Co-Author: SystemVerilog Assertions Handbook, 2005 ISBN
> > 0-9705394-7-9
> > * Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd
> > Edition, 2004, ISBN 0-9705394-6-0
> > * Real Chip Design and Verification Using Verilog and VHDL,
> 2002 isbn
> > 0-9705394-2-8
> > * Component Design by Example ", 2001 isbn 0-9705394-0-1
> > * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
> > 0-7923-8474-1
> > * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
> > 0-7923-8115
> > --------------------------------------------------------------
> > -----------
> > --------
> >
> > -----Original Message-----
> > From: Stuart Sutherland <stuart@sutherland-hdl.com>
> > To: sv-ac@eda.org
> > Sent: Fri, 9 Sep 2005 08:38:54 -0700
> > Subject: [sv-ac] FW: Possible SV 3.1a LRM error?
> >
> >
> > AC committee,
> >
> > I received the following message regarding a possible error
> > in some SVA
> > examples in the LRM.  Can someone on the AC committee please let me
> > know if
> > this is an error?  If so, then the AC committee should keep track of
> > this so
> > that it can be fixed at some point in time.
> >
> > Stu
> > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > Stuart Sutherland
> > stuart@sutherland-hdl.com
> > +1-503-692-0898
> >
>
>
>

   
Received on Sat Sep 10 14:56:01 2005

This archive was generated by hypermail 2.1.8 : Sat Sep 10 2005 - 14:56:26 PDT