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, and is believed to be clean.Received on Sun Apr 15 10:20:06 2007
This archive was generated by hypermail 2.1.8 : Sun Apr 15 2007 - 10:20:39 PDT