integer to 32-bit float conversion

[Jeff Reeve]

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]

for simulation or for synthesis?

Jeff Reeve wrote:

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com

[Srinivasan Venkataramanan]

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)

"Jeff Reeve" <je...@patmos-eng.com> wrote in message
news:kZ1a7.13520$Ke4.8...@news1.sttln1.wa.home.com...

[Jeff Reeve]

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

"Ray Andraka" <r...@andraka.com> wrote in message
news:3B68F482...@andraka.com...

[Ray Andraka]

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.

[Jeff Reeve]

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

"Ray Andraka" <r...@andraka.com> wrote in message

news:3B69B7CA...@andraka.com...

[Ray Andraka]

Righto 8,4,2,1 for unsigned input, which you have. If your input were signed,
you'd need to do 9,5,3,2. Nice thing about this is with pipelining, it won't be
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.
Glad to have helped.