Re: [sv-ec] streaming operator - target cast

It looks as though I'm in the dock here...

> module streaming; 
>   shortint j; 
>   longint str_rev, str; 
> 
>  initial begin 
>     j = 16'b1010_0011_1100_0101 ; 
>     str_rev = { << {j}}; 
>     str = { >> {j}}; 
>     $displayb(str_rev);
>     $displayb(str);
>   end 
> 
> endmodule
> 
> I expect this to display
> 
> 1010001111000101000000000000000000000000000000000000000000000000
> 1010001111000101000000000000000000000000000000000000000000000000

I think I agree with you, but I have never really understood why
the streaming-concat operators are unique in Verilog in that they
left-align their result in a target.

> But other implementations disagree

It's hard to find a non-trivial example of {<<{}} that works
the same in any two simulators.  I tried to get consensus on
this when we did Mantis 1707 (around June 2007) but failed.
Implementations disagreed then, and it seems they still do.


> P1800-2009/D8 says:
> 
>   If the target is a data object of bit-stream type, the stream 
>   created by the source streaming_concatenation shall be implicitly 
>   cast to the type of the target.
> 
> I take "the stream created by the source streaming_concatenation" to
> mean that the implicit cast is applied last. 
>
> This could have been stated more explicitly.

Indeed so.  Sorry :-(

My recollection is that the phrase about implicit casting was 
added because we all agreed that the streaming_concatenation 
itself does not have a proper data type, but we needed to make
the assignment legal.  But it's clear that the text is inconsistent,
because casting a 16-bit stream into a 64-bit target would 
right-align it, whereas the next few sentences clearly indicate
that it should be left-aligned.  With hindsight, I guess, we should
have said that the streaming_concatenation must be either the 
source or the target in an assignment-like context; this might
have avoided the need to talk about implicit casting.

Given the wide range of possibilities - for example, the target
might be a fixed-size or variable-sized unpacked array - it's 
hard to get this right.  It would be very good if we could at
least reach informal consensus, even if we can't now change
the proposed LRM text.

Thanks
-- 
Jonathan Bromley



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