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.