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, 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 04:11:27 2012
This archive was generated by hypermail 2.1.8 : Wed Aug 22 2012 - 04:11:57 PDT