Synthesis of math_real package

[Nicolas Matringe]

Hello all
I was wondering if the log2 function of the math_real package was
synthesizable in generic or constant declaration.
The idea is (obviously) to determine a vector length based on the
highest number it must represent (typically address size based on memory
depth)
I know I can define my own log2 function but I'd rather not define a
package only for this

Thanks in advance
Nicolas

 

[Mike Treseler]

Nicolas Matringe wrote:

I was wondering if the log2 function of the math_real package was
synthesizable in generic or constant declaration.

In Quartus, functions of reals work fine for constant declarations
as long as the result is casted to integer or natural
before it is used.

The idea is (obviously) to determine a vector length based on the
highest number it must represent (typically address size based on memory
depth)
I know I can define my own log2 function but I'd rather not define a
package only for this

I use this one:

function min_len_uns(arg : natural) return natural is
begin
case arg is
when 1 | 0 =>
return 1;
when others =>
return 1 + min_len_uns(arg/2);
end case;
end;

You could put it in the declarations
if you don't want a package.

-- Mike Treseler

 

[KJ]

On Feb 5, 12:51 pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:

Hello all
I was wondering if the log2 function of the math_real package was
synthesizable in generic or constant declaration.
The idea is (obviously) to determine a vector length based on the
highest number it must represent (typically address size based on memory
depth)
I know I can define my own log2 function but I'd rather not define a
package only for this

Thanks in advance
Nicolas

Whether or not math_real.log2 is 'synthesizable' or not would depend
on the tool you are using and whether or not it is smart enough to
support math_real.log2 for purposes of the computation of constants.
You'll have to try it for yourself and see.

For what it's worth, Quartus correctly synthesizes the manipulations
shown in the sample code below which compute an sRGB->RGB lookup
table. This computation requires use of the 'exp' and 'log'
functions.

Having said all that, I still use the commonly available synthesizable
version of log2 for computing vector widths just in case vendor
support of 'math_real.log2' is spotty.

Kevin Jennings


-------- Sample code to compute an sRGB->RGB conversion lookup table
------

constant sRGB_To_RGB_Table: work.pkg_vhd_common.arr_natural(0 to
TABLE_SIZE) :work.pkg_Color_Space_Conversions.sRGB_To_RGB_Table(TABLE_SIZE);

where the functions required to do all the dirty work are...

--------------------------------------------------------------------------------
-- sRGB to RGB color conversion function derived from the RGB to sRGB
definition
-- per Wikipedia, 10/15/2007
-- http://en.wikipedia.org/wiki/Srgb#Specification_of_the_transformation
--------------------------------------------------------------------------------
function sRGB_To_RGB(x: real range 0.0 to 1.0 ) return real is
variable RetVal: real;
begin
if (x <= 12.92 * 0.0031308) then
RetVal := x / 12.92;
else
RetVal := exp(log((x + 0.055) / 1.055) * 2.4);
end if;
return(RetVal);
end function sRGB_To_RGB;

-----------------------------------------------------------------------------------
-- Function to return a pre-computed table that performs the sRGB to
RGB conversion
-----------------------------------------------------------------------------------
function sRGB_To_RGB_Table(L: positive) return
work.pkg_VHD_Common.arr_natural is
variable RetVal: work.pkg_VHD_Common.arr_natural(0 to L);
begin
for i in RetVal'range loop
RetVal(i) := natural(round(real(L) * sRGB_To_RGB(real(i) /
real(L))));
end loop;
return(RetVal);
end function sRGB_To_RGB_Table;

 

[Mike Treseler]

KJ wrote:

Sample code to compute an sRGB->RGB conversion lookup table

Nice example.
Thanks.

-- Mike Treseler

 

[nmatringe@gmail.com]

Mike Treseler a écrit :

Nicolas Matringe wrote:

I was wondering if the log2 function of the math_real package was
synthesizable in generic or constant declaration.

In Quartus, functions of reals work fine for constant declarations
as long as the result is casted to integer or natural
before it is used.

Who said I was targetting an Altera FPGA ?
The code will probably end up in an ASIC after a protyping phase in a
Spartan3.

I know I can define my own log2 function but I'd rather not define a
package only for this
[...]
You could put it in the declarations
if you don't want a package.

But I can not define a port width based on a generic this way, and
unconstrained port length are not well supported. At least they were
not a few years ago when I tried to use them.

Thanks anyway
Nicolas

 

[Mike Treseler]

nmatringe@gmail.com wrote:

Who said I was targetting an Altera FPGA ?

Not me. Like KJ said, check with your synthesis vendor.

-- Mike Treseler

 

[KJ]

<nmatringe@gmail.com> wrote in message
news:1177802f-6689-4120-88b0-cbfff5a09937@v46g2000hsv.googlegroups.com...
Mike Treseler a écrit :

Nicolas Matringe wrote:

I know I can define my own log2 function but I'd rather not define a
package only for this

Commonly useful things that are not project/design specific I put into a
'pkg_vhd_common' package which has a number of useful
functions/procedures....such as log2 and several others. Start with log2
and then start building up your own and you'll quickly find that there are a
number of things in your package so 'log2' won't be the lonely member.

You could put it in the declarations
if you don't want a package.

But I can not define a port width based on a generic this way, and
unconstrained port length are not well supported. At least they were
not a few years ago when I tried to use them.

You can define a vector in a port as a function of the generic...I've done
it with the function inside a package.

Kevin Jennings

 

[nmatringe@gmail.com]

On 6 fév, 15:53, "KJ" <kkjenni...@sbcglobal.net> wrote:

Commonly useful things that are not project/design specific I put into a
'pkg_vhd_common' package which has a number of useful
functions/procedures....such as log2 and several others. Start with log2
and then start building up your own and you'll quickly find that there are a
number of things in your package so 'log2' won't be the lonely member.

That's something I should consider doing, you're right.

You could put it in the declarations
if you don't want a package.

But I can not define a port width based on a generic this way, and
unconstrained port length are not well supported. At least they were
not a few years ago when I tried to use them.

You can define a vector in a port as a function of the generic...I've done
it with the function inside a package.

I know but as I said I wanted to avoid the definition of a package,
and use the math_real.log2 function instead.
I try to make portable code with the least possible personal packages.

Nicolas

 

[KJ]

<nmatringe@gmail.com> wrote in message
news:6e064aa7-e3a9-429f-b7c7-d11203bc2b77@u10g2000prn.googlegroups.com...
On 6 fév, 15:53, "KJ" <kkjenni...@sbcglobal.net> wrote:

You can define a vector in a port as a function of the generic...I've
done
it with the function inside a package.

I know but as I said I wanted to avoid the definition of a package,
and use the math_real.log2 function instead.
I try to make portable code with the least possible personal packages.

Understood, but unless the entire set of synthesis tools that you plan on
using all support math_real (and they might, but like I said before you have
to check) you'll be making your code less portable by using math_real.log2.

By the way, the code I posted demonstrating use of math_real functions and
stuff did not compile under Quarts 5.0 but does with 7.2 so somewhere
between 2005 and 2007 Altera added support for math_real for synthesis of
constants. You may not be considering Altera, my point is only that
'synthesizable' depends very strongly on the synthesis tool used and which
version is used.

Good luck, and if you can determine which tools do support math_real, you
might want to post the results up here.

Kevin Jennings

 

[Nicolas Matringe]

KJ a écrit :

Understood, but unless the entire set of synthesis tools that you plan on
using all support math_real (and they might, but like I said before you have
to check) you'll be making your code less portable by using math_real.log2.

That was the actual sense of my question : is it "generally" synthesizable ?
I'll probably code my own (I have done it in the past)

Nicolas