FPGA Central

Hello!

Here's I feature that would be nice to have in the Accellera
VHDL-2006 Rev:

Below the normal generic's list,
there can be another list of (let's call it generic_dep's, which
contain (lets call it generic_deps, that are like generics, only that
they derive from the original generics:

Here's an example:
There are input and output items whose width derives from a single
generic.
These items are stored linearly in concat_items_in and concat_items_out


------------------------------
entity test is

generic (
g_num_items : integer;
g_main_width_param : integer);

generic_dep (
g_width_item_in : integer := func_get_width_in(main_width_param);
g_width_item_out : integer :=
func_get_width_out(main_width_param));

port (
clk : in std_logic;
rst : in std_logic;

concat_items_in : in std_logic_vector(0 to
g_num_items*g_width_item_in-1);
concat_items_out : out std_logic_vector(0 to
g_num_items*g_width_item_out-1));

end test;
------------------------------

Now in the architecture it is easy to refer to g_width_item_in and
g_width_item_out




Why is this good?
It's good, because we can define generic_deps (from the generic_dep
list) that are dependant on the normal generics; and can use them in
*both* port_width declarations and the architecture.
Otherwise:

If we stick to our current VHDL of today, we would have to use this
instead:


------------------------------
entity test is

generic (
g_num_items : integer;
g_main_width_param : integer);

port (
clk : in std_logic;
rst : in std_logic;

concat_items_in : in std_logic_vector(0 to
g_num_items*func_get_width_in(main_width_param)-1);
concat_items_out : out std_logic_vector(0 to
g_num_items*func_get_width_out(main_width_param)-1));

end test;


architecture go of test is

constant width_item_in : integer :=
concat_items_in'length/g_num_items;
constant width_item_out : integer :=
concat_items_out'length/g_num_items;

begin

end go;
------------------------------



It works, but it's ugly


Comments welcome...

Regards,
Albert Neumüller

OR alternatively:


------------------------------
architecture go of test is

constant width_item_in : integer :=
func_get_width_in(main_width_param);
constant width_item_out : integer :=
func_get_width_out(main_width_param);

begin

end go;
------------------------------



It would be nice for generics lower in a list, to reference generics
higher in the same list.
But there are consequences that disallow that (reason: generics are set
in the generic map!)

However with generic_dep, it would be possible!
(There is no generic_dep map...)

Albert Neumüller

.... of course:
(main_width_param) should be (g_main_width_param)

This (constant definitions) is the preferred solution to your problem.

The change you request does not solve any problems that this does not,
but adds needless complexity to an already abundant language.

Andy

Perhaps this is answering your question?

http://www.accellera.org/apps/group_...-clause-V1.pdf

Hans
www.ht-lab.com


<[email protected]> wrote in message
news:[email protected] oups.com...
Hello!

Here's I feature that would be nice to have in the Accellera
VHDL-2006 Rev:

Below the normal generic's list,
there can be another list of (let's call it generic_dep's, which
contain (lets call it generic_deps, that are like generics, only that
they derive from the original generics:

Here's an example:
There are input and output items whose width derives from a single
generic.
These items are stored linearly in concat_items_in and concat_items_out


------------------------------
entity test is

generic (
g_num_items : integer;
g_main_width_param : integer);

generic_dep (
g_width_item_in : integer := func_get_width_in(main_width_param);
g_width_item_out : integer :=
func_get_width_out(main_width_param));

port (
clk : in std_logic;
rst : in std_logic;

concat_items_in : in std_logic_vector(0 to
g_num_items*g_width_item_in-1);
concat_items_out : out std_logic_vector(0 to
g_num_items*g_width_item_out-1));

end test;
------------------------------

Now in the architecture it is easy to refer to g_width_item_in and
g_width_item_out




Why is this good?
It's good, because we can define generic_deps (from the generic_dep
list) that are dependant on the normal generics; and can use them in
*both* port_width declarations and the architecture.
Otherwise:

If we stick to our current VHDL of today, we would have to use this
instead:


------------------------------
entity test is

generic (
g_num_items : integer;
g_main_width_param : integer);

port (
clk : in std_logic;
rst : in std_logic;

concat_items_in : in std_logic_vector(0 to
g_num_items*func_get_width_in(main_width_param)-1);
concat_items_out : out std_logic_vector(0 to
g_num_items*func_get_width_out(main_width_param)-1));

end test;


architecture go of test is

constant width_item_in : integer :=
concat_items_in'length/g_num_items;
constant width_item_out : integer :=
concat_items_out'length/g_num_items;

begin

end go;
------------------------------



It works, but it's ugly


Comments welcome...

Regards,
Albert Neumüller