RE: [sv-bc] Stu's QUESTIONS in Draft 3a

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Tue Aug 07 2007 - 08:59:26 PDT
Then the following should yield false, because (1'b1 + 1'b1) != 0 ?
 
     (1'b1 + 1'b1) inside { [ 1'b1 + 1'b1 : 1'b1 + 1'b1 ] }
 
Or do you mean that the left operand should also be evaluated in a
self-determined context and then the result converted to longint?  This
might (or might not) yield unexpected results when the elements in the
right operand are wildcard expressions, such as 4'b0??1.
 
The idea of evaluating in a self-determined context and converting the
result to longint seems un-SystemVerilogish to me.  Recall that in
SystemVerilog
 
            longint'(1'b1 + 1'b1) == 2
 
because the expression to be cast is evaluated in the context of an
assignment to a longint -- it is not evaluated in a self-determined
context and then the result converted to longint.
 
-- Brad

________________________________

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, August 06, 2007 11:47 PM
To: Brad Pierce; sv-bc
Subject: RE: [sv-bc] Stu's QUESTIONS in Draft 3a


I would say that each expression is evaluated in a self-determined
manner and then converted to an int or longint. I agree it does not say
that currently. But it does not say anything else either.
 
Shalom


________________________________

	From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
	Sent: Tuesday, August 07, 2007 9:34 AM
	To: sv-bc
	Subject: RE: [sv-bc] Stu's QUESTIONS in Draft 3a
	
	
	According to 11.4.14, "If the bound to the left of the colon is
greater than the bound to the right, the range is empty and contains no
values."
	 
	Recall that in Verilog, -3 > 3'b100, so the following range is
empty and contains no values 
	 
	                 [ -3 : 3'b100 ]
	 
	Yet according to your interpretation the following yields true
	 
	                      0 inside { [ -3 : 3'b100 ] }
	because (-3 <= 0) & (0 <= 3'b100).
	Likewise, in Verilog 3'b100 < -3, so the following range is
non-empty 
	 
	           [ 3'b100 : -3]
	 
	Yet according to your interpretation the following yields false
	 
	          0 inside { [ 3'b100 : -3] }
	 
	both because (0 < 3'b100) and because (-3 < 0).
	-- Brad

________________________________

	From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
	Sent: Monday, August 06, 2007 11:16 PM
	To: Brad Pierce; sv-bc
	Subject: RE: [sv-bc] Stu's QUESTIONS in Draft 3a
	
	
	In all those cases, the 1'b1's are extended to 2 bits because of
the 2'b00.
	In the first and third case, they are found in the same
expression.
	In the second case, the LRM explicitly says that all the
expression are extended to the size of the widest one.
	 
	None of that holds for the 'inside' operator. 'inside' has
ranges. 'inside' can take an aggregate array in the list. 'inside' can
take $ as a range bound.
	 
	A counter-case could be that of array index declarations and
part-selects, where the msb and lsb are independent of each other.
	 
	I do agree that it needs to be defined.
	 
	In particular, ranges and $ can appear in additional contexts.
	 
	Shalom
	
	

________________________________

		From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
		Sent: Tuesday, August 07, 2007 8:41 AM
		To: sv-bc
		Subject: Re: [sv-bc] Stu's QUESTIONS in Draft 3a
		
		
		That interpretation is inconsistent with the rest of the
Verilog language.
		 
		For example,
		 
		           module test;
		           initial begin
		              if (2'b00 < 1'b1 + 1'b1)
		                 $display("OK"); else $display("error");
		              case (1'b1)
		                  2'b00 : $display("error");
		                  (1'b1 + 1'b1) >> 1 : $display("OK");
		                  default: $display("error");
		              endcase
		              if ( (2'sb01 << 999 >>> 999) ==
$signed({1000{1'b1}}))
		                $display("OK"); else $display("error");
		          end
		          endmodule
		
		-- Brad

________________________________

		From: Bresticker, Shalom
[mailto:shalom.bresticker@intel.com] 
		Sent: Monday, August 06, 2007 10:07 PM
		To: Brad Pierce; sv-bc
		Subject: RE: [sv-bc] Stu's QUESTIONS in Draft 3a
		
		
		I tried your case on two simulators that claim to
support 'inside'.
		Both returned 0.
		I also think the result should be false. I think
1'b1+1'b1=1'b0 and is not influenced by 2'b00.
		See the related Mantis 1302, as you probably remember. 
		You should add this test case to that Mantis.
		 
		Shalom
		

________________________________

			From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
			Sent: Tuesday, August 07, 2007 3:21 AM
			To: sv-bc
			Subject: RE: [sv-bc] Stu's QUESTIONS in Draft 3a
			
			
			I meant
			 
			    1'b1 inside { [2'b00 : 1'b1 + 1'b1] }
			 
			(My previous e-mail omitted the curly brackets,
hence was a syntax error.)
			 
			-- Brad

________________________________

			From: owner-sv-bc@eda.org
[mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce
			Sent: Monday, August 06, 2007 5:12 PM
			To: sv-bc
			Subject: Re: [sv-bc] Stu's QUESTIONS in Draft 3a
			
			
			Also, an important Editor Note on Table 11-23 is
that "SV operators need to be added to this table."   For example, does
the following yield true or false?
			 
			    1'b1 inside [2'b00 : 1'b1 + 1'b1]
			 
			In my opinion, it yields true.
			 
			-- Brad
			 
			 
			 

________________________________

			From: owner-sv-bc@eda.org
[mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
			Sent: Monday, August 06, 2007 9:32 AM
			To: sv-bc
			Subject: [sv-bc] Stu's QUESTIONS in Draft 3a
			
			

			3.12: Should "step" be added to this table? (per
A.8.4) 

			3.12.1: The term "time scaling" is not defined
in 1364-2005 or 1800-2005. Does it need to be? 

			8.2: "A common convention is to capitalize the
first letter of the class name so that it is easy to recognize class
declarations." Should this LRM follow this convention? 

			10.6.1: Does the result of a cont. assign to a
variable update immediately when the variable is released? 

			10.6.1: What about unpacked stucts, enums,
classes, etc.? 

			10.6.2: What about unpacked stucts, enums,
classes, etc. 

			11.2.1: Are all operators listed in table 11-1
after merging in SV still legal in constant expressions? 

			11.5.2: This text comes directly from 1364-2005.
There was no matching subclause from 1800-2005 to merge in. Is new text
needed for SV array addressing ?.

			13.4.4: Also interface and program? 

			14.3: "step" is not defined at this cross
reference. Is it missing from there, or is the cross reference wrong? 

			19.5: should $signed/$unsigned be moved to Annex
D since SV has sign casting? 

			20.3.1: Is string type legal? 

			20.3.7: Is string type legal? 

			21.4: What is this "unchanged behavior"? I could
not find it in 1364. 

			22.3.1: Is this last sentence still true in SV
(i.e. can it be one interface or one program)? 

			22.3.3.3: Is 'z correct for all net type (e.g.
tri1)? 

			28.3.2: Can "logic" also be used? 

			30.6: Can the notifier be any variable type (per
the BNF) or are only 1-bit types allowed? 

			31.9: Is string type legal? 

			32.7: Are there any changes to this subclause to
support SV design blocks? 

			34.10: This subclause seems to be mostly, if not
entirely, redundant with the rest of this Clause. Can this subclause be
deleted? If not, can the redundant text be replaced with cross
references?

			34.10: Should this be "DPI-C"? (twice) 

			40.7: Should this subclause be merged into
Clause 36? 

			40.12: Should this subclause be merged into
Clause 37? 

			D.2: does "vector" need to be changed to allow
for a single bit of a multidimensional packed array? 

			D.12: does "vector" need to be changed to allow
for other SV types? 

			D.13: can the SV string type also be used? 

			I.9.1.3: should this be changed to "P1800-2008"?


			I.12: Should this deprecated subclause be moved
to, or referenced in, Annex C? 

			Shalom Bresticker 
			Intel Jerusalem LAD DA 
			+972 2 589-6852 
			+972 54 721-1033 


			-- 
			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
<http://www.mailscanner.info/> MailScanner, 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 <http://www.mailscanner.info/>
MailScanner, 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.
Received on Tue Aug 7 10:22:03 2007

This archive was generated by hypermail 2.1.8 : Tue Aug 07 2007 - 10:22:28 PDT