Re: Proposal for Group H (Issue 21), Portable PSL

erich,

>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.

i think this is a good solution, and i think that the limitation is indeed
acceptable.

>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) {
> ...
> }

i disagree with this vehemently! the design module language should be
indentified to the tool at compile time, just like the vunit language. if
you don't do it this way, you prevent the same vunit from being applied to
modules of the exact same functionality but written in different languages
- which is the whole point of portability in the first place, isn't it?

regards,

cindy.

--------------------------------------------------------------------
Cindy Eisner
Formal Methods Group
IBM Haifa Research Laboratory
Haifa 31905, Israel
Tel: +972-4-8296-266
Fax: +972-4-8296-114
e-mail: eisner@il.ibm.com

"Erich Marschner" <erichm@cadence.com>@eda.org on 28/12/2004 16:21:04

Sent by: owner-ieee-1850-extensions@eda.org

To: <ieee-1850-extensions@eda.org>
cc:
Subject: 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 Wed Dec 29 02:10:54 2004