Re: [sv-bc] streaming operator example

> I'm not sure whether byte'{<<4{6'sb11_1010}} is legal syntax, or if
>                       8'({<<4{6'sb11_1010}}) is a legal cast.

byte'{<<4{6'sb11_1010}} is not legal syntax, because  "In a static cast,
the expression to be cast shall be enclosed in parentheses ...".

8'({<<4{6'sb11_1010}}) is not a legal cast, because "The expression
inside the cast must be an integral value when changing the size ...".
(For an analogy, recall from 8.13 that an assignment pattern cannot be
the operand of a static cast.)

-- Brad


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
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.


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