Generic Arrays

Hi,

I have the following problem:

There is an entity, which serves as an interface for
n applications (n is generic).

Example:

entity random is
generic (n: integer);
port (
any_vector: in std_logic_vector(n-1 downto 0);
any_other: out std_logic_vector(n-1 downto 0)
);
end entity;

architecture more_random of random is
type vector_array is array (0 to (n-1)) of std_logic_vector(15 downto 0);

begin
--do something with any_vector and vector_array to produce any_other
end more_random;

So far, so good.

But now I want to use the type "vector_array" for a port of the entity.
Something like:
entity random is
generic (n: integer);
port (
any_vector: in std_logic_vector(n-1 downto 0);
any_more: in vector_array;
any_other: out std_logic_vector(n-1 downto 0)
);
end random;

Where can I put the type definition into?

If I put it in an external library, the compiler moans about the unknown n.
If I put it in the entity-header in front of the ports, the compiler moans, that
the entity-header should end after the type declaration.
If I put it in the entity-header after the ports, the compiler moans about the
unknown type "vector_array".

Is there a solution for this? In the component declaration one level above
there is no problem:

architecture bla of blue is
type vector_array is array (0 to (n-1)) of std_logic_vector(15 downto 0);
component random is
generic (n: integer);
port (
any_vector: in std_logic_vector(n-1 downto 0);
any_more: in vector_array;
any_other: out std_logic_vector(n-1 downto 0)
);
end component;

Regards
Joachim

Joachim Parsch

On Aug 30, 7:23 am, Joachim Parsch <s...@bunuel.franken.de> wrote:
> Hi,
>
> I have the following problem:
<snip>
Change your definition of vector_array from...

type vector_array is array (0 to (n-1)) of std_logic_vector(15 downto
0);

to this...

type vector_array is array (natural range <>) of std_logic_vector(15
downto 0);

and put the type definition in a package. When you go to USE this new
type you'll then specify the range. In your example of the entity it
would be....

entity random is
generic (n: integer);
port (
any_vector: in std_logic_vector(n-1 downto 0);
any_more: in vector_array(n-1 downto 0);
any_other: out std_logic_vector(n-1 downto 0)
);
end random;

On a side note, don't bother with component definitions. In case you
haven't noticed it is basically identical to the entity definition
which means that you end up defining things twice...which then almost
inevitably leads to the situation where one of them gets changed but
not the other and you end up getting sometimes difficult to fathom
simulator errors when you try to start up a sim.

When you instantiate your widget that has a component definition you
will do it something like this...

U1 : random generic map(...) port map (...);

If you don't have a component definition you would instantiate the
same widget like this...

U1 : entity work.random generic map(...) port map (...);

Slightly more typing but much less when you factor in the typing (or
copy/paste) that is involved in creating the component definition.
Google for direct entity instantation (added in VHDL '93) for more
info on this technique.

KJ

KJ

Hi,

KJ schrieb:
[snip]

Thanks for the tip - "natural range" seems quite useful.

> On a side note, don't bother with component definitions. In case you
> haven't noticed it is basically identical to the entity definition

Yes - it's just copy & paste and changing entity to component...

> which means that you end up defining things twice...which then almost
> inevitably leads to the situation where one of them gets changed but
> not the other and you end up getting sometimes difficult to fathom
> simulator errors when you try to start up a sim.

If some errors seem unexplainable, it's indeed a good idea to recompile
everything.

> When you instantiate your widget that has a component definition you
> will do it something like this...
>
> U1 : random generic map(...) port map (...);
>
> If you don't have a component definition you would instantiate the
> same widget like this...
>
> U1 : entity work.random generic map(...) port map (...);
>
> Slightly more typing but much less when you factor in the typing (or
> copy/paste) that is involved in creating the component definition.
> Google for direct entity instantation (added in VHDL '93) for more
> info on this technique.

This feature is actually new to me - it is mentioned in none of
the VHDL references I use.

Joachim

Joachim Parsch

On Aug 30, 9:33 am, Joachim Parsch <s...@bunuel.franken.de> wrote:
>
> If some errors seem unexplainable, it's indeed a good idea to recompile
> everything.
>
Unfortunately recompiling everything still will not catch the problem
when you have a component definition that is different from the
entity. Everything will compile just fine, when you start up the
simulation and the 'elaboration' phase is going on it ties everything
together (called 'binding') and at that point you get the error that
it can't find the proper entity to bind because the entity that it was
expecting (i.e. what was defined in the component definition) does not
exist (because the actual entity definition is different than the
component). If there are only a handful of input/outputs you can
probably spot the problem, if not then you scratch your head looking
for the difference. If instead you use the direct entity
instantiation method, the compiler will catch and flag the error for
you telling you that port 'such and such' is of one type but it is
attached to signal 'this and that' which is something else.

What component definitions bring is the ability to defer the actual
entity definition until 'later'. In practice it really isn't of much
help at all (in my opinion) because of the above mentioned problem.
The one exception being when the entity is some 'black box' (i.e. some
third party purchased/provided hunk of logic that you don't have the
source files for) but in that situation you're not writing the entity
definition in the first place and whoever is the provider of the
'black box' component has probably already provided you with the
interface to that part (possibly in the form of a component, possibly
as an example of how to instantiate the part).

KJ

KJ