for language experts: generic lower in list may reference generics higher in list

A

albert.neu

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
 
A

albert.neu

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
 
A

Andy

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
 
H

Hans

Perhaps this is answering your question?

http://www.accellera.org/apps/group...ing-generics-within-the-generic-clause-V1.pdf

Hans
www.ht-lab.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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top