RE: [sv-cc] Mantis 1835 proposed changes - rough draft

I like these suggestions.  I suggest checking with Karen Pieper before going
too far with the proposal to make sure that the changes are in line with
what the PAR allows, but I don't think there is any issue with that.

 

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898

www.sutherland-hdl.com



 

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of John
Shields
Sent: Tuesday, June 03, 2008 6:16 PM
To: SV-CC
Subject: [sv-cc] Mantis 1835 proposed changes - rough draft

 

Hi Everyone,

The purpose of this item is to address a serious objection from JEITI.  I am
making a rough proposal here inline with the ideas I noted in the Mantis
item a couple of months ago.  If it is deemed worthy, I'll finish the myriad
trivial details across the LRM for next meeting.

The general approach this item is to change terminology to more effectively
describe the the core language, assertion, and coverage information model
and API provided to access it.  What was called VPI will be called SVPI and
the assertion and coverage APIs will be more properly viewed as extensions
to the core language information model or subsets of SVPI.  It retains the
document structure for separating the information into 3 parts, but unifies
it under one term.

We deprecate VPI as a historical term, while keeping backward compatibility
with the naming conventions for the data diagrams, header fields and their
contents, which will use vpi as a prefix.  We presume it will be desirable
to migrate to a new prefix in the future, svpi, but we do not address that
issue here.

At one level, this is all aimed at giving a better conceptual model of the
parts and the history.  At another, it is a lot of cosmetic change without a
disruptive change to the APIs themselves.

Below are the minor changes across the body of the LRM up to clause 35,
which is the PLI/SVPI chapter. I apologize that it isn't colorized, but they
short chunks of text lifted directly from draft 5.  The clause 35 change is
authored from a framemaker source file and a pdf is attached for it. It is
done properly but I stopped abruptly at 35.3.

There is no point to go further with the construction of this proposal until
we are sufficiently in sync with the approach.  


Regards, John  
-----------------------------------

1. Cover page, add new keyword SVPI

2. page v, change the credit statement 
from:
The C API Committee (SV-CC) was responsible for on the specification of the
DPI, the assertions and coverage
APIs, and the Verilog programming interface (VPI) features of SystemVerilog.
to:
The C API Committee (SV-CC) was responsible for on the specification of the
DPI, and the SystemVerilog 
programming interface (SVPI) which includes the core language information
model and its assertion and coverage subsets.

3. page 4, section 1.3
from:
This standard serves as a complete specification of the SystemVerilog
language. This standard contains the
following:
- The formal syntax and semantics of all SystemVerilog constructs
- Simulation system tasks and system functions, such as text output display
commands
- Compiler directives, such as text substitution macros and simulation time
scaling
- The Programming Language Interface (PLI) mechanism
- The formal syntax and semantics of the Verilog Procedural Interface (VPI)
- Application Programming Interfaces (APIs) for assertions, coverage and
data read
- Direct Programming Interface (DPI) for interoperation with the C
programming language
- VPI, API, and DPI header files
- Concurrent assertion formal semantics
- The formal syntax and semantics of standard delay format (SDF) constructs
- Informative usage examples
to:
This standard serves as a complete specification of the SystemVerilog
language. This standard contains the
following:
- The formal syntax and semantics of all SystemVerilog constructs
- Simulation system tasks and system functions, such as text output display
commands
- Compiler directives, such as text substitution macros and simulation time
scaling
- The Programming Language Interface (PLI) mechanism
- The formal syntax and semantics of the SystemVerilog Procedural Interface
(SVPI) for
  the core language (footnote 1)
- The assertion and coverage subsets of SVPI
- SVPI header files for the core language and the assertion and coverage
subsets
- Direct Programming Interface (DPI) for interoperation with the C
programming language
- DPI header files
- Concurrent assertion formal semantics
- The formal syntax and semantics of standard delay format (SDF) constructs
- Informative usage examples

footnote 1 - The core language information model and routines retain the
prefix VPI for backward compatibility, but the
Verilog Procedural Interface and its acronym VPI are deprecated.

4. page 8, section 1.8
from:
Part Three: Application Programming Interfaces (APIs)
Clause 34 describes SystemVerilog's Direct Programming Interface (DPI), a
direct interface to foreign languages
and the syntax for importing functions from a foreign language and exporting
tasks and functions
subroutines to a foreign language.
Clause 35 provides an overview of the Programming Language Interface (PLI
and VPI).
Clause 36 presents the VPI data model diagrams, which document the VPI
object relationships and access
methods.
Clause 37 describes the VPI routines.
Clause 38 describes the assertion API in SystemVerilog.
Clause 39 describes the coverage API in SystemVerilog.
Clause 40 describes the data read API, which contains enhancements to the
VPI to support accessing design
and simulation data from files.
to:
Part Three: Application Programming Interfaces (APIs)
Clause 34 describes SystemVerilog's Direct Programming Interface (DPI), a
direct interface to foreign languages
and the syntax for importing functions from a foreign language and exporting
tasks and functions
subroutines to a foreign language.
Clause 35 provides an overview of the Programming Language Interface (PLI
and SVPI).
Clause 36 presents the SVPI data model diagrams, which document the SVPI
object relationships and access
methods for the core language
Clause 37 describes the SVPI routines.
Clause 38 describes the assertion SVPI subset of the data model.
Clause 39 describes the coverage SVPI subset of the data model.

5. page 777, section 32.7, paragraph 2
from:
It shall also be able to use VPI to display the binding information. The
following VPI properties shall exist
for objects of type vpiModule:
- vpiLibrary-the library name into which the module was compiled
- vpiCell-the name of the cell bound to the module instance
- vpiConfig-the library.cell name of the config controlling the binding of
the module
instance
to:
It shall also be able to use SVPI to display the binding information. The
following SVPI properties shall exist
for objects of type vpiModule:
- vpiLibrary-the library name into which the module was compiled
- vpiCell-the name of the cell bound to the module instance
- vpiConfig-the library.cell name of the config controlling the binding of
the module
instance

6. Clause 34, Direct programming interface (DPI)

All references to VPI to be changed to SVPI

7. Clause 35, page 817, title
from:
35. Programming language interface (PLI/VPI) overview
to:
35. Programming language interface (PLI/SVPI) overview

8. See the attached pdf

TBD - corresponding changes to 36,37,38,39 and the Annexes with the same
intent to change VPI to SVPI in refering to the interface and keeping the
vpi prefix for the names of constants, functions, etc. in the actual API and
information model diagrams.





-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.