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

I've entered 1707 for the sv-ec with a proposal to clarify the function
of the stream operator.

I think the original issue of using this operator in an integral
expression would be an enhancement left for the sv-bc. The issue of how
to put this operator in a cast should also be left for the sv-bc.

Dave




> -----Original Message-----
> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> Sent: Thursday, January 04, 2007 7:24 PM
> To: Rich, Dave
> Cc: Arturo Salz; Greg Jaxon; Subhamoy Pal; sv-bc@eda-stds.org;
sv-ec@eda-
> stds.org
> Subject: Re: [sv-ec] RE: [sv-bc] streaming operator example
> 
> Egads, I wrote "byte" in my confused state, sorry.  "4" is what I
> intended.
> 
> I read Arturo, Dave, and the LRM as agreeing that { << 4
> {10'sb11_0101_1010}}
> moves from right to left cutting off the trailing 4 bits and copying
them
> in their original order into the next 4 bits of the result, moving
across
> the result from left to right.  This case yields 10'b1010_0101_11, and
> might
> have "bit unsigned [9:0]" type if used in a self-determined context.
> 
> So the slicing is not a fixed step done "first", it is interleaved and
> done sensitive to the direction of the stream arrows << or >>.  The
"_"
> in the constants was a clear clue to the original intent.
> 
> The original question was about how all this would work in an
expression.
> The LRM says the result isn't integral, a cast is required to use it
in
> an expression.  I'm not sure what that means in the type system.  That
> it has NO type until one is imposed by cast or assignment?
> 
> These operators were introduced in the era before assignment patterns
> picked
> up the '{ } notation.  Back then, the idea of assignment-like context
> hadn't
> become formalized.   But that is clearly the intention when the LRM
talks
> about using them in assignments or casts.  {<< and {>> are just as
> distinct
> as '{ in the token stream.  I think they trigger similar inheritance
> of type info from any assignment-like context.  Whereas the assignment
> pattern recurses into that type info and distributes it to the pattern
> items,
> the pack and unpack operators flatten the type to its bitstream
> representation.
> 
> Like '{}, {<<{}} and {>>{}} canNOT be used everywhere an integral
value
> might go.
> 
> Right-hand padding, and endianness conversion are not
arithmetic-friendly.
> Requiring the user to impose a type at least clues the reader in that
> something
> numerically unsound has just happened.  We should include some example
of
> that.
> I'm not sure whether byte'{<<4{6'sb11_1010}} is legal syntax, or if
>                        8'({<<4{6'sb11_1010}}) is a legal cast.
> Even there, you can see that there is some question about whether the
> signed
> constant affects anything.  Note that cast is an assignment-like
context.
> In fact it is defined in terms of assignment to a temp of the
cast-type.
> 
> If raw streams are to become legal in expressions,
> the inner {}s of these operators should interrupt type propagation
> in and out of their operand list.
> 
> Firstly, the self-determined width of the stream would influence the
> expression width, which might end up being larger than the stream.
> Without a cast, the stream is neither signed nor unsigned.  The
> LRM explicitly says that streams extend by 0 padding on the RIGHT.
> That sounds like a new data type to me (something from VHDL, right?)
> 
> So we'd add rules for "extension" (but not truncation) of
stream-types.
> That would align the data - but is it honest to call it "integral"?
> A purist wouldn't, but this is Verilog, and we have a precedent:
> look what happens to signed data in an unsigned expression.  It isn't
> C-like, or arithmetically pure, but we happily 0-extend on the left.
> This devil-may-care principle is definitely in the spirit of original
> Verilog, so I'd say "go for it".
> 
> Greg
> 
> Rich, Dave wrote:
> > 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.