RE: [sv-bc] streaming operator unpack doubt

From: Steven Sharp <sharp@cadence.com>
Date: Thu Feb 10 2011 - 16:50:40 PST

Actually, I think he meant "reg [3:1] c", since he is talking about the truncation case, and his suggested results are 3 bits wide.

The LRM specifies that the most significant bits are taken. But when the streaming operator specifies some kind of reordering of the stream, are those the most significant bits of the source expression before reordering, or after? That is his question.

________________________________
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Arturo Salz
Sent: Thursday, February 10, 2011 3:20 PM
To: Daniel Mlynek; sv-bc@eda.org
Subject: RE: [sv-bc] streaming operator unpack doubt

Daniel,

I assume in you meant "reg [5:1] c;" in your code snippet.

The sentence following the one you quoted in the LRM states: However, if more bits are needed than are provided by the source expression, an error shall be generated.

An the example that follows reinforces the concept:

{>>{ a, b, c }} = 23'b1; // error: too few bits in stream

Hence, in your example, an error should be generated.

                Arturo

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek
Sent: Thursday, February 10, 2011 4:59 AM
To: sv-bc@eda.org
Subject: [sv-bc] streaming operator unpack doubt

What should be the results of streaming operator unpack if there is more than we need bits on RHS
LRM:
'If the source expression contains more bits than are needed, the appropriate number of bits shall be consumed from its left (most significant) end."
But does LRM mean that we need to take appropriate number of bits from source expression or from reordered stream.
So attached example should print:
1z0
0z1
or
1z0
x0z
Example
module top;
reg [4:1] b1;
reg [5:1] d;
initial
begin
    #1 b1='b1z0x;
      {>>{c}} =b1; $display("c=%b ",c);
    #1 b1='b1z0x;
      {<<{c}} =b1; $display("c=%b ",c);
end
endmodule

DANiel

--
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<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 Thu Feb 10 16:51:20 2011

This archive was generated by hypermail 2.1.8 : Thu Feb 10 2011 - 16:51:36 PST