Re: [sv-bc] Question about stream unpacking

[Forwarding from Jonathan Bromley]

On Tue, Jul 27, 2010 at 10:08 PM, Paul Graham <pgraham@oasys-ds.com> wrote:

    LRM 11.4.14.3 says:

       If the source expression contains more bits than are needed,
       the appropriate number of bits shall be consumed from its left
       (most significant) end.

Right. I added that as part of the resolution of Mantis 1707.
At the time I was concerned that the dropping of LSBs was
somewhat un-Verilog-ish, but the question was definitely
discussed in sv-ec and the left justification was affirmed
as the correct, desired behaviour.
 

    Later there are two examples (including my $display statements):

       int a, b, c;
       {>>{ a, b, c }} = 96'b1; // OK: unpack a = 0, b = 0, c = 1
       $display("a = %x, b = %x, c = %x", a, b, c);
       {>>{ a, b, c }} = 100'b1; // OK: unpack as above (4 bits unread)
       $display("a = %x, b = %x, c = %x", a, b, c);

The second example is clearly in disagreement with the normative
LRM text and I'm ashamed I missed that. I absolutely agree
that the result should be 0,0,0. However, at the time I noted that
all three major simulators disagreed dramatically about various
tricky cases around streaming operators - the situation with
right-to-left streaming was even more confused, and maybe
still is today - and although the current LRM text is an
improvement over 1800-2005, it's evidently still nowhere near
clear enough. I had hoped to be able to include a reference
algorithm (written in SV) in the LRM, but SV-EC had too much
else to do and didn't have the time to address that.

You'll also note that the LRM is reasonably thorough about
packing, but skates over the details of unpacking. I wanted to
define unpacking by saying that the sequence of operations
    {<<N{ <concatenation> }} = stream;
    stream = {<<N{ <concatenation> }};
is guaranteed to update "stream" with exactly its original value,
but again that slipped the net. I believe that was my oversight;
I failed to include it in the proposal.

Thanks for highlighting the problem. I'll try to review the
behaviour of current simulators and raise another Mantis
in the next few days.

See also Mantis 2592 and the discussion starting at
http://www.eda-stds.org/sv-ec/hm/6484.html

-- 
Jonathan Bromley
----- Original Message -----
From: "Paul Graham" <pgraham@oasys-ds.com>
To: "sv-bc" <sv-bc@eda.org>
Sent: Tuesday, July 27, 2010 5:08:11 PM
Subject: [sv-bc] Question about stream unpacking
LRM 11.4.14.3 says:
    If the source expression contains more bits than are needed, 
    the appropriate number of bits shall be consumed from its left 
    (most significant) end.
Later there are two examples (including my $display statements):
    int a, b, c;
    {>>{ a, b, c }} = 96'b1; // OK: unpack a = 0, b = 0, c = 1
    $display("a = %x, b = %x, c = %x", a, b, c);
    {>>{ a, b, c }} = 100'b1; // OK: unpack as above (4 bits unread)
    $display("a = %x, b = %x, c = %x", a, b, c);
In the second assignment, the rhs has more bits than is neeed (100 vs 96).  The rule above says that the bits should be taken from the msb of the expression.  Following this rule I would expect to get a=0, b=0, c=0.  Yet the comment "unpack as above" suggests that the second assignment behaves the same as the first.  And a leading simulator also treats the two assignments the same:
# a = 00000000, b = 00000000, c = 00000001
# a = 00000000, b = 00000000, c = 00000001
Maybe the rule hinges on the meaning of "appropriate"?
Paul
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.