[sv-bc] LRM review ch 18.


Subject: [sv-bc] LRM review ch 18.
From: Mark Hartoog (Mark.Hartoog@synopsys.com)
Date: Sun Feb 08 2004 - 21:51:22 PST


1) In section 18.1, page 262, it says:

— Removal of the $root global declaration space from SystemVerilog 3.1

I don't think this belongs in this list of enhancements that System Verilog
adds for design hierarchy. I would remove this from this list, and add another
paragraph at the end of section 18.1:

Note the $root global declaration space from SystemVerilog 3.1 has been removed.

-----------------------------------------------------------------------------------------------

2) In first paragraph of 18.2 it says:

Types, variables, tasks, functions, sequences, and properties may be declared
within a package.

This is incomplete. We should add parameters and classes to this list.

-----------------------------------------------------------------------------------------------

3) In Syntax 18-1 on page 263, 'timeunits_declaration' under package_item has footnote
19 attached to it. Since this is footnote 19 in Annex A, I don't think the footnote
should be included in Syntax 18-1.

-----------------------------------------------------------------------------------------------

4) The example at the bottom of page 263 has one line that is improperly indented.

Instead of:

package ComplexPkg;
   typedef struct {
   float i, r;
} Complex;

   function Complex add(Complex a, b);
   ...

It should be:

package ComplexPkg;
   typedef struct {
      float i, r;
   } Complex;

   function Complex add(Complex a, b);
   ...

-----------------------------------------------------------------------------------------------

5) In section 18.13, on page 279, it says:

"5) The module name space is introduced by $root and the module, macromodule, interface, package,
program, and primitive constructs. It unifies the definition of modules, macromodules, interfaces,
programs, functions, tasks, named blocks, instance names, parameters, named events, net
declarations,
variable declarations and user defined types within the enclosing construct."

I do not believe that $root belongs here any more. I think this should be changed to

"5) The module name space is introduced by the module, macromodule,...."

-----------------------------------------------------------------------------------------------

6) In section 18.13, on page 279, the item on the port name space talks about input, output
and inout ports, but not ref ports. I would propose the following changes:

From: "The connection can be unidirectional (either input or output) or
bidirectional (inout)."

To: "The connection can be unidirectional (either input or output) or
bidirectional (inout or ref)."

From: "The port type of declarations includes input, output, and inout."

To: "The port type of declarations includes input, output, inout, and ref."

-----------------------------------------------------------------------------------------------

7) In section 18.14 on Hierarchical Names, the last sentence says:

"They can also be used as type, task or function names."

I thought we voted that type names cannot be hierarchical names? Is my memory wrong or did we miss
this?

Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com



This archive was generated by hypermail 2b28 : Mon Feb 09 2004 - 06:24:13 PST