Subject: [sv-cc] Final LRM corrections from sv-cc
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Tue Apr 22 2003 - 15:06:26 PDT
David,
attached are the final LRM corrections for sv-cc. This includes a batch of
corrections that was missed in the process of getting corrections into draft 5
These corrections primarily tighten up the semantics and wording for the DPI
interface, as well as correct a few mistakes.
Joao
LRM-298:
Annex G, page 355
========================================
add the following entries to the glossary:
DPI: Direct Programming Interface. This is an interface between
SystemVerilog and foreign programming languages permitting direct
function calls from SystemVerilog to foreign code and from foreign
code to SystemVerilog. It has been designed to have low inherent
overhead and permit direct exchange of data between SystemVerilog
and foreign code.
VPI: Verilog Procedural Interface. The 3rd generation Verilog PLI
(Programming Language Interface), providing object-oriented access
to Verilog behavioral, structural, assertion and coverage objects.
Additional corrections to sv-cc sections:
Section 26.1.2, page 246
========================================
(end of first paragraph) replace:
With some restrictions and with some notational extensions, most SystemVerilog data types
are allowed in DPI. Function result types are restricted to small values,
however (see Section 26.4.5).
with:
A rich subset of SystemVerilog data types is allowed for formal arguments of import
and export functions, although with some restrictions and with some notational extensions.
Function result types are restricted to small values, however (see Section 26.4.5).
Section 26.2, page 246
========================================
add new text at end of paragraph:
Different foreign languages will require, of course, that the SystemVerilog implementation shall use
the appropriate function call protocol, argument passing and linking mechanisms. This shall be,
however, transparent to SystemVerilog users. SystemVerilog 3.1 requires only that its implementation
shall support C protocols and linkage.
Section 26.3, page 247
========================================
(first paragraph + examples) replace
Every function imported to SystemVerilog must eventually resolve to a
global symbol. Similarly, every function exported from SystemVerilog
defines a global symbol. Thus the functions imported to and exported
from SystemVerilog have their own global name space, different from
$root name space. Global names of imported and exported functions must
be unique (no overloading is allowed ) and shall follow C conventions
for naming; specifically, such names must start with a letter or
underscore, and may be followed by alphanumeric characters or
underscores. Exported and imported functions, however, may be declared
with local SystemVerilog names. Import and export declarations allow
users to specify a global name for a function in addition to its
declared name. If a global name is not explicitly given, it will be
the same as the SystemVerilog function name. Example:
export "DPI" foo_plus = function \foo+ ; // "foo+" exported as "foo_plus"
export "DPI" function foo; // "foo" exported under its own name
import "DPI" init_1 = function void \init[1] (); // "init_1" is a global name
with
Every function imported to SystemVerilog must eventually resolve to a
global symbol. Similarly, every function exported from SystemVerilog
defines a global symbol. Thus the functions imported to and exported
from SystemVerilog have their own global name space of linkage names, different from
$root name space. Global names of imported and exported functions must
be unique (no overloading is allowed ) and shall follow C conventions
for naming; specifically, such names must start with a letter or
underscore, and may be followed by alphanumeric characters or
underscores. Exported and imported functions, however, may be declared
with local SystemVerilog names. Import and export declarations allow
users to specify a global name for a function in addition to its
declared name. Should a global name clash with a SystemVerilog keyword or a
reserved name, it shall take the form of an escaped identifier. The leading backslash (\)
character and the trailing whitespace will be stripped off. If a global name is not explicitly given, it will be
the same as the SystemVerilog function name. Example:
export "DPI" foo_plus = function \foo+ ; // "foo+" exported as "foo_plus"
export "DPI" function foo; // "foo" exported under its own name
import "DPI" init_1 = function void \init[1] (); // "init_1" is the linkage name
import "DPI" \begin = function void \init[2] () ; // "begin" is a linkage name
Section 26.4.6, page 251
========================================
(first paragraph and first list item) replace:
With some restrictions and with notational extensions, all SystemVerilog data types are allowed for formal
arguments of imported functions.
-- Enumerated data types are not supported directly. Instead, an enumerated data type is interpreted as the
type associated with that enumerated type.
with:
A rich subset of SystemVerilog data types is allowed for formal arguments of import and export
functions. Generally, C compatible types, packed types and user defined types built of types from these two
categories can be used for formal arguments of DPI functions. The set of permitted types is defined inductively.
The following SystemVerilog types are permitted for formal arguments of import and export functions:
-- void, byte, shortint, int, longint, real, shortreal, handle, and string
-- scalar values of type bit and logic
-- packed one dimensional arrays of type bit and logic
Note however, that every packed type, whatever is its structure, is eventually equivalent to a packed one
dimensional array. Therefore practically all packed types are supported, although their internal structure
(individual fields of structs, multiple dimensions of arrays) will be transparent and irrelevant.
-- enumeration types interpreted as the type associated with that enumeration
-- types constructed from the supported types with the help of the constructs:
-- struct
-- unpacked array
-- typedef
-- all and only the types listed above are permitted
The following caveat applies for the types permitted in DPI:
-- Enumerated data types are not supported directly. Instead, an enumerated data type is interpreted as the
type associated with that enumerated type.
Annex D.7.7, page 329
========================================
(almost bottom of page):
replace text reading:
-- bit (i.e., 2-state) packed arrays up to 32 bits (canonical representation shall be used, like
for a function result)
with:
-- bit (i.e., 2-state) packed arrays up to 32 bits (canonical representation shall be used, like
for a function result; thus a small packed bit array shall be represented as const svBitVec32)
Annex D.7.8, page 330
========================================
(entire section) replace text reading:
inout and output arguments, with the exception of open arrays, are always passed by reference. The same
rules about unused bits apply as in Annex D.11.7.
with:
inout and output arguments, with the exception of open arrays, are always passed by reference. Specifically,
packed arrays are passed, accordingly, as svBitPackedArrRef or svLogicPackedArrRef. The same rules about
unused bits apply as in Annex D.11.7.
Annex D.8.2, page 331
========================================
(beginning of last paragraph in section) replace text reading:
Note that context is transitive through imported and export context functions. That is, if an imported function
is running in a certain context, and if it in turn calls an exported function, the exported function will inherit the
context from the imported function.
with:
Note that context is transitive through import and export context functions declared in the same scope. That is, if
an exported function is running in a certain context, and it in turn calls an exported function that is available
in the same context, the exported function can be called without any use of svSetScope().
Annex D.8.3, page 331
========================================
add new text just prior to the C header code at the end of page:
A user wanting to share a data area across multiple contexts must do so by allocationg the common data area,
then storing the pointer to it individually for each of the contexts in question via multiple calls to
svPutUserData(). This is because, although a common user key can be used, the data must be associated with
the individual scopes (denoted by svScope) of those contexts.
Annex D.8.3, page 332:
========================================
(bottom of second to last comment) replace text reading:
* This function returns NULL for all error cases, 0 upon success.
* This function also returns NULL in the event that a prior call
* to svPutUserData() was never made.
*/
with:
* This function returns NULL for all error cases and a non-NULL
* user data pointer upon success.
* This function also returns NULL in the event that a prior call
* to svPutUserData() was never made.
*/
Annex D.9.1.3, page 335
========================================
add new text at start of section:
/* a handle to a scope (an instance of a module or an interface) */
typedef void *svScope;
Annex D.10.3.2, page 338
========================================
(end of first paragraph) replace text reading:
Additionally, 64-bit wide part select can be read as a single value of type long long.
with
Additionally, 64-bit wide part select can be read as a single value of type unsigned long long.
Annex D.10.3.2, page 338
========================================
(4th prototype from the bottom) replace text reading:
long long svGet64Bits(const svBitPackedArrRef s, int i); // 64-bits
with
unsigned long long svGet64Bits(const svBitPackedArrRef s, int i); // 64-bits
Annex E, page 346
========================================
replace text reading:
/* implementation-dependent representation */
/* a handle to a generic object (actually, unsized array) */
by:
/* implementation-dependent representation */
/* a handle to a scope (an instance of a module or interface) */
typedef void* svScope;
/* a handle to a generic object (actually, unsized array) */
Annex E, page 347
========================================
(near bottom of page) replace text reading:
/* canonical <-- actual */
void svGetPartSelectBit(svBitVec32* d, const svBitPackedArrRef s, int i,
int w);
void svGetPartSelectLogic(svLogicVec32* d, const svLogicPackedArrRef s, int i,
int w);
/* actual <-- canonical */
void svGetPartSelectBit(svBitVec32* d, const svBitPackedArrRef s, int i,
svBitVec32 svGetBits(const svBitPackedArrRef s, int i, int w);
svBitVec32 svGet32Bits(const svBitPackedArrRef s, int i); // 32-bits
long long svGet64Bits(const svBitPackedArrRef s, int i); // 64-bits
void svPutPartSelectLogic(svLogicPackedArrRef d, const svLogicVec32 s, int i,
int w);
by:
/* canonical <-- actual */
void svGetPartSelectBit(svBitVec32* d, const svBitPackedArrRef s, int i,
int w);
svBitVec32 svGetBits(const svBitPackedArrRef s, int i, int w);
svBitVec32 svGet32Bits(const svBitPackedArrRef s, int i); // 32-bits
unsigned long long svGet64Bits(const svBitPackedArrRef s, int i); // 64-bits
void svGetPartSelectLogic(svLogicVec32* d, const svLogicPackedArrRef s, int i,
int w);
/* actual <-- canonical */
void svPutPartSelectBit(svBitPackedArrRef d, const svBitVec32 s, int i, int w);
void svPutPartSelectLogic(svLogicPackedArrRef d, const svLogicVec32 s, int i,
int w);
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Tue Apr 22 2003 - 15:09:48 PDT