Guest
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
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