I strongly agree. In the current language, directionality has little to do with data type. And I feel it muddies the language to confuse the two. (I admit I'm somewhat of a purist.) I really like the user-defined modes (i.e. augmenting IN, OUT, INOUT, ...), but putting the information in the type/subtype feels wrong.
And I'm going to repeat myself, hopefully more clearly and for the last time. :-) I don't think the shared bus example is compelling. WISHBONE in particular has an INTERCON concept that handles complex interconnections between master(s) and slave(s) that allows the master and slave interfaces to remain simple and consistent -- and reusable. I guess I have a hard time liking a feature and syntax in an example design that I don't care for. (I don't mean to impugn the skills of the proposers. I rather dislike the style of some of our most talented designers here. Most likely the feeling is mutual, though we get along and work together quite well. :-)
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, August 22, 2012 5:10 AM
To: vhdl-200x@eda.org
Cc: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Records with diectional subtypes
Don't you have an issue with the concepts of type vs subtype and the determination of drivers? Types get resolved statically, subtypes are not (in general) determined until run-time. Is it not the case that pushing mode info into the subtype makes it too late to determine the drivers of the signals? How is this supposed to be implemented (in the tool)?
Apart from that, the notion of pushing modes into subtypes seems to contradict the conceptual framework of VHDL. But perhaps that's just me being unimaginative ;-)
Cheers,
John A
-----owner-vhdl-200x@eda.org wrote: -----
To: vhdl-200x@eda.org
From: Brent Hayhoe
Sent by: owner-vhdl-200x@eda.org
Date: 08/21/2012 11:18PM
Subject: Re: [vhdl-200x] Records with diectional subtypes
Regardless of what has been suggested so far, I'm going to rewrite the
example with Jim's suggested new syntax and a few modification's of my
own. Please pull it apart and see if it makes sense.
So, types in a package first:
package cpu_bus_pkg is
type t_cpu_bus is record
adr : std_logic_vector(15 downto 0); --Address
dat : std_logic_vector(15 downto 0); --Data from master to slave
we : std_logic; --Write enable from master
en : std_logic_vector(7 downto 0); --Enable from master
sdt : std_logic_vector(15 downto 0); --Data from slave to master
ack : std_logic; --Acknowledge from slave
err : std_logic; --Error from slave
end record;
subtype t_master is t_cpu_bus port(
adr, dat, we, en : out;
sdt, ack, err : in);
subtype t_id is natural range 7 downto 0;
subtype t_slave is t_cpu_bus generic(
j : t_id)
port(
adr, dat, we, en(j) : in;
sdt, ack, err : out;
en(others) : null);
end package cpu_bus_pkg;
--Master entity
use work.cpu_bus_pkg.all
entity master is
port (
clk : in std_logic;
bus : t_master
);
end entity master;
--Slave entity
use work.cpu_bus_pkg.all
entity slave is
generic (
id : t_id
);
port (
clk : in std_logic;
bus : t_slave(id) --generic mapped through to subtype
);
end entity slave;
--Top level
use work.cpu_bus_pkg.all
signal cpu_bus : t_cpu_bus;
i_master : master
port map (
clk => clk,
bus => cpu_bus
);
i_slave_id : slave
generic map (
id => 4 --internally 'bus.en(id)' is the only enable port that exists
)
port map (
clk => clk,
bus => cpu_bus --and is mapped to 'cpu_bus.en(4)'
);
"JimLewis Question: Can we extend this to also allow open in the subtype? The
following slave does not use the we element (perhaps it is read only): "
BrentHayhoe: I've altered this to 'null' rather than 'open'. To me 'open' infers
the port is still there on the slave entity, just not connected. A 'null'
port would mean it doesn't exist within the slave entity. From the top
level instantiation point of view, it is a WOM. It has no driver and
cannot be read, but it provides connectivity at this level.
"JimLewis Question: Can we allow some ports to not use all elements? In the
following, the slave does not use all of the en "
BrentHayhoe: However we look at it, we definitely need a form of generic
mechanism in the slave subtype.
"JimLewis Question: Inside the slave is en seen as en(1) or just en? Is there
a notation that allows just en? "
BrentHayhoe: I think it has to be seen as 'en(id)' as the generic needs to be
mapped for the instantiation.
"JimLewis Question: Can we use others with open? "
BrentHayhoe: Using 'others' is cool I think.
This suggestion has added a generic part to the 'port mode' of the record subtype, is it viable?
Can anyone rewrite this example using deferred mapping as Jim suggested:
subtype t_slave is t_cpu_bus port(
adr, dat, we, en(array <>) : in;
sdt, ack, err : out;
en(others) : open);
--
Regards,
Brent Hayhoe.
Aftonroy Limited Telephone: +44 (0)20-8449-1852
135 Lancaster Road,
New Barnet, Mobile: +44 (0)79-6647-2574
Herts., EN4 8AJ, U.K. Email: Brent.Hayhoe@Aftonroy.com
Registered Number: 1744190 England.
Registered Office:
4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
=
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Aug 22 08:12:11 2012
This archive was generated by hypermail 2.1.8 : Wed Aug 22 2012 - 08:12:59 PDT