Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Fixed Point Rounding (http://www.velocityreviews.com/forums/t723046-fixed-point-rounding.html)

Tricky 05-14-2010 02:43 PM

Fixed Point Rounding
 
Im using the new float fix lib, and Im getting a bit confused with the
resize function.

Im using the following code:

video_us : out ufixed(7 downto 0)
...
variable weighted_pix0 : ufixed(7 downto -12);
variable weighted_pix1 : ufixed(7 downto -12);
.......
video_us <= resize(weighted_pix0 + weighted_pix1, 7 ,
0);

Now, when the sum of the 2 weighted pixels is X.5, the rounded output
(round style is defaulting to fixed_round) is always X, not X+1. Is
there a rule Im missing? Is this not what the resize function is for,
because otherwise whats the point of the "round_style" and
"overflow_style" function arguments? do I have to go back to old way
of rounding that is +0.5 and then truncating?

Thanks for help in advance

KJ 05-14-2010 11:36 PM

Re: Fixed Point Rounding
 
On May 14, 10:43*am, Tricky <trickyh...@gmail.com> wrote:
> Im using the new float fix lib, and Im getting a bit confused with the
> resize function.
>
> Im using the following code:
>
> video_us : out ufixed(7 downto 0)
> ..
> variable weighted_pix0 * *: ufixed(7 downto -12);
> variable weighted_pix1 * *: ufixed(7 downto -12);
> ......
> video_us * * * * * * * *<= resize(weighted_pix0 + weighted_pix1, 7 ,
> 0);
>
> Now, when the sum of the 2 weighted pixels is X.5, the rounded output
> (round style is defaulting to fixed_round) is always X, not X+1. Is
> there a rule Im missing?


What you're missing is that whether X.5 rounds up or down depends on
what X is.

From ther user's guide...
"round_style" defaults to fixed_round (true) that turns on the
rounding routines. If false (fixed_truncate), the number is truncated.
Rounding is done by first looking to see if the MSB of the remainder
is a “1”, AND the LSB of the unrounded result is a “1” or the lower
bits of the remainder include a “1”, the result will be rounded. This
is similar to the floating-point “round_nearest” style. The down side
is that ALL of the bits are included in the decision to round


> do I have to go back to old way
> of rounding that is +0.5 and then truncating?
>


I use the "+0.5 and then truncating" approach because it takes less
logic to implement (hence the 'down side' mentioned in the user's
guide) and my requirements haven't so far required the floating-point
“round_nearest” style

Kevin Jennings

KJ 05-15-2010 04:04 AM

Re: Fixed Point Rounding
 
On May 14, 11:04*pm, David Bishop <dbis...@vhdl.org> wrote:
> KJ wrote:
> > I use the "+0.5 and then truncating" approach because it takes less
> > logic to implement


Should've said "I *have* used +0.5...". I've also used 'fixed_round'.

>
> Which causes data forking.
> Take the numbers 1.5 to 8.5 and round by your method and add up the
> error.


Depending on the application though, this additional error for certain
input combinations might still be acceptable. "+0.5 and truncate" is
generally intermediate between 'fixed_truncate' and 'fixed_round' both
in error and logic resources to implement. Which of the three methods
is 'best' will depend on the accuracy requirements of the particular
application.

"+0.5 and truncate" is a design tradeoff that should be evaluated
versus 'fixed_truncate' and 'fixed_round'...it's just another tool in
the toolbox.

As an example of resource usage, I took Tricky's code (actual code
posted below) and ran it through Quartus 9.0 to produce the following
results:

Rounding method Logic resources
=============== ===============
fixed_round 44
+.5_and_trunc 39
fixed_truncate 29

Kevin Jennings

--- START OF CODE
library ieee_proposed;
use ieee_proposed.math_utility_pkg.all;
use ieee_proposed.fixed_pkg.all;

entity Resizer_Adder is port(
weighted_pix0: in ufixed(7 downto -12);
weighted_pix1: in ufixed(7 downto -12);
video_us: out ufixed(7 downto 0));
end Resizer_Adder;
architecture rtl of Resizer_Adder is
begin
-- Uncomment the line you would like to evaluate
video_us <= resize(weighted_pix0 + weighted_pix1, 7 , 0,
fixed_overflow_style,fixed_round);
-- video_us <= resize(weighted_pix0 + weighted_pix1 +
to_ufixed(0.5,-1,-1), 7 , 0, fixed_overflow_style,fixed_truncate);
-- video_us <= resize(weighted_pix0 + weighted_pix1, 7 , 0,
fixed_overflow_style,fixed_truncate);
end rtl;
--- END OF CODE

Tricky 05-17-2010 07:47 AM

Re: Fixed Point Rounding
 

>
> KJ is correct.
>
> 4.5 rounds to 4
> 5.5 rounds to 6
>
> Though carrying 12 bits of decimal is a bit overkill.
>
> >> do I have to go back to old way
> >> of rounding that is +0.5 and then truncating?

>
> > I use the "+0.5 and then truncating" approach because it takes less
> > logic to implement (hence the 'down side' mentioned in the user's
> > guide) and my requirements haven't so far required the floating-point
> > “round_nearest” style

>
> Which causes data forking.
> Take the numbers 1.5 to 8.5 and round by your method and add up the
> error. * Then do the same for my method (I wrote the fixed point packages).


For me, data forking (if I understand correctly - is that like
compounding errors?) shouldnt be an issue becuase this is the final
output. The 12 bits are carried only because I have a previous divide
(by a constant 2^n, with n as a generic) with input data only carrying
4 bits fractional. 12 bits contains the worst possible case of N, with
me expecting the synthesiser to clear up anything thats overkill. And
actually, for my output, I require X.5 to always round to X+1, so
there is no error.


All times are GMT. The time now is 03:37 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.