Re: [vhdl-200x] Interface and Bundle Enhancements

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.

Aftonroy Limited                            Telephone: +44 (0)20-8449-1852
135 Lancaster Road,
New Barnet,                                    Mobile: +44 (0)79-6647-2574
Herts., EN4 8AJ,  U.K.                          Email: Brent.Hayhoe@Aftonroy.com

Registered Number: 1744190 England.
Registered Office:

4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.


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