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 MailScanner, and is
believed to be clean.