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

My reading of the PAR indicates that the clarification of the descriptive language would be allowed.

Am I correct that no functionality changes, just descriptive language?

Thanks,

Karen



----- Original Message ----
From: Stuart Sutherland <stuart@sutherland-hdl.com>
To: John Shields <John_Shields@mentor.com>; SV-CC <sv-cc@server.eda.org>
Sent: Tuesday, June 3, 2008 8:33:46 PM
Subject: 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 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. 


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