RE: [sv-ec] RE: [sv-bc] streaming operator example

That means the slicing only has an effect if the streaming is
right-to-left "<<".

Somewhere along this thread 'byte' replaced '4' in the example. It has
always been '4'

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Arturo Salz
> Sent: Thursday, January 04, 2007 2:19 PM
> To: Rich, Dave; Greg Jaxon
> Cc: Subhamoy Pal; sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org
> Subject: [sv-ec] 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.
> 


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