bit vector to real

R

RealInfo

Guest
Hi all

I am working on a FIR that is totally "mathematical" not RTL based meaning
that
it is a pure "sum of multiplicands" all values inside are REAL defined
signals multiplied and summed from input to output.

I try not to involve RTL as much as I can .

The problem is that the data into it comes as BIT_VECTOR from the AtoD and
again must go out as BIT_VECTOR
to feed the output DtoA .

My question is : how do I translate the input stream of bytes to REAL and
vice versa
the final REAL result to BIT_VECTOR ?

Do I have to scan each bit in the input and to add to some REAL signal or
VAR
and opposite action in the output, or a better and shortr way ?

Many thanks in advance .

RealInfo
 
RealInfo wrote:
Hi all

I am working on a FIR that is totally "mathematical" not RTL based meaning
that
it is a pure "sum of multiplicands" all values inside are REAL defined
signals multiplied and summed from input to output.

I try not to involve RTL as much as I can .

The problem is that the data into it comes as BIT_VECTOR from the AtoD and
again must go out as BIT_VECTOR
to feed the output DtoA .

My question is : how do I translate the input stream of bytes to REAL and
vice versa
the final REAL result to BIT_VECTOR ?

Do I have to scan each bit in the input and to add to some REAL signal or
VAR
and opposite action in the output, or a better and shortr way ?

Many thanks in advance .

RealInfo
Click to expand...
You can convert via numeric_bit e.g.

use IEEE.numeric_bit.all;
....
bv <= bit_vector( to_signed( integer(r), bv'length) ) );

This uses the fact that integer and real are closely related so can be
converted simply using the data type, e.g. integer(r) where r is real.

regards
Alan

--
Alan Fitch
Doulos
http://www.doulos.com
 
On 14 Jan, 09:21, "RealInfo" <therighti...@yahoo.com> wrote:
Hi all

I am working on a FIR that is totally "mathematical" not RTL based meaning
that
it is a pure "sum of multiplicands" all values inside are REAL defined
signals multiplied and summed from input to output.

I try not to involve RTL as much as I can .

The problem is that the data into it comes as BIT_VECTOR from the AtoD and
again must go out as BIT_VECTOR
to feed the output DtoA .

My question is : how do I translate the input stream of bytes to REAL and
vice versa
the final REAL result to BIT_VECTOR ?

Do I have to scan each bit in the input and to add to some REAL signal or
VAR
and opposite action in the output, or a better and shortr way ?

Many thanks in advance .

RealInfo
Click to expand...
If you are simply writing a simulation model, then do as alan says and
keep with reals.

If you plan to synthesise your design you will have to remove the real
type completly from the design because it is not synthesisable. You
have 2 options:

1) Remember that reals are simply 32 bit numbers that follow the IEEE
floating point standard. They need to be handled properly and
arithmatic in hardware uses a lot of resources. You can use either the
Altera or Xilinx floating point libraries.
2) use the IEEE float/fixed libraries - though the floating libraries
are unlikely to give you satisfactory results when it comes to
synthesis. Available from here: http://www.vhdl.org/fphdl/vhdl.html
 
Tricky wrote:


2) use the IEEE float/fixed libraries - though the floating libraries
are unlikely to give you satisfactory results when it comes to
synthesis. Available from here: http://www.vhdl.org/fphdl/vhdl.html
Click to expand...
In the latest version of these packages there is actually a "real2bits"
function, which takes in a real and returns a 64 bit std_logic_vector.
 
On 15 Jan, 03:39, David Bishop <dbis...@vhdl.org> wrote:
Tricky wrote:
2) use the IEEE float/fixed libraries - though the floating libraries
are unlikely to give you satisfactory results when it comes to
synthesis. Available from here:http://www.vhdl.org/fphdl/vhdl.html

In the latest version of these packages there is actually a "real2bits"
function, which takes in a real and returns a 64 bit std_logic_vector.
Click to expand...
Theres nothing wrong with that. The only problem is that synthesised
versions of these libraries will not yield a sufficiently pipelined
result.
 
On 15 Jan, 08:52, Tricky <Trickyh...@gmail.com> wrote:
On 15 Jan, 03:39, David Bishop <dbis...@vhdl.org> wrote:

Tricky wrote:
2) use the IEEE float/fixed libraries - though the floating libraries
are unlikely to give you satisfactory results when it comes to
synthesis. Available from here:http://www.vhdl.org/fphdl/vhdl.html

In the latest version of these packages there is actually a "real2bits"
function, which takes in a real and returns a 64 bit std_logic_vector.

Theres nothing wrong with that. The only problem is that synthesised
versions of these libraries will not yield a sufficiently pipelined
result.
Click to expand...
Edit: I meant only the float library. The fixed library is a godsend.

To the OP: have you looked into using fixed point instead of floating?
fixed point is perfectly manageable, floating point is comparativly
complex and resource hungry.
 
I think that the fixed point option will be the best .
I will have to make sure that the * operator will deal well with the format
of incoming data .

I think i will switch to a RTL level described multilier for best synthesis
results .
It may be "Shift and ADD" or a static non synchronus like M array multiplier
..
I will look into it soon to decide which is most synthesis friendly .

What is your opninion regarding the synthesis friendly issue of those both
options, "Shift and ADD"
and Marray or similar static multiplier .


Thanks
RealInfo





"Tricky" <Trickyhead@gmail.com> ???
??????:7b7c65e2-3350-44dd-81e0-0e68c7226361@r37g2000prr.googlegroups.com...
On 15 Jan, 08:52, Tricky <Trickyh...@gmail.com> wrote:
On 15 Jan, 03:39, David Bishop <dbis...@vhdl.org> wrote:

Tricky wrote:
2) use the IEEE float/fixed libraries - though the floating libraries
are unlikely to give you satisfactory results when it comes to
synthesis. Available from here:http://www.vhdl.org/fphdl/vhdl.html

In the latest version of these packages there is actually a "real2bits"
function, which takes in a real and returns a 64 bit std_logic_vector.

Theres nothing wrong with that. The only problem is that synthesised
versions of these libraries will not yield a sufficiently pipelined
result.

Edit: I meant only the float library. The fixed library is a godsend.

To the OP: have you looked into using fixed point instead of floating?
fixed point is perfectly manageable, floating point is comparativly
complex and resource hungry.
Click to expand...
 
-- bit_vector -> real :
constant Bit_Vector_Cst : bit_vector(3 downto 0):="1011";
constant Slv_Cst : std_logic_vector(3 downto
0):=To_StdLogicVector(Bit_Vector_Cst); -- std_logic_1164 package
constant Uns_Cst : unsigned(3 downto 0):=unsigned(Slv_Cst);
-- numeric_std package
constant Int_Cst : integer:=To_Integer(Uns_Cst); --
numeric_std package
constant Real_Cst : real:=real(Int_Cst);

-- real -> bit_vector :
constant Real_Cst2 : real:=5.8;
constant Int_Cst2 : integer:=integer(Real_Cst2);
constant Uns_Cst2 : unsigned(3 downto 0):=To_Unsigned
(Int_Cst2,4); -- numeric_std package
constant Slv_Cst2 : std_logic_vector(3 downto
0):=std_logic_vector(Uns_Cst2);
constant Bit_Vector_Cst2 : bit_vector(3 downto 0):=To_bitvector
(Slv_Cst2);
 
On 15 Jan, 12:05, "RealInfo" <therighti...@yahoo.com> wrote:
I think that the fixed point option will be the best .
I will have to make sure that the * operator will deal well with the format
of incoming data .

I think i will switch to a RTL level described multilier for best synthesis
results .
It may be "Shift and ADD" or a static non synchronus like M array multiplier
.
I will look into it soon to decide which is most synthesis friendly .

What is your opninion regarding the synthesis friendly issue of those both
options, "Shift and ADD"
and Marray or similar static multiplier .

Thanks
RealInfo
Click to expand...

Shift and add is fine, but only really works when you are multiplying
by 2^n, or combinations of 2^n (like 6 = 4 + 2). When you move to more
complex numbers, you'll have to have far to many add stages to make it
worthwhile. You need n-1 adders, where n is the width of the 2 inputs,
so 8bit x 8bit requires 7x 2 input adders. Dedicated multipliers are
usually the best option, normally only having a latency of 1-2 clocks,
and wide (most common is to have 18 bit multipliers).
 
Tricky wrote:

Theres nothing wrong with that. The only problem is that synthesised
versions of these libraries will not yield a sufficiently pipelined
result.

Edit: I meant only the float library. The fixed library is a godsend.
Click to expand...
I knew that when I wrote it. Without automatic pipelining the floating point
library give you too much logic to synthesize. That is why all of the
functions are broken up into 3 logical parts. You are also allowed to shut off
the "hardware heavy" parts of floating point.

When I use the floating point libraries I use a fraction which fits nicely into
a multiplier.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top