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 Mon Jul 16 04:59:47 2012