generic record exploration.

R

Rick North

Guest
Hi all,

Has anybody felt the need to know how many fields
there are in a record? I have, at least for the second level.

The reason is that I want to be able to change the number of
events that each member of the record have and also to be
able to add new members. The code snippet below shows my
intentions (hopefully). The Different Systems has in one case
a fix number of Events tied to them and they are stored in a
constant. Fair enough, but I want to be able to change the
number of Events for each Systems. Therefore, a record is
created containing each Systems with its events.

Now, the code should loop through the Systems Event in the
record looking for an event that corresponds to one defined
in the PKG and set MyEvent high if MyEnable is high.

Can anybody give a pointer or an alternative approach?

Regards,
RN

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package pkg_test is

type Systems is (Mike_sys, Peter_sys, Austin_sys, Paul_sys);

constant Lenght_of_Sel : natural := 5;

type events is (Alice_event, Bob_event, John_event, Adam_event);
type event_def is array (events) of unsigned(Lenght_of_Sel downto 0);
type event_definition_type is array (Systems) of event_def;

constant Event_definition : event_definition_type := (
Mike_sys => (
Alice_event => "000001",
Bob_event => "000010",
John_event => "000100",
Adam_event => "001000"),
Peter_sys => (
Alice_event => "111110",
Bob_event => "111101",
John_event => "111011",
Adam_event => "110111"),
Austin_sys => (
Alice_event => "100000",
Bob_event => "010000",
John_event => "001000",
Adam_event => "000100"),
Paul_sys => (
Alice_event => "000001",
Bob_event => "000010",
John_event => "000011",
Adam_event => "000100")
);

type ch_event_type is array (events) of std_logic;

-- test for records where the members don't have all possible events
type Mike_sys_Rec_type is
record
Alice_event : unsigned(Lenght_of_Sel downto 0);
Bob_event : unsigned(Lenght_of_Sel downto 0);
John_event : unsigned(Lenght_of_Sel downto 0);
Adam_event : unsigned(Lenght_of_Sel downto 0);
end record Mike_sys_Rec_type;
type Peter_sys_Rec_type is
record
Alice_event : unsigned(Lenght_of_Sel downto 0);
John_event : unsigned(Lenght_of_Sel downto 0);
Adam_event : unsigned(Lenght_of_Sel downto 0);
end record Peter_sys_Rec_type;
type Austin_sys_Rec_type is
record
Alice_event : unsigned(Lenght_of_Sel downto 0);
Bob_event : unsigned(Lenght_of_Sel downto 0);
Adam_event : unsigned(Lenght_of_Sel downto 0);
end record Austin_sys_Rec_type;
type Paul_sys_Rec_type is
record
Alice_event : unsigned(Lenght_of_Sel downto 0);
Bob_event : unsigned(Lenght_of_Sel downto 0);
end record Paul_sys_Rec_type;

type Rec_sys_type is
record
Mike_sys : Mike_sys_Rec_type;
Peter_sys : Peter_sys_Rec_type;
Austin_sys : Austin_sys_Rec_type;
Paul_sys : Paul_sys_Rec_type;
end record Rec_sys_type;

constant Rec_sys_con : Rec_sys_type := (
Mike_sys => (
Alice_event => "100001",
Bob_event => "100010",
John_event => "100100",
Adam_event => "101000"),
Peter_sys => (
Alice_event => "010001",
John_event => "010100",
Adam_event => "011000"),
Austin_sys => (
Alice_event => "000011",
Bob_event => "000110",
Adam_event => "001100"),
Paul_sys => (
Alice_event => "001111",
Bob_event => "011111")
);
end package pkg_test;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.pkg_test.all;

entity Test is
generic (
System : Systems := Mike_sys);
port (
clk : in std_logic;
reset : in std_logic;
MyEnable : in std_logic;
EventOn : in ch_event_type;
SelEvent : in unsigned(Lenght_of_Sel downto 0);
MyEvent : out std_logic
);
end entity;

architecture beh of test is
begin

P_a : process (clk, reset) is
variable AtLeastOneTrue : boolean := false;
begin -- process P_a
if reset = '1' then -- asynchronous reset (active
high)
MyEvent <= '0';
AtLeastOneTrue := false;
elsif clk'event and clk = '1' then -- rising clock edge


-------------------------------------------------------------------------
-- Record atempt
-- Don't know howto use a generic in a record pointer nor howto
use it in
-- a loop
-- for n in (Rec_sys_con.(System)'low to
Rec_sys_con.(System)'high) loop
-- if Rec_sys_con.System.(n) = SelEvent then
-- MyEvent <= EventOn(n) and MyEnable;
-- AtLeastOneTrue := true;
-- end if;
-- end loop; -- n


-------------------------------------------------------------------------
-- constant array atempt
for k in events'low to events'high loop
if Event_Definition(Mike_sys)(k) = SelEvent then
MyEvent <= EventOn(k) and MyEnable;
AtLeastOneTrue := true;
end if;
end loop; -- k

-- This assertion might be done more effective somehow...
assert AtLeastOneTrue report "Event does not exist in
Event_definitions" severity error;
AtLeastOneTrue := false;
end if;
end process P_a;

end beh;
 
On 26 Jul 2005 06:02:29 -0700, "Rick North"
<dontreplytothisaddy@hotmail.com> wrote:

Hi all,

Has anybody felt the need to know how many fields
there are in a record? I have, at least for the second level.
Click to expand...
Whilst I think I see what you're driving at, I also think that
there is a simpler way.

All your complicated records are being used simply to configure
the system, yes? So I think it would be OK instead to
build them all as arrays, using enumerations to do the
indexing as you have already done. Of course, some of the
elements will be full of zeros (the elements that are missing
from some of your records) but at least you will know the shape
of them, and how to access any field in them.

If you really want to have "missing" items, then you could
also consider maintaining an array of booleans, also indexed
by the enumeration type, saying which elements exist (true)
and which are to be ignored (false).

Changing the number of elements in an array is as simple as
changing the type definition that defines the enumeration
used to index the array.

With everything in arrays indexed by enumerations, you can
simply loop your way through the subscripts, locating places
where your enable flag is true. Given that the whole
configuration structure is a constant, synthesis will surely
optimise away all the parts that are unused, even though you
were obliged to create the data indicating that "unused-ness".

Sorry if I've missed your point. Your example is quite
intricate and it's not clear at a glance (not to me, anyhow)
what you're trying to achieve.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Hi Jonathan,

All your complicated records are being used simply to configure
the system, yes? So I think it would be OK instead to
build them all as arrays, using enumerations to do the
indexing as you have already done. Of course, some of the
elements will be full of zeros (the elements that are missing
from some of your records) but at least you will know the shape
of them, and how to access any field in them.
Yes I am guilty of trying to make new use of records. I like the record
Click to expand...
structure allot and use it frequently.

If you really want to have "missing" items, then you could
also consider maintaining an array of booleans, also indexed
by the enumeration type, saying which elements exist (true)
and which are to be ignored (false).
I do appreciate the array way, but my aim for sticking with records
Click to expand...
is the way the different post are encapsulated with name and all
spelled out. I think records give a more readable code and does not
force me to have all sub post in the same manner, ie,
unsigned(7 dowto 0) for all post where I might what to have some
unsigned vectors, some signed vectors with different length. But
that of course is in the eye of the beholder.

For a record like :
type MyRecord_type is
record
Alice : unsigned(5 downto 0);
Bob : signed(9 downto 0);
John :Boolean;
Adam :bit;
end record MyRecord_type;
It would be nice to have an attribute something like this.
MyRecord'members which will return (Alice, Bob, John, Adam)

And in the other way around used in a loop
For n in MyRecord'members'left to MyRecord'members'right loop
If MyRecord.n'member = SomeThing then
Do this..
Else
Do that...
End if;
End loop;

Changing the number of elements in an array is as simple as
changing the type definition that defines the enumeration
used to index the array.

With everything in arrays indexed by enumerations, you can
simply loop your way through the subscripts, locating places
where your enable flag is true. Given that the whole
configuration structure is a constant, synthesis will surely
optimise away all the parts that are unused, even though you
were obliged to create the data indicating that "unused-ness".
Seems to be what I have to live with.
Click to expand...

Sorry if I've missed your point. Your example is quite
intricate and it's not clear at a glance (not to me, anyhow)
what you're trying to achieve.
No you seam to have grasped the idea. Although the lack of comments in
Click to expand...
the code:) Thank you for your comments.

Cheers,
/R N
 
Rick,
You should consider submitting this as a VHDL feature
enhancement request. For now, these can be submitted
by following the enhancement request link which is on
the left side of the following page:
http://www.eda.org/vhdl-200x/

Cheers,
Jim Lewis


Hi Jonathan,


All your complicated records are being used simply to configure
the system, yes? So I think it would be OK instead to
build them all as arrays, using enumerations to do the
indexing as you have already done. Of course, some of the
elements will be full of zeros (the elements that are missing
from some of your records) but at least you will know the shape
of them, and how to access any field in them.

Yes I am guilty of trying to make new use of records. I like the record
structure allot and use it frequently.


If you really want to have "missing" items, then you could
also consider maintaining an array of booleans, also indexed
by the enumeration type, saying which elements exist (true)
and which are to be ignored (false).

I do appreciate the array way, but my aim for sticking with records
is the way the different post are encapsulated with name and all
spelled out. I think records give a more readable code and does not
force me to have all sub post in the same manner, ie,
unsigned(7 dowto 0) for all post where I might what to have some
unsigned vectors, some signed vectors with different length. But
that of course is in the eye of the beholder.

For a record like :
type MyRecord_type is
record
Alice : unsigned(5 downto 0);
Bob : signed(9 downto 0);
John :Boolean;
Adam :bit;
end record MyRecord_type;
It would be nice to have an attribute something like this.
MyRecord'members which will return (Alice, Bob, John, Adam)

And in the other way around used in a loop
For n in MyRecord'members'left to MyRecord'members'right loop
If MyRecord.n'member = SomeThing then
Do this..
Else
Do that...
End if;
End loop;


Changing the number of elements in an array is as simple as
changing the type definition that defines the enumeration
used to index the array.

With everything in arrays indexed by enumerations, you can
simply loop your way through the subscripts, locating places
where your enable flag is true. Given that the whole
configuration structure is a constant, synthesis will surely
optimise away all the parts that are unused, even though you
were obliged to create the data indicating that "unused-ness".

Seems to be what I have to live with.


Sorry if I've missed your point. Your example is quite
intricate and it's not clear at a glance (not to me, anyhow)
what you're trying to achieve.

No you seam to have grasped the idea. Although the lack of comments in
the code:) Thank you for your comments.

Cheers,
/R N
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top