[sv-cc] RE: Resolution of sv-cc LRM issues


Subject: [sv-cc] RE: Resolution of sv-cc LRM issues
From: David W. Smith (david.smith@synopsys.com)
Date: Wed Apr 09 2003 - 15:47:41 PDT


Thank you Joao,
I now have something to do this evening (was worried about getting bored :)
).
I really appreciate you getting as much as can to me before Friday.

Regards
David

-----Original Message-----
From: Joao Geada [mailto:joao@Synopsys.COM]
Sent: Wednesday, April 09, 2003 3:21 PM
To: sv-cc; David Smith
Cc: Ghassan Khoory; Swapnajit Mittra
Subject: Resolution of sv-cc LRM issues

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:45:33 PDT