Code quality is essential to staying on schedule, avoiding design iterations and worse, bugs found in production. For any design team, creating readable and maintainable code that everyone understands takes some common discipline, starting with the basics such as naming conventions. It’s not so much whether the organization prefers big endian or little endian, spaces or tabs, prefixes or suffixes, underscores or hyphens or camel case, the important thing is to have a coding standard and stick to it. By standardizing on naming conventions for instances, modules, signals, clocks, resets, architectures, packages, and so on, code becomes clearer and reusable and, as a side benefit, it reduces the code complexity.

Blue Pearl Software’s Visual Verification Suite (VVS) includes a variety of naming checks that offer enormous flexibility and scope. Users specify parameters for each activated check using regular expressions.

Name Analysis vs. Identify

The tool includes two kinds of naming parameters and checks. First, there are parameters that pertain to rules about names assigned to objects and items of a known type. Since the tool has identified the object or item as being of a specific type, it can then check the name against the parameter to see if it is properly named. We label such checks and parameters as Name Analysis. There are numerous types of objects and items covered by Name Analysis parameters and checks, most having multiple sub-types. The bulk of this paper concerns these Name Analysis items.

Second, there are parameters intended to assist the tool in determining the object type, or to declare that objects of a given sort are not to be flagged. For example, in the case of a gated clock, it is often the designer’s intent that one input of the gate be the clock itself and the other be an enable. It might be necessary to assist the tool by declaring that a signal that conforms to a given naming parameter is an enable rather than a clock.

You may also have in your design nets that are tied to one or zero, or signals or pins that are intentionally left dangling. You will want to prevent the tool from flagging these as issues.

We label these sorts of checks and parameters as Identify. The objects that can be Identified are Clock Gating Signals, Reset and Set signals, Dangling signals and pins, Static Control Registers, and nets Tied high or low. Each of these has a corresponding IDENTIFY check and a corresponding parameter that can be set as described above. There are also two additional parameters that can aid the tool in identifying top level clocks and internal clocks.

Global, Object type, and Sub-type

The types of items whose names can be analyzed include: Filenames, Modules, Ports, Signals, Instances, Function Names, Labels, Constants, Language Keywords, Constant Value, Data Types, Port Data Types, Generic Data Types, Operator Parameter Names and Types Names, VHDL Others Assignments, Verilog Include Files, and Libraries. In addition, it is possible to specify Global naming rules that apply to all objects. For example, it is common to strictly forbid consecutive underscores throughout the design. One might also have a list of forbidden keywords.

With a few exceptions, each type has one or more sub-types, which in turn may have one or more sub-sub-types. For example, the three sub-types of Ports are Inputs, Outputs, and Inouts. Each of these has a sub-sub-type for buses, such as Input buses. Each of these is further sub-divided into Top Level and Sub Level.

For each type and at all levels of nesting, the user can specify a Regular Expression which the name of a particular item must match, and a Disallowed Regular Expression which the name must not match. Violations detected by Allowed and Disallowed expressions produce separate messages. In addition, the user can choose whether these expressions (allowed and disallowed) will apply to the full hierarchical path name, whether the expressions will be considered case-insensitive, and whether the specified expressions will be applied in lieu of, or in addition to, the expressions covering its parent type.

To specify any such parameters for a given type, the corresponding NAME_ANALYSIS check must be enabled. For example, you cannot specify a Regular Expression for Outputs if the NAME_ANALYSIS_PORTS check is not enabled. In some cases, a sub-type may have its own check. For example, under Signals each of the available sub-types (Registers, Clocks, Resets, Sets, and Clock Gating/Enabling Signals) is governed by its own check. This is in addition to the NAME_ANALYSIS_SIGNALS check and its corresponding parameter since there are signals which do not belong to any of the available sub-types.

Variables

There are several design-specific variables that can be used as part of the regular expressions. For example, you might use the ${FILE} variable to indicate that the base filename would be part of the regular expression. Some variables have restrictions are their use. For example, ${ENTITY} can only be used with VHDL, and ${PARENT_CLOCK} can only be used during clock analysis.

Conclusion

Having robust and specific naming rules can enhance the readability and reusability of your RTL code. The Visual Verification Suite provides regular expression-based naming rules that offer greater flexibility and scope than other methods.

Used early and often in the design process, as opposed to as an end of design/sign-off only tool, significantly contributes to design security, efficiency, and quality, while minimizing chances of field vulnerabilities and failures.

To learn more about the Visual Verification suite, please request a demonstration.