Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

vhdl square root function

2,057 views
Skip to first unread message

Renaud Pacalet

unread,
Sep 6, 2000, 4:28:19 AM9/6/00
to
vin...@mailexcite.com wrote:
>
> Hello all
> I want to use IEEE's sqrt function(defined in math_real) for
> calculating the square root through vhdl. But this square root function
> takes the real input,
> while i have integer/std_logic_vector. Can anybody tell me how can i
> convert integer nto real and again real in integer, so i can use vhdl
> square root function.

A := INTEGER(SQRT(REAL(B));

where B is REAL and A is INTEGER.

Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr

Ray Andraka

unread,
Sep 6, 2000, 8:45:33 AM9/6/00
to
Keep in mind that this is not synthesizable.

--
-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 or http://www.fpga-guru.com

Renaud Pacalet

unread,
Sep 6, 2000, 9:50:21 AM9/6/00
to
Renaud Pacalet wrote:
>
> vin...@mailexcite.com wrote:
> >
> > Hello all
> > I want to use IEEE's sqrt function(defined in math_real) for
> > calculating the square root through vhdl. But this square root function
> > takes the real input,
> > while i have integer/std_logic_vector. Can anybody tell me how can i
> > convert integer nto real and again real in integer, so i can use vhdl
> > square root function.
>
> A := INTEGER(SQRT(REAL(B));
>
> where B is REAL and A is INTEGER.
>

Oops,

Where A and B are INTEGER.

Ray Andraka

unread,
Sep 6, 2000, 12:26:33 PM9/6/00
to
Still not synthesizable. Synthesizers don't recognize type real, even for
generation of constants. The SQRT function, as well as all the other math_real
functions are strictly for use in testbenches. You'll have to either write your
own or use a third party's SQRT macro to make a synthesizable square root.

--

Renaud Pacalet

unread,
Sep 7, 2000, 3:04:23 AM9/7/00
to
Ray Andraka wrote:
>
> Still not synthesizable. Synthesizers don't recognize type real, even for
> generation of constants. The SQRT function, as well as all the other math_real
> functions are strictly for use in testbenches. You'll have to either write your
> own or use a third party's SQRT macro to make a synthesizable square root.

You're perfectly right Ray. But as we are on comp.lang.vhdl and not
comp.lang.synopsys I think we can talk about a language that is
named VHDL even when what we are debating is not synthesizable.
Especially when one asks about real type, pointers or physical
types without even mentioning synthesis. More generally I think
there is a danger in making a confusion between the language and the
tools. CAD vendors don't define the language, whatever their
specific needs and limitations are.

But once again you're right: real types and square roots are not
directly synthesizable today with the logic synthesizers I know.

Dave Higton

unread,
Sep 7, 2000, 5:21:18 PM9/7/00
to
In message <39B66FBD...@andraka.com>
Ray Andraka <r...@andraka.com> wrote:

> Still not synthesizable. Synthesizers don't recognize type real, even for
> generation of constants.

But why do we have this limitation? I've wanted to use real, as you
said, for generation of a constant. It didn't require synthesis of
logic to deal with real numbers at any stage. I think it's an
unnecessary limitation, and one I'd like to see removed. How do
others feel? Or is there some reason (invisible to me) that means it
would be impossible?

Dave

Ray Andraka

unread,
Sep 7, 2000, 7:57:43 PM9/7/00
to
I'd like to see that removed too. It is a royal PITA getting tables of
constants for things like arctangent tables into synthesizable code without the
ability for synthesizers to be able to use reals at least for compile time
constants.

--

ed.m...@snellwilcox.com

unread,
Sep 8, 2000, 7:07:13 AM9/8/00
to
You mean like:

TYPE lookup_type IS ARRAY(0 TO 31) OF REAL;
CONSTANT lookup : lookup_type :=
(
7.853981634e-1,
4.636476090e-1,
2.449786631e-1,
1.243549945e-1, etc etc.

Works fine in Exemplar Leonardo.

--Edward Moore.

In article <39B82AFE...@andraka.com>,


Ray Andraka <r...@andraka.com> wrote:
> I'd like to see that removed too. It is a royal PITA getting tables
of
> constants for things like arctangent tables into synthesizable code
without the
> ability for synthesizers to be able to use reals at least for compile
time
> constants.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Dave Higton

unread,
Sep 10, 2000, 4:51:23 PM9/10/00
to
In message <39B82AFE...@andraka.com>
Ray Andraka <r...@andraka.com> wrote:

> I'd like to see that removed too. It is a royal PITA getting tables of
> constants for things like arctangent tables into synthesizable code without the
> ability for synthesizers to be able to use reals at least for compile time
> constants.
>
> Dave Higton wrote:
> >
> > In message <39B66FBD...@andraka.com>
> > Ray Andraka <r...@andraka.com> wrote:
> >
> > > Still not synthesizable. Synthesizers don't recognize type real, even for
> > > generation of constants.
> >
> > But why do we have this limitation? I've wanted to use real, as you
> > said, for generation of a constant. It didn't require synthesis of
> > logic to deal with real numbers at any stage. I think it's an
> > unnecessary limitation, and one I'd like to see removed. How do
> > others feel? Or is there some reason (invisible to me) that means it
> > would be impossible?

OK, but - where does the limitation arise? Does the LRM say that tools
must not do it? (Probably not...) Or do we just have tools which are
minimally conformant? Or what?

To clarify, what I'd like is for my synthesis tool to be able to do
real arithmetic *at* *compile* *time*, and to be able to generate
integer constants as a result of this real arithmetic - if I use the
correct conversion functions. It would seem easy. At the moment, I
don't even get this with FPGA Express.

Dave

Ray Andraka

unread,
Sep 10, 2000, 10:40:44 PM9/10/00
to

Exactly what I'd like to see. Don't get it with Synplicity (at least last time
I checked...two versions ago). Someone said they could do it with exemplar.

> OK, but - where does the limitation arise? Does the LRM say that tools
> must not do it? (Probably not...) Or do we just have tools which are
> minimally conformant? Or what?
>
> To clarify, what I'd like is for my synthesis tool to be able to do
> real arithmetic *at* *compile* *time*, and to be able to generate
> integer constants as a result of this real arithmetic - if I use the
> correct conversion functions. It would seem easy. At the moment, I
> don't even get this with FPGA Express.
>
> Dave

--

Mike Treseler

unread,
Sep 11, 2000, 6:13:21 PM9/11/00
to
Ray Andraka wrote:
>
> Exactly what I'd like to see. Don't get it with Synplicity (at least last time
> I checked...two versions ago). Someone said they could do it with exemplar.

Yes. You can define constants using math functions with exemplar.

-- mike.t...@flukenetworks.com or
-- tr...@tc.fluke.com

Ray Andraka

unread,
Sep 11, 2000, 8:13:34 PM9/11/00
to
Can you define them using math functions that return reals? Specifically, Can
you use a function from ieee.math_real to define a compile time constant such as

constant real:pi:=3.141592;
constant sine_pi_over_8:integer:=to_integer((2.**16)*sine(2.0*pi/16.0));

I tried it again in symplicity and get an error stating something like can't
implement functions using ufcalls or something like that.

--

Mike Treseler

unread,
Sep 13, 2000, 3:00:00 AM9/13/00
to
Ray Andraka wrote:
>
> Can you define them using math functions that return reals? Specifically, Can
> you use a function from ieee.math_real to define a compile time constant such as
>
> constant real:pi:=3.141592;
> constant sine_pi_over_8:integer:=to_integer((2.**16)*sine(2.0*pi/16.0));
>
> I tried it again in symplicity and get an error stating something like can't
> implement functions using ufcalls or something like that.


The following worked with exemplar with math_real in scope:

--Code
. . .
constant pi : real := 3.141592 ;
constant sin_pi_over_8 : integer := integer(round( (2.0)**16 * sin(2.0*pi/16.0) ));
. . .
begin
assert false report "Sin(pi)/8 uses " & integer'image(sin_pi_over_8) severity note;

--Transcript:

# ** note :
Sin(pi)/8 uses 25080

0 new messages