integer to 32-bit float conversion
Author Message
integer to 32-bit float conversion

What is the best way to convert a integer to a 32-bit float conforming to
IEEE 754? Is it as simple as a type conversion?

fee <= real(foo);

Where fee is type real and foo is type integer.

Thanks
Jeff

Mon, 19 Jan 2004 09:24:32 GMT
integer to 32-bit float conversion
for simulation or for synthesis?

Quote:

> What is the best way to convert a integer to a 32-bit float conforming to
> IEEE 754? Is it as simple as a type conversion?

> fee <= real(foo);

> Where fee is type real and foo is type integer.

> Thanks
> Jeff

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://www.andraka.com

Mon, 19 Jan 2004 14:33:14 GMT
integer to 32-bit float conversion
Hi,
Yes that should do the job, I am not sure the LRM says it explicitly but
atleast I know modelsim implements it this way.

Srini

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India (http://www.vlsisrini.com)

Quote:
> What is the best way to convert a integer to a 32-bit float conforming to
> IEEE 754? Is it as simple as a type conversion?

> fee <= real(foo);

> Where fee is type real and foo is type integer.

> Thanks
> Jeff

Mon, 19 Jan 2004 18:11:53 GMT
integer to 32-bit float conversion
For simulation purposes. I want to be able to test the rtl code for
correctness.

FWIW...high level rtl description follows:

My algorithm for converting signed 24-bit to 32-bit float works as follows

1. Convert signed 24-bit input to magnitude.

For floating point sign I just pipe the 24-bit input sign bit (using SRL16)
to match exponent and signficand delays.

For exponent I take output of 1. above and priority encode it. I take this
5-bit priority output and add 104. This becomes the 8-bit exponent.

For significand I take the 5-bit priority output and take 23 - priority
output to determine how much I need to left shift the output of step 1. (the
magnitude). I shift using a optimized barrel shifter to to this. This
becomes the 23-bit significand.

I'm reasonably confident my barrel shifter is optimal, but I suspect there
is a better way to generate the exponent than to add 104 to priority encoded
output. I haven't had a chance to think about it, but thought I would get
the test bench working before optimizing.

My priority encoder looks like this:

FOR N IN ((magnitude'LEFT)-1) DOWNTO 0 LOOP
IF magnitude(N) = '1' THEN
priority <= conv_unsigned(N, priority'LENGTH);
EXIT;
END IF;
END LOOP;

If anyone is willing to share a better way of generating the exponent, I
would really appreciate it.

Jeff

Quote:
> for simulation or for synthesis?

> > What is the best way to convert a integer to a 32-bit float conforming
to
> > IEEE 754? Is it as simple as a type conversion?

> > fee <= real(foo);

> > Where fee is type real and foo is type integer.

> > Thanks
> > Jeff

> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950

> http://www.andraka.com

Tue, 20 Jan 2004 04:01:01 GMT
integer to 32-bit float conversion
You don't need to generate the exponent if you do the barrel shift
correctly...the barrel shift will generate it for you.

Do your barrel shift as a series of power of 2 shifts doing the largest one
first.  The shift decision at each stage becomes a bit in the exponent.  For
example if you have a 16 position barrel shift, the shifter is 4 layers of 2:1
muxes.  The first layer either passes the data unchanged, or shifts it by 8
positions.  The decision on whether or not to shift is made by looking at the 9
most significant bits.  If they are all the same, you shift up 8 positions.  The
next layer shifts up 4 positions or passes the data.  Use the 5 msbs of the
output from the first layer to make the shift decision.  If all bits match you
shift, otherwise no shift.  repeat for the next two layers with shifts of 2 and
1 respectively.  If you retain the shift decision from each stage, it indicates
the number of bit positions shifted, so it is your raw exponent.  Depending on
the exponent representation, you may need to add a constant to that exponent (or
you might get away with just inverting the MSB of the exponent for an excess
representation).  In your case, you want an unsigned mantissa, so before you go
into the normalizing barrel shift go through an absolute value stage (invert and
add 1 if the sign bit is a 1), then the barrel shift decisions only look at the
top 8,4,2 and 1 bits to make sure none are a '1'.  This also pipelines quite
nicely, so you can easily achieve clock rates in the shifter that are faster
than the carry chain in the absolute value stage can go.

Quote:

> For simulation purposes. I want to be able to test the rtl code for
> correctness.

> FWIW...high level rtl description follows:

> My algorithm for converting signed 24-bit to 32-bit float works as follows

>     1. Convert signed 24-bit input to magnitude.

> For floating point sign I just pipe the 24-bit input sign bit (using SRL16)
> to match exponent and signficand delays.

> For exponent I take output of 1. above and priority encode it. I take this
> 5-bit priority output and add 104. This becomes the 8-bit exponent.

> For significand I take the 5-bit priority output and take 23 - priority
> output to determine how much I need to left shift the output of step 1. (the
> magnitude). I shift using a optimized barrel shifter to to this. This
> becomes the 23-bit significand.

> I'm reasonably confident my barrel shifter is optimal, but I suspect there
> is a better way to generate the exponent than to add 104 to priority encoded
> output. I haven't had a chance to think about it, but thought I would get
> the test bench working before optimizing.

> My priority encoder looks like this:

>     FOR N IN ((magnitude'LEFT)-1) DOWNTO 0 LOOP
>         IF magnitude(N) = '1' THEN
>           priority <= conv_unsigned(N, priority'LENGTH);
>           EXIT;
>         END IF;
>      END LOOP;

> If anyone is willing to share a better way of generating the exponent, I
> would really appreciate it.

> Jeff

> > for simulation or for synthesis?

> > > What is the best way to convert a integer to a 32-bit float conforming
> to
> > > IEEE 754? Is it as simple as a type conversion?

> > > fee <= real(foo);

> > > Where fee is type real and foo is type integer.

> > > Thanks
> > > Jeff

> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950

> > http://www.andraka.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://www.andraka.com

Tue, 20 Jan 2004 04:26:26 GMT
integer to 32-bit float conversion
Played with your suggested priority encoder this morning.....beautiful!
Though for me, 1st stage OR's upper 8, next stage 4, then 2 and 1. It does
indeed generate a relative 0 number for the most siginificant bit position.
Excellent! Much more efficient than the code I had previously posted for
priority encoding.

Thank you very much!
Jeff

Quote:
> You don't need to generate the exponent if you do the barrel shift
> correctly...the barrel shift will generate it for you.

> Do your barrel shift as a series of power of 2 shifts doing the largest
one
> first.  The shift decision at each stage becomes a bit in the exponent.
For
> example if you have a 16 position barrel shift, the shifter is 4 layers of
2:1
> muxes.  The first layer either passes the data unchanged, or shifts it by
8
> positions.  The decision on whether or not to shift is made by looking at
the 9
> most significant bits.  If they are all the same, you shift up 8
positions.  The
> next layer shifts up 4 positions or passes the data.  Use the 5 msbs of
the
> output from the first layer to make the shift decision.  If all bits match
you
> shift, otherwise no shift.  repeat for the next two layers with shifts of
2 and
> 1 respectively.  If you retain the shift decision from each stage, it
indicates
> the number of bit positions shifted, so it is your raw exponent.
Depending on
> the exponent representation, you may need to add a constant to that
exponent (or
> you might get away with just inverting the MSB of the exponent for an
excess
> representation).  In your case, you want an unsigned mantissa, so before
you go
> into the normalizing barrel shift go through an absolute value stage
(invert and
> add 1 if the sign bit is a 1), then the barrel shift decisions only look
at the
> top 8,4,2 and 1 bits to make sure none are a '1'.  This also pipelines
quite
> nicely, so you can easily achieve clock rates in the shifter that are
faster
> than the carry chain in the absolute value stage can go.

> > For simulation purposes. I want to be able to test the rtl code for
> > correctness.

> > FWIW...high level rtl description follows:

> > My algorithm for converting signed 24-bit to 32-bit float works as
follows

> >     1. Convert signed 24-bit input to magnitude.

> > For floating point sign I just pipe the 24-bit input sign bit (using
SRL16)
> > to match exponent and signficand delays.

> > For exponent I take output of 1. above and priority encode it. I take
this
> > 5-bit priority output and add 104. This becomes the 8-bit exponent.

> > For significand I take the 5-bit priority output and take 23 - priority
> > output to determine how much I need to left shift the output of step 1.
(the
> > magnitude). I shift using a optimized barrel shifter to to this. This
> > becomes the 23-bit significand.

> > I'm reasonably confident my barrel shifter is optimal, but I suspect
there
> > is a better way to generate the exponent than to add 104 to priority
encoded
> > output. I haven't had a chance to think about it, but thought I would
get
> > the test bench working before optimizing.

> > My priority encoder looks like this:

> >     FOR N IN ((magnitude'LEFT)-1) DOWNTO 0 LOOP
> >         IF magnitude(N) = '1' THEN
> >           priority <= conv_unsigned(N, priority'LENGTH);
> >           EXIT;
> >         END IF;
> >      END LOOP;

> > If anyone is willing to share a better way of generating the exponent, I
> > would really appreciate it.

> > Many thanks in advance!
> > Jeff

> > > for simulation or for synthesis?

> > > > What is the best way to convert a integer to a 32-bit float
conforming
> > to
> > > > IEEE 754? Is it as simple as a type conversion?

> > > > fee <= real(foo);

> > > > Where fee is type real and foo is type integer.

> > > > Thanks
> > > > Jeff

> > > --
> > > -Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950

> > > http://www.andraka.com

> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950

> http://www.andraka.com

Wed, 21 Jan 2004 01:01:58 GMT
integer to 32-bit float conversion
Righto  8,4,2,1 for unsigned input, which you have.  If your input were signed,
the critical path in your design, where a more obvious priority encode plus
barrel shift is likely to be one of the worst case paths.  It is also smaller.

Quote:

> Played with your suggested priority encoder this morning.....beautiful!
> Though for me, 1st stage OR's upper 8, next stage 4, then 2 and 1. It does
> indeed generate a relative 0 number for the most siginificant bit position.
> Excellent! Much more efficient than the code I had previously posted for
> priority encoding.

> Thank you very much!
> Jeff

> > You don't need to generate the exponent if you do the barrel shift
> > correctly...the barrel shift will generate it for you.

> > Do your barrel shift as a series of power of 2 shifts doing the largest
> one
> > first.  The shift decision at each stage becomes a bit in the exponent.
> For
> > example if you have a 16 position barrel shift, the shifter is 4 layers of
> 2:1
> > muxes.  The first layer either passes the data unchanged, or shifts it by
> 8
> > positions.  The decision on whether or not to shift is made by looking at
> the 9
> > most significant bits.  If they are all the same, you shift up 8
> positions.  The
> > next layer shifts up 4 positions or passes the data.  Use the 5 msbs of
> the
> > output from the first layer to make the shift decision.  If all bits match
> you
> > shift, otherwise no shift.  repeat for the next two layers with shifts of
> 2 and
> > 1 respectively.  If you retain the shift decision from each stage, it
> indicates
> > the number of bit positions shifted, so it is your raw exponent.
> Depending on
> > the exponent representation, you may need to add a constant to that
> exponent (or
> > you might get away with just inverting the MSB of the exponent for an
> excess
> > representation).  In your case, you want an unsigned mantissa, so before
> you go
> > into the normalizing barrel shift go through an absolute value stage
> (invert and
> > add 1 if the sign bit is a 1), then the barrel shift decisions only look
> at the
> > top 8,4,2 and 1 bits to make sure none are a '1'.  This also pipelines
> quite
> > nicely, so you can easily achieve clock rates in the shifter that are
> faster
> > than the carry chain in the absolute value stage can go.

> > > For simulation purposes. I want to be able to test the rtl code for
> > > correctness.

> > > FWIW...high level rtl description follows:

> > > My algorithm for converting signed 24-bit to 32-bit float works as
> follows

> > >     1. Convert signed 24-bit input to magnitude.

> > > For floating point sign I just pipe the 24-bit input sign bit (using
> SRL16)
> > > to match exponent and signficand delays.

> > > For exponent I take output of 1. above and priority encode it. I take
> this
> > > 5-bit priority output and add 104. This becomes the 8-bit exponent.

> > > For significand I take the 5-bit priority output and take 23 - priority
> > > output to determine how much I need to left shift the output of step 1.
> (the
> > > magnitude). I shift using a optimized barrel shifter to to this. This
> > > becomes the 23-bit significand.

> > > I'm reasonably confident my barrel shifter is optimal, but I suspect
> there
> > > is a better way to generate the exponent than to add 104 to priority
> encoded
> > > output. I haven't had a chance to think about it, but thought I would
> get
> > > the test bench working before optimizing.

> > > My priority encoder looks like this:

> > >     FOR N IN ((magnitude'LEFT)-1) DOWNTO 0 LOOP
> > >         IF magnitude(N) = '1' THEN
> > >           priority <= conv_unsigned(N, priority'LENGTH);
> > >           EXIT;
> > >         END IF;
> > >      END LOOP;

> > > If anyone is willing to share a better way of generating the exponent, I
> > > would really appreciate it.

> > > Many thanks in advance!
> > > Jeff

> > > > for simulation or for synthesis?

> > > > > What is the best way to convert a integer to a 32-bit float
> conforming
> > > to
> > > > > IEEE 754? Is it as simple as a type conversion?

> > > > > fee <= real(foo);

> > > > > Where fee is type real and foo is type integer.

> > > > > Thanks
> > > > > Jeff

> > > > --
> > > > -Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930     Fax 401/884-7950

> > > > http://www.andraka.com

> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950

> > http://www.andraka.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://www.andraka.com

Wed, 21 Jan 2004 02:40:36 GMT

 Page 1 of 1 [ 7 post ]

Relevant Pages