Re: [vhdl-200x] Directional records proposal

It has been a long time since I was on the code-writing side of the
business. However, IMO this would have less impact than embedding mode
information in the type definition. This keeps the mode attributed to the
port and not the type. In today's implementations, the mode is implicitly
propagated to all scalar elements of a port because compilers must be able
to treat all scalar elements of a port as individual signals (although
that can be optimized).

------------
Stephen Bailey
Director of Emerging Technologies, DVT
Mentor Graphics
www.Mentor.com

On 7/15/12 7:39 AM, "Brent Hayhoe" <Brent.Hayhoe@Aftonroy.com> wrote:

>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.
>
Received on Sun Jul 15 07:13:33 2012