RE: [sv-bc] RE: [sv-ec] query on evaluation of typecast expression

Ad 1.Changing the sample will help for sure. Should a mantis be filled on
that change, or will be changed with anywas.

Ad2. As per change the wording  change as you proposed "in the context of an
assignment to an implied temporary of the casting type"  - i think that this
one is better.

DANiel

-----Original Message-----
From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com] 
Sent: Thursday, May 15, 2008 8:46 PM
To: Daniel Mlynek
Cc: 'Bresticker, Shalom'; 'Sumay Guin'; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] RE: [sv-ec] query on evaluation of typecast expression

Daniel Mlynek wrote:
> IMHO the test in 2269 still leaves a bit ambiguity when analysing the 
> code sned byt Sumay.
> 
> 1st the example would be better if it explicitly shows the expression 
> instead of using expr_1, expr_2
> 
> A = cast_t1'(a+b) + cast_t2'(c+d);
> 
> is the same as
> 
> cast_t1 temp1;
> cast_t2 temp2;
> 
> temp1 = a+b;
> temp2 = c+d;
> A = temp1 + temp2;

OK

> 2. The sentence :"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."
> does not describes the nature of casting - it should state that the 
> expression inside casting is determined by casting operator, not by 
> whole expression.
> (the other possibilites which user may consider are: fully context 
> determined or self-determined - both interpretation are wrong AFAIK )

Agreed - both alternatives are inaccurate.  This was why the "assignment
fidelity" approach was taken.  As to whether this sentence captures
casting's nature, I can't say.  I suppose we could be more operational and
talk about the operand of an explicit cast being evaluated "in the context
of an assignment to an implied temporary of the casting type".  Would that
help?

> 3. It would be nice to have all new SV operators including cast 
> operator summarized in table describing rules for bit length 
> (self-context
> determined) 1364-2005 Table 5-22-Bit lengths resulting from 
> self-determined expressions
> 
> 
> 4. similarly for size casting : 
> "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 the cast shall return the value that a packed array type 
> with a single [n-1:0] dimension would hold after being assigned the 
> expression, where n is the cast size. The signedness shall pass 
> through unchanged, i.e., the signedness of the result shall be the 
> self-determined signedness of the expression inside the cast. The 
> array elements shall be of type bit if the expression inside the cast 
> is 2-state, otherwise they shall be of type logic."
> 
> There should be said that size of expr inside size case is determined 
> by size cast operator, the sing of variable returned by size cast 
> operator is the same as sign of the underlaying expression.
> 
> Sumay sample for size cast:
> 
>        module top;
> 	   reg [7:0] out1;
> 	   reg [7:0] out2;
>        reg [3:0]in1,in2;
> 	   reg signed [3:0]sin1,sin2;
> 		
>        initial
>        begin
>        in2 = 4'b0101 ;
>        in1 = 4'b1100 ;
> 	   sin2 = 4'b0101 ;
>        sin1 = 4'b1100 ;
> 	   out1 = 8'(in2 -in1);	   //11111001  ?
> 	   out2 = 8'(sin2 -sin1);  //00001001 ?
> 	   $display( "%b",out1);
> 	   $display( "%b",out2);	   
>        end
>       endmodule
> 
> 5.The sign cast operand are  just selfdetermined, and the sign of 
> returned value depends on the sign cast.
> 
> 
> 
> DANiel
> 
> 
> 
> PS: Is it true that finily IEEE is going to merge both 1364 (verilog) 
> and 1800 (system verilog) in single document (to close the chapter 
> called 1364 verilog forever)

This is the great work in progress, now in draft 5...


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.