RE: [sv-bc] sign/width casting semantics

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Wed Jan 30 2008 - 08:08:48 PST
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 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. 

---------------------------------------------------------------------
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 MailScanner, and is
believed to be clean.
Received on Wed Jan 30 08:10:48 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 30 2008 - 08:11:29 PST