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

Cindy,

Yes, it doesn't make sense to specify the language of the design module in the vunit. I'm not sure what I was thinking when I originally suggested that, but it clearly doesn't make sense to do so.

Regards,

Erich

| -----Original Message-----
| From: Cindy Eisner [mailto:EISNER@il.ibm.com]
| Sent: Wednesday, December 29, 2004 5:09 AM
| To: Erich Marschner
| Cc: ieee-1850-extensions@eda.org
| Subject: 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 Sun Jan 2 20:14:16 2005