Re: [vhdl-200x] Directional records proposal

2012/7/15 Brent Hayhoe <Brent.Hayhoe@aftonroy.com>:
> 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.
>

This is an interesting idea. A bit too verbose compared to what I
originally had in mind, but it seems to get the job done.

If we go down this route, I'm not sure we really need to introduce a
record in the port though. Wouldn't it just be sufficient with a dot
notation?

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

-- 
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design