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

steve,

>1. Just because the modeling layer makes it difficult to specify a
>single flavor, it does not follow that the PSL syntax outside the
>modeling layer should be different from one flavor to another. I
>believe the flavors should differ only at the modeling and HDL
>expression levels.

this is the way things were defined in the original proposal, but that was
changed before lrm 1.0 so that the flavor influences parts of the syntax
outside the boolean and modeling layers as well. for instance, the "flavor
macro" AND_OP, which is used to "and" two properties, uses different syntax
in the different flavors, according to the syntax of the "and" operator in
the various base languages. and there are a small number of other places
as well that that happens (see the list of flavor macros in A.3.2).

there are arguments both ways, but the question is if we should reverse a
previous decision and thus cause problems of backwards compatibility. (i
think not!)

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

"Bailey, Stephen" <SBailey@model.com>@eda.org on 28/12/2004 16:38:42

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

To: "Erich Marschner" <erichm@cadence.com>,
       <ieee-1850-extensions@eda.org>
cc:
Subject: RE: Proposal for Group H (Issue 21), Portable PSL

Hi Erich,

This is, in general, a good approach. Two comments:

1. Just because the modeling layer makes it difficult to specify a
single flavor, it does not follow that the PSL syntax outside the
modeling layer should be different from one flavor to another. I
believe the flavors should differ only at the modeling and HDL
expression levels.

2. You followed this email with an email on the SystemC flavor. Yet,
SystemC is not discussed here. The assumption should be that VHDL and
Verilog are used for demonstrative purposes and that the approach
specified here is general and can be applied to any mixed language
verification supported by the tool. It would be good to make that
explicit.

-Steve Bailey

> 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:18:15 2004