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.Received on Thu Jan 4 19:24:40 2007
This archive was generated by hypermail 2.1.8 : Thu Jan 04 2007 - 19:24:59 PST