[sv-ec] Bitstream operators: 1707 conflicts with example

hi EC,

I still have some problems with creating a
clear set of rules for 1707.

~~~~~~~~~~~~~~~~~~~~
(1) Order of slicing
~~~~~~~~~~~~~~~~~~~~
In draft-3a clause 11.4.15 (was 8.17 before the merge), 
there is an example of the use of {<<{}} as follows:

  { << 4 { 6'b11_0101 } }  yields 'b0101_11

This clearly suggests that the slicing (into blocks of 4 in this 
case) proceeds from right to left if the << operator is used, 
leaving 2'b11 as the "left-overs".  The existing LRM text says
nothing more about this.

Dave Rich's proposed text from 1707 equally clearly says of the
slicing operation that it proceeds from left to right.  This would
slice the original value as 6'b1101_01, and therefore would yield
the result 'b01_1101.

My algorithm was written to make the examples work, and follows the
first approach (slice in the same order as the operator).

Which do we want?  I have no strong preference.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(2) Concatenation of unpacked aggregates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the "stream_concatenation" is a single data object, then the 
existing LRM text is clear enough: each [packed] integral component 
of that object is independently streamed by the operator.  If the
"stream_concatenation" is a list of packed things, then the examples
fairly clearly hint that they should be treated as a single packed
aggregate and therefore concatenated into one long bitstream before
being streamed as a single unit.  But what happens if I mix
packed and unpacked things in the "stream_concatenation" list?  Is
it illegal for any unpacked aggregate to appear there, unless it is 
the one and only member of the list?  Or is it treated in isolation,
separately from its neighbours in the list?  If the latter, then
the comma separator in the list is doing very different things 
depending on whether it has packed or unpacked things next to it.

Once again I have no strong preference for anything other than
clarity and completeness of the LRM.
-- 
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.