RE: [sv-bc] MERGE REVIEW draft 2: Chapter 11

They are mostly a result of the merge, often in text newly added by the
editor.

-- Brad

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Tuesday, April 10, 2007 4:54 PM
To: Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] MERGE REVIEW draft 2: Chapter 11

Hi Brad,

For the review of 1800-2008 draft 2, are these issues a direct result of
the merge, or are these issues that existed in the original sources?

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Brad Pierce
> Sent: Tuesday, April 10, 2007 4:33 PM
> To: sv-bc@server.eda-stds.org
> Subject: [sv-bc] MERGE REVIEW draft 2: Chapter 11
> 
> Intro "Process threads and process control"  Wrong clause.
> 
> 11.1 "An operand can be one of the following: ... Any net type ... Any

> net type"  What is a net type?  (And why is it listed twice?) A net is
a
> more likely operand than a type, although, of course, the type
operator
> and some system tasks can be applied to data types.
> 
> 11.1 This long list of possible operands is not an aid to
understanding.
> 
> Table 11-1 "C-like"  Why are we bothering to say "C-like"?  And why 
> aren't any of the following operators, also in C, considered "C-like":
> %=, <<=, >>=, &=, ^=, |= ?
> 
> Table 11-2 Where else does the LRM say that ++ and -- can be applied
to
> real operands?  Is this based on the precedent of C?
> 
> 11.2.10  "All net types are unsigned by default.  The byte, shortint, 
> int, integer and longint variable types are signed types by default.
> Other variable types are unsigned by default. See 6.5 for variable 
> types."  The reason 'byte', 'shortint', etc. are disallowed on nets is

> not because they are "variable types", but because they are 2-state 
> types.  (This limitation was the topic of ballot issue 228.)  There
are
> kinds and there are types, and some types cannot be used with some 
> kinds.  For example, a data object of net kind cannot have a 2-state 
> data type.
> 
> 11.2.18 "If cond_predicate is true, the operator returns the first 
> expression; if false, it returns the second expression."  Actually, it

> evaluates an expression and returns its value.
> 
> 11.3.1-2 A bit-select, constant part-select, or indexed part-select
can
> be used with unpacked arrays, too.
> 
> 11.5 "The cast operator can be used to change either the signedness or

> type of an expression"  Signedness is an aspect of a packed type.  A 
> packed type is either signed or unsigned.  Saying "either ... or" here

> is like saying "either speed or velocity".
> 
> 11.5 "for casting the signedness (but not the type) of expressions"
The
> signedness is an aspect of the type.
> 
> 11.5 "These functions shall evaluate the input expression and return a

> value with the same size and value of the input expression and the
type
> defined by the function."  Even according to the immediately preceding

> sentence, it not the type that is "defined" by $unsigned() and
$signed()
> -- it is the signedness of the type.
> 
> 11.5, In the following newly added example, the value assigned to regA

> would be the same without the unsigned'() cast
> 
>     regA = unsigned'(-4); // regA = 8'b11111100
> 
>   Yes, there's already a similarly useless example for $unsigned(),
but
> why compound the problem?
> 
> 11.6.1 "For the purposes of this discussion, any packed type is
referred
> to as a vector."  Data objects, not data types, are referred to as 
> "vectors" in 11.6.1.1.  For example, "stored in vectors".
> 
> 11.9 "SystemVerilog models typically specify three values for delay 
> expressions."  Is this really typical?
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 


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