Section 13.2.3 - Interface usage issues (Stuart/Cadence) [Basic, System]
- need to be able to specify and enforce rules about interface usage
- e.g., use of either Read or Write operation but not both
- e.g., limits on number of modules/processes invoking a given interface operation
- should be possible to define such rules in the interface itself without changing other code
- need to check rules in a way that allows for separate compilation
- need to be able to specify that some tasks/members of an interface are private

"Generic" interfaces allow a module to be attached to different interfaces, but they do not convey to the reader or allow tools to enforce that the module must be connected to an interface that implements a specific set of tasks or has specific members. As a simple example, there may be several different interface implementations of a FIFO -- one might gather statistics, another might not. In both cases modules that might be connected to such FIFOs should have an interface declaration that clearly specifies the set of FIFO operations that must be supported. E.g. write() but NOT read(), or vice-versa. Given the current proposed scheme, it can only be determined at elaboration-time whether an interface binding in a particular case is legal or not. Instead I believe it ought to be possible to determine this legality at the time a single module or interface is compiled.

It should be possible to do port registration checks for interfaces. For example, a user might want to implement a FIFO interface that enforces that it has exactly one module or process that writes to it, and exactly one module or process that reads from it. It should be possible for the designer to create such checks only within the interface, without forcing the code within modules attached to the interface to be modified.

In SystemVerilog today all tasks and members of an interface are available to be used by modules attached to the interface. This will inevitably lead to designs or models that use tasks or members of an interface that were never intended to be used externally. Therefore I believe that it should be possible to make certain tasks and members private so that they cannot be accessed externally.