>In Verilog, function arguments are not self-determined, they are determined in the context of an assignment to the corresponding formal. Exactly - I meant that argument are not determined in context where function is called but in the context of corresponding formals. >But why do you think the following behavior is like a Verilog function? HM this is how I interpret the sentence:), I just have no doubts - I've assumed that casting is kind of function. Maybe you are right it isn't clearly defined in the text. DANiel _____ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce Sent: Wednesday, January 30, 2008 5:09 PM To: sv-bc Subject: RE: [sv-bc] sign/width casting semantics Daniel, In Verilog, function arguments are not self-determined, they are determined in the context of an assignment to the corresponding formal. But why do you think the following behavior is like a Verilog function? "When changing the size, the signing shall pass through unchanged and the result type shall be a one-dimensional packed array with a right bound of zero. When changing the signing, the type of the expression to be cast shall pass through unchanged, except for the signing." -- Brad _____ From: danielm [mailto:danielm@aldec.com.pl] Sent: Wednesday, January 30, 2008 8:02 AM To: 'Bresticker, Shalom'; 'Brad Pierce'; 'sv-bc' Subject: RE: [sv-bc] sign/width casting semantics IMHO current wording is ok. Function arguments are self determined so Greg interpretation is simply wrong because casting is kind of function. Lets take a look into example (u is an unsigned var, while s1,s2 are signed variables): u + 8'(s1+s2) To get result we should perform operation : 1.signed extension of s1, s2 to max s1,s2 size 2.perform addition 3.change s1+s2 result size to 8 bits - it remains signed 4.perform u and s1+s2 result unsigned extension to max size of u and s1+s2 result 5.perform addition u + s1+s2. Same for yours case regS = signed'(4'b1100); we shouldn't perform extension on 4'b1100 because it is a cast func argument we should perform extension on result returned by signed' function : 4'sb1100 This is how I interpret this isssue. DANiel _____ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Wednesday, January 30, 2008 4:33 PM To: Brad Pierce; sv-bc Subject: RE: [sv-bc] sign/width casting semantics Brad, I would agree with 1. For 2, I think it should have the same signedness as that of the cast operand. Shalom _____ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce Sent: Wednesday, January 30, 2008 5:30 PM To: sv-bc Subject: RE: [sv-bc] sign/width casting semantics Shalom, I would prefer to remove the current weird text and simply say that 1) signed'() and unsigned'() are new syntax for $signed() and $unsigned() 2) the value of a width cast is the same as the result of an assignment to an unsigned bit or logic variable of that same width, depending on whether the expression to be cast is purely 2-bit. Yes, that breaks backward compatibility with the LRM, but tools are already in divergence, because the LRM is so confusing. The more obvious the semantics, the better. -- Brad _____ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom Sent: Wednesday, January 30, 2008 5:47 AM To: sv-bc Subject: [sv-bc] sign/width casting semantics Hi, There is unclearness about the semantics of sign casting and width casting. For casting to a full type, the semantics are clear: "If the expression is assignment compatible with the casting type, then the cast shall return the value that a variable of the casting type would hold after being assigned the expression." However, how do sign casting and width casting work? The LRM says, "When changing the size, the signing shall pass through unchanged and the result type shall be a one-dimensional packed array with a right bound of zero. When changing the signing, the type of the expression to be cast shall pass through unchanged, except for the signing." Let's take an example: logic signed [7:0] regS; regS = signed'(4'b1100); My understanding is that "signed'(4'b1100)" turns into 4'sb1100, which is then sign-extended to the width of regS, giving 8'sb11111100. This means it works the same as $signed(). However, some people (e.g., Greg Jaxon) say that the context-determined width of the entire expression, 8 bits, is propagated into the cast operand, while the sign cast determines the signedness of the size-extended expression, giving 8'sb00001100, giving a different result from $signed(). Look at 11.7, which contains these examples: logic signed [7:0] regS; regS = $signed (4'b1100); // regS = -4 regS = signed'(4'b1100); // regS = -4 The $signed() example comes from 1364-2005. The signed'() example was added by the editor during the LRM merge. He assumed it is identical to $signed(). Is this correct? Another example, from the $clog2() discussion recently: Greg wrote (slightly edited), (expr) | signed'(1'b1) ... Note that 1'sb1 would be sign-extended to match width (bad!), whereas signed'(1'b1) will 0-extend the literal before cloaking it with signedness (so as to not poison expr with unsignedness). and I disagree with Greg. The question about width casting is similar. Is the expression inside the width-cast affected by the signedness of the surrounding expression before changing its width (e.g., changing it from signed to unsigned, causing zero-extension instead of sign-extension)? The committee needs to decide on the correct semantics and clarify them in the LRM. Tools are divergent on this already. Some relevant links: <http://www.eda-stds.org/sv-bc/hm/1346.html> http://www.eda-stds.org/sv-bc/hm/1346.html <http://www.eda-stds.org/sv-bc/hm/1714.html> http://www.eda-stds.org/sv-bc/hm/1714.html <http://www.eda.org/sv-bc/display_issue.cgi?issue_num=38> http://www.eda.org/sv-bc/display_issue.cgi?issue_num=38 <http://www.eda-stds.org/sv-bc/hm/1777.html> http://www.eda-stds.org/sv-bc/hm/1777.html <http://www.eda-stds.org/sv-bc/hm/1780.html> http://www.eda-stds.org/sv-bc/hm/1780.html <http://www.eda-stds.org/sv-bc/hm/1790.html> http://www.eda-stds.org/sv-bc/hm/1790.html <http://www.eda-stds.org/sv-bc/hm/1794.html> http://www.eda-stds.org/sv-bc/hm/1794.html <http://www.eda-stds.org/sv-bc/hm/1796.html> http://www.eda-stds.org/sv-bc/hm/1796.html <http://www.eda-stds.org/sv-bc/hm/1800.html> http://www.eda-stds.org/sv-bc/hm/1800.html Thanks, Shalom Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6582 +972 54 721-1033 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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 <http://www.mailscanner.info/> MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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 <http://www.mailscanner.info/> MailScanner, 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 Wed Jan 30 08:24:59 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 30 2008 - 08:25:15 PST