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

Hi,

 

> Attached are Cliff's review notes for chapter 10

 

1. Cliff wrote:

 

Page 167 - paragraph before Example 1: (Problem - description added some
cases but not

all cases - I think we would do well to define either "DRIVER" or
"DRIVING SOURCE"

and we can reference and keep the driving-source list up to date)

WAS: Nets can be driven by multiple continuous assignments or by a
mixture of

primitive outputs, module outputs, and continuous assignments. Variables
can only be

driven by one continuous assignment or by one primitive output or module
output,. It

shall be an error for a variable driven by a continuous assignment or
primitive output to

have an initializer in the declaration or any procedural assignment. See
also 6.3.

PROPOSED: Nets can be driven by a mixture of one or more continuous
assignments

and driving sources. Variables can only be driven by one continuous
assignment or by

one driving source. It shall be an error for a variable driven by a
continuous assignment

or driving source to have an initializer in the declaration or any
procedural assignment.

See also 6.3.

PROPOSED: 10.2.2.1 Driving Source

A driving source drives a value onto a net that resolves all driving
sources to the

appropriate value and strength of all of the combined driving sources.
Driving sources are

defined as:

* module outputs and inouts.

* program outputs and inouts.

* primitive outputs.

* clocking block outputs and inouts.

* interface outputs and inouts.

 

This distinguishes between continuous assignments and driving sources. I
don't see the reason for the distinction. I also think that currently it
is a problem to define the terms "driver" or "driver source" as Cliff
has done. These terms are currently used widely throughout the LRM with
respect to both nets and variables, including with respect to continuous
assignments. They are also used with respect to both sources and sinks.
By that, I mean that the term "net driver", for example, can mean either
"net which is a driver" or "driver of a net". So I think Cliff's
proposal would be more confusing than helpful without an LRM-wide
revision to make the use of these terms consistent throughout.

 

 

2. Cliff wrote,

 

"Page 170 - I believe Stu correctly added Procedural assignment
operators, but I think this

list is still incomplete.

 

WAS: SystemVerilog contains three types of procedural assignment
statements:

- Blocking procedural assignment statements (see 10.3.1)

- Nonblocking procedural assignment statements (see 10.3.2)

- Procedural assignment operators (see 11.2.7)"

 

Stu has added the term "procedural assignment operator". It is used only
here and in 10.3.1, "Procedural assignment operators are described in
11.2.7", which is also text that Stu has added. 11.2.7 itself does not
use that term, just "assignment operators". So I think 11.2.7 should
define the term.

 

In fact, the entire term 'assignment operator' is not used consistently
in the LRM. It is used sometimes to refer to an entire set of operators,
and sometimes to refer specifically to '='.

 

 

3. Cliff wrote,

 

"PROPOSED: SystemVerilog contains five types of procedural assignment
statements:

- Blocking procedural assignment statements (see 10.3.1) including
procedural

assignment operators (see 11.2.7) and increment and decrement operators
(see

11.2.8).

- Nonblocking procedural assignment statements (see 10.3.2)

- Clocking block synchronous drives (see 14.14)"

 

Cliff wrote, "five". As a general note, it is best not to write the
number because it is not important, and because it changes as we change
the LRM. In fact, as Cliff has written the proposal, there are 3, not 5.

 

 

4. Regarding Stu's question:

Does the result of a continuous assignment to a variable update
immediately when the

variable is released?

 

I think it should, in order to be consistent with the behavior of
continuous assignments. 

 

Regards,

Shalom

 

 


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