How to declare a port with a new type

[Weng Tianxiang]

Hi,
I am in VHDL.

I have the following statements:

type integer_array is array(natural range <>) of integer;
type cs_type is array (0 to N) of integer_array (1 to Nmax);
signal cs : cs_type;

If those statements live within an architecture, everything goes well.

But if I make the signal cs as a port of the entity, the problem
arise:

I must specify integer_array and cs_type somewhere in the project
globally.

Is anything I can do to use the type declarations locally in the file
of the entity?

Thank you.

Weng

 

[Martin Thompson]

Hi,
I am in VHDL.

I have the following statements:

type integer_array is array(natural range <>) of integer;
type cs_type is array (0 to N) of integer_array (1 to Nmax);
signal cs : cs_type;

If those statements live within an architecture, everything goes well.

But if I make the signal cs as a port of the entity, the problem
arise:

I must specify integer_array and cs_type somewhere in the project
globally.

Is anything I can do to use the type declarations locally in the file
of the entity?

You have to put them in a package. The package can exist within the
same file as the entity though. Then things which instantiate that
entity can make use of the package to see the same definitions.

Be aware - just because it's in the same file doesn't mean you don't
have to do:

use work.my_package.all;

before the entity declaration!

Also be aware that if you put the package in the same file and compile
the file "normally", you'll have to recompile anything which depends
on the that package (as it's been touched). If you're using Modelsim,
you can use

vcom -just bac myfile.vhd

to compile just the package bodies, architetcures and configs, which
doesn't touch the package and entity declarations, which then don't
ripple on to other files.

If your compiler can't do something similar, you may be better to put
the package (and probably the entity) in a separate file to the
architecture, as it's the architecture which get's the most iteration
during the development of the code, and it's great to only have to
recompile the one file most of the time.

Cheers,
Martin

 

[Weng Tianxiang]

You have to put them in a package.  The package can exist within the
same file as the entity though.  Then things which instantiate that
entity can make use of the package to see the same definitions.

Be aware - just because it's in the same file doesn't mean you don't
have to do:

   use work.my_package.all;

before the entity declaration!

Also be aware that if you put the package in the same file and compile
the file "normally", you'll have to recompile anything which depends
on the that package (as it's been touched). If you're using Modelsim,
you can use

   vcom -just bac myfile.vhd

to compile just the package bodies, architetcures and configs, which
doesn't touch the package and entity declarations, which then don't
ripple on to other files.

If your compiler can't do something similar, you may be better to put
the package (and probably the entity) in a separate file to the
architecture, as it's the architecture which get's the most iteration
during the development of the code, and it's great to only have to
recompile the one file most of the time.

Cheers,
Martin

Hi Martin,
Thank you.

It seems the package definition is the only way to go.

I don't like it, but have to obey it.

Weng

 

[Martin Thompson]

Hi Martin,
Thank you.

It seems the package definition is the only way to go.

I don't like it, but have to obey it.

Why not? It makes sure you use the same definition everywhere in your
design.

As an aside, I have a standard package I use in all projects, which
has (amongst many other things) types for "array of int" and "array of
natural" in it. That way you avoid one of your type definitions
(which is a very general purpose one) being in a file-specific
package.

I guess it's too late for a "standard" package like that to take off
so we could all use the same "basic, useful but undefined by the
standard" types. Maybe I should publish lots of sample code with "use
ieee.std_martin_package.all" in it and see if I can replicate the "success"
of "std_logic_arith". Hmm... Can't seem to get my tongue out of my
cheek now

Cheers,
Martin

 

[Weng Tianxiang]

You have to put them in a package.  The package can exist within the
same file as the entity though.  Then things which instantiate that
entity can make use of the package to see the same definitions.

Be aware - just because it's in the same file doesn't mean you don't
have to do:

   use work.my_package.all;

before the entity declaration!

Also be aware that if you put the package in the same file and compile
the file "normally", you'll have to recompile anything which depends
on the that package (as it's been touched). If you're using Modelsim,
you can use

   vcom -just bac myfile.vhd

to compile just the package bodies, architetcures and configs, which
doesn't touch the package and entity declarations, which then don't
ripple on to other files.

If your compiler can't do something similar, you may be better to put
the package (and probably the entity) in a separate file to the
architecture, as it's the architecture which get's the most iteration
during the development of the code, and it's great to only have to
recompile the one file most of the time.

Cheers,
Martin

Hi Martin,
Thank you for your response.

It seems to be that to include a local package is the only way to do
properly.

Weng

 

[Weng Tianxiang]

Why not?  It makes sure you use the same definition everywhere in your
design.

As an aside, I have a standard package I use in all projects, which
has (amongst many other things) types for "array of int" and "array of
natural" in it.  That way you avoid one of your type definitions
(which is a very general purpose one) being in a file-specific
package.

I guess it's too late for a "standard" package like that to take off
so we could all use the same "basic, useful but undefined by the
standard" types.  Maybe I should publish lots of sample code with "use
ieee.std_martin_package.all" in it and see if I can replicate the "success"
of "std_logic_arith".  Hmm... Can't seem to get my tongue out of my
cheek now

Cheers,
Martin

Martin,
Here is an example why I don't like to use a global package file to
declare a often used signal type.

--********************************************* I like this version

type integer_array : array(natural range<>) of integer;

signal A : integer_array;

---------------------------------- I dislike this version

LIBRARY ieee;

-- SMS: state machine statement
Package Global_SMS_Constant is
type integer_array is array(natural range <>) of integer;
end Global_SMS_Constant;

----------------------------------

....
use work.Global_SMS_Constant.all; -- where is there goodness?

....

signal A : integer_array;
....

Weng

 

[Martin Thompson]

Martin,
Here is an example why I don't like to use a global package file to
declare a often used signal type.

--********************************************* I like this version

type integer_array : array(natural range<>) of integer;

signal A : integer_array;

---------------------------------- I dislike this version

LIBRARY ieee;

-- SMS: state machine statement
Package Global_SMS_Constant is
type integer_array is array(natural range <>) of integer;
end Global_SMS_Constant;

Well, when you've built that package up to contain all sorts of other
useful types, functions, procedures and the like it becomes as natural
to bring in as ieee.std_logic_1164.all. It's just part of getting the
job done. For a single type in a single file it's a bit of an
overhead, but for arrays of integers, that's a different case!

My standard package is over 700 lines long, has about 20 functions, 11
procedures and 4 types - most of which I use as a matter of course in
most modules I write (or their testbenches).

Cheers,
Martin

 

[Weng Tianxiang]

Well, when you've built that package up to contain all sorts of other
useful types, functions, procedures and the like it becomes as natural
to bring in as ieee.std_logic_1164.all.  It's just part of getting the
job done.  For a single type in a single file it's a bit of an
overhead, but for arrays of integers, that's a different case!

My standard package is over 700 lines long, has about 20 functions, 11
procedures and 4 types - most of which I use as a matter of course in
most modules I write (or their testbenches).  

Cheers,
Martin

Hi Martin,
Would you like to publish your full standard package for other's
reference?

Or would you like to send me a copy of it? I am surprising why you
have so many functions to use.

Thank you.

Weng

 

[Martin Thompson]

Hi Martin,
Would you like to publish your full standard package for other's
reference?

I would, but I can't - my employer owns it...

Or would you like to send me a copy of it? I am surprising why you
have so many functions to use.

Well, it's the accumulation of the last 10 years or so of my VHDL
development. And I'm the type of engineer who notices I've done the
same thing twice and think "hmmm, I ought to make this a bit more
generic and reusable". Then on the third or fourth time of reuse I
actually listen to myself

In addition, there are a number of overloaded functions which allow me
to do the same thing to various data types (integers, unsigned,
signed, etc...)

Cheers,
Martin