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

From: Ernst Christen <christen.1858@comcast.net>
Date: Wed Mar 04 2015 - 09:47:09 PST
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, and is
believed to be clean. Received on Wed Mar 4 09:47:21 2015

This archive was generated by hypermail 2.1.8 : Wed Mar 04 2015 - 09:48:00 PST