Proposal for Group H (Issue 21), Portable PSL

Proposal for Group H (Issue 21), Portable PSL
===================================

In the past, we've discussed the possibility of interpreting a single PSL flavor in multiple HDL contexts. While such an approach seems feasible to a point, it would not be easy to apply to the modeling layer, and in any case it has not been widely accepted. This proposal suggests an alternative, which amounts to allowing a vunit written in one flavor to be bound to a design module written in another HDL, with an implicit interface between the two languages.

Proposal Sketch
=============

If a vunit V written in language flavor F is bound to a design module or instance D written in language L, and F/=L, then the effect is as follows:

 - if F is Verilog, then an implicit Verilog module M is created, with an input for each variable name referenced in V;
 - if F is VHDL, then an implicit entity M is created, with an input for each variable name referenced in V;
 - M is implicitly instantiated within D, with the formals of M associated with the same-named actuals;
 - V is bound to M, and therefore the directives in V are interpreted in the context of M.

We might also need to restrict the data types that could be used in such a situation, to stay within the limits of typical mixed-language simulators' ability to do cross-language instantiation. Or, we might just leave this undefined, to leave room for future expansion of those capabilities (e.g., as SystemVerilog comes on line, which will increase the potential for more complex types in cross-language instantiations).

Potential Issues
============

1. This approach depends upon common support for mixed-language design and verification in the underlying tools.

Although such support is not defined in any standard, it has evolved over time in commercial implementations, so this is probably not significant in practice.

2. This approach might require that the vunit 'flavor' be identified up front, to ensure that it is parsed correctly.

This might be necessary because the flavor would no longer be implied by the language of the design module to which the vunit is bound. One solution might be to require the user to specify the flavor of the vunit when compiling it. This might preclude putting vunits of different flavors in the same file, but that might be an acceptable limitation.

3. This approach might require that the design module language be identified up front, for the same reason.

This might be addressed by allowing an optional language identifier as part of the pathname - e.g.,

  vunit V1 (vhdl M) {
    ...
  }

  vunit V2 (verilog M2) {
    ...
  }

4. This approach would create an additional level of hierarchy that might complicate debugging.

This issue might be addressed by defining PSL so that this implicit, additional level of hierarchy is always present (even if F=L), so that it can be handled consistently in all cases - e.g., so that the implicit module or entity M can be ignored in all cases.
Received on Tue Dec 28 06:21:08 2004