why does bitstoreal function return these weird values... - verilog

On 16 May 2007 16:57:25 -0700, masoodtahir@hotmail.com wrote:

[in paraphrase]

> real xxx_real;
> reg [63:0] xxx_bits = 5;
> ...
> xxx_real = $bitstoreal(xxx_bits);
>
> The simulation results are:
> xxx_bits = 0000000000000005
> xxx_real = 2.47033e-323
>
> I would expect that the value of xxx_real should be "5".

$bitstoreal and $realtobits make NO promises about the numeric
value of the 64-bit representation of the real value. The
ONLY promise they make is that the conversion

$bitstoreal( $realtobits( some_real ) )

gives the same value that was originally stored in some_real,
possibly give-or-take some rounding error in the fractional
part. These functions are designed to make it possible for
you to ship a real value across a module port, given the
Verilog limitation that module ports must be nets (on at
least one side of the port) and you can't make a net of
'real' type.

If you want to convert between integers and reals, preserving
the integer part of the numeric value, then you want
the functions $itor and $rtoi.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On May 16, 4:57 pm, masoodta...@hotmail.com wrote:
> Hi,
> Please see the following short piece of verilog code:
> wire [63:0] xxx_bits = 64'h5;
> real xxx_real;
> reg [63:0] xxx_btbits;
> integer xxx_int;
> always @(posedge clk or xxx_bits ) begin
> xxx_real = $bitstoreal(xxx_bits);
> xxx_int = $rtoi(xxx_real);
> xxx_btbits = $realtobits(xxx_real); //btbits=back to bits
> end
>
> The simulation results are:
> xxx_bits = 0000000000000005
> xxx_real = 2.47033e-323
> xxx_int = 00000000
> xxx_btbits = 0000000000000005
>
> I would expect that the value of xxx_real should be "5". If xxx_real
> were "5", then xxx_int would also be "5" and everything would make
> sense. Am I missing something here?? Any help will be really
> appreciated.

>From the LRM, it says...

The real numbers accepted or generated by these functions shall
conform to the IEEE Std 754-1985 [B1]
representation of the real number. The conversion shall round the
result to the nearest valid representation.

So think of $realtobits as converting the real number to its IEEE-754
bit representation (for double precision numbers). In your case
(integer value = 5), it is an example of a denormalized number so

real_value = 2^(-1022)*5/2^52 = 2.4703282292062327208828439643411e-323

For more information about the IEEE-754 representation, see
http://en.wikipedia.org/wiki/Ieee_floating_point

David Walker

On 17 May 2007 12:27:10 -0700,
<dbwalker0min@gmail.com> wrote:

>From the LRM, it says...
>
>The real numbers accepted or generated by these functions shall
>conform to the IEEE Std 754-1985 [B1]
>representation of the real number.

Thanks, I had forgotten that (change from Verilog-1995 where
the representation was undefined, to Verilog-2001 where it
is defined to follow IEEE-754).
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

masoodtahir@hotmail.com wrote:
>
> I would expect that the value of xxx_real should be "5". If xxx_real
> were "5", then xxx_int would also be "5" and everything would make
> sense. Am I missing something here??

Yes. $bitstoreal and $realtobits are not conversion functions between
integer and real numbers. That is what $itor and $rtoi are for.

What $realtobits does is take the internal representation of the real
number, which is in IEEE 754 double precision floating point format,
and give those 64 bits to you as a bit vector. Those bits won't make
any sense to you unless you understand how IEEE floating point numbers
are represented, and know the endianess with which they are being
given to you.

The reason for $realtobits is to produce a value that can be passed
through a port as a bit vector, and then converted back to the
original real value on the other side. This works around the fact
that Verilog does not allow passing reals through ports.