Subject: [sv-bc] RE: LRM 3.1 d raft 4 "light" review - Chapter 9
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Apr 10 2003 - 21:39:10 PDT
Hi Matt,
I have handled all of the issues from your review. I noted the LRM numbers
for the changes I made and reasons for not make some of the changes.
Thanks for the review.
Regards
David
-----Original Message-----
From: David W. Smith [mailto:david.smith@synopsys.com]
Sent: Thursday, April 10, 2003 9:16 PM
To: 'Maidment, Matthew R'
Subject: RE: LRM 3.1 d raft 4 "light" review - Chapter 9
-----Original Message-----
From: Maidment, Matthew R [mailto:matthew.r.maidment@intel.com]
Sent: Thursday, April 10, 2003 10:12 AM
To: 'david.smith@synopsys.com'
Subject: FW: LRM 3.1 d raft 4 "light" review - Chapter 9
Hi David.
FYI. Here are my comments regarding chapter 9.
Matt
-----Original Message-----
From: Maidment, Matthew R
Sent: Thursday, April 10, 2003 12:49 AM
To: Srouji, Johny
Subject: LRM 3.1 d raft 4 "light" review - Chapter 9
Hi Johny.
Here are my comments. They are numerous and picky.
Matt
9.1
CHANGE:
In an always block which is used to model combinational logic, forgetting an
else
leads to an unintended latch. To avoid this mistake, SystemVerilog adds
specialized always_comb and always_latch blocks, which indicate design
intent to simulation,
synthesis and formal verification tools. SystemVerilog also adds an
always_ff block
to indicate sequential logic.
TO:
In an always block which is used to model combinational logic, forgetting an
else
leads to an unintended latch. To avoid this mistake, SystemVerilog adds
specialized always_comb and always_latch blocks, which indicate design
intent to simulation,
synthesis and formal verification tools. Along with always_latch blocks,
SystemVerilog adds always_ff blocks to indicate sequential logic.
DWS: No change. There is some disagreement on this that needs to be resolved
before a change is made.
-- both latches and flops are sequential circuits
CHANGE:
Execution of each thread may be interrupted between statements at a
semicolon, but a single statement (not a block) containing no user task or
function call is uninterrupted.
TO:
Execution of each thread may be interrupted between statements at a
semicolon, but a single statement (not a block) containing no user task or
function call cannot be interrupted.
--symmetry of phrasing
DWS: Fixed in LRM-183
CHANGE:
SystemVerilog 3.1 adds dynamic processes by enhancing the fork...join
construct, in a way that is more natural to Verilog users.
TO:
SystemVerilog 3.1 adds dynamic processes by enhancing the fork...join
construct in a way that is more natural to Verilog users.
--unnecessary comma
DWS: Fixed in LRM-184
9.3
-- What is "latch sensitive?" Latches are level sensitive.
Why not Level-Sensitive Sequential Logic for 9.3, Edge-Sensitive
Sequential Logic for 9.4 and either Combinational Logic or
Level-Sensitive Combinational Logic for 9.2?
DWS: Changed titles of 9.2, 9.3, and 9.4 in LRM-185
9.6
"The fork...join construct provides the primary mechanism for creating
concurrent processes."
Aren't always blocks the primary mechanism for creating concurrent
processes? Why not something like...
"The fork...join construct enables the creation of concurrent processes from
each of its parallel statements."
DWS: Changed in LRM-186
CHANGE:
In Verilog a fork...join block always causes the process executing the fork
statement to block until all the forked off processes terminate.
SystemVerilog adds the join_any and
join_none keywords that specify when the parent (forking) process resumes
execution.
TO:
In Verilog a fork...join block causes the process executing the fork
statement to block until the termination of all forked processes. With the
addition of the join_any and join_none keywords, SystemVerilog provides
three choices for specifying when the
parent (forking) process resumes execution.
-- fork..join also specifies when the parent process resumes execution.
join_any and join_none off 2 additional choices
DWS: Changed in LRM-187
QUESTION:
In table 9-1, the verb for creating separate processes is "spawn" but
before and after it is fork. I suggest using "fork" in the table
or substiting the verb fork with the verb spawn in the entire chapter.
DWS: I will choose to leave as is. I do not think it generates confusion. I
do agree it is inconsistent but both terms are well understood.
CHANGE:
In the following example, two processes are forked off,
TO:
In the following example, two processes are forked,
--I believe the off is redundant in "forked off"
DWS: Fixed in LRM-188
CHANGE:
Because the join keyword is specified, the parent process will block until
the two processes complete, that is, 20ns have elapsed
and eventA has been triggered.
TO:
Because the join keyword is specified, the parent process will block until
the two processes complete. That is, 20ns have elapsed and eventA has been
triggered.
-- New sentence starting with "That is"
DWS: Fixed in LRM-188
CHANGE:
SystemVerilog 3.1 deprecates the process statement, in favor or the
fork...join_none form.
TO:
SystemVerilog 3.1 deprecates the process statement in favor of
fork...join_none.
DWS: Fixed in LRM-188
9.7
CHANGE:
but a single statement (not a block) containing no user task or function
call shall not be interrupted.
TO:
but a single statement (not a block) containing neither a user task nor a
function call shall not be interrupted.
DWS: Fixed in LRM-189
9.8.1
REGARDING:
"In the following example, in the task do_test, the first two processes are
spawned and the task blocks until one of the two processes completes (either
exec1, or exec2). Next, two more processes are spawned in the background.
The wait fork statement will ensure that
the task do_test waits for all four spawned processes to complete before
returning to its caller."
--Again there's a switch from fork to spawn. Why not replace spawn with
fork?
DWS: See above response.
9.8.2
CHANGE:
static syntactical information
TO:
static, syntactical information
DWS: Fixed in LRM-189
REGARDING:
"Thus, disable will end all processes executing a particular block, whether
the processes were forked by the calling thread or not, while disable fork
will end only those processes that were spawned by the calling thread."
--Again we see the intermixing of fork and spawn. Would prefer one or the
other
DWS: See above response.
-----Original Message-----
From: Srouji, Johny [mailto:johny.srouji@intel.com]
Sent: Tuesday, April 08, 2003 11:05 AM
To: sv-bc@eda.org
Subject: RE: [sv-bc] Draft 4 section numbers have changed - Was: LRM 3.1 d
raft 4 "light" review process
Hi All,
Here are the new assignments, based on Draft 4.0
Chapters 1, 14, 15 ==> Cliff Cummings
Chapter 12 ==> Brad Pierce
BNF, Annex A, B ==> Dan Jacobi
Chapters 2, 3, 4, 5, 7 ==> Dave Rich
Chapters 11, 13 ==> Francoise Martinolle
Chapter 16 ==> Karen
Chapter 8 ==> Dennis
Chapter 9 ==> Matt Maidment
Chapter 10 ==> Johny
Thanks,
--- Johny
-----Original Message-----
From: Clifford E. Cummings [mailto:cliffc@sunburst-design.com]
Sent: Monday, April 07, 2003 11:52 PM
To: sv-bc@eda.org
Subject: [sv-bc] Draft 4 section numbers have changed - Was: LRM 3.1 draft 4
"light" review process
Hi, Johny -
I think we need to make a quick adjustment to some of the section
assignments. I signed up to review section 13, based on the chapter-order
of Draft 3.
Draft 3-section 13 is now Draft 4-section 15.
Draft 4-section 14 is new (Scheduling Semantics). I will also review this
section.
Draft 3-section 12 is now Draft 4-section 13. I believe Francoise
Martinolle signed up to take this section.
More section juggling has taken place, so you probably need to make a quick
correction to the assignments.
Cliff Cummings will now review - Section 1, 14, 15.
Regards - Cliff
At 05:56 PM 4/3/03 +0300, Srouji, Johny wrote:
>Hi all,
>
>Please do not start any review until Draft 4.0 is out. It will be very
>hard to get the section/page numbering correct otherwise.
>
>The meeting for next Monday, April 7, is CANCELLED (we don t have
>enough
>time to review draft 4.0)
>
>--- Johny.
>
>-----Original Message-----
>From: Srouji, Johny
>Sent: Wednesday, April 02, 2003 8:18 PM
>To: sv-bc@eda.org
>Cc: David W. Smith
>Subject: [sv-bc] LRM 3.1 draft 4 "light" review process
>
>Hi All,
>
>Given that draft 4.0 is not out yet, I suggest that we follow a lighter
>process of the EC sections review.
>
>David Smith did a quick analysis of the BC and EC changes which were
>submitted to Stu for Draft 4.0. Based on his analysis there were no
>conflicts requiring changes, which is good news.
>
>I suggest that each owner (list is below) for a chapter, reads the
>relevant EC section in his chapter and send any typo, semantics
>corrections, etc issues to David and copy me (I will compile major
>issues which probably will have to be tabled for LRM 3.2). At this
>stage, I don t think we need another sv-bc meeting next Monday, April
>7. I will send an update before the weekend.
>
>Here is the list of owners per chapters:
>
>Chapters 1, 13 à Cliff Cummings
>Chapter 20 à Brad Pierce
>BNF, Annex A, B à Dan Jacobi
>Chapters 2, 3, 4, 5, 7 à Dave Rich
>Chapters 11, 12 à Francoise Martinolle
>Chapter 15 à Karen
>Chapter 8 à Dennis
>Chapter 9, 10 à Matt Maidment
>Chapter 10 à Johny
>
>Thanks,
>
>--- Johny.
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com /
www.sunburst-design.com Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Thu Apr 10 2003 - 21:36:52 PDT