| Number | 228
|
| Category | errata
|
| Synopsis | 4.2.1: indexed part-select with width-expression of -5
|
| State | lrmdraft
|
| Class | errata-simple
|
| Arrival-Date | Dec 23 2002
|
| Originator | "Brad Pierce" <Brad.Pierce@synopsys.com>
|
| Release | 2001b: 4.2.1
|
| Environment |
|
| Description |
Which constant expressions are legal as width expressions in an indexed part-select? The width is said to indicate the number of bits selected. So we shouldn't be able to select 0 bits, e.g., big_vect[15 +: 0] But what about big_vect[15 +: -5] ? Is -5 cast to signed or should this produce an error? What about 5.0? What does this mean? -- "The last one shows an indexable nature." The initial block is a strange way to "show the identity between the two part select constructs". The example isn't numbered. |
| Fix |
1. Legal values for the width expressions should be a semantic restriction. Specifically, after the sentence, "The width_expr shall be a constant expression.", add the following: "The value of the width_expr shall be a positive integer." 2. Change the Examples preceding Example 1, starting with "reg [31:0] big_vect;" through line beginning with "dword[8*sel +:8] = big_vect[7:0]; // Replace the byte selected." with the following: reg [31: 0] big_vect; reg [0 :31] little_vect; reg [63: 0] dword; integer sel; big_vect[ 0 +: 8] // == big_vect[ 7 : 0] big_vect[15 -: 8] // == big_vect[15 : 8] little_vect[ 0 +: 8] // == little_vect[0 : 7] little_vect[15 -: 8] // == little_vect[8 :15] dword[8*sel +: 8] // variable part-select with fixed width ("reg" and "integer" keywords in bold) |
| Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/228: 4.2.1, indexed part-select with width-expression of -5 Date: Tue, 24 Dec 2002 17:00:48 +0200 Comments inside. Shalom Brad Pierce wrote: > Which constant expressions are legal as width expressions > in an indexed part-select? The width is said to indicate > the number of bits selected. So we shouldn't be able to > select 0 bits, e.g., > > big_vect[15 +: 0] > > But what about > > big_vect[15 +: -5] ? > > Is -5 cast to signed or should this produce an error? > What about 5.0? 1. Legal values for the width expressions should be a semantic restriction. Specifically, we should add a sentence similar to parallel cases in section 3, that "The value of the width_expr shall be a positive integer." > What does this mean? -- > > "The last one shows an indexable nature." 2. Yeah, lousy wording. It should say something about a variable base for the part-select. The wording came from the idea that "indexed part-select" implicitly means a variable index. So "indexable nature" refers to the variable position of the part-select within the vector. > The initial block is a strange way to "show the identity > between the two part select constructs". 3. Yeah, do you want to change it? How about the following? reg [31: 0] big_vect; reg [0 :31] little_vect; reg [63: 0] dword; integer sel; big_vect[ 0 +: 8] // == big_vect[ 7 : 0] big_vect[15 -: 8] // == big_vect[15 : 8] little_vect[ 0 +: 8] // == little_vect[0 : 7] little_vect[15 -: 8] // == little_vect[8 :15] dword[8*sel +: 8] // variable part-select with fixed width > The example isn't numbered. 4. There are dozens of unnumbered examples in the LRM. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 "The devil is in the details." |
| Unformatted |
|
Hosted by Boyd Technology