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 Fri Jun 26 21:03:52 2015
This archive was generated by hypermail 2.1.8 : Fri Jun 26 2015 - 21:04:31 PDT