Number | 128
|
Category | errata
|
Synopsis | 10.3.5 Example: ram_model
|
State | lrmdraft
|
Class | errata-simple
|
Arrival-Date | Sep 26 2002
|
Originator | Shalom.Bresticker@motorola.com
|
Release | 2001a,b: 10.3.5
|
Environment |
|
Description |
This was included in Cliff's letter to IEEE on Oct 10, 2001: "This was a requested correction that was sent to Yatin on 04/25/2001 to be added to Draft 6 before it was sent to the IEEE. The clogb2 function is very broken in this example in Draft 6. The corrected clogb2 function has been tested and works, even with Verilog-1995.) REPLACE: function integer clogb2 ; input depth ; integer i, result ; begin for (i=0; 2**i < depth; i=i+1) result = i + 1 ; clogb2 = result ; end endfunction WITH: function integer clogb2 ; input [31:0] value ; for (clogb2=0; value > 0; clogb2=clogb2+1) value = value >> 1 ; endfunction |
Fix |
In example in 10.3.5: 1. REPLACE: localparam adder_width = clogb2(ram_depth); input [adder_width-1:0] address ; WITH: localparam addr_width = clogb2(ram_depth); input [addr_width-1:0] address ; ("localparam" in bold) (I.e., CHANGE "adder_width" to "addr_width".) 2. REPLACE: function integer clogb2 ; input depth ; integer i, result ; begin for (i=0; 2**i < depth; i=i+1) result = i + 1 ; clogb2 = result ; end endfunction WITH: function integer clogb2 ; input [31:0] value ; begin value = value - 1 ; for (clogb2 = 0; value > 0; clogb2 = clogb2 + 1) value = value >> 1 ; end endfunction (All keywords in bold.) NOTE that there is no semicolon after "clogb2+1". A semicolon was incorrectly inserted in 2001b. Delete it. 3. CHANGE: // the rest to the ram model TO: // the rest of the ram model |
Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/128: 10.3.5 Example: ram_model Date: Thu, 17 Oct 2002 14:36:47 +0200 >Category: errata >Confidential: no >Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com> >Release: 2001b >Class: TBD >Description: > REPLACE WITH: > > function integer clogb2 ; > input [31:0] value ; > > for (clogb2=0; value > 0; clogb2=clogb2+1) > value = value >> 1 ; > endfunction There is a mistake in the execution of the correction in 2001b: In the line "for (clogb2=0; value > 0; clogb2=clogb2+1)" there is an extra semicolon before the right parenthesis at the end of the line. Also, an additional correction: There is a comment a few lines down: "//the rest to the ram model" It should be: "//the rest of the ram model" From: "Shalom Bresticker"<Shalom.Bresticker@motorola.com> To: Steven Sharp<sharp@cadence.com> Cc: <etf@boyd.com> Subject: Re: errata/128: clogb2 still wrong Date: Tue, 28 Jan 2003 11:33:09 +0200 (IST) Hmmm, looks like you're right. A simple fix would be to write "value>1" instead of "value>0" in the termination condition of the for loop statement. Also, you are correct that "adder_width" should obviously have been "addr_width". Shalom On Mon, 27 Jan 2003, Steven Sharp wrote: > Date: Mon, 27 Jan 2003 20:20:07 -0500 (EST) > From: Steven Sharp <sharp@cadence.com> > To: etf@boyd.com > Subject: errata/128: clogb2 still wrong > > Precedence: bulk > > The proposed clogb2 function still doesn't do what it is described as doing. > For exact powers of 2, it will produce 1 more than the log. In the specific > example in the text, it will compute that 9 address bits are needed for a > 256 word memory. > > Also, I think a localparam named addr_width would be better than adder_width > for the width of an address (as opposed to the width of an adder). > > Steven Sharp > sharp@cadence.com > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/128: clogb2 still wrong Date: Mon, 07 Apr 2003 12:47:13 +0300 Resend from Cliff Cummings: I finally got a chance to look at this one. The fix (untested) is to change the localparam statement, not the constant function: WAS: localparam adder_width = clogb2(ram_depth); PROPOSED: localparam adder_width = clogb2(ram_depth-1); Simply changing the constant function test from (value>0 -> value>1) will not work because now a requested DEPTH of 7 ( 'b111 ) will return a value of 2, which will cause a declaration of: input [addr_width-1:0] address; to be // only 2 address bits to access 7 address locations input [2-1:0] address; My original function is a true ceiling-log-base-2 function, but of course, most declarations have an LSB of 0, not 1, so we first need to take the depth and subtract 1 to get the correct MSB index, then call the clogb2 function. The other proposed corrections (adder_width -> addr_width) and (the rest to the ram model -> the rest of the ram model) should be changed as already described. At 11:33 AM 1/28/03 +0200, you wrote: > >Hmmm, looks like you're right. >A simple fix would be to write "value>1" instead of "value>0" in the >termination >condition of the for loop statement. > >Also, you are correct that "adder_width" should obviously have been >"addr_width". > >Shalom > > >On Mon, 27 Jan 2003, Steven Sharp wrote: > > > The proposed clogb2 function still doesn't do what it is described as > doing. > > For exact powers of 2, it will produce 1 more than the log. In the > specific > > example in the text, it will compute that 9 address bits are needed for a > > 256 word memory. > > > > Also, I think a localparam named addr_width would be better than > adder_width > > for the width of an address (as opposed to the width of an adder). > > ---------------------------------------------------- Cliff Cummings - Sunburst Design, Inc. From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/128: clogb2 still wrong Date: Mon, 07 Apr 2003 13:11:09 +0300 > My original function is a true ceiling-log-base-2 function But that is exactly what Steven Sharp pointed out, that "For exact powers of 2, it will produce 1 more than the log." With your correction, you will get the correct result, but the function is not a true ceiling log function. Therefore, the correct correction seems to be subtract 1 from the argument in the function calculation, not in the function call. That gives the following: function integer clogb2 ; input [31:0] value ; begin value = value - 1 ; for (clogb2 = 0; value > 0; clogb2 = clogb2+1) value = value >> 1 ; end endfunction and the function call is as before, localparam addr_width = clogb2(ram_depth) ; From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/128: clogb2 still wrong Date: Mon, 7 Apr 2003 15:39:17 -0400 (EDT) Shalom's version appears to be correct. Another approach would be more like the original version in the standard, with the bugs fixed: function integer clogb2; input [31:0] value; begin for (clogb2 = 0; 2**clogb2 < value; clogb2 = clogb2 + 1) begin end // nothing to do end endfunction Or if you don't like the odd-looking null loop body: function integer clogb2; input [31:0] value; begin clogb2 = 0; while (2**clogb2 < value) clogb2 = clogb2 + 1; end endfunction And you can use (1<<clogb2) instead of (2**clogb2), if you are worried about uncertainty in the still-pending decision on signed powers. There are some differences in behavior from Shalom's version at the endpoints: value equal to 0 or greater than 2**31. In fact, this one will go into an infinite loop for value greater than 2**31. That could be fixed by declaring value as an integer or signed reg. Steven Sharp sharp@cadence.com |
Unformatted |
|
Hosted by Boyd Technology