Subject: [sv-cc] Resolution of sv-cc LRM issues
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Apr 09 2003 - 15:20:54 PDT
David,
attached is the resolution of most of the sv-cc LRM issues.
Still outstanding are LRM issues: 40, 41, 44, 45, 70, 71
I expect to be able to have those remaining issues addressed by end of day
tomorrow at the latest.
(all page and section references are with respect to draft 4, page numbers
are LRM page numbers, not PDF page numbers)
LRM-12:
(page 82, section 10.6, last paragram):
Resolution: Change 2nd sentence to read as follows:
from:
For any given cname, all declarations, regardless of scope, must have exactly the same type
signature. The type signature includes...
to:
For any given cname, all declarations, regardless of scope, must have exactly the same function
signature. The function signature is...
Note to editors: function signature is a well defined concept in programming
languages and is conceptually just the canonical prototype of a function.
Two functions have the same signature if their canonical prototypes are identical.
LRM-13:
(page 82, section 10.6, last paragraph):
Issue: update cross-ref (in draft 4, reads 1.4.5)
Answer: 26.4.6.1
LRM-28: update cross-ref
(page 258, section 26.4.4, first paragraph):
Issue: update cross-ref (in draft 4, reads 10.6)
Answer: 10.6
LRM 29: NULL should be lower-case
(page 259, section 26.4.4, in examples)
Issue: is uppercase NULL correct.
Answer: should be lowercase "null"
LRM 30:
(page 260, section 2.4.6.1, examples at bottom of page)
Issue: confusion between lower-case 'L' and digit '1'
Resolution: change examples to read as follows:
logic
bit [8:1]
bit[]
bit [7:0] array8x10 [1:10] // array8x10 is a formal arg name
logic [31:0] array32xN [] // array32xN is a formal arg name
logic [] arrayNx3 [3:1] // arrayNx3 is a formal arg name
bit [] arrayNxN [] // arrayNxN is a formal arg name
LRM 31:
(page 264, section 27.1.2, last definition)
Resolution: remove the comment (text reading "// This is ...")
LRM 32:
(page 263, section 27.2, first paragraph)
Resolution:
- change paragraph
from:
These extension shall be merged into the ...
to:
These extensions shall be appended to the ...
sv-cc resolved to keep all remaining text unchanged, as it is the
intent that there be only 1 (one) include file necessary to be
able to use vpi interface
LRM 33:
(page 265, section 27.2.3, assertion enumerations)
Resolution: there is no issue. VPI object properties, callbacks and control
constants all have different enumeration spaces and so can use the same
integer values across different spaces without clashing.
LRM 34:
(page 267, section 27.3.2)
Resolution:
delete item 6 (it was only a comment for sv-ac reviewers)
following line "-- Assertion source..." should be indented left to the
same indentation as list of items that start with "-- Assertion name"
follwing line "-- Assertion clocking...", remove the digit '2' at the end
of the line.
LRM 35:
(page 269, section 27.4.1, section header)
Resolution: remove quotes around the word "system"
LRM 36:
(page 270, section 27.4.2, cbAssertionStepSuccess description, first sentence)
Resolution:
change:
... one "thread" along an attempt.
to:
... along one path through the attempt.
LRM 37:
(page 272, section 27.5.2, list item preceeding vpiAssertionEnableStep)
Resolution:
remove quotes around "step control".
(NOTE: to sv-cc readers: the comment about clock stepping follows immediately
at the bottom of page, so no need to repeat it again in this sentence)
LRM 38:
(page 274, section 28.2)
Replace: This section ...
With: This section describes the mechanisms in SystemVerilog through which
SystemVerilog code can query and control coverage information. Coverage
information is provided to SystemVerilog by means of a number of built-in
system functions (described in section 28.2.2) using a number of predefined
constants (described in section 28.2.1) to describe the types of coverage
and the control actions to be performed.
LRM 39:
(page 275, section 28.2.2)
Remove: This section ...
LRM 42:
(page 281, section 28.4)
Remove: This section ...
LRM 43:
(page 281, section 28.4.1)
Remove: This section ...
Also, I (Joao) need to provide a number of VPI entity/relation diagrams for
this section.
LRM 62:
(page 331, section D.1)
correct cross ref: 26.5.1
LRM 63:
(page 333, section D.5)
correct cross ref: 26.4.1
LRM 64:
(page 334, section D.5.5)
correct cross ref: 26.4.3
LRM 65:
(page 335, section D.5.6)
correct cross ref: 26.4.2
LRM 66:
(page 335, section D.5.7)
correct cross ref: 26.4.1.4
LRM 67:
(page 337, section D.6.6)
correct cross ref: 4.2
LRM 68:
(page 339, section D.7.2)
correct cross ref: D.11.11
LRM 69:
(page 339, section D.7.5)
correct cross ref: D.11.11
LRM 72:
(page 347, section D.10.2)
correct cross ref: D.6.6
LRM 73: update cross-ref
(page , section D.11.1)
correct cross ref: D.6.6
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
344 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Wed Apr 09 2003 - 15:23:09 PDT