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

From: Graham, Paul <>
Date: Fri Jun 26 2015 - 07:15:36 PDT

What is the distinction between "instantiating" an sv interface, and "declaring" a vhdl bundle?  In either case you "declare" an interface/bundle, and then create an instance of it.  The difference is that vhdl distinguishes between declarative and statement regions, while verilog mixes declarations and statements into one region.


From: [] On Behalf Of Daniel Kho
Sent: Friday, June 26, 2015 10:02 AM
Subject: 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 =;
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;
    -- 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. <=;
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;
        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,

On Fri, 26 Jun 2015 at 03:40 Peter Flake <<>> 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.



From:<> [<>] On Behalf Of Ernst Christen
Sent: 10 June 2015 07:07
To: Brent Hayhoe;<>
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 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.


On Wed, 03 Jun 2015 17:19:18 +0100, Brent Hayhoe <<>> 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

These will be reviewed via the WG meetings.

I've set up three pages initially:

This contains the requirements as detailed in Ernst's white paper.
    Ernst, can you update this with the modifications we made at the last

This is some bullet points and examples I put together regarding new mode
 requirements for a simple CPU master/slave interface.

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).



 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.

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.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Jun 26 07:16:32 2015

This archive was generated by hypermail 2.1.8 : Fri Jun 26 2015 - 07:16:34 PDT