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

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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.