RE: [sv-bc] semantics of unpack operation

From: Rich, Dave <Dave_Rich_at_.....>
Date: Wed Sep 12 2007 - 10:37:30 PDT
There really is no separate pack and unpack operators. There is a
streaming operator that can perform pack and unpack operations. 

Whether you're packing, unpacking, or doing both depends on your point
of view. Usually merging multiple operands or multiple elements of an
array into single stream is called packing; and splitting a stream into
multiple operands or elements of an array is called unpacking.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Wednesday, September 12, 2007 10:13 AM
> To: sv-ec@server.eda-stds.org; sv-bc@server.eda-stds.org
> Subject: 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.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Sep 12 10:38:00 2007

This archive was generated by hypermail 2.1.8 : Wed Sep 12 2007 - 10:38:18 PDT