RE: EXTERNAL: Re: [vhdl-200x] Directional records proposal

I think the enumerated type of modes (type mode) is no longer needed. It is incomplete as soon as you define a new mode. It was suggested early in association with an array-type definition of composite modes which I believe was withdrawn.

The syntax for a mode declaration is still in work. I used "port mode" since mode is not a keyword but port already is. We need to ensure that the new syntax is sufficiently identifiable but not mistaken for any existing code. The less of the statement that has to be analyzed to do that, the better (enables better diagnostic messages). Maybe "mode" by itself can accomplish that?

mode m_master of t_cpu_bus is (...

--or-

port mode m_master of t_cpu_bus is (...

There has been some discussion about syntax for a non-all-inclusive subtype of a record. Is a parenthesized range (like an array) sufficient? Do we need a '.' before the '(range)'? Do we use a subrange declaration like that for an enumerated type, or like that of an array:

subtype t_cpu_bus_mosi is t_cpu_bus (adr to en); -- a record with adr, dat, we, en

--or --

subtype t_cpu_bus_miso is t_cpu_bus range sdt to err; -- a record with sdt, ack, err

Note that the whole issue of non-all-inclusive subtypes of records (and implicit types of record element names) is only very narrowly associated with composite modes. The only place where these intersect is in the potential syntax for the composite mode declaration.

But there are MANY other issues that are impacted by non-all-inclusive subtypes of records:

Can a for-loop iterate through the elements of a record? If so, are there any restrictions? This ability would be really nice for converting records of slv elements to one long slv, (and back), etc. But other than that fairly narrow application, I can't think of any huge benefits of it. Anybody have some other useful applications?

For I in sub_record_type'range loop
  My_vector(j to j + my_record.i'length) := my_record.i;
  J := j + my_record.i'length + 1;
End loop;

Since these are almost entirely different issues (composite modes and non-all-inclusive record subtypes), I recommend we treat them entirely separately.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Tuesday, July 17, 2012 3:36 AM
To: vhdl-200x@eda.org
Subject: Re: EXTERNAL: Re: [vhdl-200x] Directional records proposal

Here's a summary of our discussion so far.

/* Packaged definitions. */
/* Type definition */
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; --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 t_cpu_bus;

subtype t_cpu_bus_mosi is t_cpu_bus (adr to en); -- a record with adr, dat, we, en
subtype t_cpu_bus_miso is t_cpu_bus (sdt to err); -- a record with sdt, ack, err

type mode is (in,out,inout,buffer,linkage); --explicitly specify enumerated type for valid values of mode. Not mandatory for implementation.
/* Andy and Daniel
    Minor change to standard: allow specifying record ranges.
    Both mode definitions can work well with each other. One uses externally-declared subtype definitions using record
    ranges (which is good for modularity), and the other uses record ranges directly in the mode definitions.
*/
/* Master Mode definition */
mode m_master of t_cpu_bus is (t_cpu_bus_mosi => out, others => in);
mode m_master of t_cpu_bus is (adr to en => out, others => in); -- alternate definition without using subtype.

/* Slave Mode definition */
mode m_slave of t_cpu_bus is (t_cpu_bus_mosi => in, others => out);
mode m_slave of t_cpu_bus is (adr to en => in, others => out); -- alternate definition

/* Monitor Mode definition */
mode m_monitor of t_cpu_bus is (others => in);
mode m_monitor of t_cpu_bus is (others => in); -- alternate definition

/* Alternate mode syntax. Choose either this or the above, not both (they don't work well together). */
/* Ryan. */
mode m_master of t_cpu_bus is
    adr, dat, we, en : out;
    sdt, ack, err : in;
end mode m_master;

/* Entity declarations */

/* This is the original shorthand method by Andy.
*/
/* Master entity */
entity master is
   port (
      clk, rst : in std_logic;
      bus_rio : m_master t_cpu_bus);
end entity;

/* Slave entity */
entity slave is
   port (
      clk, rst : in std_logic;
      bus_rio : m_slave t_cpu_bus);
end entity;

/* Monitor entity */
entity monitor is
   port (
      clk, rst : in std_logic;
      bus_rio : m_monitor t_cpu_bus);
end entity;

/* Brent and Olof.
    Alternate entity declarations with direct record I/O mappings.

    These instantiations should be equivalent to Andy's, except that you do not need to specify the "named modes" m_master,
    m_slave, and m_monitor.

    This syntax does not conflict with Andy's, so both can be specified in the standard.
*/
entity master is
    port (
        clk, rst : in std_logic;
        bus_rio : mode (
            adr : out std_logic_vector(15 downto 0);
            dat : out std_logic_vector(15 downto 0);
            we : out std_logic;
            en : out std_logic;
            sdt : in std_logic_vector(15 downto 0);
            ack : in std_logic;
            err : in std_logic
        ) t_cpu_bus
    );
end entity master;

entity slave is
    port (
        clk, rst : in std_logic;
        bus_rio : mode (
            adr : in std_logic_vector(15 downto 0);
            dat : in std_logic_vector(15 downto 0);
            we : in std_logic;
            en : in std_logic;
            sdt : out std_logic_vector(15 downto 0);
            ack : out std_logic;
            err : out std_logic
        ) t_cpu_bus
    );
end entity slave;

/* Top level */
signal cpu_bus : t_cpu_bus; -- TODO: (From Ryan): consider cpu_bus as a resolved signal.

i0_master : master
    port map (
        clk => clk,
        rst => rst,
        bus_rio => cpu_bus);

/* Second master driving the same cpu_bus. */
i1_master : master
    port map (
        clk => clk,
        rst => rst,
        bus_rio => cpu_bus);

i_slave : slave
    port map (
        clk => clk,
        rst => rst,
        bus_rio => cpu_bus);

i_monitor : monitor
    port map (
        clk => clk,
        rst => rst,
        bus_rio => cpu_bus);

Let me know if there is anything I've missed.

-daniel

On 16 July 2012 20:50, Jones, Andy D <andy.d.jones@lmco.com<mailto:andy.d.jones@lmco.com>> wrote:
I think Brent's proposal is an excellent implementation of an "anonymous" port mode for a record, and in that role provides beneficial functionality.

The benefits to associating named port modes with types is to provide encapsulation. A package could define the entire bus: the type(s), the modes, functions, procedures, etc. Associating the mode with the type also provides a unique name space (port mode master of cpu_bus is different from port mode master of i2c_bus).

The encapsulation also provides a way to conduct a bus interface across intermediate levels of hierarchy without necessarily needing to know anything about it at those levels, or change port maps when the bus changes.

This is the same advantage of using record types for generics today: one can add or subtract information from the record type as the design evolves, and intermediate levels just pass along whatever is in the conduit transparently. If a lower level module needs a generic, add it to the record definition, assign it at the top, and extract it at the leaf level: done! This same ability could be available to signal and variable ports on entities and procedures.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org>] On Behalf Of Daniel Kho
Sent: Monday, July 16, 2012 6:59 AM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: EXTERNAL: Re: [vhdl-200x] Directional records proposal

Hi Brent, Olof,
Neat. I feel this is similar to Andy's proposal, only difference (other than the "unconn" mode) is that the definitions are made within the entities themselves, while in Andy's case, they are all defined using the "port mode" structure outside of the entity definitions. Perhaps it's a good idea to implement both style alternatives in the standard, so users have the flexibility to choose whichever they prefer.

Another thing mentioned by Ryan is that we need to consider resolution functions (to take into consideration the scenario where there are multiple drivers to the same nets/ports). I agree that changing any of the mode syntax could possibly affect how resolution functions work and vice versa.

<quote>... we *don't* want a resolution function for type t_cpu_bus. It doesn't even make sense because only parts -- in fact different parts -- of the record are driven by each entity. But we *do* want resolution functions for the elements of t_cpu_bus.</quote

Ryan, do you think perhaps it's still possible to have a resolution function for the record type t_cpu_bus, but the function iteratively resolves the elements of the type? This means that we still (iteratively and selectively) resolve the elements of the t_cpu_bus type. And, perhaps use matching conditionals (such as matching relational operators, etc.) to resolve only those ports we need, and treat the rest as don't cares (or unconnected)?
This idea just crossed my mind, but I haven't thought of a workable solution yet, so I'm not completely sure if it's feasible.

regards, daniel
On 16 July 2012 19:19, Olof Kindgren <olof.kindgren@orsoc.se<mailto:olof.kindgren@orsoc.se>> wrote:
2012/7/15 Brent Hayhoe <Brent.Hayhoe@aftonroy.com<mailto: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<tel:%2B44%20%280%2920-8449-1852>
> 135 Lancaster Road,
> New Barnet, Mobile: +44 (0)79-6647-2574<tel:%2B44%20%280%2979-6647-2574>
> Herts., EN4 8AJ, U.K. Email:
> Brent.Hayhoe@Aftonroy.com<mailto: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<http://www.orsoc.se>
Email: olof.kindgren@orsoc.se<mailto:olof.kindgren@orsoc.se>
______________________________________________
FPGA, ASIC, DSP - embedded SoC design