Visite Webhosting Latino, el site sobre alojamiento web.
Generics vs Constants - what criteria do you use to choose between these? - Mombu the Programming Forum
Mombu the Programming Forum sponsored links

Go Back   Mombu the Programming Forum > Programming > Generics vs Constants - what criteria do you use to choose between these?
User Name
REGISTER NOW! Mark Forums Read

sponsored links

1 4th June 13:28
External User
Posts: 1
Default Generics vs Constants - what criteria do you use to choose between these?


I just want to be able to declare a record type, and then be able to
declare one or more named modes for that type that indicate the
individual modes on each element of the record for use in a port
declaration. Note that for a record of records, you would also have a
"mode of modes".

For example, say I wanted to define a processor bus, and hook it up
between a cpu and a peripheral. Both cpu and periph attach to the same
signal (of type bus) but the cpu and peripheral drive/read different
signals within that bus.

Here is an idea of what I would like to be able to do, both for
synthesis and testbenches :

library ieee;
use ieee.std_logic_1164.all;

package bus_types is

-- abbreviations
subtype slv is std_logic_vector;
subtype sl is std_logic;

-- typedefs
type bus_t is
addr : slv(0 to 35);
as_n : sl;
aack_n: sl;
data : slv(0 to 63);
ds_n : sl;
dack_n: sl;
ts : slv(0 to 2);
tt : slv(0 to 3);
end record bus_t;

-- mode defs
mode master of bus_t is -- new keyword "mode"???
addr : out; -- only the name of the element need be repeated, not
its type
as_n : out; -- so changes in element types do not ripple to mode
aack_n : in;
data : inout;
ds_n : out;
dack_n: in;
ts : out;
tt : out;
end mode master;

mode slave of bus_t is
addr : in;
as_n : in;
aack_n : out;
data : inout;
ds_n : in;
dack_n : out;
ts : in;
tt : in;
end mode slave;

end package bus_types;

use work.bus_types.all;
entity periph is
port (pbus: slave bus_t); -- compiler selects & verifies mode slave
exists for type bus_t
end entity periph;

use work.bus_types.all;
entity cpu is
port (pbus: master bus_t);
end entity cpu;

Then in some architecture, I could:

architecture some of thing is

signal mybus: bus_t;


u1: entity work.cpu(rtl)
port map (pbus => mybus);

u2: entity work.periph(rtl)
port map (pbus => mybus);

end architecture rtl;

In more complex examples, this could be used to quickly and easily
plumb complex ports up/down through multiple levels of the hierarchy,
in a "virtual" way such that the type and mode definitions can be
changed, but the entities/architectures along the way remain unchanged.
Think of a record/mode combination as a handle by which to abstract
the interface.

I could also use it in procedure calls in a testbench, such as write(),
read(), or respond();

  Reply With Quote

  sponsored links


Thread Tools
Display Modes

Copyright 2006 - Dies Mies Jeschet Boenedoesef Douvema Enitemaus -