Passing Generics into a Package File

Is it possible to pass generics into a package file? A lot of the
constants in my package file are dependent upon an INPUT_WIDTH generic
in my main file.
-Kevin

Kevin Neilson

"Kevin Neilson" <> wrote in message
news:g106qt$...
> Is it possible to pass generics into a package file? A lot of the
> constants in my package file are dependent upon an INPUT_WIDTH generic in
> my main file.
> -Kevin

Not until VHDL2006/8 becomes available, see example below copied from one of
Jim Lewis' presentations:

package MuxPkg is
generic( type array_type) ;
function Mux4 (
Sel : std_logic_vector(1 downto 0);
A : array_type ;
B : array_type ;
C : array_type ;
D : array_type
) return array_type ;
end MuxPkg ;
package body MuxPkg is
.. . .
end MuxPkg ;

library ieee ;
package MuxPkg_slv is new work.MuxPkg
Generic map (array_type => ieee.std_logic_1164.std_logic_vector) ;

library ieee ;
package MuxPkg_unsigned is new work.MuxPkg
Generic map (array_type => ieee.numeric_std.unsigned
) ;

http://www.synthworks.com/papers/index.htm

Hans
www.ht-lab.com

HT-Lab

On May 21, 12:01*am, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:
> Is it possible to pass generics into a package file? *A lot of the
> constants in my package file are dependent upon an INPUT_WIDTH generic
> in my main file.
> -Kevin

Not today. One work around though until VHDL-2008 is real is to make
the thing that you'd like to be a generic in your main package file
instead dependent on a constant from yet another package. Then each
design would use their own customized package.

i.e.

-- Put this package in a separate file that is 'design specific'. It
would contain all the 'parameters' of the main package file
'pkg_Lots_Of_Good_Stuff' and nothing else.

package pkg_User_Constants is
constant INPUT_WIDTH: natural := 100;
end package pkg_User_Constants;

-- In your 'main' file
package pkg_Lots_Of_Good_Stuff is
constant Blah_Blah: real :=
log(work.pkg_User_Constants.INPUT_WIDTH);
...
end package pkg_Lots_Of_Good_Stuff;

Although it doesn't accomplish the goal of being able to parameterize
the main package itself, it does separate out all the user controls
into a separate package that is easier for someone to pick up and be
able to confidently make changes to it (i.e. create a new file with a
new 'pkg_User_Constants' package.

In the end, any code that would be written to *use* the parameterized
package would most likely have to have a unique design file that tells
it to use the package with the unique parameterization which is not
terribly different than having the unique design file be the one that
contains 'pkg_User_Constants'.

Where this breaks down though is if you need to use
'pkg_Lots_Of_Good_Stuff' with different parameters but in the same
design.

Kevin Jennings

KJ

On May 22, 7:53*am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 21 May 2008 05:10:42 -0700 (PDT), KJ <kkjenni...@sbcglobal.net>

>
> >Where this breaks down though is if you need to use
> >'pkg_Lots_Of_Good_Stuff' with different parameters but in the same
> >design.
>
> Another place it CAN break down is with tools that don't expect packages
> to be used in other packages.
>
> I had problems with XST 7.1 in that respect; it wouldn't find items from
> the "user_constants" package (Modelsim had no problem). I had to
> backtrack from that solution to including the text of the
> "user_constants" package.
>
> Newer versions may have solved that problem. (It may have been the GUI's
> inability to build libraries properly rather than XST itself; in which
> case, hand building project scripts would have solved the problem. I
> didn't fully investigate)
>

Good point, I can say that it does work with Quartus and I think I've
used this with Synplify without problems...the folks at brand X seem
to be a bit behind the competition in regards to synthesizing code for
whatever reason.

KJ

KJ