Date: Mon Apr 16 2007 - 08:39:27 PDT
Some comments about organization, clause 1, and clause 3: 12.7 ("Named blocks and statement labels") should be in 9.2 ("Block statements"). 16.15 ("Binding"): it was suggested to move this section to the clause on hierarchies. That suggestion seems to generally have been favorably received. 35 ("Programming language interface (PLI and VPI) overview"): On the one hand, VPI is treated as one generation of PLI, e.g., "Verilog procedural interface routines, called VPI routines, are the third generation of the PLI," i.e., as being included in the term 'PLI'. On the other hand, it is also treated separately, as in the title of clause 35, "PLI and VPI". This seems inconsistent and confusing. 1.2: "Informative delay model for SDF": What is this referring to? 1.4: "If the name of any category starts with an italicized part, it is equivalent to the category name without the italicized part. The italicized part is intended to convey some semantic information. For example, "msb_index" and "lsb_index" are equivalent to "index." Can we finally take this out? I don't think it applies anywhere except in the VCD file syntax description, which is not part of Annex A anyway. 1.6: "Clause 25 describes user-defined packages, compilation units ($unit), and built-in packages.": $unit is described in 3.8.1. 1.6: "Annex G (normative) describes the SystemVerilog standard packages, containing type definitions for mailbox, semaphore, randomize, and process." -> should be "package", as only one package, Std, is described. 1.8: "Several small SystemVerilog code examples are shown throughout this standard.": 'several' sounds like just a few. Since it is probably several hundred, the word 'several' should just be deleted. 3.1: "A design element is a SystemVerilog module (see Clause 22), program (see Clause 22), interface (see Clause 24), package (see Clause 25), primitive (see Clause 27) or configuration (see Clause 31)." - Yes, I see that 31.1 insists that a configuration is a design element, but almost of all the uses of the term within the LRM, most of which relate to timescales, are not relevant to configs. And if a configuration is to be treated as a design element, then it needs to have an overview description in clause 3, like the other types of design elements. 3.2 lists among the constructs modules can contain: "procedural blocks", where the reference is to always, initial, etc. procedures/constructs. Re the discussion about what to call these constructs, there are a number of places, such as here, where the term 'procedural block' is used, and it will be either awkward or unclear to just say 'procedure'. 3.7: "A list of building block instances is referred to as a netlist." I think this is too big a generalization of the term netlist, and it is not used elsewhere except in one example in 3.7 where it is really is a gate-level description. I think the sentence should be stricken. 3.7: That same example contains the line: "not g1(sel_n, a, sel);". That looks like a mistake. A not gate has one input and one or more outputs, and a is an input to the module. I think it should just be "not g1(sel_n, sel);". But what can you expect from us? Who writes gate-level manually anymore except analog designers?? Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
