RE: [vhdl-200x] Revision of path name proposal doc

Hi Peter,

Feedback on the document:

1. Introduction

A key use of pathnames is not listed here. Users specify pathnames from outside an HDL design in order to specify the objects to which commands apply. This usage includes wildcard specifications, so the user can specify groups of objects with one or a few pathnames. While this is technically outside the language, it could be argued that this nonetheless is worth defining as part of the language, just as the printed form of a pathname is in some sense also outside the language.

2.5 PSL names

Pathnames appear in PSL in the context of a verification unit, which can be 'bound' to either a module (i.e., design entity) or an instance within the design hierarchy. In the general case, we may be dealing with a mixed language design, so PSL pathnames need to allow for a mixture of VHDL and Verilog names.

Pathnames only appear in the PSL grammar in one place: as the module/design entity or instance name to which a verification unit is 'bound' (i.e., the portion of the design in the context of which the PSL is interpreted). This pathname appears within parentheses, as in these Verilog-oriented examples:

  vunit (modulename) {
    ...
  }

or
  
  vunit (top.i1.i2.i3) {
    ...
  }

In a VHDL context, PSL v1.1 now allows a vunit to specify the design unit to which it is bound using the syntax for "entity_aspect" in VHDL - i.e., an /entity/_Name optionally followed by a parenthesized /architecture/_Name. So the following examples will be accepted in PSL v1.1:

  vunit (E) { -- bound to (every architecture of) entity E
    ...
  }

  vunit (E(A)) { -- bound to architecture A of entity E
    ...
  }

For an instance pathname, the PSL v1.1 LRM is not very specific, but it basically says that, following an initial module/design entity specification, there may be a sequence of (VHDL or Verilog) instance names. So the following would all be acceptable:

  vunit (e.a.b.c.d) ...

      (where e is an entity and a,b,c,d are all labels on subordinate component/entity instances)

  vunit (e(a).b.c.d) ...
    
      (where e is an entity, a is an architecture of e, and b,c,d are labels on instances under a)

Note that a pathname always starts with a 'module name', i.e., an entity_aspect for a VHDL design entity, or a module_name for a Verilog module. (I'll use 'module' from now on to mean either of these, as appropriate for a given context.) This may be the name of the topmost module in the design (which is not instantiated elsewhere) or a module that is instantiated one or more times at various places and levels within the design.

Following is the syntax for PSL pathnames (called "Hierarchical_HDL_Name" in the syntax):
    
    Hierarchical_HDL_Name ::=
      HDL_MOD_NAME { Path_Separator /instance/_Name }

    Flavor Macro HDL_MOD_NAME =
      SystemVerilog: /module/_Name
      / Verilog: /module/_Name
      / VHDL: entity_aspect
      / GDL: /module/_Name

    Path_Separator ::=
      '.' | '/'

(In case it is not evident, /text/ in the BNF represents italicized text, i.e., comments that carry semantic information but can be ignored when building a parser.)

The "Flavor Macro" here is like a BNF production, except that it requires a consistent selection based on the underlying HDL context - so in VHDL, HDL_MOD_NAME must go to entity_aspect, and in other languages it must go to a single Name that denotes a 'module' in whatever language is involved.

Note that the syntax allows both '.' and '/' to be used as separators in a pathname, and also allows them to be intermixed in the same pathname.

One limitation of PSL today is that it does not deal with blocks (including generate statements) nested within an architecture - or rather, the PSL LRM does not acknowledge the possibility that labels in a pathname might refer to blocks rather than instances. In incorporating PSL into VHDL 200x, we might consider clarifying this (which clarification should eventually be merged back into some future PSL v1.x LRM).

Another limitation is the fact that PSL doesn't consider library logical names.

3.3 Wildcard path names

What you've outlined here addresses PSL requirements quite well. Note that PSL only requires pathnames that end in (designations of) declarative regions. A vunit is bound to (all instances of) a design entity (or, if/when we extend it, blocks within a design entity). Pathnames that identify objects, processes, etc. are not of any use to PSL. It might be worth giving a name (in the VHDL LRM) to a pathname that designates a declarative region, so that we can say that form of pathname is required as the "Hierarchical_HDL_Name" in a PSL verification unit.

4. Concrete syntax.

Item 3: I definitely prefer a consistent syntax for specifying secondary unit names that qualify primary unit names. The 'entity_aspect' production is the oldest occurrence of this, and for that reason it is arguably better than using ':', especially given the conflict with ':' elsewhere.

Note also that using "primaryname ( secondaryname )" for design entities is consistent with the syntax for referring to generated blocks - e.g., a.b(3).c, where b is the label on a generate statement in a, and (3) is the value of the for generate index for the block of interest. Here, the generate index value 3 is analogous to a secondary unit qualifier, where the generate statement label b is analogous to a primary unit name. I suppose a similar comment could be made about names that involve signatures.

Item 5: Choice of separator

You say "The PSL committee currently uses '.' for wildcard names (a form of design hierarchy name) in order to avoid conflict with the use of ':' for ranges in Verilog." This is essentially correct, but the proper term is "Hierarchical HDL Name", not "wildcard name".

Item 7. Choice of form for subprogram activation indicators

This is not an issue for PSL.

Item 8. Choice of syntax for subelements, etc.

PSL allows VHDL expressions to appear as the primitive elements of a PSL declaration - e.g., for a signal S of a type that is an array of records, I might write

   assert never S(i).j'stable(1 ms);

However, this is entirely handled within the context of VHDL expression syntax, so whatever choices are made here will propagate to PSL as well. It is only the pathname (i.e., "Hierarchical HDL Name) in a verification unit that we need to address specially.

If you have any questions about the above, please email me or call me at 410-750-6995.

Regards,

Erich

| -----Original Message-----
| From: owner-vhdl-200x@eda.org
| [mailto:owner-vhdl-200x@eda.org] On Behalf Of Peter Ashenden
| Sent: Friday, April 30, 2004 3:43 AM
| To: vhdl-200x@eda.org
| Subject: [vhdl-200x] Revision of path name proposal doc
|
|
| Folks,
|
| Here's round 2 of the path name doc. I've expanded the
| section dealing with design hierarchy path names
| considerably, and made strawman proposals for concrete path
| name syntax. I haven't proposed a strawman for a separate
| character, since I think the issue of '.' vs ':' and Verilog
| interoperability needs to be explored further. Also, I
| haven't had an opportunity to look into the details of PSL to
| complete the sections relating to it.
|
| Nonetheless, comments invited...
|
| Cheers,
|
| PA
|
| --
| Dr. Peter J. Ashenden peter@ashenden.com.au
| Ashenden Designs Pty. Ltd. www.ashenden.com.au
| PO Box 640 Ph: +61 8 8339 7532
| Stirling, SA 5152 Fax: +61 8 8339 2616
| Australia Mobile: +61 414 70 9106
|
Received on Wed May 5 14:43:00 2004