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

See inline comments.

John

> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On
> Behalf Of Lehmann, Patrick
> Sent: 18. februar 2015 21:22
> To: vhdl-200x@eda.org
> Subject: [vhdl-200x] AW: Interfaces with normal, conjugated and monitor
> flavours
>
> Hello John,
>
> I would suggest to use a record definition like syntax to define interfaces:
> type i_fifo is interface
>   valid : out std_logic;
>   data : out std_logic_vector(7 downto 0);
>   ack : in std_logic;
> end interface;

This syntax is fine for me. It also makes it very clear that it is allowed to define signals and variables of interfaces.

>
> Do you have plans to allow generic interfaces?
> In my example i_fifo defines a typical fifo interface. But fifos can have
> different widths.
> What about this synthax?
>
> type i_fifo is interface
>   generic (BITS : positive);
>   port (
>     valid : out std_logic;
>     data : out std_logic_vector(BITS - 1 downto 0);
>     ack : in std_logic
>   );
> end interface;
>

Interface should support the same type of generics as records. This proposal makes a generic interface more like an entity than a record. I prefer defining a generic interface in a generic package instead of adding generics directly to the type. Adding a generic each time the interface is used in a declaration of an entity, signal or variable makes  the design more difficult to keep consistent.

> Putting interfaces into interfaces is nice, but can have some drawbacks. Let's
> assume a fifo-interface
> with frame markers (like LocalLink). In your example it would look like this:
>
> type i_framed is interface
>   fifo : interface i_fifo;
>   sof  : out std_logic;
>   eof  : out std_logic;
> end interface i_framed;
>
> signal myFramed : i_framed;
> signal myData : std_logic_vector(7 downto 0);
>
> If you want to access data, you have to write:
> myData <= myFramed.fifo.data;

I do not see any problem with this. This is the same syntax as for records when I use a record within another record.
If this is too verbose, an alias might be used.

>
> What is your opinion on interface extensions (inheritance):
> type i_framed is interface
>   extend (i_fifo);
>   port (
>     sof  : out std_logic;
>     eof  : out std_logic
>   );
> end interface;
>
> And here is a signal declaration:
> signal myFramed : i_framed(BITS => 8);
>

Object-orientation (and inheritance) must be handled generically for VHDL and should not be added just for interfaces.
I do not really see any major benefits of using inheritance (is-a relationship) vs composition (has-a relationship) for component interfaces. Component interfaces do not have methods and I do not see what inheritance gives us (except allowing a shorter name, i.e. myData <= myFramed.data instead of myData <= myFramed.fifo.data)

Composition is well known in VHDL and adding inheritance belongs to another proposition.

>
> Regards
>     Patrick
>
>
> Von: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] Im
> Auftrag von
> John.Aasen@kongsberg.com
> Gesendet: Mittwoch, 18. Februar 2015 15:40
> An: vhdl-200x@eda.org
> Betreff: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours
>
> There are multiple suggested extensions for ports.
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/PackageAsInterface
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceConstructandPortM
> odeConfigurations
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/NewBusModeForBidirectiona
> lPortSignals
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ProtectedTypesPublicSignal
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ProtectedTypeEntity
>
> But I still want to suggest a way of modelling ports that is based on the
> concepts from SysML (http://www.omgsysml.org/) which I believe match
> very well
> with VHDL.
>
> In SysML a port can typed with an interface. This interface may contain flows
> with directions, i.e. in, out or inout, or other interfaces.
> When connecting two ports the directions will be reversed on one side. To
> avoid needing two definitions of the interface, SysML uses the concept of a
> conjugated port. The conjugated port will invert the direction of the flows:
> in becomes out, out becomes in while inout stays inout. In addition it is
> allowed to create ports-of-ports to represent bundles of information.
>
> This allows a single interface definition to be used on both sides of a
> connection, and it is no longer necessary to define for example a master and
> a
> slave interface with the same signals but the opposite direction.
> This is useful both in testbenches and in designs
>
> Example (Similar to
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces)
>
> -- Single definition of the interface
> -- Directions defined as seen from the CPU (master)
> -- slaves will need a conjugated  version of the interface
> -- Which end is normal and which is conjugated is a convention
> interface i_cpu_bus is
>   adr : out   std_logic_vector(15 downto 0);  --Address
>   dat : inout std_logic_vector(15 downto 0);  --Data between master and
> slave
>   cs  : out std_logic_vector(7 downto 0);  -- ChipSelect-bus from master
>   we  : out std_logic;    --Write enable from master
>   en  : out std_logic;    --Enable from master
>   ack : in std_logic;    --Acknowledge from slave
>   err : in std_logic;    --Error from slave
> end interface;
>
> --Master entity
> entity master is
>   port (
>     clk : in std_logic;
>     bus : interface i_cpu_bus
>     );
> end entity;
>
> --Slave entity - reverses direction for 'in' and 'out' interface elements
> entity slave is
>   port (
>     clk : in std_logic;
>     bus : conjugated i_cpu_bus
>   );
>
> -- bus monitor - all interface elements are 'in'
>   port (
>     clk : in std_logic;
>     bus : monitor i_cpu_bus
>   );
>
> --Top level
>   signal cpu_bus : t_cpu_bus;
>
>   i_master : master
>     port map (
>       clk => clk,
>       bus => cpu_bus
>       );
>
>   i_slave : slave
>     port map (
>       clk => clk,
>       bus => cpu_bus
>     );
>
>   i_monitor : monitor
>     port map (
>       clk => clk,
>       bus => cpu_bus
>     );
>
>
> Hierarchical interfaces
> use 'normal' VHDL syntax to build ports-of-ports and arrays-of-ports, or
> combination
>
> interface i_cpu_bus_vec is array (natural range <>) of i_cpu_bus;
>
> interface i_foo
>   sof  : in std_logic;
>   eof  : in std_logic;
>   data : in std_logic_vector(7 downto 0);
> end interface i_foo;
>
> interface i_bar
>   req : in std_logic;
>   ack : out std_logic;
> end interface i_bar;
>
> interface i_baz
>   handshake : interface i_bar;
>   packet : conjugated i_foo;
>   cpu_vec : i_cpu_bus_vec(3 downto 0);
> end interface;
>
>
>
> -- use port configurations to disconnect unused elements
> -- I am not sure that this is a good syntax, but we need something to
> -- avoid connecting elements and pick out elements / vectors of arrays
> -- Alternative might be some kind of port configuration
> -- see
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceConstructandPortM
> odeConfigurations
>
> entity slave is
>   port (
>     clk : in std_logic;
>     bus : conjugated i_cpu_bus
>   );
>
>   i_slave : slave
>     port map (
>       clk => clk,
>       bus => cpu_bus(cs => cs(c_SlaveId),  -- pick single element,
>          -- type of cs becomes the base type of the vector,
>          -- i.e. std_logic
>                      data => data(7 downto 0),  -- pick a slice,
>          -- range of data becomes sub_range std_logic_vector(7 downto
> 0)
>                      we => open)  -- unused port (read-only slave)
>
>     );
>
> Alternative - limit width in entity
> entity slave is
>   generic (
>     c_SlaveId : integer);          -- Selects CS element
>   port (
>     clk : in std_logic;
>     bus : conjugated i_cpu_bus(cs => cs(c_SlaveId),
>                                data => data(7 downto 0),
>                                we => open)
>   );
>
>
>
> Final notes:
>
> Records with direction might be used instead of interface. See
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/NewBusModeForBidirectiona
> lPortSignals#3_Assignments_can_be_to_a_record
> for how a modification to a record assignment may be used to handle partial
> assignments to the elements in a record or interface.
> The main point of the proposal is to use normal, conjugated and monitor
> ports
> and have a single definition of an interface.
>
> I also propose that this interface also may be used instead of a type or
> subtype to define signals or variables in a design / testbench.
>
> John Aasen
>
> ________________________________________
>
> CONFIDENTIALITY
> This e-mail and any attachment contain KONGSBERG information which may
> be
> proprietary, confidential or subject to export regulations, and is only meant
> for the intended recipient(s). Any disclosure, copying, distribution or use is
> prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
> error, please delete it immediately from your system and notify the sender
> properly.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

________________________________

CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be proprietary, confidential or subject to export regulations, and is only meant for the intended recipient(s). Any disclosure, copying, distribution or use is prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in error, please delete it immediately from your system and notify the sender properly.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.