Although the last configuration solution should work, we now have to have generics on the entity. It would be nice not to have to do this and it could be addressed by something that appears to be missing from the language and that is the ability to configure generic packages. use work.cpu_bus_pkg.all entity slave_3rd_ent is port( rst_i : std_logic; clk_i : std_logic; addr_vi : addr_vst; data_vi : data_vst; ... ); end entity slave_3rd_ent; We start with the 3rd part entity without generics but with a 'use' of the uninstantiated generic package. Now instantiate two version of the 3rd party entity in a structural level with the two different instantiated versions of the generic package declared before the 'top' entity. use work.cpu_bus_A_pkg.all use work.cpu_bus_B_pkg.all entity top is port( ... ); ... end entity top; architecture rtl of top is component slave_3rd_cmp is port( ... rst_i : std_logic; clk_i : std_logic; addr_vi : addr_vst; data_vi : data_vst; ... ); end component slave_3rd_cmp; begin cpu_bus_A_inst : component slave_3rd_cmp port map( ... ); cpu_bus_B_inst : component slave_3rd_cmp port map( ... ); ... end architecture rtl; The structure and instantiations are much the same. The problem now comes in the configuration. I am assuming that compilers keep an association of the visible packages with the entity once compiled, in order to check the mapping of formals to actuals when configuring a component. To configure a package requires some new syntax. The 'for' structure would seem unsuitable as it implies a form of structure in the instantiation level. Packages do not have structure as such but are abstract, so I'll just invent something: use work.cpu_bus_A_pkg.all use work.cpu_bus_B_pkg.all configuration cpu_busses_config of top is for rtl for cpu_bus_A_inst : slave_3rd_cmp use entity work.slave_3rd_ent(slave_3rd_arch); package map work.cpu_bus_pkg to work.cpu_bus_A_pkg end for; for cpu_bus_B_inst : slave_3rd_cmp use entity work.slave_3rd_ent(slave_3rd_arch) package map work.cpu_bus_pkg to work.cpu_bus_B_pkg end for; end for; end configuration cpu_busses_config; I'm not sure if the 'package map' statement should come before or after the 'use entity' statement but the intent should be obvious. I prefer this mechanism as a solution. Brent. On 16/09/2015 22:56, Brent Hayhoe wrote: > > Well done Ryan and I think that you did bring this up in the last WG > teleconference (then my Alzheimer's kicked in). > > Your point is that we need to be able to support multiple instances of the > interface package within the same structural level. > > The problem is that we are instantiating the package for the entity, so let's > not do that and leave it as a generic version with a 'use' of the uninstantiated > package: > > use work.cpu_bus_pkg.all > entity slave_3rd_ent is > generic( > awidth_jg : positive; > dwidth_jg : positive > ); > port( > ... > ); > ... > end entity slave_3rd_ent; > > The 3rd party developer now has to include the address and data width generics > on the slave entity. > > To solve the problem, we will use components and configurations to map the > generics. > > First instantiate two versions of the package, say 'cpu_bus_A_pkg' and > 'cpu_bus_A_pkg' and then the top structural level will look something like this: > > use work.cpu_bus_A_pkg.all > use work.cpu_bus_B_pkg.all > entity top is > port( > ... > ); > ... > end entity top; > > architecture rtl of top is > component slave_3rd_cmp is > generic( > awidth_jg : positive; > dwidth_jg : positive > ); > port( > ... > ); > ... > end component slave_3rd_cmp; > begin > cpu_bus_A_inst : component slave_3rd_cmp > port map( > ... > ); > > cpu_bus_B_inst : component slave_3rd_cmp > port map( > ... > ); > ... > end architecture rtl; > > We leave out the generic mappings in the structure above and then assign the > them using a configuration below: > > use work.cpu_bus_A_pkg.all > use work.cpu_bus_B_pkg.all > configuration cpu_busses_config of top is > for rtl > for cpu_bus_A_inst : slave_3rd_cmp > use entity work.slave_3rd_ent(slave_3rd_arch) > generic map( > awidth_jg => cpu_bus_A_pkg.awidth_jg, > dwidth_jg => cpu_bus_A_pkg.dwidth_jg > ); > end for; > > for cpu_bus_B_inst : slave_3rd_cmp > use entity work.slave_3rd_ent(slave_3rd_arch) > generic map( > awidth_jg => cpu_bus_B_pkg.awidth_jg, > dwidth_jg => cpu_bus_B_pkg.dwidth_jg > ); > end for; > end for; > end configuration cpu_busses_config; > > > Will this achieve what we are after? > > > Brent. > > > On 15/09/2015 23:22, ryan.w.hinton@L-3com.com wrote: >> Quick thought; I didn't hear the original conversation, so I hope I don't >> derail your thoughtful response. >> >> We avoid this style approach when we might have multiple instances of the >> package in a design. It's also caused problems for us before when trying to >> simulate two FPGAs (with different versions of a package) that need to >> interoperate in the real world. In our case, we were using multiple copies of >> a concrete package with different constants instead of a generic package, but >> I believe the concept is the same. >> >> - Ryan >> >> -----Original Message----- >> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of >> Brent Hayhoe >> Sent: Tuesday, September 15, 2015 4:09 PM >> To: vhdl-200x@eda.org >> Subject: Re: [vhdl-200x] Interface and Bundle Enhancements >> >> In the last WG teleconference Peter raised a problem regarding instantiated >> generic packages and their use with 3rd party generated IP. >> >> In the Complex RTL Use Case: >> >> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/UCComplexRTLSignalCPUInterface >> >> The use of a generic package to define the interface types and mode views >> gives the following type of code: >> >> use work.cpu_bus_2m8s_pkg.all >> entity slave_ent is >> ... >> end entity slave_ent; >> >> where 'cpu_bus_2m8s_pkg' is the name of the instantiated version of the >> interface package (cpu_bus_pkg) and as the name suggests, is to support a 2 >> master and 8 slave implementation of the CPU bus interface. >> >> For the case where a 3rd party is supplying a generic entity, the 'use' >> statement requirement does not support the required generalized use as is. >> >> >> My solution is methodology based, rather than a language altering fix. >> >> Given that objects are to be designed around the CPU bus interface, this will >> require the distribution of the generic interface package (cpu_bus_pkg) to all >> interested parties. >> >> The suggestion is that any local implementation of a design using this >> interface will instantiate the package with a generalized name, say >> 'cpu_bus_inst_pkg'. >> >> Now the 3rd party entity can be supplied as: >> >> use work.cpu_bus_inst_pkg.all >> entity slave_3rd_ent is >> ... >> end entity slave_3rd_ent; >> >> Another user can now take this entity into their design environment and >> instantiate the interface package as 'cpu_bus_inst_pkg' with say 12 slaves and >> 3 masters (plus data and address bus widths to suit) and not have to modify >> the provided IP source files. >> >> The important point is that the package only needs to be instantiated by the >> end user and the generalized naming concept makes this portable. >> >> >> So does this work and more importantly, have I understood the problem correctly? >> >> >> Brent. >> >> >> On 10/08/2015 00:08, Brent Hayhoe wrote: >> > Apologies, the address for the working page to add comments and questions >> in my >> > last posting should have been this: >> > >> > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceAcceptedRequirements >> > >> > On 10/08/2015 00:00, Brent Hayhoe wrote: >> >> There is now a new proposal entry under the 'collected requirements' >> section, >> >> intended to be the definitive *interface* requirement. >> >> >> >> It is being generated via the working group teleconferences and its >> production >> >> is currently ongoing. >> >> >> >> The more astute of you will notice that all the old 'interface'/'directional >> >> record' proposals have now been removed from the 'collected requirements' >> page. >> >> >> >> They have not been deleted and the links to these subsumed requirements >> can be >> >> found via the 'reference links' section of the new proposal: >> >> >> >> >> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceAndBundleEnhancements >> >> >> >> If you are unable to attend the teleconferences but still wish to make >> comments >> >> then you can include them via the requirements 'whiteboard' page here: >> >> >> >> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceWhiteboard >> >> -- Regards, Brent Hayhoe. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Fri Sep 18 2015 - 14:55:35 PDT