The Will Adams mantis is 1548. Looking more carefully, it seems that Stu simply used the 1800-2005 wording instead of the 1364-2005 wording. I personally think that the 1800-2005 wording is clearer. In V2K5, 5.1.13, the 'condition' is indeed a scalar, but 'expression1' is what appears in the code syntax. 'condition' is the result, internally computed, of "a logical equality comparison (see 4.1.8) of expression1 with zero". This 'expression1' is now called 'cond_predicate'. So the 'condition' is a scalar, but not 'expression1' nor 'cond_predicate'. Note that the syntax of cond_predicate in SystemVerilog is wider than in 1364-2005: cond_predicate ::= expression_or_cond_pattern { &&& expression_or_cond_pattern } expression_or_cond_pattern ::= expression | cond_pattern cond_pattern ::= expression matches pattern Regards, Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, August 16, 2007 6:22 PM To: Brad Pierce; sv-bc; sv-ac@server.eda-stds.org Subject: RE: [sv-bc] RE: [sv-ac] Mantis 1974: Definitions of true and false conditions Without looking carefully at it, I think Stu changed it deliberately, maybe because there was a problem with the V2K5 fix, namely that we got it reversed (I think Will Adams from Freescale pointed that out.) or because the description was unclear. Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce Sent: Thursday, August 16, 2007 6:13 PM To: sv-bc; sv-ac@server.eda-stds.org Subject: [sv-bc] RE: [sv-ac] Mantis 1974: Definitions of true and false conditions Shalom, Thanks, you're right that I was confused about the content of http://www.boyd.com/1364_btf/report/full_pr/403.html <http://www.boyd.com/1364_btf/report/full_pr/403.html> It resolved that "The evaluation of a conditional operator shall begin with a logical equality comparison (see 4.1.8) of expression1 with zero, termed the condition." See 5.1.13 of IEEE Std 1364-2005 -- in Verilog-2005, the condition is a scalar. So either Draft 3a has a merge problem in 11.4.12, because it does not preserve the fix from Verilog-2005, or there is some reason why an SV cond_predicate cannot participate in a logical equality comparison with zero. -- Brad ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Thursday, August 16, 2007 1:05 AM To: Brad Pierce; sv-bc Cc: sv-ac@eda-stds.org Subject: RE: [sv-ac] Mantis 1974: Definitions of true and false conditions Brad, I think you misunderstood me. 1364 issue 403 did not refer to how the first and second expressions are combined when the condition has an ambiguous value. The issue there, and the issue I have brought up now in two other places, is how to describe when the condition is true, when false, and when ambiguous. (It is true that in the conditional operator, the ambiguous result is distinguished from a false result, whereas in assertions and in if-else, an ambiguous result is treated the same as a false result.) This is only indirectly related to Mantis 1190. You wrote "The cond_predicate has a scalar type, and cannot usefully be considered bitwise." Actually it does not have a scalar type. If I write "a[1:0] ? 1'b1 : 1'b0" or "if (a[1:0])", the cond_predicate a[1:0] is still a two-bit vector. But it is treated as either true, false, or ambiguous. Now, what are true, false, and ambiguous? Draft 3a for the conditional operator does not define true and false and says that ambiguous is "x or z". 12.4 says that true is "a nonzero known value" and false is "0 or x or z". 16.3 says that false is "0 or x or z" and true is "otherwise". So how is 2'b1x to be considered? It is not completely known, nor completely unknown, nor completely x. However it is definitely non-zero. This is if any bit is definitely 1. As such, it is considered to be TRUE. The real condition for true is its non-zero-ness. If the condition is definitely non-zero, it is true. For if-else and assertions, it is otherwise false. For the conditional operator, if the condition value is definitely zero (all bits zeroes), then it is false. If it is not definitely zero, nor definitely non-zero (i.e., no bit is 1, not all are zero), then it is ambiguous. This is not what 12.4 and 16.3 say. 12.4 say that true requires a 'known' value. 2'b1x could be considered to not be a known value. I don't known whether the value is 2 or 3. Nevertheless, it is definitely non-zero and therefore should be considered true. 11.4.12 avoids this trap by not defining what true and false are, but still is not precise requiring the ambiguous result. Regards, Shalom ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Brad Pierce Sent: Wednesday, August 15, 2007 9:17 AM To: sv-bc Cc: sv-ac@server.eda-stds.org Subject: RE: [sv-ac] Mantis 1974: Definitions of true and false conditions Shalom, The fix for 1364 issue 403 became the following in 11.4.12 of Draft 3a -- "If cond_predicate is true, the operator returns the value of the first expression; if false, it returns the value of the second expression. If cond_predicate evaluates to an ambiguous value (x or z), then both the first expression and the second expression shall be evaluated, and their results shall be combined bit by bit using Table 11-22 to calculate the final result". The cond_predicate has a scalar type, and cannot usefully be considered bitwise. Instead, this paragraph is saying that, if the cond_predicate is ambiguous, then where the first and second expression agree about particular bits of the result, a non-x-pessimistic value is calculated for those bits. This is related to enhancement request <http://www.eda-stds.org/svdb/view.php?id=1190> http://www.eda-stds.org/svdb/view.php?id=1190 which was <http://www.boyd.com/1364_btf/report/full_pr/401.html> http://www.boyd.com/1364_btf/report/full_pr/401.html . -- Brad ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom Sent: Tuesday, August 14, 2007 9:54 PM To: sv-bc Cc: sv-ac@eda-stds.org Subject: [sv-ac] Mantis 1974: Definitions of true and false conditions Section 12.4 has the following definitions of 'true' and 'false' conditions: "If the cond_predicate expression evaluates to true (that is, has a nonzero known value), the first statement shall be executed. If it evaluates to false (that is, has a zero value or the value is x or z), the first statement shall not execute." These descriptions are incorrect. We corrected them for the conditional operator (?:) in 1364-2005, but missed this place. See old 1364 issue 403 ( <http://boyd.com/1364_btf/report/full_pr/403.html> http://boyd.com/1364_btf/report/full_pr/403.html). Section 16.3 (Immediate Assertions) has the same mistake: "The expression is nontemporal and is interpreted the same way as an expression in the condition of a procedural if statement. In other words, if the expression evaluates to X, Z, or 0, then it is interpreted as being false, and the assertion is said to fail. Otherwise, the expression is interpreted as being true, and the assertion is said to pass." The difference is where some of the bits are X/Z and some are 0/1. The value is known but also not completely unknown. The value is not quite X/Z, but not completely 0s and 1s. What is known is that if any of the bits is 1, then the value is definitely non-zero. In this case, the condition is true, even though the value is not quite known. On the other hand, if the known bits are all 0, then the condition is false, even though its value is not quite 0, X, or Z. This is Mantis 1974. Shalom 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 Thu Aug 16 08:40:40 2007
This archive was generated by hypermail 2.1.8 : Thu Aug 16 2007 - 08:41:01 PDT