Re: [vhdl-200x] Directional records proposal

Hi Guys,
I'd forgotten just how important having an 'unconnected' port mode is until I
read Peter's post:
>
> From: Peter Flake <flake@elda.demon.co.uk>
> Date: Mon Jul 16 2012 - 03:59:03 PDT
>
> Hi Daniel,
>
> A bus master may have several slaves, each with a control signal back to the
> master. To represent the bus with a single record, there must be an array
> of control signals which are all connected to the master but not all are
> connected to each slave. This has already been discussed earlier in the
> thread.
>
> Brent Hayhoe's recent suggestion tackles this problem.
>
>
> Regards,
>
> Peter
>
So, let's re-define the record in a recursive manner:
     type master_r is
       record
         adr_vl : std_logic_vector(15 downto 0); -- Address
         dat_vl : std_logic_vector(15 downto 0); -- Data from master to slave
         we_l : std_logic; -- Write enable from master
         en_l : std_logic; -- Enable from master
       end record master_r;
     type slave_r is
       record
         sdt_vl : std_logic_vector(15 downto 0); -- Data from slave to master
         ack_l : std_logic; -- Acknowledge from slave
         err_l : std_logic; -- Error from slave
       end record slave_r;
and we need a means of generically defining slave ports, so lets
have an array for 2 slaves:
     subtype slave_jrt is natural range 2 downto 1;
     type slave_at is array(slave_jrt) of slave_r;
to give us our overall record type of:
     type cpu_bus_r is
       record
         master_rl : master_r; -- bus from master
         slave_al : slave_at; -- buses from slaves
       end record cpu_bus_r;
which now leads to a more compact entity declaration:
     entity master is
       port (
         clk_i : in std_logic;
         bus_rio : record (
           master_rl : out master_r;
           slave_al : in slave_at
           ) cpu_bus_r;
         rst_i : in std_logic
        );
     end entity master;
and generically for the slaves:
     entity slave is
       generic (
         inst_jg : slave_jrt
       );
       port (
         clk_i : in std_logic;
         bus_rio : record (
           master_rl : in master_r;
           slave_al : array (
             inst_jg : out slave_r;
             others : unconn slave_r
             ) slave_at;
           ) cpu_bus_r;
         rst_i : in std_logic
       );
     end entity slave;
We have to have a new array element port mode assignment similar to the
record type's mode structure. This gives us the ability to generically assign
the slave port. I think the compiler should know enough about the array type's
structure to be able to build a template for instantiation at this point.
which then leads to instantiations as shown:
     signal clk_s : std_logic;
     signal cpu_bus_rs : cpu_bus_r;
     signal rst_s : std_logic;
     master_inst : master
       port map (
         clk_i => clk_s,
         bus_rio => cpu_bus_rs,
         rst_i => rst_s
       );
     slave_inst1 : slave
       generic map (
         inst_jg => 1
       )
       port map (
         clk_i => clk_s,
         bus_rio => cpu_bus_rs,
         rst_i => rst_s
       );
     slave_inst2 : slave
       generic map (
         inst_jg => 2
       )
       port map (
         clk_i => clk_s,
         bus_rio => cpu_bus_rs,
         rst_i => rst_s
       );
and this now looks quite compact and tidy.
Internally the slave's architecture would have to replicate the drive to all
ports of the slave array I think.
Thoughts?

-- 
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.