[sv-ec] 1707 redux

hi SV-EC,

Last meeting I was actioned to update the 1707 proposal
(streaming concatenation operators).  I posted a couple
of queries to the reflector but got no response, so I've
taken some "ex cathedra" decisions based on a combination
of common sense, the examples in the existing LRM and 
de facto tool behaviour.  Attached (and uploaded to 
Mantis 1707) are two docs:

* proposal-1707-jb1.pdf:
Mantis proposal in the usual "what to change" format.

* clean-1707-jb1.pdf:
Since the changes are quite significant, I've rewritten the
whole of clause 11.4.15 as it would appear with the proposed
changes; I've also added to that the small changes implied
by Mantis 1384, which is very closely linked.

The potentially controversial points are:

(1) When the streaming operation traverses an unpacked
aggregate, does it stream and re-order each element of 
that aggregate individually, and then concatenate all
those result streams to form its final result?  Or does
it first concatenate all the elements into a single 
long bit-stream and then do its re-ordering on that?  
The original LRM text (just after the first example)
explicitly says "...causes each item to be streamed
individually", but current tools do the opposite, and
Dave Rich's proposal 1707_stream_slice.pdf agrees with
them ("the streams are concatenated into a single stream").
I've gone with the de-facto/Dave-Rich behaviour, contradicting
the existing LRM; it seems to me to make more sense.  None
of the LRM examples gives any clue about this.

(2) How is the slicing performed when right-to-left 
streaming is specified?  The LRM is silent, but its first
group of examples clearly expects slicing to begin at the
right (LSB), leaving a shorter slice at the MSB end. 
Existing tools agree with that example, as does the
"reference algorithm" I posted a couple of weeks ago;
no-one has yet taken issue with that.  However, Dave's 
proposal says "starting with the leftmost bit".  Again
I have chosen to write up the de facto behaviour, as 
captured in the original LRM examples - {<<{}} slices
from the RIGHT-hand end of the stream.

(3) I've written-up the stream concatenation in a
recursive algorithmic style.  Please check that I have 
correctly captured everyone's understanding.

(4) I appear to be in a minority of one in my concerns
about left-to-right streaming using {>>{}}.  The present
rules mean that slicing is irrelevant for this direction,
no re-ordering takes place, and the slice size is effectively
ignored.  I've made this explicit, following the consensus
of the last meeting, but I'd like to double-check that 
everyone is OK with it.

(5) I have not attempted to work my "reference algorithm"
into the proposal, as I believe I have now captured the 
intent clearly enough in the text.

Thanks

-- 
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

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. 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.