Re: [vhdl-200x] Heterogeneous Interfaces in VHDL

Hi Ernst,
Thank you for taking your time to come up with such an excellent white
paper.

Of late, I have been working with some SystemVerilog interfaces. One thing
I found different was that in SVI, one needs to "instantiate" the interface
before interconnections can be made between several modules. E.g. (adapted
from Twiki example on SVInterfaces):

module top;
    logic clk = 0;

    // "instantiate" the interfaces - well these look like instances to me.
    // Assume these interfaces are different (ifc1 and ifc2).
    ifc1 #(.DWIDTH(16)) wide_intf1(.clk(clk), .reset(reset));
    ifc2 #(.DWIDTH(16)) wide_intf2(.clk(clk), .reset(reset));
    ...
    // instantiate the modules.
    block1 u_block1(.reset(reset), .clk(clk), .ifc(wide_intf1));
    block2 u_block2(.reset(reset), .clk(clk), .ifc(wide_intf2));

    // make the connections.
    assign wide_intf2.data = wide_intf1.data;
    ...
endmodule

I still prefer the existing VHDL way, just declare the interface instead of
"instantiating" it. Currently, one would do the following (assuming we use
record structures with custom-resolved members):

entity top is end entity top;

architecture sim of top is
    signal ifc1: wide_intf1;
    signal ifc2: wide_intf2;
begin
    -- instantiate the components
    u_block1: entity work.block1(rtl) port map(reset=>reset, clk=>clk,
ifc=>wide_intf1);
    u_block2: entity work.block2(rtl) port map(reset=>reset, clk=>clk,
ifc=>wide_intf2);

    -- make the connections.
    wide_intf2.data <= wide_intf1.data;
    ...
end architecture sim;

I feel declaring the interfaces the usual VHDL way is simpler than what is
used in SVI. However, SVI has the concept of modports. What we usually do
is to write custom resolution functions to ensure there are no multiple
drivers on the interface.

The modport concept is perhaps a bit too bulky IMO, as one usually needs to
define a pair of modports for a pair of blocks to interconnect with each
other. This makes the concept rather prone to human error, as one could
define one of the pairs incorrectly. I still like the concept of conjugated
ports for this purpose.

I feel it necessary to define mixed modes within an interface, so the
conjugated port concept fits nicely with interfaces having members with
different modes (again shamelessly adapted from the Bundles Twiki):

-- I prefer to maintain the syntax to be consistent with records.
-- Also, a signal declaration expects a type and an optional resolution
-- function preceding the type, e.g.:
--    signal s: resolved some_type;
-- so defining bundles as a type makes some sense.
type b is bundle
    generic (type t);
    port (
        signal clk, reset: in std_ulogic;
        -- master to slave direction.
        signal data:        mst_to_slv t;

        -- both master and slave can drive at
        -- different times.
        signal serial:       inout  std_ulogic;

        -- slave to master direction.
        signal resp:        slv_to_mst t;
        signal ack:         slv_to_mst std_ulogic;
        signal busy:       slv_to_mst std_ulogic
    );
    signal s1: std_ulogic := '0';    -- Permanent objects of the bundle
    signal s2: std_ulogic_vector(ub downto 0) := (others => '0');
    shared variable sv : my_protected_type;
end bundle b;

Here, mst_to_slv and slv_to_mst are conjugated modes. I was thinking in the
lines of:
package modes is
    mode mst_to_slv is default;    -- or perhaps, just "mode mst_to_slv"?
    mode slv_to_mst is conjugated of mst_to_slv;
end package modes;

Internally, the implementation should use resolution functions which errors
out whenever there are multiple drivers driving the same net. Also, in the
implementation of bundles, should we require users to always use unresolved
types for all signals? Is there a use case where multiple drivers are
allowed in a bus interface (I mean, multiple drivers at the same instance
of time)?

For example, in the declaration:
        signal resp:        slv_to_mst t;
I was thinking that a custom resolution function be attached implicitly to
each member of the bundle, e.g.:
        signal resp:        resolved slv_to_mst t;
where the "resolved" function is written such that multiple drivers are not
allowed:

[Example resolution function for std_logic]:
    function resolve(s: std_ulogic_vector) return std_logic is
        variable result: std_logic;
    begin
        for i in s'range loop
            if is_LH01(s(i)) then    -- checks for 'L', 'H', '0', or '1'.
                assert not is_LH01(result) report "Multiple driving signals
detected." severity error;

                if is_LH01(result) then
                    result := 'X';
                else result := s(i);
                end if;
            end if;
        end loop;
        return result;
    end function resolve;

Let me know your thoughts. Have a great weekend ahead!

Best regards,
Daniel

On Fri, 26 Jun 2015 at 03:40 Peter Flake <flake@elda.demon.co.uk> wrote:

> Hi Ernst,
>
>
>
> Thanks for your overview of SystemVerilog interfaces.  One point that is
> missing is that the import/export feature is aimed at transaction level
> modelling, like in SystemC.  This feature allows a call in one module
> instance to a task in another module instance without the caller knowing
> the path name of the callee.  The task operates on local module data, so
> cannot be located in a package.  A point of clarification is that a virtual
> interface is essentially a pointer to an interface instance.
>
>
>
> One problem that we need to be careful about is the use case where the
> interface is defined by one vendor and various IP blocks are defined by
> other vendors.  This needs a relaxation of the type system, like the
> situation we already have with records.
>
>
>
> Regards,
>
>
>
> Peter.
>
>
>
>
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Ernst Christen
> *Sent:* 10 June 2015 07:07
> *To:* Brent Hayhoe; vhdl-200x@eda.org
> *Subject:* Re: [vhdl-200x] Heterogeneous Interfaces in VHDL
>
>
>
> I have updated the document that Brent created with my notes from the last
> meeting, and I have added a new page at
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/SVInterfaces that gives an
> overview of the bundling capabilities of SV interfaces. I'll add the
> behavioral aspects as well once I have familiarized myself with them.
>
>
>
> Regards.
>
> Ernst
>
>
> On Wed, 03 Jun 2015 17:19:18 +0100, Brent Hayhoe <
> Brent.Hayhoe@Aftonroy.com> wrote:
>
>
>
>  Following the meetings discussing interfaces and Ernst's excellent white
> paper
>  detailing initial requirements, I've set up some 'whiteboard' pages in
> order to
>  provide a brainstorming mechanism for the group.
>
> If you can't get to the meetings then please add your suggestions,
> comments and
>  questions on these pages. The idea is to keep it free-form bullet points
> and/or
>  examples.
>
> These will be reviewed via the WG meetings.
>
> I've set up three pages initially:
>
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P107/HeterogeneousInterfaceRequirements
>
> This contains the requirements as detailed in Ernst's white paper.
>     Ernst, can you update this with the modifications we made at the last
>     meeting?
>
>
>
>     http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceConcepts
>
> This is some bullet points and examples I put together regarding new mode
>  requirements for a simple CPU master/slave interface.
>
>
>
>     http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceBundles
>
> Some bullet points on the new 'bundle' requirements for interfaces. This
> is the
>  first priority for the next meeting.
>
>
> These areas can all be accessed from a new 'Whiteboards' link on the main
> P1076
>  web page.
>
> The aim is for the WG meeting to condense these concepts and requirements
> into a
>  final proposal(s).
>
>
> Regards,
>
> Brent.
>
>
> --
>  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.
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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