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

From: John Shields <John_Shields_at_.....> Date: Wed Jun 04 2008 - 08:32:38 PDT · This archive was generated by hypermail 2.1.8 : Wed Jun 04 2008 - 08:33:45 PDT


Yes, Karen, no functionality changes. SV-CC is meeting this morning
and we will discuss this particular descriptive language itself.
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.