RE: [sv-bc] Stu's QUESTIONS and NOTES in Draft 4

Hi Shalom,

 

I can take a stab at a few of these, mostly in the DPI area.

(Hence I'm copying SV-CC, hello guys)

 

34.10:  I can no longer see the question in Draft4, but I do see

all the strike-through text.  (Maybe my Acrobat is acting up again,

though I do see other questions).

 

I remember Stu asked SV-CC this question some months back,

and the answer was "Yes", the text is redundant and can be removed.

 

I.9.1.3  I think we should change the comment to read as follows:

/*

 * Returns one of the following version strings:

 * "1800-2008"

 * "1800-2005"

 * "SV3.1a"

 */

const char* svDpiVersion();

 

I filed Mantis 2101 and uploaded a proposal for this one.

SV-CC should add this to their list of items at the next meeting.

(It's trivial)

 

I.12 I think the deprecated clause should be referenced in Annex C,

like the rest of the deprecated PLI material.  That would be for SV-CC

to decide, maybe at the next meeting?

 

Thanks,

Doug

 

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Thursday, October 11, 2007 4:32 AM
To: sv-bc@server.eda.org
Subject: [sv-bc] Stu's QUESTIONS and NOTES in Draft 4

 

These are all the editor's questions that I found in Draft 4. I filed
them as Mantis 2099.


 
3.10.1: These (22.7, 22.6) are the cross-references that were in
1800-2005. Are they correct? 

3.12, Table 3-1: Should "step" be added to this table? (per A.8.4) 

3.12.1: The term "time scaling" is not defined in 1364-2005 or
1800-2005. Does it need to be? 

6.6, Syntax 6-1: are more productions needed? (e.g. to show packed and
unpacked dimensions)

6.7, Syntax 6-2: Are all these productions needed here?

6.20.1:  Does this rule only apply to parameter port lists?

6.24.3: The description of this example would make more sense if the
definition of source_t and dest_t were added.

6.24.3: Is "xor()" a keyword in this context (should it be bold)? (also
see 7.13.3)

7.4.3:  Are these rules really for "all arrays", including dynamic,
associative and string?

7.13.3:  Are "and()" "or()" and "xor()" keywords in this context (should
they be bold)?

8.2: "A common convention is to capitalize the first letter of the class
name so that it is easy to recognize class declarations." Should this
LRM follow this convention? 

9.6.2, Example 3:  Is a new example needed? I added indentation for
clarity, but: 1) The second "always" has no context. 2) The task disable
does not show the "terminate execution of a named block" in the
description.

10.6.1: Does the result of a cont. assign to a variable update
immediately when the variable is released? 

10.6.1: What about unpacked stucts, enums, classes, etc.? 

10.6.2: What about unpacked stucts, enums, classes, etc. 

11.2.1: Are all operators listed in table 11-1 after merging in SV still
legal in constant expressions? 

11.5.2: This text comes directly from 1364-2005. There was no matching
subclause from 1800-2005 to merge in. Is new text needed for SV array
addressing ?

11.6.1, Table 11-23: SV operators need to be added to this table. 

13.4.4: Also interface and program? 

16.14.3:  This code looks like a mix of BNF and example. Should it be
all one or the other?

19.5: should $signed/$unsigned be moved to Annex D since SV has sign
casting? 

20.3.1: Is string type legal? 

20.3.7: Is string type legal? 

21.4: What is this "unchanged behavior"? I could not find it in 1364. 

22.3.1: Is this last sentence still true in SV (i.e. can it be one
interface or one program)? 

22.3.3.3: Is 'z correct for all net type (e.g. tri1)?  

24.9: Shouldn't this new example have an intro paragraph and
explanation? (Update for Draft 4: This question is filed as Mantis 1742,
but is not resolved)

26.3, Syntax 26-1: The 1364-2005 BNF was organized differently than
1800's. The BC committee needs to verify that I copied the right
productions.

28.3.2: Can "logic" also be used? 

30.6: Can the notifier be any variable type (per the BNF) or are only
1-bit types allowed? 

31.9: Is string type legal? 

32.7: Are there any changes to this subclause to support SV design
blocks? 

34.10: This subclause seems to be mostly, if not entirely, redundant
with the rest of this Clause. Can this subclause be deleted? If not, can
the redundant text be replaced with cross references?

35.11:  These tables were not updated as part of the merge. Are there
additional routines to add? Would a better place for these tables be the
beginning of clause 37?

40.7: Should this subclause be merged into Clause 36? 

40.12: Should this subclause be merged into Clause 37? 

D.2: does "vector" need to be changed to allow for a single bit of a
multidimensional packed array? 

D.12: does "vector" need to be changed to allow for other SV types? 

D.13: can the SV string type also be used? 

I.9.1.3: should this be changed to "P1800-2008"? 

I.12: Should this deprecated subclause be moved to, or referenced in,
Annex C? 

Shalom Bresticker 
Intel Jerusalem LAD DA 
+972 2 589-6852 
+972 54 721-1033 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


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