Hi, My name has become associated with a very peculiar idea about signedness casting that isn't my idea, but which I have tried to articulate clearly and implement faithfully because it appears to be what is required by http://www.eda.org/sv-bc/display_issue.cgi?issue_num=38 To bring a consistent principle to the discussion, I coined the term "assignment fidelity" to describe this definition for casting. It is a clear case of Stockholm Syndrome at work, though, because my first principles of language design are to reject context-sensitivity where self-determinedness would work as well. However, I had to start with the given: assignment fidelity is the current approved standard for casts of the form _type'()_ . Disagreement seems to center on the partial casts - signedness mostly. When the committee confronted this disagreement they found that $signed() implemented the most commonly sought alternative to assignment-fidelity signed'(). This was why the committee (at least in discussions) encouraged $signed() and signed'() to diverge - have it both ways! There are other possible treatments for signed'(). But a significant complication is that C defines casting to a signed type very differently than Verilog. C attempts to preserve the arithmetic value of the operand, and so always does extensions using the signedness of the operand. As you know Verilog does not define signedness change in this way. HOWEVER, the unusual way that assignment propagates LHS size, but not signedness (known to IEEE-1364 as "type") /has a corrective effect/: at the level of assignment, a cast of signed RHS to a wider unsigned LHS causes sign extension of the (unanimously) signed operands of the RHS. But when Verilog signed operands are used in a wider _unsigned_context_, they 0-extend. So one alternative is to _not_call_it_casting_. As defined, signed'() acts primarily as a /barrier/ to the upward propagation of unsigned type which otherwise poisons a signed outer context. This subtle effect is its only defining characteristic, so calling it _signedness_firewall_ would invite less confusion. Another alternative would be to make the signedness of the "cast" propagate downward into the operand either overriding any self-determined signedness, or more consistent with Verilog being considered as just another operand signedness - with any unsigned operand getting veto power. Neither of these mimics assignment semantics, but since those are poorly understood in practice maybe this is not so important. A final alternative would be to make signed'() and unsigned'() be exceptions to the rule that the operand of cast is context-determined. Suppose they are self-determined. The question then would be how the result of signed'() behaves in a wider unsigned context - would it 0-extend as does the result of $signed(), or would we make a further exception to say it sign-extends as C would do? If the answer is that signed'() and unsigned'() are synonymous with $signed() and $unsigned(), I think removal of the syntax is probably the wisest choice. But then I'd want to know why anyone motivated by the love of functional language notations would dislike the idea of adding "signedness firewall" semantics to a language plagued by a bad context-determinedness infection. If one of your operands is an unsigned port, why should your signed data path have to be broken up into an assignment to a signed temporary? This is the whole concept behind signedness_firewall. I wish I'd coined that term earlier, it might have saved us this discussion. Greg Jaxon P.S. The above opinions are mine personally and do not represent views or product commitments of my employer. danielm wrote: >>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/1714.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.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/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/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/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/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/1796.html__ > > <http://www.eda-stds.org/sv-bc/hm/1800.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 *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* > <http://www.mailscanner.info/>*, 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 *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* > <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 Wed Jan 30 10:32:08 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 30 2008 - 10:32:35 PST