Subject: [sv-cc] RE: Final LRM corrections from sv-cc
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Apr 22 2003 - 17:22:13 PDT
These have all had changes created. See the LRM numbers below for
references.
Regards
David
-----Original Message-----
From: David W. Smith [mailto:david.smith@Synopsys.COM]
Sent: Tuesday, April 22, 2003 4:55 PM
To: Joao.Geada@Synopsys.COM; 'David Smith'
Cc: 'sv-cc'
Subject: RE: Final LRM corrections from sv-cc
See below
David
-----Original Message-----
From: Joao Geada [mailto:joao@Synopsys.COM]
Sent: Tuesday, April 22, 2003 3:06 PM
To: David Smith
Cc: sv-cc
Subject: Final LRM corrections from sv-cc
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.
DWS: LRM-298
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).
DWS: LRM-328
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.
DWS: LRM-329
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
DWS: LRM-330
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.
DWS: LRM-331
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)
DWS: LRM-332
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.
DWS: LRM-333
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().
DWS: LRM-334
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.
DWS: LRM-335
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.
*/
DWS: LRM-336
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;
DWS: LRM-337
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.
DWS: LRM-338
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
DWS: LRM-339
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) */
DWS: LRM-340
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);
DWS: LRM-341
============================================================================
==
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 - 17:21:41 PDT