20.1.5 Attributes of Named Items
The ‘simple_name attribute returns a string representation of the name of an item. For example, if a package utility_definitions in a library utilities declares a constant named word_size, the attribute
utilities.utility_definitions.word_size‘simple_name
returns the string “word_size”. We might ask why VHDL provides this attribute, since we need to write the simple name of the item in order to apply the attribute. It would be simpler to write the string literal directly. If nothing else, we can use the attribute to gain consistency of style in reporting item names in messages, since the ‘simple_name attribute always returns a lowercase version of the name.
The ‘path_name and ‘instance_name attributes both return string representations of the path through the design hierarchy to an item. They are especially useful in assertion or report statements to pinpoint exactly which instance of a library unit is the source of a message. VHDL only requires that the message reported to the user by these statements indicate the name of the library unit (entity, architecture body or package) containing the statement. We can use the ‘path_name or ‘instance_name attribute to determine which particular instance of a process in the design hierarchy is the source of a message.
The format of the string produced by the ‘path_name and ‘instance_name attributes for a library, a design-unit package, or an item declared in a design-unit package is described by the EBNF rule
package_based_path
: library_logical_name :
subprogram_designator signature
variable_identifier
package_identifier :
identifier character_literal operator_symbol
The colon characters serve as punctuation, separating elements within the path string. If the item to which the attribute is applied is a library, the path string includes only the library name. If the item is a design-unit package, the path string includes the library name and the package name. If the item is declared in a package, the path string includes the library name, the package name and the name of the item. If the item is nested within a subprogram, shared variable, or local package in the design-unit package, the string also includes the names of the containing subprogram, shared variable, or local package. The signature of each subprogram is also included to distinguish between possibly overloaded versions of the subprogram name. Recall that the syntax rule for a subprogram signature is
signature
[ type_mark , return type_mark ]If the item is further nested, the names of all the enclosing subprograms, shared variables, or local packages are included in order from outermost to innermost.
Note that, for subprograms that overload operators, the name included in the path string is the operator symbol surrounded by quotation marks. For example, an overloaded abs operator declared in a package pkg in a library lib would have the path string:
:lib:pkg:“abs”:
In the case of a shared variable, it is the name of the variable that is included in the path string, not the name of the protected type used to declare the variable. This allows us to distinguish between items declared in a protected type but occurring in different shared variables.
If an item is declared within an entity or architecture body, the ‘path_name and ‘instance_name attributes return different strings depending on the structure of the elaborated design and the location of the declared item within the design hierarchy. We first look at the string returned by the ‘path_name attribute, as it is the simpler of the two. The format of the string is described by the EBNF rules
instance_based_path
:
path_instance_element :simple_name character_literal operator_symbol
path_instance_element
entity_identifier
component_instantiation_label
block_label
generate_label ( literal )
process_label
subprogram_designator signature
loop_label
variable_identifier
package_identifier
The string starts with the name of the topmost entity in the design and continues with the labels of any blocks (see Chapter 23), generate statements, processes, subprograms, and so on, between the top and the item. If the design hierarchy includes a component instance bound to an entity and architecture body containing the item, the attribute string includes the label of the component instantiation statement. If the item is contained within a for-generate statement, the string includes the value of the generate parameter for the particular iteration containing the item. The value is included in parentheses after the generate statement label. If the item is included in a process that has no label, the string includes an empty element in place of a process label. If the item is included in a subprogram, the string includes the signature of the subprogram to distinguish between possibly overloaded versions of the subprogram name. If the item is the loop parameter of a for loop, the string includes the label of the loop, or an empty element if the loop is unlabeled. If the item is declared in a protected type used as the type of a variable, the string includes the name of the variable (not the name of the protected type). If the item is included within a locally declared package, the string includes the package name.
The format of the string returned by the ‘instance_name attribute is described by the EBNF rules
full_instance_based_path
:
full_path_instance_element :simple_name character_literal operator_symbol
full_path_instance_element
entity_identifier ( architecture_identifier )
component_instantiation_label
@ entity_identifier ( architecture_identifier )
block_label
generate_label ( literal )
process_label
subprogram_designator signature
loop_label
variable_identifier
package_identifier
It is the same as that returned by ‘path_name, except that the names of the entity and architecture bound to a component instance are included after the label of the component instantiation statement. Furthermore, the architecture name for the top-level design entity is also included.