Re: [sv-bc] P1800 draft2 review : Sec 9 Processes

>Also, the Formal Syntax  Annex A A.1.4 these are still defined as
initial_construct, final_construct, always_construct
 
Good point.  It would make sense to rename these and define
 
       procedure ::= initial_procedure | always_procedure |
final_procedure
 
and add a footnote in non_port_program_item that it shall be illegal to
use an always_procedure in a program.
 
- Brad

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gran, Alex
Sent: Sunday, April 15, 2007 10:20 AM
To: sv-bc@eda-stds.org
Subject: [sv-bc] P1800 draft2 review : Sec 9 Processes


I had some time so I decided to read through Sec 9 Processes (1364-2005
9.7, 9.8,9.9, 10.3, 1800-2005 10.7 10.10, 11)
 
Here's what I noted.  Most of this stuff is just trying to find
consistency in the terms that are used for certain things, as apposed
any problems with the actual content.
 
~Alex
 
 
 
9.1
    In the list at top of 9.1 'initial' and 'always' are described as
"procedures" not "constructs".  Why is 'final' still a :"construct" not
a procedure?
        Section 9.1.3 refers to these as "final procedure"
 
    Also, the Formal Syntax  Annex A A.1.4 these are still defined as
initial_construct, final_construct, always_construct
        Will this introduce confusion having one term used in he BNF and
a different term used in the descriptive text?  Or will mucking with the
BNF between revisions cause more of a headache?
 
 
 
9.1.2.2
    This is a rather nit-picky thing.  Section 9.1.2.2 contains the
sentence "SystemVerilog provides a special always_comb procedure for
modeling combinational logic behavior."
      What makes always_comb so special, does it think its better than
all the other types of processes? :-)
     I think this sentence made more sense in 1800-2005 as way of
stating that always_comb was only in SV, not in plain old Verilog, but
in the merged document shouldn't all procedures be created equal?
 
 
 
9.1.2.2
     The phrase "a normal always procedure" has been replaced with "the
general purpose always construct"
     :Aren't we trying to use the term 'procedure' not 'construct' in
this version of the document?
 
 
9.1.2.2.1
    A few different places in this sub-sub-section always_comb is
referred to as a 'block'   I've always referred to always in verilog as
"always blocks" so reading this section it was clear to me what it was
saying, but it seems like we're trying to get some consistency in naming
of these things, so should we use the word 'procedure' instead?
    "The implicit sensitivity list of an always_comb includes the
expansions of the longest static prefix of each variable or select
expression that is read within the procedure or within any function
called within the procedure with the following exceptions:"
 
 
 
9.1.3
    The phrase "final block" is replaced with "final procedure"
everywhere in this section with the exception of the sentence
"SystemVerilog final blocks execute in an arbitrary but deterministic
sequential order. This is possible because final blocks are limited to
the legal set of statements allowed for functions"
 
 
 
9.3.2.3
    This sub-section starts with the sentence "SystemVerilog adds an iff
qualifier to the @ event control."
      I think  this wording made more sense in 1800-2005 to point out
something was was new in SV that didn't exist in plain old Verilog.  In
the merged version do we just want say something like "There is an
optional iff qualifier to the @ event control"?
 
 
9.4
    The list at the beginning of section 9.4 has the phrases "initial
block" "final block" and "always, always_comb, always_latch" and
"always_ff block"  For consistency should we use the same terms as the
list at top of Sec 9.1?  
 
 
 
9.4
    One of the items in the list at the top of this section is "Each
parallel statement in a fork...join (or join_any or join_none) statement
group"
    For consistent use of terms with Sec 9.2.3 should we use the term
"fork-join parallel block" instead?
 
 

-- 
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.