Re: [vhdl-200x] Directional records proposal

It's really great to see so much interest in this topic. It's something that I
had hoped would have made it into the 2008 revision as this problem has been
bugging me for a long time.

I feared that it had been subsumed into the interface concept, which I believe
in itself could be an excellent addition to introduce into VHDL, but I believe
the record I/O problem should be solved in its own right and also not limited to
just a master and slave port concepts.

Forgive me if am I re-covering old ground, but I think the problem is not with
the record type itself, instead it resides within the port mode structure and
can be solved by the addition of a new mode (which seems to have been alluded to
in some posts).

I'd like to suggest looking at the problem from this different angle and so
given our record type definition:

    type cpu_bus_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
        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 cpu_bus_r;

we need a new a new port mode of, let's say 'record' (being a kind of
hierarchical mode):

    entity master is
      port (
        clk_i : in std_logic;
        bus_r : record (
          adr_vl : out std_logic_vector(15 downto 0);
          dat_vl : out std_logic_vector(15 downto 0);
          we_l : out std_logic;
          en_l : out std_logic;
          sdt_vl : in std_logic_vector(15 downto 0);
          ack_l : in std_logic;
          err_l : in std_logic
          ) cpu_bus_r;
        rst_i : in std_logic
       );
    end entity master;

    entity slave is
      port (
        clk_i : in std_logic;
        bus_rio : record (
          adr_vl : in std_logic_vector(15 downto 0);
          dat_vl : in std_logic_vector(15 downto 0);
          we_l : in std_logic;
          en_l : in std_logic;
          sdt_vl : out std_logic_vector(15 downto 0);
          ack_l : out std_logic;
          err_l : out std_logic
          ) cpu_bus_r;
        rst_i : in std_logic
       );
    end entity slave;

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_inst : slave
      port map (
        clk_i => clk_s,
        bus_rio => cpu_bus_rs,
        rst_i => rst_s
      );

I can imagine this may cause problems for compiler designers, but from a user
perspective I think it will cover all problem areas.

Functions could still use the existing format, as all ports by definition are
inputs and procedures would use the same new structure as entities (with the
'record' sub-modes being limited to 'in', 'out' or 'inout').

This does make the entity/component (and procedure) declarations more verbose,
but the instantiations will be quite compact. It should also allow recursive
record types to be mapped.

The instantiation mappings could still be expanded to individual element
mappings (cf. existing record or array elements), but we could also consider
another new mode type to allow an unconnected mapping for a particular record
element in an object that does not use that element.

The open keyword will work as a mapping, but the object then has to define an
unused 'out' element to be instantiated as 'open'. A new sub-mode of unconnected
would mean the port of that record would not have to be assigned or read from
within the object, but just defined in the declaration e.g.

    entity slave2 is
      port (
        clk_i : in std_logic;
        bus_rio : record (
          adr_vl : in std_logic_vector(15 downto 0);
          dat_vl : in std_logic_vector(15 downto 0);
          we_l : in std_logic;
          en_l : in std_logic;
          sdt_vl : out std_logic_vector(15 downto 0);
          ack_l : out std_logic;
          err_l : unconn std_logic
          ) cpu_bus_r;
        rst_i : in std_logic
       );
    end entity slave2;

Let's see what you all think.

Apologies for my verbosity and I hope I'm not talking complete hogwash!

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