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

Hi Cindy,

We discussed yesterday that a neutral-flavor could be defined (probably
a selection of one of the existing flavors) while retaining the existing
language-specific flavors. I believe that would satisfy two
constituencies:

1. The direct users who are designing in VHDL, Verilog, SystemC and
want the PSL to look as much like the language they are using.
(Existing flavors.)

2. The verification IP providers who want to write their checkers once
and have it work with any language that their customers are using.

-Steve Bailey
 
> 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 10:51:28 2004