Subject: VPI requirements for System Verilog
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Sep 10 2002 - 16:13:22 PDT
Here are the long awaited requirements for VPI SV.
Be aware that I will be on vacation starting 9/12 until 9/23 and will not
be able to respond to any questions or comments during that time
R1: Basic requirements
PLI 1.0 should not be enhanced. PLI 1.0 was not enhanced to support Verilog
2001.
VPI which is Object-Oriented is more easily extensible and should be
enhanced to support SV. VPI has already been enhanced to support Verilog 2001.
VPI SV should be defined as ANSI-C API
R2: Functional requirements
VPI information model should be enhanced to support the new systemVerilog
constructs.
VPI access and modification of values should be enhanced to support new
value data
types and new object types in SV.
VPI should be enhanced to support simulation interaction and control of
systemVerilog simulation
R3: compatibility
Should we ensure backward compatibility?
basically this would mean that no existing VPI function prototype or data
type will be changed and that no type/method/property will disappear with
VPI SV.
If a data type or function needs to be enhanced to support SV, then this
would require to create a new data type or function to support SV.
Should old VPI code continue to work on SV?
Should new VPI work on Verilog?
R4: scope of VPI enhancements:
Currently VPI is only aimed at providing access to the SV core design
language features; what do we do if testing and assertion language features
are added to the SV language.
Should VPI also provide access to the testing and assertion language
constructs?
and how? One may only be interested in the design model and not in the
testing or assertions. Should we provide different methods to retrieve
either of these elements?
R5: Foreign models development and integration
VPI SV should allow the registration of foreign models written in C or C++
user-defined foreign functions should be extended to return the new data
types of SystemVerilog.
VPI-SV should allow easier integration of foreign models than the VPI
registration mechanism (aka DirectC or through attributes)
R6: abstracted data
VPI should not make any assumption about the underlined data implementation
in SV
R7: concurrency
VPI should allow multiple concurrent VPI applications to read and write to
the simulation data
R8: Binary or source portability of VPI SV applications across different SV
simulators
In the past VPI applications written for Verilog 1364 are only source
portable across various simulators and need to be recompiled for each
simulator vendor
However many applications can be written to be also binary compatible and
users have
taken the advantage of it.
Francoise
'
This archive was generated by hypermail 2b28 : Tue Sep 10 2002 - 16:14:13 PDT