RE: [sv-bc] streaming operator example

However, that wording would change the meaning of the LRM.

The two words Greg dropped, "first" and "then" are intended to specify a
two-step process:
1) Break up the data into the specified chunks (i.e., slices)
2) Stream the chunks in the specified order

This is intended to resolve the ambiguity regarding the order of
streaming vs. slicing, and whether the streaming operator reverses the
bits within each chunk (slice) or only reverses the order of the chunks
- the LRM intent is the latter. Hence, the LRM example:

	{<< byte {6'b11_0101}} is 0101_11, not 0111_01.
	{>> byte {6'b11_0101}} is 1101 01, not 0101_11.

As for the inverse property, I believe it only holds true when the chunk
size is 1, that is, the streaming operator is applied only to bits.

I believe the only thing that is left underspecified is the fact that
the break up of the data into slices is always done left-to-right.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Rich, Dave
Sent: Thursday, January 04, 2007 12:43 PM
To: Greg Jaxon
Cc: Subhamoy Pal; sv-bc@eda-stds.org; sv-ec@eda-stds.org
Subject: RE: [sv-bc] streaming operator example

I like that wording.

> -----Original Message-----
> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> Sent: Thursday, January 04, 2007 12:37 PM
> To: Rich, Dave
> Cc: Subhamoy Pal; sv-bc@eda-stds.org; sv-ec@eda-stds.org
> Subject: Re: [sv-bc] streaming operator example
> 
> The text currently says:
> > The stream operator determines the order in which data are streamed:
>>
> causes data to be streamed in leftto-
> > right order, while << causes data to be streamed in right-to-left
order.
> If a slice size is specified, then the
> > data to be streamed are first broken up into slices with the
specified
> number of bits, and then the slices are
> > streamed in the specified order.
> 
> Assuming the example is not blatantly wrong, it may have been written
> to settle the textual ambiguity about whether slicing happens
> "in the specified order", or "first" (before considering the
> direction of streaming).  Which reading is the most natural
> handling of endianness if the datasize != 0 mod grainsize?
> 
> My answer: Neither is natural for the odd-sized cases, because
> the "final" grain changes value.  BUT endian-sensitive slicing
> has one desirable property:  {<< byte ...} and {>> byte ...}
> become inverse functions.
> 
> {<< byte {6'b11_0101}} is either   0111_01  or  0101_11
>                {>> byte {that} is   01_0111  or  11_0101
> 
> I think the LRM example and the idea that these are complimentary
> functions suggests that the word "first" should be dropped and
> the comma in the text should be moved:
> 
> "data to be streamed are broken up into slices with the specified
> number of bits and the slices are streamed, both in the specified
> order."
> 
> Greg Jaxon
> 
> Rich, Dave wrote:
> > I believe the intent is that the slicing begins with the MSB. I will
> > enter a mantis issue for this.
> >
> >
> >
> > Dave
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > *From:* owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org]
> > *On Behalf Of *Subhamoy Pal
> > *Sent:* Thursday, January 04, 2007 10:02 AM
> > *To:* sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org
> > *Subject:* [sv-bc] streaming operator example
> >
> >
> >
> > In SV LRM 1800-2005 section no 8.17,
> >
> >
> >
> > I found the following example:
> >
> >
> >
> > "{ << 4 { 6'b11_0101 }} // generates stream 'b0101_11"
> >
> >
> >
> > This, I think, is wrong.
> >
> >
> >
> > "If a slice size is specified, then the data to be streamed are
first
> > broken up into slices with the specified number of bits, and then
the
> > slices are
> >
> > streamed in the specified order."
> >
> >
> >
> > However the verse does not mention the order of breaking up, so the
> > above stream can be broken up as 'b1101_01 (Left->right) or
'b11_0101
> > (Right->left). Now stream operator can make the result stream either
as
> > 'b01_1101 or as 'b0101_11.
> >
> >
> >
> > Why the first one is not chosen here is not clear to me. Can anyone
> > explain on this?
> >
> >
> >
> >
> >
> > --Subhamoy
> >
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>*,
and
> is
> > believed to be clean.
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and
> is
> > believed to be clean. *


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