Re: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours

In answer to:

Tristan,

With regard to verbosity; the record declaration is a given to start with.  That 
has to be there.

The port modes then need to be specified and the shortest it could be is:

interface i_cpu_bus of r_cpu_bus is
    port master(
       adr: out;
       dat: inout;
       cs:  out;
       we:  out;
       en:  out;
       ack: in;
       err: in
    );
    port slave(master'converse);
end interface i_cpu_bus;

Its use in the entity declaration and instancing is pretty much the same in 
terms of verbosity, so I don't see how we can reduce it any more.


Olof,

1. I suggested the dot notation specifically to differentiate it from current
'modes'. The 'interface' object captures 'port modes' and associates them 
together with a composite type.

2. Another good suggestion. I think we should do a straw poll on the attribute
name.

3. As I mentioned above, I think its probably as minimal (verbosity-wise) as
we could hope for.


Martin,

I think that we concur.


Peter,

A valid suggestion to use the 'port mode' structure on its own.

My gut feeling was that 'ports' are not structural objects in their own right.

They are always associated with 'entities', 'blocks', 'functions' and
'procedures'. As such, the new 'interface' concept gives an object to associate
'port modes' with.

It may also give us the opportunity to include functions and procedures within
the interface for doing things like protocol checking and other stuff.


Ernst,

Some very important points and I think we do not necessarily consider the
implications that changes may have on VHDL-AMS enough. I know that I am pretty
ignorant myself in this respect.

The discussion seems to have swung back to an 'interface' encapsulating
'modes' with a particular composite type (or maybe that's just me that's
caused it).

By using this, it is not necessarily restricted to 'entity' interfaces and part
of my original intent was that it could be expanded to block and sub-program
interfaces by design.

If I understand correctly (and I almost certainly do not) 'terminals' are a
'port mode' and 'quantities' are equivalent to 'types'? If I am correct, will
these not map through into the interface's 'port modes' and include the
'quantities' as an associated composite quantity structure?


Regards,

Brent.


On 04/03/2015 17:47, Ernst Christen wrote:
> Peter, Brent and others,
> I haven't followed this discussion in its entirety, but I have to raise an
> objection to considering a collection of ports to be a type. Brent's proposal on
> Interface Construct and Port Mode Configuration and the original email of this
> thread by John Aasen avoided that by defining the concept of an interface as
> such a collection, but it seems that the direction of the discussion quickly
> went towards types, apparently to align/reuse syntax but maybe also influenced
> by the separate proposal of records with directional subtypes. The reason for my
> objection follows.
>
> If I understand the intent correctly, the purpose of the extension is to first
> bundle a collection of ports. This is the abstract interface. Then, actual
> interfaces are derived from the abstract one with differing properties; modes
> have been mentioned as an obvious discriminator. The actual interfaces are then
> used in an entity or block and for the corresponding actuals to create valid
> port associations. Different ideas have been communicated for the derivation,
> e.g. master/slave, conjugated, and more.
> The issue for me is that the whole discussion has focused entirely on signal
> ports of an entity/block. In my opinion two things are missing. First, it should
> be possible to abstract the parameters of subprograms in a similar way. The
> reason for this is the concurrent procedure call, whose signal parameters have
> similar requirements as entity/block ports. However, subprograms have interface
> objects other than signals, so a signal centric view is not sufficient, i.e. the
> object class would have to be another discriminator. And this brings me to the
> second issue. In VHDL-AMS the ports of an entity/block may be quantities or
> terminals, in addition to signals. Again the signal centric view is not
> sufficient here. In addition, while quantities have types and a mode, terminals
> have a nature instead of a type, so basing an interface concept on types will
> not scale to VHDL-AMS.
> I have seen many situations where "digital" implementations of a model have to
> be replaced by AMS implementations for certain verification tasks. It is these
> situations where the scalability of a port bundle to include AMS concepts is
> necessary, but of course it's not sufficient. I have no expectations that the
> P1076 WG will solve this problem in its entirety, but I have hopes that you will
> come up with a solution that can be extended by P1076.1 to support the AMS needs.
> It is certainly possible that I misunderstand the intent and scope of this
> discussion. To clarify, I think it would be helpful to write down the
> requirements to be addressed by a port abstraction in a neutral way, including
> aspects raised in the 6 proposals listed in John Aasen's email. The different
> ideas can then be assessed against these requirements.
> Regards.
> Ernst Christen
> Chair, IEEE P1076.1 Working Group
> On Wed, 4 Mar 2015 12:03:06 -0000, Peter Flake <flake@elda.demon.co.uk> wrote:
>   Hi Brent,
>
> I agree it is concise, but why do we need the interface statement?  Is there
> anything else that can go in it apart from ports?
>
> If not, we can just define the ports on their own:
>
> port cpu_bus_master of r_cpu_bus is
>         adr: out;
>         dat: inout;
>         cs:  out;
>         we:  out;
>         en:  out;
>         ack: in;
>         err: in;
> end port
> port cpu_bus_slave of r_cpu_bus is
>         adr: in;
>         dat: inout;
>         cs:  in;
>         we:  in;
>         en:  in;
>         ack: out;
>         err: out
> end port
>
> And use them without a dot:
>
> entity cpu_master is
>      port(
>         rst:     in std_logic;
>         clk:     in std_logic;
>         cpu_bus: i_cpu_bus_master
>      );
> end entity cpu_master;
>
> Regards,
>
> Peter.
>
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
> Brent Hayhoe
> Sent: 03 March 2015 23:33
> To: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] Interfaces with normal, conjugated and monitor
> flavours
>
>
>   From your interface suggestions, I thought that I'd detail and adapt them
> to a possible solution.
>
> It looks quite concise and a nice first attempt.
>
> What do you think?
>
> So the record and signals:-
>
>      type r_cpu_bus is record
>         adr:  std_logic_vector(15 downto 0);  -- Address
>         dat:  std_logic_vector(15 downto 0);  -- Data between master and
> slave
>         cs:   std_logic_vector(7 downto 0);   -- ChipSelect-bus from master
>         we:   std_logic;                      -- Write enable from master
>         en:   std_logic;                      -- Enable from master
>         ack:  std_logic;                      -- Acknowledge from slave
>         err:  std_logic;                      -- Error from slave
>      end record r_cpu_bus;
>
>      signal s_rst:     std_logic;
>      signal s_clk:     std_logic;
>      signal s_cpu_bus: r_cpu_bus;
>
>
>
> The interface definition to associate the modes for master and slave ports
> with the record type.
>
> I've included the short attribute option (defining the slave port) as a
> comment with an attribute of converse/conjugate/inverse/opposite etc, at the
> end:-
>
> interface i_cpu_bus of r_cpu_bus is
>      port master(
>         adr: out;
>         dat: inout;
>         cs:  out;
>         we:  out;
>         en:  out;
>         ack: in;
>         err: in
>      );
>      port slave(
>         adr: in;
>         dat: inout;
>         cs:  in;
>         we:  in;
>         en:  in;
>         ack: out;
>         err: out
>      );
> --   port slave(master'converse);
> end interface i_cpu_bus;
>
>
>
> This is how they would be used to encapsulate the mode and type together in
> an entity declarations:-
>
> entity cpu_master is
>      port(
>         rst:     in std_logic;
>         clk:     in std_logic;
>         cpu_bus: i_cpu_bus.master
>      );
> end entity cpu_master;
>
> entity cpu_slave is
>      port(
>         rst:     in std_logic;
>         clk:     in std_logic;
>         cpu_bus: i_cpu_bus.slave
>      );
> end entity cpu_slave;
>
>
>
> And finally the normal record use when instantiating components:-
>
> cpu_master_inst: cpu_master
>      port map(
>         rst      => s_rst,
>         clk      => s_clk,
>         cpu_bus  => s_cpu_bus
>      );
>
> cpu_slave_inst: cpu_slave
>      port map(
>         rst      => s_rst,
>         clk      => s_clk,
>         cpu_bus  => s_cpu_bus
>      );
>
>
>
>
> --
>   This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.


-- 

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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.