Named Package Bodies

Proposal Editing Information

• Who Updates: JimLewis, DavidBishop, <Add YourName >, ...
• Date Proposed: 2012-08-20
• Date Last Updated: 2012-08-20
• Priority:
• Complexity:
• Focus: Testbench

Requirement Summary

Support named package bodies and a method for selection.

By default the most recently compiled package body will be selected.

in 2016_MeetingMay5 is covered by abstract packages - hence reject

Related and/or Competing Issues

in 2016_MeetingMay5 is covered by abstract packages - hence reject

Use Model

from DavidBishop In the fixed point packages, we can have an implementation for a trig function with an algorithm, with a lookup table, or with real variables. There are use cases where it is desirable to use a function from the algorithmic package and another from the lookup table package.

library ieee_proposed ; 
use ieee_proposed.fixed_alg_pkg.all;
A <= sin (b).lookup;       -- select implementation from lookup table package
C <= sin (d).algorithm;   -- select implementation from algorithm package

From JimLewis While this is a little more verbose, it is more consistent with architecture selection in configurations:

library ieee_proposed ; 
use ieee_proposed.fixed_alg_pkg.all;
A <= fixed_alg_pkg(lookup).sin (b);       -- select implementation from lookup table package
C <= fixed_alg_pkg(algorithm).sin (d);   -- select implementation from algorithm package

[Main.RyanHinton] Personally, I would use aliases. It makes it look prettier, but doesn't change the proposal at all.

alias sin_lookup is ieee_proposed.fixed_alg_pkg(lookup).sin [sfixed return sfixed];
alias sin_alg is ieee_proposed.fixed_alg_pkg(algorithm).sin [sfixed return sfixed];

A <= sin_lookup(b);
C <= sin_alg(b);

Proposal

package body syntax:

package lookup body Fixed_Alg_Pkg is
   ... 
end package lookup body Fixed_Alg_Pkg ; 

[Main.RyanHinton] What about this alternative package body syntax?

package body lookup of Fixed_Alg_Pkg is
   ... 
end package body lookup of Fixed_Alg_Pkg ; 

It's more similar to the architecture syntax. Of course, most of the "end package" line is optional.

Use clauses:

use ieee_proposed.fixed_alg_pkg(lookup).all ;

Subprogram calls:

A <= ieee_proposed.fixed_alg_pkg(lookup).sin (b);       
C <= ieee_proposed.fixed_alg_pkg(algorithm).sin (d); 

Questions

- Is there a requirement that each named package body implement everything in the package? If so, then that would seem to be a barrier, since maybe there is no good 'lookup' version of some algorithm. Replicating the 'algorithm' version just so you can meet the requirement (if there is one) of would not be productive.

[Main.RyanHinton - 2013-04-12] Using the analogy to architectures, each package body should implement the interface advertised in the package declaration. If there is no good 'lookup' version for a particular operation, I would fill in the function body with an assert failure.

- How is the usage model really any different than having either a separate package or a naming convention for functions? In other words, how are these three substantially different?

A <= sin(b).lookup (Bishop proposal)

A <= fixed_alg_pkg(lookup).sin(b) (Lewis proposal)

A <= sin_lookup(b) (Current language)

In all three cases, the 'lookup' is hard coded. Changing from one implementation to another requires editing each instance.

-- KevinJennings - 2013-04-05

[Main.RyanHinton - 2013-04-12] Good point. I guess the main difference is that each package body implements the same interface (package declaration), just like multiple architectures for the same entity. You could copy and paste the package declaration into several similarly-named files, but that seems wrong. We need to balance this wrongness against the cost of making an LRM change.

One more thought. Like an architecture, we may be able to extend configuration bindings to be able to specify package bodies. This would provide a way around the hard coding you don't like.

General Comments

Supporters

Add your signature here to indicate your support for the proposal

-- PatrickLehmann - 2016-02-19