I have updated the Bundles Twiki ( http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BundlesInVHDL) with some of the ideas mentioned here, as well as some usage examples using uninstantiated and generic packages. I named them under "Candidate 1", but really they are meant to be open to discussion. I can't think of a suitable section heading, so feel free to rename it (or even move the content) as you see fit. Cheers, Dan On Sat, 27 Jun 2015 at 12:03 Daniel Kho <daniel.kho@gmail.com> wrote: > All, > Giving this bundle concept a bit more thought with regards to supporting > generics, I was thinking that we can use the concept of uninstantiated > packages or package generics. That means that we do not have a generic list > within the bundle specification, but instead use the generics from the > enclosing package. > > Just to give you a couple of examples. When writing a bundle within an > uninstantiated package, here is what I have in mind: > > -- Note that there is no generic list in the bundle. However, the bundle > may > -- use the generic types made visible from the uninstantiated package. > package bundlesTLM is > generic(type t; ub: integer := 7); > > mode mst_to_slv is default; > > mode slv_to_mst is conjugated of mst_to_slv; > > type b is bundle > > port ( > signal clk, reset: in std_ulogic; > signal data: mst_to_slv t; > signal serial: inout std_ulogic; > > 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'; > signal s2: std_ulogic_vector(ub downto 0) := (others => '0'); > shared variable sv : my_protected_type; > end bundle b; > end package bundlesTLM; > > > When using with a generic package, this is what we can possibly do: > > -- generic package (to be included in the generic list of another > uninstantiated package). > package tlm is > generic(type t; ub: integer := 7); > end package tlm; > > -- uninstantiated package using a generic package. > package bundlesTLM is > generic( > package i_transactor is new work.tlm generic map(<>) > ); > use i_transactor.all; > > mode mst_to_slv is default; > > mode slv_to_mst is conjugated of mst_to_slv; > > type b is bundle > > port ( > signal clk, reset: in std_ulogic; > signal data: mst_to_slv i_transactor.t; > signal serial: inout std_ulogic; > signal resp: slv_to_mst i_transactor.t; > > signal ack: slv_to_mst std_ulogic; > signal busy: slv_to_mst std_ulogic > ); > ... > end bundle b; > end package bundlesTLM; > > Cheers, > Dan > > On Fri, 26 Jun 2015 at 22:47 Daniel Kho <daniel.kho@gmail.com> wrote: > >> Paul, >> I just felt that not all things need to be instantiated. A simple >> declaration is usually sufficient, and we have been declaring interfaces in >> VHDL all this while. >> >> There are already other things that we instantiate in VHDL, e.g. the >> usual components / entities, and instantiated packages. IMHO, interfaces / >> bundles are an enhanced concept of VHDL ports - conceptually they should be >> similar. >> -- How it's done currently (interface declaration within a port). >> entity design is port( >> clk, reset: in std_ulogic; >> a: in some_interface; >> b: out some_interface >> ); >> >> architecture rtl of design is >> -- Interface declaration within the architecture body >> signal s: some_interface; >> begin >> s <= a; >> ... >> b <= s; >> end architecture rtl; >> >> It would be nice if we can maintain the simple syntax of an interface >> similar to how it's currently being used (as above), perhaps with minor >> (yet useful) syntax enhancements. Hopefully some of the nitty gritty >> details of new language syntax (e.g. "mode", "bundle", "conjugated") can be >> implemented within a standard package. Other than defining the interface >> "some_interface" within a user package, much of the code above, except for >> slight changes to the mode of the interfaces, will remain changed. >> >> May I suggest that when bundles are used, the mode can be dropped, since >> modes are already individually assigned to each member of the bundle: >> entity design is port( >> clk, reset: in std_ulogic; >> a, b: some_interface >> ); >> However, checks should be done to ensure that the modes for every member >> of the interface are valid. >> >> -Daniel >> >> On Fri, 26 Jun 2015 at 22:16 Graham, Paul <Paul_Graham@mentor.com> wrote: >> >>> Daniel, >>> >>> 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. >>> >>> >>> >>> Paul >>> >>> >>> >>> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On >>> Behalf Of *Daniel Kho >>> *Sent:* Friday, June 26, 2015 10:02 AM >>> *To:* vhdl-200x@eda.org >>> >>> >>> *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 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* <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.Received on Sat Jun 27 03:14:15 2015
This archive was generated by hypermail 2.1.8 : Sat Jun 27 2015 - 03:15:01 PDT