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 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 Mon Aug 6 23:16:37 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 06 2007 - 23:16:48 PDT