Abi, all- Below are my review comments on the VPI Compatibility proposal you sent out several months ago now (the refinement of Michael's original). I have attempted here to stay at the philosophical level (30,000 feet), rather than attempt to critique any implementation details at this time. I look forward to continuing this discussion soonest after the holidays. Thanks, Chuck ===================================================================== A) General- Overall, this approach has good advantages, the primary one being that multiple applications could be linked-in to the master simulation executeable at the same time, presumably also allowing multiple levels of compatibility (through the differentiated vpi function names) to be supported. Very cool! Another important advantage is that it does not by itself add any performance impact to the application. A key part of the "compatibility customization" of the scheme is done at compile- time rather than at run-time. The downside (but probably not a deal breaker), is that all applications that want to take advantage of this MUST recompile their source to do so. I expect that this is what *any* approach may inevitably require for SystemVerilog support by 3rd party applications developers, so I don't believe this is a unique problem by any means. For the benefits, it's a reasonable trade-off. B) More Specific- It is clear what this scheme will do for the following cases (running with this scheme in the SystemVerilog 1800-2005 environment): 1) A 1364-1995-compatible application (using 1364-1995-flavored VPI functions) running against a 1364-1995-compatible design. 2) A 1364-2001-compatible application (using 1364-2001-flavored VPI functions) running against a 1364-2001-compatible design. The above cases are presumed to be fully "compatibility-aligned", and thus should work with no problems. However, what should the behavior of the compatibility-adjusted function flavors be when the 1364 applications encounter 1800-level design environments ? Several possibilities come to mind: 1) Application behavior is simply indeterminate. No operability guarantees are stated or implied. LRM includes a full "disclaimer" to this end. It would left totally up to the VPI providers to offer any graceful exception handling. 2) Some minimally predictable "firewall" behavior is specified, and thus required of the supporting VPI functions (a generalized error mechanism of some sort). 3) Limited emulation of SV constructs for 1364 applications (a more customized error handling interface, with some limited "recasting" of objects for backwards compatibility). Shivers go up my spine writing this; it feels like a huge amount of work to implement and support (SV is hard enough already!). I think it goes way beyond the scope of the intent here. Realistically, #1 is perhaps where the LRM should "draw the line", and the VPI providers would then be free to implement #2 as they see fit. C) Conclusions and Implications- I think a reasonable compromise between "accommodation" efforts by VPI vendors (to support older 1364-compatible applications), and some amount of "pain incentive" (to nudge application developers to upgrade their code) is important. Neither extreme is desirable for either party in the long run. The identified compatibility issues will ultimately become liabilities for both application developers *and* VPI providers over time under the best conditions. Given this, I think your proposed scheme is a good move (with my prior behavior issue nailed down). I would suggest that, while the strategy and particular compilation symbols (defines etc.) be added to the VPI standard, the compatibility mode scheme as a whole should not be *required* for 1800 *compliance*. I.e. this should be optional for VPI vendors to support, but those who *do* support it should adhere to the LRM recommendations (so 3rd party application developers have a consistent framework to operate in). It would then be up to us in the committee to nail-down the specifics of the naming, calling, and compiling conventions to frame the work.Received on Fri Dec 22 15:26:57 2006
This archive was generated by hypermail 2.1.8 : Fri Dec 22 2006 - 15:27:19 PST