RE: [sv-bc] semantics of unpack operation

[Sending this for the second time, since the first 
attempt didn't seem to make it to the reflector]


> The lrm should define the semantics of the unpack operation.
> The pack operation (streaming on the rhs) is defined well
> enough, but nothing is said about the unpack operation.

I attempted to address this in Mantis 1707: the new text for
11.4.15.3 says 

  When a streaming_concatenation appears as the target of an 
  assignment, the streaming operators perform the reverse operation;

With hindsight it might have been better to say "inverse" rather
than "reverse".  I believe that the definition of packing in
1707 is now both unambiguous and invertible (apart from possible
information loss through 4-state to 2-state conversion).

There is, I think, a possible approach to a rigorous 
definition - here's a sketch:
  
  Let S be an expression conforming to the syntax production 
  "streaming_concatenation".

  Let B be a variable of some bitstream type.
  Let C be a variable of identical type to B.
  Further, let the number of bits in B be equal to the 
  number of bits yielded by S, so that the pack operation
    B = S;
  writes to all bits of B with no surplus bits and with
  no padding required.

  The unpack operation 
    S = B;
  behaves so that, after sequential execution of the following
  procedural statements, and for arbitrary initial contents of S:
    B = S;  // pack, possible 4-to-2-state conversion
    S = B;  // unpack
    C = S;  // pack the results of unpack to a different variable
  the contents of B and C shall be identical.

This definition is flawed because it would be satisfied by
an implementation of S=B; that failed to write to the variables
that comprise S.  Otherwise, though, I think it's OK.

I agree that the current LRM text and the Mantis 1707 revision both
fall somewhat short here, but 
 - I am unable to imagine a different interpretation that 
   would make any sense;
 - I have failed in my attempts to write a definition of unpack
   that is less obscure;
 - I don't see the style of definition presented here as being
   something that would fit with the rest of the LRM.

Suggestions welcomed!
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

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