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> 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] *On
> Behalf Of *Daniel Kho
> *Sent:* Monday, July 16, 2012 6:59 AM
> *To:* 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> wrote:****
>
> 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****
>
>
>
Received on Tue Jul 17 01:36:24 2012
This archive was generated by hypermail 2.1.8 : Tue Jul 17 2012 - 01:37:00 PDT