Mentor Graphics Corporation, Base Rules Reference Guide, Release v2018.2

Base Rules Reference Guide
Release v2018.2
© 2018 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: mentor.com/trademarks.
The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.
End-User License Agreement: You can print a copy of the End-User License Agreement from:
mentor.com/eula.
Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com
Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Table of Contents
Chapter 1
DesignChecker Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
DesignChecker Base Rule Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2
Base Rules References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Parameters Common to all Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Allow Base Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Allowed Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Allowed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Allowed Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Allowed Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Allowed Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Allowed Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Allowed Implied Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Allowed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Allowed Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Allowed Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Allowed Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Allowed System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Allowed Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Assignment Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Continuous Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Duplicate Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Initialization Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Input Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Mixed Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Multiple Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Multiple Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Unassigned Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Vector Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Case Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Case Statement Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Case Statement Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Clock and Reset Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Asynchronous Reset Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Clock Declaration Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Consistent Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Consistent Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Controllable Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Base Rules Reference Guide, v2018.2 3

Table of Contents
Internally Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Internally Generated Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Mixed Clocks Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Multiple Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Multiple Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Reset Logic Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Untested Edge Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Comments Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Comments and Blank Lines Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Statements Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Complexity Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
FSM Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Number of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Type Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Condition Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Logical and Bitwise Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Non-Unrollable Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Scalar Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Configuration Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
VHDL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Dead Logic Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undriven and Unused Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Declarations Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Bad VHDL Type Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Class Members Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Class Members Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Class Methods Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Entity Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Explicit Net Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Hard Coded Numeric Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Numeric Width Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Undefined Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Unused Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Verilog Constant Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
VHDL Deferred Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Directive Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Verilog `define Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Verilog `timescale Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
FSM Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
FSM Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
FSM State Encoding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
FSM Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Gates Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Clock Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Gate Level Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
4 Base Rules Reference Guide, v2018.2

Table of Contents
Hierarchy Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Feedthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Re-entrant Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Snake Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Instance Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Cascading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Generic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Unconnected Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Label Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Statement Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Logic Optimization Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Case instead of if-else-if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Naming Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Capitalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Classes Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
File Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Inferred Elements Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Mixed Case Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Named Object Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Unique Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Order Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Operator Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Vector Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Partition Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Partition Design Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Partition Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Related Combinatorial Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Structural Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Race Condition Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Clock Used As Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Combinatorial Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Register Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Range Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Constrained Ranges and Bounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Matching Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Non-Static Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Register Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Asynchronous Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Asynchronous Load Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Blocking Nonblocking Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Edge Trigger Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Input Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Latch Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Register Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Register Controllability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Register IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Table of Contents
Register Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Register Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
SV Always Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Report Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Arithmetic Gate Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Design Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
FSM Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Memory Element Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
String Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Sensitivity Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Event Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Sensitivity List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Style Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Assignment Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Dangling Else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Declaration Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Enclosed Block Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
File References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Indentation Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Mixed Combinational Sequential Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Statement Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Verilog Statement Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
VHDL Statement Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Sub-Program Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Operator Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Parameter Association List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Sub-Program Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Sub-Program Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Verification Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Allowed Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Class Methods Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Factory Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Object Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Vital Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
VITAL Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Appendix A
Simple Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Appendix B
Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Appendix C
System and Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
End-User License Agreement

List of Figures
Figure 1-1. Base Rule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

List of Figures

List of Tables

List of Tables

Chapter 1
DesignChecker Base Rules
The DesignChecker static checking and analysis tool ensures interoperability and consistency
across design styles and coding practices for developers and development teams creating
complex designs. DesignChecker is a powerful solution for individual engineers and can be
useful in situations where a number of individuals or teams are involved in the design and
development processes.
DesignChecker includes a set of parameterized base rules, which you use as the building blocks
to create the checks you need to run. Base rules are available in a configurable and extensible
form that allows you to tailor base rules to your precise requirements in a simple and intuitive
manner. The tool contains a large number of read-only base rules, which you can use to create
writable copies and configure parameters according to your coding standards. Base rules
support VHDL, Verilog, SystemVerilog, or mixed VHDL and Verilog language designs.
The Base Rules Reference Guide provides full details of the parameters and configuration
options for all DesignChecker’s base rules. You can access the full description of a specific base
rule by right-clicking on the base rule in DesignChecker and choosing Base Rule Details.
DesignChecker Base Rule Configuration Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
DesignChecker Base Rule Configuration

Overview
DesignChecker provides a wide range of categorized read-only base rules. To check your
design against specific base rules, you should create writable copies of the base rules in your
rulesets. To identify any violations to your coding standards, you can configure the parameters
of the base rule copies to match your standards. You have to reference the rulesets in your
default policy and then run analysis. The analysis results enable you to detect any violations in
your code.
The following figure shows a high-level summary of base rule configuration in DesignChecker
until you run analysis.
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
DesignChecker Base Rules
DesignChecker Base Rule Configuration Overview
Figure 1-1. Base Rule Configuration
Related Topics
DesignChecker User Guide
Chapter 2
Base Rules References
Parameters Common to all Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Allow Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Allowed Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Allowed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Allowed Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Allowed Constructs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Allowed Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Allowed Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Allowed Implied Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Allowed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Allowed Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Allowed Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Allowed Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Allowed System Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Allowed Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Assignment Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Continuous Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Duplicate Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Initialization Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Input Port Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Mixed Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Multiple Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Multiple Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Unassigned Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Vector Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Case Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Case Statement Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Case Statement Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Clock and Reset Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Asynchronous Reset Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Clock Declaration Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Consistent Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Consistent Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Controllable Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Gated Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Internally Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Mixed Clocks Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Multiple Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Multiple Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Reset Logic Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Untested Edge Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Comments Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Statements Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Complexity Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
FSM Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Number of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Type Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Condition Base Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Logical and Bitwise Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Non-Unrollable Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Scalar Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Configuration Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
VHDL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Dead Logic Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undriven and Unused Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Declarations Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Bad VHDL Type Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Class Members Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Class Members Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Class Methods Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Entity Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Explicit Net Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Undefined Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Unused Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Verilog Constant Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
VHDL Deferred Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Directive Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Verilog `define Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Verilog `timescale Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

FSM Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
FSM Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
FSM State Encoding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
FSM Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Gates Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Clock Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Gate Level Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Hierarchy Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Feedthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Snake Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Instance Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Cascading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Generic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Unconnected Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Label Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Statement Labels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Logic Optimization Base Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Case instead of if-else-if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Naming Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Capitalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Classes Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
File Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Mixed Case Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Name Spaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Named Object Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Unique Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Order Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Operator Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Vector Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Partition Base Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Partition Design Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Partition Design Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Structural Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Race Condition Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Clock Used As Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Combinatorial Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Register Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Range Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Matching Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Non-Static Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Register Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Asynchronous Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Asynchronous Load Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Blocking Nonblocking Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Latch Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Register Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Register Controllability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Register IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Register Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Register Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
SV Always Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Report Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Arithmetic Gate Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Design Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
FSM Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Memory Element Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
String Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Sensitivity Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Event Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Sensitivity List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Style Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Assignment Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Dangling Else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Declaration Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Enclosed Block Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
File References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Indentation Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Statement Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Verilog Statement Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Sub-Program Base Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Operator Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Parameter Association List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Parameters Common to all Base Rules
Sub-Program Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Sub-Program Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Verification Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Allowed Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Class Methods Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Vital Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
VITAL Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

All DesignChecker base rules contain common parameters that are described below.
Parameters:
• Name
Specify an arbitrary, user-entered string to act as a name for the configured rule. The
name must be unique within the RuleSet. The default is <Base Rule Name>.
• Severity
Specify the severity rating for a configured rule. Available ratings are defined using the
Rule Severity and Design Quality Settings dialog box and are applied to the RuleSet.
The default is Error (Except the Report base rules in which the default is Note.).
o Error
o Warning
o Note
• Score/ Weight
Shows the default score and weight corresponding to the Severity (as defined in the Rule
Severity and Design Quality Settings dialog box)
On configuring a rule, you can override the default values if needed. The Score and
Weight parameters are only available if the option to perform design quality analysis is
set (as they are used to calculate the quality percentage of the design).
Since the default Severity for base rules is “Error”, then the default Score is 5 and the
default Weight is 2. (Except the Report base rules in which the default Severity is
“Note”, and hence the default Score is 1 and the default Weight is 1.)
• Language
Specify to which language the rule applies. The default is VHDL Any and/or Verilog
Any depending on appropriate language/s.
• Hint (optional)
Specify additional information on the possible causes of violations of the rule.
• Short Description (optional)
Specify an arbitrary string which describes the configured rule.
• Keywords (optional)
Specify any number of keywords to associate with the configured rule. Keywords and
their synonyms can be used to identify rules when using the search functionality. When
specifying keywords for a configured rule, it is recommended that they are chosen from
a consistent set of keywords used throughout a given RuleSet. A new configured rule
will automatically initialize with the keywords from the corresponding Base Rule. These
can then be edited as required.
Related Topics
Design Correctness and Synthesizability [DesignChecker User Guide]
Register and Control Signal Inference [DesignChecker User Guide]
Finite State Machines (FSMs) [DesignChecker User Guide]
Miscellaneous [DesignChecker User Guide]
Allow Base Rules
Allow Base Rules

The Allow base rules check for constructs, coding styles, or logic that should be allowed or
disallowed in the design.
Allowed Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Allowed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Allowed Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Allowed Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Allowed Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Allowed Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Allowed Implied Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Allowed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Allowed Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Allowed Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Allowed Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Allowed System Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Allowed Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Allowed Arrays
Allowed Arrays
Language support: All (including SystemVerilog)
Checks that only specified types and maximum dimension count arrays are used. You can
specify any of the types and array styles. You can also define the maximum allowed dimension
count for the arrays. Any array declaration that has more than the allowed number of
dimensions is flagged as an error. You can also specify the types that are internally coded as
vectors, so that an extra dimension is added when using these types.
Usage
Allowed Arrays
Common Parameters
Applies To
Array Types
Maximum Allowed Dimension
Types Internally Coded As Vectors
Other Qualifiers
Parameters
• Common Parameters
See Parameters Common to all Base Rules
• Applies To
A required parameter for specifying the types to which the check applies. The default is
Verilog/System-Verilog Variables.
o Ports
o Nets
o Verilog/System-Verilog Variables
o VHDL Variables
o Signals
• Array Types
A required parameter for specifying the types of array styles to check. The default is
Associative Arrays.
o Fixed Size Arrays
o Dynamic Arrays
o Associative Arrays
o Queues
o Bound Queues
Allowed Arrays
• Maximum Allowed Dimension

An integer for specifying the maximum allowed dimensions for the checked arrays. The
default is 1.
Note
The Maximum allowed dimension cannot be negative.
• Types Internally Coded As Vectors

An optional parameter for specifying the types that are internally coded as vectors. These
types introduce an extra dimension that affects the maximum allowed dimensions check.
o integer
o real
o time
o <user-defined>
o <none>
• Other Qualifiers
An optional parameter for specifying other qualifiers. The default is <don’t care>.
o rand
o <don’t care>
Examples
Example 1
Check that Ports has the maximum dimension of 1.
Rule Configuration
• Applies To — Ports
• Array Types — Fixed Size Arrays, Dynamic Arrays, Associative Arrays, Queues,
Bound Queues
• Maximum Allowed Dimensions — 1
• Other Qualifiers — <don’t care>
Allowed Arrays
Analyzed Code
module allowed_arrays_1 (data_in, data_out);
input reg [3:0][3:0] data_in; // Violation
output reg [15:0] data_out;
reg clk;
always@(posedge clk)
for (int i = 0; i< 4; i++)
for (int j = 0; j < 4; j++)
data_out[i*4 + j] = data_in[i][j];
endmodule
Violation Produced
ERROR, "data_in" is 2-dimensional which exceeds maximum allowed "1" dimension(s) for
"fixed size arrays"
Example 2
Check that Verilog/SystemVerilog variables are always of scalar type (no dimension allowed).
Rule Configuration
• Applies To — Verilog/SystemVerilog Variables
• Array Types — Fixed Size Arrays, Dynamic Arrays, Associative Arrays, Queues,
Bound Queues
• Maximum Allowed Dimensions — 0
• Other Qualifiers — <don’t care>

Analyzed Code
package allowed_arrays_2;
logic assocArr[int]; // Violation 1
logic dynArr[]; // Violation 2
bit Q[$]; // Violation 3
reg BQ[$:15]; // Violation 4
endpackage
Violations Produced
• ERROR, "assocArr" is of disallowed "associative arrays" type – Violation 1
• ERROR, "dynArr" is of disallowed "dynamic arrays" type – Violation 2
• ERROR, "Q" is of disallowed "queues" type – Violation 3
• ERROR, "BQ" is of disallowed "bound queues" type – Violation 4
Related Topics
Allowed Types
Allowed Attributes
Allowed Attributes
Language support: All
Checks for the use of specific kinds of VHDL Attributes. This includes Function, Range,
SignalType attributes (e.g. base), Common Attributes (e.g. Left, Right) and Range Attributes
(e.g. reverse_range). You can check for either allowed kinds of Attributes (those that may be
used) or disallowed kinds of Attributes (those that must not be used).
Note
Important notes:
• Usage of Attributes other than those in an Allowed set will cause a violation.
• Usage of any Attributes in a Disallowed set will cause a violation.
Usage
Allowed Attributes
Common Parameters
Action
Attribute Name
Parameters
• Action
Specify whether the kind of Attribute is required or disallowed. The default is Disallow.
o Allow
o Disallow
• Attribute Name
Specify which attributes or groups of attributes to check for. You can choose from the
supplied options and/or enter your own values. The default is All Attributes.
o All Attributes
o Function Attributes:
[active, driving, driving_value, event, high, image, last_active, last_event,
last_value, left, leftof, low, pos, pred, right, rightof, succ, val, value]
o Range Attributes:
[range, reverse_range]
o Signal Attributes:
[delayed, stable, quiet, transaction]
Allowed Attributes
o Type Attributes:
[base]
o Value Attributes:
[ascending, high, instance_name, left, length, low, path_name, right, simple_name ]
o ACTIVE
o ASCENDING
o BASE
o DELAYED
o DRIVING
o DRIVING_VALUE
o EVENT
o HIGH
o IMAGE
o INSTANCE_NAME
o LAST_ACTIVE
o LAST_EVENT
o LAST_VALUE
o LEFT
o LEFTOF
o LENGTH
o LOW
o PATH_NAME
o POS
o PRED
o QUIET
o RANGE
o REVERSE_RANGE
o RIGHT
o RIGHTOF
o SIMPLE_NAME
Allowed Attributes
o STABLE
o SUCC
o TRANSACTION
o VAL
o VALUE
o <user-defined>
Examples
Example 1
Analyzed Code
ser_out_muxcombo_proc: PROCESS(status, zeros, ser_if_select)
BEGIN
CASE ser_if_select IS
WHEN "10" => ser_if_data(3) <= status’left; -- Avoid using
disallowed attribute ‘left’
WHEN OTHERS => ser_if_data<= zero;
END CASE;
END PROCESS ser_out_muxcombo_proc;
Violation Produced
ALLOWED_ATTRIBUTES 402
Avoid using disallowed attribute "'LEFT"
Allowed Characters
Allowed Characters
Checks for the use of special characters which includes control characters and foreign
characters.
Usage
Allowed Characters
Common Parameters
Allowed Characters
Check Comments
Parameters
• Allowed Characters
Specify which characters are allowed. The default is ASCII characters (32-126), CR, HT
and LF.
ASCII Characters (32-126)
Named ASCII Characters
o Controls for Code Extensions:
Escape (ESC)Shift In (SI), Shift Out (SO)
o Format Effectors:
Backspace (BS), Carriage Return (CR), Form Feed (FF), Horizontal Tab (HT), Line
Feed (LF), Vertical Tab (VT)
o Information Separators:
File Separator (FS), Group Separator (GS), Record Separator (RS), Unit Separator
(US)
o Logical Communication Controls:
Acknowledge (ACK), Data Link Escape (DLE), End of Text (ETX), End of
Transmission (EOT), End of Transmission Block (ETB), Enquiry (ENQ), Negative
Acknowledge (NAK), Start of Header (SOH), Start of Text (STX), Synchronous
Idle (SYN),
o Physical Communication Controls:
Cancel (CAN), Delete (DEL), End of Medium (EM), Null (NUL), Substitute (SUB)
o Physical Device Controls:
Bell (BEL), DC1, DC2, DC3, DC4
o <Custom Parameter>
Allowed Characters
Note
Custom Parameter text box can accept a single ASCII numeric value or character
only. For example:
• A: (Single Character)
• (: (Single Character)
• 65: (Numeric value representing Character ‘A’)
• 40: (Numeric value representing Character ‘(‘ )
• Check Comments
Specify whether characters inside comments also need to be checked. It takes the values Yes
or No. The default is Yes.
Examples
Example 1
Checks that only Line feed, Carriage Return and ASCII characters are allowed.
Rule Configuration
• Language — Verilog Any
• Allowed Characters — LF, CR, ASCII characters (32-126)
• Check Comments — Yes

Analyzed Code
module FLOP(q, d, clk, load, ldata);
output q;
input d, clk,load,ldata;
reg q;
always @(posedge clk or posedge load )

if (load)
q <= ldata; // Violation
else
q<= d;
endmodule
Violation Produced
Do not use disallowed character HT (decimal 9)
Related Topics
Allowed Types
Allowed Operators
Case Statement Directives
Allowed Constructs
Allowed Constructs
Checks for the use of specific language constructs.
Usage
Allowed Constructs
Common Parameters
Disallowed Constructs
Parameters
• Disallowed Constructs
Specify which constructs are not allowed. The default is <all non-synthesizable constructs>
and <all non-portable constructs>.
Values Applicable to VHDL Only:
o <all non synthesizable constructs>:
ALIAS, BUFFER, Enumeration Type as Array Index, FILE, Global Signals,
Incomplete Types, INERTIAL Delay, Infinite Loops, POSTPONED, PURE
FUNCTION, TRANSPORT Delay, WAIT, WAIT with Timeout
o <all non portable constructs>:
BLOCK, BUS Signals, DISCONNECT, GENERATE, GENERIC, GUARDED
Ports, IMPURE FUNCTION, LINKAGE Ports, Non-text Files, REGISTER Signals,
SHARED VARIABLE
o <Verilog reserved words in VHDL designs>
o <obsolete VHDL 87 constructs>
o ACCESS Types
o ASSERT Statements
o Loop EXIT
o Loop NEXT
o RECORD Types
o Resolution Functions
o <VARIABLE>
Process, Subprogram
o VHDL Replacement Characters
Allowed Constructs
o Synthesizable Wait (wait until)

Values Applicable to Verilog Only:
`timescale, Array of Integers, casex, casez, deassign, defparam, event, force, forever
Loops, fork join, Gate Delays / Gate Strengths, Hierarchical Names, initial Blocks,
Net Strengths, Procedural Continuous assign, release, repeat Loops, specify, String
Literals, Systems Functions, System Tasks ($display, $finish, $monitor, $stop,
$strobe), time, trireg Net Data Type, User Defined Primitives
o <all non portable constructs>:
Built-in Primitives
o <VHDL reserved words in Verilog designs>
o `define
o `define without a default value
o ìnclude
o ìfdef
o ìfndef
o `resetall
o Disable Statement
o macromodule
o Task Calls
o $cast as Task
o Non-Enum/Non-Int Static Cast
o $cast of non-class Object
o Cast to String, Bit Select on entire Vector
o Function/Task in Package
o Interface with parameters
o Fine-grain process control methods
o Final blocks
o Verilog Generate Blocks
o Program Blocks
o Always outside Interface
Allowed Constructs
o DPI import
o DPI-C task export
o Wildcard index
o Randc
o Wait_order
o Semaphore extension
o mailbox
o string replication
Common Values Applicable to VHDL & Verilog:
Delayed Assignments, Functions Returning Type Real, Multiple Wait Statements on
Same Clock, Real Types, while Loops, Zero Delayed Assignments
o INOUT Ports
o Four State Logic
o Wait Statements inside For Loops
Note
• Global Signals: Signals defined in a package.

• Incomplete Types: Types declared in a package header but with no definition (such as
deferred constants). For example: TYPE mytype;
• Non-text files: Files whose type is not defined in std.textio package (i.e. not of type
"text").
Examples
Example 1
Check for generics, delays and variables.
Rule Configuration
• Disallowed Constructs — <all non synthesizable constructs>: Delayed Assignments,
VARIABLE
<all non portable constructs>: GENERIC
Allowed Constructs
Analyzed Code
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY top5 IS
GENERIC (bus_width : integer := 3; flag : bit := '0'); -- Violation 1
PORT (clk_master : IN std_logic;
rst_master : IN std_logic;
in_sig : IN std_logic;
out_sig : OUT std_logic);
END top5;
ARCHITECTURE rtl OF top5 IS
TYPE MYVECTOR IS ARRAY (7 downto 0) OF bit;
CONSTANT WIDTH : integer := 8;

SIGNAL clk_master_a, rst_master_a, rst_master_b, sig : std_logic;
SIGNAL vector : STD_LOGIC_VECTOR (3 downto 0);
BEGIN
sig <= '0' after 5 ns; -- Violation 2
proc1: PROCESS (clk_master, rst_master)
TYPE BLOCKTYPE IS ARRAY (15 downto 0) OF bit;
CONSTANT COUNT : integer := 5;
VARIABLE var : std_logic; -- Violation 3
BEGIN
IF (rst_master = '0') THEN
ELSE
IF (clk_master'EVENT AND clk_master = '1') THEN
out_sig <= '1' after 3 ns; -- Violation 4
END IF;
END IF;
END PROCESS;
END rtl;
Violations Produced
• Avoid using VHDL non-portable construct GENERIC – Violation 1
• Net or assignment delay has been used. – Violation 2
• Variable Declaration "var": preferably avoid using variables for synthesis purposes –
Violation 3
Example 2
Check for delayed assignments, gate delays or gate strengths, net strengths, built-in primitives
and VHDL reserved words in Verilog designs.
Rule Configuration
• Disallowed Constructs — <all non synthesizable constructs>: Delayed Assignments,
Gate Delays / Gate Strengths, Net Strengths
<all non portable constructs>: Built-in Primitives
<VHDL reserved words in Verilog designs>
Allowed Constructs
Analyzed Code
module allowed (input enable, a, b, in, output out3, f, output reg out1,
out2); // Violation 1
wire (strong1, pull0) mynet1 = enable ; // Violation 2
assign out3 = mynet1;
or #5 g3 (f, a, b); // Violation 3, 4
always @(in)
begin
#25 out1 = ~in; // Violation 5
out2 = ~in;
end
endmodule
Violations Produced
• Do not use VHDL 87 reserved word""in" in Verilog designs – Violation 1
• Do not use built-in primitive or gate "or". Primitives and gates might not be portable
between different technologies. – Violation 2
• Strength has been used with net, instance or assignment. – Violation 3
• Gate delay or strength has been used. – Violation 5
Example 3
Check for Non-Enum/Non-Int Static Cast and Cast to Strings.
Rule Configuration
• Disallowed Constructs — Non-Enum/Non-Int Static Cast, Cast to Strings
Analyzed Code
module castTest;
int i = int’(2.0*3.0); // Violation 1
string str = string’(“sample”); // Violation 2 & 3
endmodule
Violations Produced
• Disallowed Static casts on Non Int or Non Enum Types. – Violation 1
• Disallowed Static cast to Strings. – Violation 2
• Disallowed Static casts on Non Int or Non Enum Types. – Violation 3
Related Topics
Allowed Types
Allowed Operators
Allowed Declarations
Language support: Verilog Any (including SystemVerilog)
Checks the use of a specified declaration types is used in the allowed scopes. It also checks for
the use of any data in global namespace and usage of chandle only for the storage of C pointers
passed via DPI. The base rule is applicable only for Verilog. Usage of Declaration types in any
scope other than in the Allowed scope will cause a violation. Usage of chandle with value other
than non-chandle or non-null value will cause a violation. Also any declaration of data in global
namespace will cause a violation.
Usage
Common Parameters
Declarations Types
Allowed Scopes
Additional Checks
Parameters
• Declarations Types
Specify to which type the check applies. The default is typedef struct.
o wire
o typedef struct
o <don’t care>
• Allowed Scopes
Specify in which scope the type is allowed. The default is class.
o interface
o class
o <don’t care>
• Additional Checks
Specify which additional check/s with the above rule. The default is <don’t care>.
o Use chandle only to store C pointers passed via DPI
o No declarations allowed in global namespace
o <don’t care>
Note
Declaration type wire is disallowed in class scope.
Examples
Example 1
Checks for the use of wire declarations in interface scope.
Rule Configuration
• Declaration Types — wire
• Allowed Scoped — interface
• Additional Checks — <don’t care>

Analyzed Code
module myModule(input clk); // port as wire declaration
reg a;
always @(posedge clk)
a = 1;
endmodule
Violation Produced
“wire” declarations are allowed only in “interface” scope.
Example 2
Checks for the use of typedef struct declarations in class scope.
Rule Configuration
• Declaration Types — typedef struct
• Allowed Scoped — class

Analyzed Code
program myprogram;
typedef struct { // typedef struct inside program
logic a;
bit c;
} mystruct;
endprogram
Violation Produced
“typedef struct” declarations are allowed only in “class” scope
Example 3
Checks for the use of declarations in global namespace.
Rule Configuration
• Declaration Types — <don’t care>
• Allowed Scoped — <don’t care>
• Additional Checks — No declarations allowed in global namespace

Analyzed Code
parameter int myGlobVal = 5; // global parameter declaration
wire myWire; // global wire declaration
interface sBus;
logic req,grant;
logic [7:0] addr, data;
endinterface;
Violations Produced
• “myGlobVal” declared in global scope is disallowed
• “myWire” declared in global scope is disallowed
Related Topics
Allowed Types
Allowed Expressions
Allowed Expressions
Checks for the use of disallowed values within various expression types. Also, checks for the
use of specific values within expressions such as assignments, IF conditions, LOOP conditions
etc. The rule can also check that the right-hand-side operand of all shift operators are static
values.
Usage
Allowed Expressions
Common Parameters
Expression Type
Disallowed Expression Values
Parameters
• Expression Type
Specify which expression types to check. The default is All.
o Assignment Operand
o Case Alternative Choice
o Case Statement Expression
o Conditional Assignment Condition, [WHEN …]
o For Loop Expression
o If Condition
o Shift Operator Right Operand, [Applies only to Non-static Expression]
o Ternary Operator Condition, [op = enable ? data : 8`bz]
o While Loop Condition
• Disallowed Expression Values
Specify which signal value/s are not allowed. The default is X.
o U
o W
o X
o Z
o 0
Allowed Expressions
o 1
o Non-integer Expression
o Non-static Expression, [Applies only to Shift Operator Right Operand]
o Static Expression
o <user-defined>
Note
The value “Shift Operator Right Operand” must only be used with the disallowed
expression value “Non-static Expression”. This combination checks that the right-hand-side
operand of all shift operators are static values.
This base rule checks for valid combination of Disallowed Expression Value and Expression
Type. For example, "Non-integer values" can only be selected with "For Loop Expression".
Examples
Example 1
Illegal value
ser_out_muxcombo_proc: PROCESS(status, zeros, ser_if_select)
BEGIN
CASE ser_if_select IS
WHEN "10" => ser_if_data <= status;
WHEN "11" => ser_if_data <= zeros;
WHEN OTHERS => ser_if_data <= (OTHERS => 'X');
-- Avoid using illegal value “X” in assignments or initializations
END CASE;
END PROCESS ser_out_muxcombo_proc;
Violation Produced
Avoid using illegal value "X" in assignments or initializations
Example 2
Non-static shift operators - VHDL
OUTPUT_2 <= "11001001" sra INPUT; -- RHS operands of shift operators
should be static
Non-static shift operators - Verilog

assign Data_Out = (Data_In >> zero_count(~A | 4'b1010)); // RHS operands
of shift operators should be static
Violation Produced
RHS operands of shift operators should be static
Allowed Implied Logic

Checks for disallowed logic being inferred. [Optionally Design-wide]. This rule checks if
disallowed logic is being inferred by the source code. Disallowed logic includes Tri-states,
Delay-chains, Binary counters and Double-Data-Rate flops.
Usage
Common Parameters
Disallowed Logic
Parameters
• Disallowed Logic
Specifies which logic is to be disallowed. The default is Internal Tristates and Tristates
Driving Primary Outputs.
o Binary Counters
o Delay Chains
o Input Double-Data-Rate Flip-Flops
o Internal Tristates
o Tristates Driving Primary Outputs
Definitions of different Disallowed Logic:
Binary Counters:
Counters with width less than 4-bits with increment or decrement of 1.
Delay Chains:
Delay chains are series of inverters/buffers inserted by the designers to delay the
propagation of a signal. These series of inverters/buffers are unused elsewhere in the design
and hence are single fan-in/fan-out.
Assignments which contribute to delay chains can be modeled using:
o Signal assignments in VHDL
o Continuous assignments or non-blocking assignments in combinational always
blocks for Verilog
Please note that variable assignments in VHDL and blocking assignments in Verilog imply
immediate update of the value and hence are not considered as delay chain elements. On the
other hand, signal assignments/non-blocking assignments imply that earlier value may also
be read and hence buffers/inverters are preserved in this case. Hence these are valid
constructs to model delay chains.
Input Double-Data-Rate Flip-Flops:
These flops are characterized by the following:
a. Same D-input.
b. Same output.
c. Opposing edge of the same clock.
d. D-input is a port.
Internal Tristates:
Internal tristates are tristates whose outputs do not reach the primary outputs. This is a
design-wide check.
Tristates Driving Primary Outputs:
These are tristates whose output reaches a top output port. This output port can be an
explicit output-port or a bidirectional port acting as an output. This is a design-wide check.
Examples
Example 1
Counters with width less than 4-bits are disallowed.
Rule Configuration
• Language — Any
• Disallowed Logic — Binary Counters

Analyzed Code
module fifo(input clk, output [1:0] out1);
reg [1:0] cnt;
always @(posedge clk) begin
cnt <= cnt - 1; //Violation 1
end
assign out1 = cnt;
endmodule;
Violation Produced
Counter 'cnt[1 : 0]' of width '2' violates the lower limit of 4 bits for counters
Example 2
Delay chains are disallowed.
Rule Configuration
• Disallowed Logic — Delay Chains

Analyzed Code
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity top is
port (
in1 : in std_logic;
out1: out std_logic);
end top;
architecture abc of top is
signal temp1 : std_logic;
begin
temp1 <= in1; -- violation 5
temp2 <= not temp1; -- violation 4
temp3 <= temp2; -- violation 3
temp4 <= not temp3; -- violation 2
out1 <= temp4; -- violation1
end;
Violations Produced
• Delay chain detected from 'out1' to 'in1' – Violation 1
• Assignment to 'temp4' causes a delay chain – Associated Violation 2
Example 3
Double-data-rate flip-flops are disallowed.
Rule Configuration
• Disallowed Logic — double-data-rate flip-flops

Analyzed Code
module top (input [2:5]in1, input clk, output reg [2:6] out2, output reg
[2:6] out1);
always @(posedge clk) out1[2:4] <= in1[2:4]; // violation1, violation 3
always @(negedge clk) out1[2:3] <= in1[2:3]; // violation 2
always @(negedge clk) out1[4] <= in1[4]; // violation 4
endmodule
Violations Produced
• Register 'out1[2 : 3]' which is being driven at the positive edge of the clock 'clk' is also
driven at its negative edge – Violation 1
• Double-data-rate register 'out1[2 : 3]' is being registered at the negative edge of the
clock 'clk' – Associated Violation 2
• Register 'out1[4]' which is being driven at the positive edge of the clock 'clk' is also
driven at its negative edge –Violation 3
• Double-data-rate register 'out1[4]' is being registered at the negative edge of the clock
'clk' – Associated Violation 4
Example 4
Internal tristates and tristates driving primary outputs are disallowed.
Rule Configuration
• Disallowed Logic — Internal Tristates, Tristates Driving Primary Outputs

Analyzed Code
module top (input a, output reg b);
wire t1;
mid1 inst1(a, t1); // violation 2
mid2 inst2(t1, b); // violation 3, violation 6
endmodule;
module mid1 (
input c,
output reg d);
assign d = c ? c : 1'bz; // violation 1
endmodule;
module mid2 (input g, output reg h);

bot inst3(g, h); // violation 4, violation 5
wire p1,p2;
assign p1 = g ? g : 1'bz; // violation 7
endmodule;
module bot (input e, output reg f);

assign f = e;
endmodule;
Violations Produced
• Detected tri-state driver 'top.inst1.d' driving primary output port 'b': avoid using tri-state
drivers in designs – Violation 1
• Tri-state path passes through port 'd' in instance 'top.inst1' – Associated Violation 2
• Tri-state path passes through port 'g' in instance 'top.inst2' – Associated Violation 3
• Tri-state path passes through port 'e' in instance 'top.inst2.inst3' – Associated Violation 4
• Tri-state path passes through port 'f' in instance 'top.inst2.inst3' – Associated Violation 5
• Tri-state path passes through port 'h' in instance 'top.inst2' – Associated Violation 6
• Internal tri-state driver 'p1' detected : avoid using tri-state drivers in designs –Violation 7
Related Topics
Arithmetic Gate Report
Feedthrough
Memory Element Report
Allowed Libraries
Allowed Libraries
Language support: VHDL Any
Checks for the use of specified VHDL Libraries. It can check for either allowed Libraries (those
that may be used) or disallowed Libraries (those that must not be used).
Checking specifically is done for references of libraries Library clauses, Library use clauses,
Entity Instances, Config Instances and Entity Aspects.
Note
References to Libraries other than those in an Allowed set will cause a violation.
References to Libraries in a Disallowed set will cause a violation.
Usage
Allowed Libraries
Common Parameters
Action
Libraries
Parameters
• Action
Specify whether the specified Libraries are allowed or disallowed. The default is Disallow.
o Allow
o Disallow
• Libraries
Specify which VHDL Library names to check for. You can choose from the supplied
options and/or enter your own values. The default is <none>.
o IEEE
o <user-defined>
Note
A validation error is issued if Action field is set to “Disallow” and “std” is specified
in Libraries.
Examples
Example 1
Disallow libraries “ieee” and “lib1”.
Allowed Libraries
Rule Configuration
• Action — Disallow
• Libraries — ieee, lib1

Analyzed Code
Library IEEE; -- Primary violation 1
use IEEE.STD_LOGIC_1164.ALL; -- Associated violation 2
use IEEE.NUMERIC_STD.ALL; -- Associated violation 3
library lib1; -- Primary violation 4
entity fulladder is
port (a : in std_logic;
b : in std_logic;
cin : in std_logic;
sum : out std_logic;
carry : out std_logic );
end fulladder;
architecture behavior of fulladder is

signal s1,c1,c2 : std_logic:='0';
--signal dummySig : real := 1.5;
--signal dummySig1 : real;
begin
--instantiate and do port map for the first half adder.
HA1 : entity lib1.halfadder port map(a,b,s1,c1); -- Associated
violation 5
--instantiate and do port map for the second half adder.
HA2 : entity lib1.halfadder port map(s1,cin,sum,c2); -- Associated
violation 6
carry <= c1 or c2; --final carry calculation
--dummySig1 <= dummySig;
end;
Violations Produced
• Found disallowed library ‘ieee’. – Primary Violation 1
• Found disallowed library ‘ieee’. – Associated Violation 2
• Found disallowed library ‘ieee’. – Associated Violation 3
• Found disallowed library ‘lib1’. – Primary Violation 4
• Found disallowed library ‘lib1’. – Associated Violation 5
• Found disallowed library ‘lib1’. – Associated Violation 6
Example 2
Allow “ieee” library.
Rule Configuration
• Action — Allow
Allowed Libraries
• Libraries — ieee
Analyzed Code
library drs; -- Primary violation 1
configuration addr4c_config of add4c is
for circuits
for a0 : fadd
use entity drs.fulladder(behavior); --Associated violation 2
end for;
for a1 : fadd
use entity drs.fulladder(behavior); -- Associated violtion 3
end for;
end addr4c_config
Violations Produced
• Found disallowed library ‘drs’. – Primary Violation 1
• Found disallowed library ‘drs’. – Associated Violation 2
• Found disallowed library ‘drs’. – Associated Violation 3
Related Topics
Allowed Types
Allowed Methods
Allowed Methods
Checks that disallowed methods are not used.This rule checks that the methods specified by the
user for the selected types like strings, arrays etc. are not used.
Usage
Allowed Methods
Common Parameters
Applies To
DisAllowed Methods
Parameters
• Applies To
Specify the type on which the disallowed methods are applicable. The default is Strings.
o Strings
o Fixed Size Arrays
o Dynamic Arrays
o Associative Arrays
o Queues
• DisAllowed Methods
Specify the methods which are disallowed. The default is <custom method>.
o <custom method>
o <user-defined>
Examples
Example 1
Checks that disallowed methods “exists” and “num” are not used on associative arrays.
Rule Configuration
• Applies To — Associative Arrays
• Disallowed Methods — exists, num
Allowed Methods
Analyzed Code
program assoc_t;
int map[string];
string s;
initial begin
$display("The number of entries in the array map is %0d",map.num()); //
violation 1
if(map.exists("hello")) // violation 2
map["hello"] += 1;
else
map["hello"] = 0;
end
endprogram
Violations Produced
• Method “num” for “associative arrays” is disallowed – Violation 1
• Method “exists” for “associative arrays” is disallowed – Violation 2
Related Topics
Allowed Types
Allowed Operators
Allowed Operators
Checks for the use of specific operators. This rule checks if the disallowed operators are used
within the scopes which are specified to be checked. Note that DesignChecker does not check
operators that are implicitly used.
Usage
Allowed Operators
Common Parameters
Scope
Disallowed Operators
Ignore
Parameters
• Scope
Specify the scope of the disallowed operators. The default is <Design Units>, <Blocks> and
<Sub-Programs>.
o <Design Units>
Architecture, Class, Configuration, Entity, Interface, Module, Package body,
Package header, Program, SV Packages
o <Sub-Programs>
Function, Procedure, Task
o <Blocks>
Always block, Block, Final Block, Generate, Initial Block, Process
o Conditional Statement
o File
• Disallowed Operators
Specify which operators are not allowed. The default is Case Equality (===), Case
Inequality (!==), Multiplication (*), Wild Equality(==?) and Wild Inequality(!=?).
o Arithmetic
Arithmetic: (%), Arithmetic: (&), Arithmetic: (*), Arithmetic: (**), Arithmetic: (+
binary), Arithmetic: (+ unary), Arithmetic: (++ post), Arithmetic: (++ pre),
Arithmetic: (- binary), Arithmetic: (- unary), Arithmetic: (-- post), Arithmetic: (--
pre), Arithmetic: (/), Arithmetic: (abs), Arithmetic: (mod), Arithmetic: (rem)
o Bitwise
Bitwise: (& binary), Bitwise: (& unary), Bitwise: (^ binary), Bitwise: (^ unary),
Allowed Operators
Bitwise: (^~ binary), Bitwise: (^~ unary), Bitwise: (| binary), Bitwise: (| unary),
Bitwise: (~), Bitwise: (~&), Bitwise: (~^), Bitwise: (~|)
o Case Equality(===)
o Case Inequality(!==)
o Condition
Condition: (??)
o Logical
Logical: (!), Logical: (&&), Logical: (and), Logical: (nand), Logical: (nor), Logical:
(not), Logical: (or), Logical: (xnor), Logical: (xor), Logical: (||)
o Multiplication ( * )
o Procedural Blocking Assignment
Procedural Blocking Assignment: (%=), Procedural Blocking Assignment: (&=),
Procedural Blocking Assignment: (*=), Procedural Blocking Assignment: (+=),
Procedural Blocking Assignment: (-=), Procedural Blocking Assignment: (/=),
Procedural Blocking Assignment: (<<<=), Procedural Blocking Assignment: (<<=),
Procedural Blocking Assignment: (>>=), Procedural Blocking Assignment: (>>>=),
Procedural Blocking Assignment: (^=), Procedural Blocking Assignment: (|=)
o Relational
Matching Relational: (?/=), Matching Relational: (?<), Matching Relational: (?<=),
Matching Relational: (?=), Matching Relational: (?>), Matching Relational: (?>=),
Relational: (==), Relational: (/=), Relational: (<), Relational: (<=), Relational: (=),
Relational: (==), Relational: (>), Relational: (>=)
o Shift
Shift: (<<), Shift: (<<<), Shift: (>>), Shift: (>>>), Shift: (rol), Shift: (ror), Shift:
(sla), Shift: (sll), Shift: (sra), Shift: (srl)
o Ternary
Ternary: (?)
o Wild Equality ( ==? )
o Wild Inequality ( !=? )
• Ignore
Specify the items to ignore on checking disallowed operators. The default is <don’t care>.
o <don’t care>
o Ignore increment/decrement operators in for_step assignments
Examples
Example 1
Check for the use of ampersand character in a conditional statement.
Allowed Operators
Rule Configuration
• Language — VHDL Any
• Disallowed Operators — Arithmetic: (&)
• Scope — Conditional Statement
• Ignore — <don’t care>

Analyzed Code
architecture rtl of ampersand is
signal internal : std_logic_vector(7 downto 0);
begin
internal <= "01000001";
ampersand_condition:process(my_in,internal)
begin
if ((my_in(4 downto 1) & internal(2)) = "10110" ) then –- Violation
end if;
end process ampersand_condition;
end rtl;
Violation Produced
Avoid using disallowed operator " & " in conditional statements
Example 2
Check for the use of ( === ) character in a conditional statement.
Rule Configuration
• Disallowed Operators — Case Equality ( === )
• Scope — Conditional statements

Analyzed Code
...
If (a === b) -- Violation
...
Violation Produced
Avoid using disallowed operator " === "
Example 3
Check for the use of +, -, * operators inside the “Module” scope.
Rule Configuration
Allowed Operators
• Disallowed Operators — Arithmetic: (*), Arithmetic: (+ binary), Arithmetic: (- binary)
• Scope — Module

Analyzed Code
module test;
parameter MAX_WIDTH = 5;
parameter OFFSET=1;
typedef bit [MAX_WIDTH:MAXWIDTH+OFFSET]uint10; // Violation 1
reg count,clk,x,y;
wire [5:0] incr;
function [MAX_WIDTH:MAX_WIDTH_OFFSET] myfunc2 (input [7:0] x,y);
return x * y – 1; // Violation 2, 3
endfunction
for (int i=0;i<12;i++)
count = count + incr[i*j]; // Violation 4, 5
endmodule
Violations Produced
• Avoid using disallowed operator " + binary " – Violation 1
• Avoid using disallowed operator " * " – Violation 2
• Avoid using disallowed operator " - binary" – Violation 3
• Avoid using disallowed operator " + binary" – Violation 4
Example 4
Check for the use of the specified operators inside the Generate Block.
Rule Configuration
• Disallowed Operators — Arithmetic: (*) , <Logical> ‘&&’, <Relational> ‘==’
• Scope — Blocks: (Generate Block)
Allowed Operators
Analyzed Code
module generate_block(in1,in2,output1) ;
int a,b;
assign a =1;
assign b = 2;
reg c;
generate
begin
if (a==b) ifname : begin // Violation 1
always @ (in1)
begin
output1 = in1&&in2; // Violation 2
end
end
case (a*b) // Violation 3
1,c*2: // Violation 4
assign x =1;
endcase
end
gen2: begin
case (a*b) // Violation 5
1,2:
assign x =1;
3,4 :
assign x =2;
endcase
end
endgenerate
endmodule
Violations Produced
• Avoid using disallowed operator " == " – Violation 1
• Avoid using disallowed operator " && " – Violation 2
Example 5
Check for disallowed operators (++,--,*) and the ability to use (++,--) inside the increment area
of the loop.
Rule Configuration
• Disallowed Operators — Multiplication(*), Arithmetic: (- binary), Arithmetic: (+

binary), Arithmetic: (-- post), Arithmetic: (++ post), Arithmetic: (-- pre), Arithmetic:
(++ pre)
• Scope — <Design Units>, <Blocks>, <Sub-Programs>
Allowed Operators
• Ignore — Ignore increment/decrement operators in for_step assignments

Analyzed Code
module operatorsIncrDecr ;
always begin
for(int I = 0; I < 5; i-- , ++i)
begin
--i; //Violation 1
I = i++; //Violation 2
I = I * i; //Violation 3
end
end
endmodule
Violations Produced
• Avoid using disallowed operator " -- pre " – Violation 1
• Avoid using disallowed operator " ++ post " – Violation 2
Related Topics
Allowed Constructs
Allowed Pragmas
Allowed Pragmas
Checks for the use of certain pragmas. This rule checks for the use of pragmas other than a
specified allowed set.
Usage
Allowed Pragmas
Common Parameters
Disallowed Pragmas
Parameters
• Disallowed Pragmas
Specify the allowed pragmas. The rule can check for the use of “Translate on/off” and
“Synthesis on/off” pragmas irrespective of the Pragma Class keyword. The default is Other
Specific Pragmas.
o HDL Designer Series Specific Pragmas
o Other Specific Pragmas
o SYNTHESIS ON/OFF
o TRANSLATE ON/OFF
Choosing the option “Other Specific Pragmas” will check for other pragmas (other than
translate_on/off, synthesis_on/off) that are tool-specific of the form <pragma_class>
<pragma_name>
Where <pragma_class> is any of the following:
pragma <pragma_name>
exemplar <pragma_name>
synopsys <pragma_name>,
and <pragma_name> is any of the following:
async_set_reset
synthesis_off, synthesis_on
full_case, parallel_case
enum, map_to_entity, map_to_module
return_port, return_port_nam
state_vector
syn_encoding
syn_keep
label
Allowed Pragmas
sync_set_reset
template
resolution_method
dc_script_begin, dc_script_end
Examples
Example 1
ARCHITECTURE rtl OF top IS
TYPE MYVECTOR IS ARRAY (7 downto 0) OF bit;
CONSTANT WIDTH : integer := 8;

SIGNAL clk_a, rst_a, rst_b, sig : std_logic;
SIGNAL vector : STD_LOGIC_VECTOR (3 downto 0);
-- exemplar enum -- Pragma “enum”: Avoid using disallowed synthesis

pragmas
-- synopsys map_to_module -- Pragma “synopsys map_to_module”: -- Avoid
using disallowed synthesis pragmas
-- pragma return_port_name -- Pragma “return_port_name”: Avoid using
disallowed synthesis pragmas
-- pragma sync_set_reset -- Pragma “sync_set_reset”: Avoid using
disallowed synthesis pragmas
end rtl;
Violation Produced
Pragma “my_pragma": Avoid using disallowed synthesis pragmas
Allowed System Calls

Checks for usage of disallowed system calls. You can specify a list of system calls which should
not be used. The rule violates for every usage of a disallowed system call.
Usage
Common Parameters
Disallowed Calls
Parameters
• Disallowed Calls
Specify which system should not be used. The default is $display, $cast, $finish and
$random.
o $display
o $cast
o $finish
o $random
Examples
Example 1
Checks that system calls $cast and $display are not used.
Rule Configuration
• Disallowed Calls — $cast, $display
Analyzed Code
module allowed_sys_call;
int num;
byte b1;
always@(*)
if($cast(num, b1)) // Violation 1
$display("Casting successful."); // Viollation 2
else
$display("Casting failed."); // Violation 3
endmodule
Violations Produced
• ERROR, System call "$cast" is disallowed – Violation 1
• ERROR, System call "$display" is disallowed– Violation 2
• ERROR, System call "$display" is disallowed– Violation 3

Related Topics
Allowed Constructs
Allowed Types
Allowed Types
Checks for the use of specified VHDL Types, VHDL Packages and multi-dimensional VHDL/
Verilog arrays. Also, can check for either allowed Types, Packages, and Types inside Packages
(those that may be used), or it can check for disallowed Types, Packages, and Types inside
Packages (those that must not be used).
Enumerated types used to describe state variables can be excluded from the check.
The usage of Types/Packages/Types defined in Packages other than those in an “Allowed” set
will cause a violation. Similarly, the usage of any Types/Packages/Types defined in Packages in
a “Disallowed” set will cause a violation.
Usage
Allowed Types
Common Parameters
Applies To
Action
Packages
Types
Excluded Types
Parameters
• Applies To
Specify to which construct/s the check applies. The default is [VHDL] <all>.
o [VHDL]
<all>, Ports, Generics, Signals, Global Signals, VHDL Variables, Constants, Types,
Subprogram Arguments, Array Bounds
o [Verilog] <all> Ports, Nets, Verilog/System-Verilog Constants, Verilog/System-
Verilog Variables, Verilog/System-Verilog Types, Packed Struct Members,
Associative Array Indices, Associative Array Elements, For-Loop Iterators
Note
The value "Variables" can be used for VHDL and Verilog. For VHDL, “Variables”
refers to regular VHDL variables, whereas for Verilog, it refers to all variable data
types (for example: reg, integer, real, real time, time).
• Action
Specify whether the Types/Packages are allowed or disallowed. The default is Disallow.
o Allow
Allowed Types
o Disallow
• Packages
Specify which VHDL Packages to check for. You can choose from the supplied options
and/or enter your own values. The default is ieee.std_logic_arith.
o ieee.*
o ieee.numeric_std
o ieee.std_logic_arith
o <user-defined>
o <don’t care>
• Types
Specify which VHDL and Verilog Types to check for. You can choose from the supplied
options and/or enter your own values. The default is std.bit and std.bit_vector.
o <VHDL Types>
<IEEE Types>
ieee.signed, ieee.std_logic, ieee.std_logic_vector, ieee.std_ulogic,
ieee.std_ulogic_vector, ieee.unsigned, <other IEEE Types>
<STD Types>
<integer types>, <other STD Types>, std.bit, std.bit_vector
<VHDL array of array>
record
vhdl enum
o <Verilog Types>
<Integer data types>
int, integer, longint, shortint
<Net data types>
wand, wire, wor
<Real and time data types>
real, realtime, shortreal, time
<Variable data types>
bit (SystemVerilog), byte, chandle, event, logic, reg, string,
class
enum
struct
typedef
union
o <Multi-Dimension Arrays>
o <don't care>
Allowed Types
• Excluded Types
Specify whether enumerated state types should be excluded from this check. The default is
<don’t care>.
o FSM State Variables Enum Type
o <don’t care>
Note
The value of the Packages parameter cannot be set as “<don't care>” when the Types
parameter is set as “<don't care>”.
The Types parameter cannot have any value along with the “<don't care>” value.
Regarding <user-defined> values:
• If you manually enter a type name which already exists within one of the package
options in the parameter list, the entry will be regarded as a duplicate and will not be
retained when you close the tool.
• If you wish to only check specific types from within one of the listed packages,
please prefix the type with the appropriate package name. For example, to check for
type “real”, enter “std.real”. Similarly for “time”, “string” or “integer” enter
“std.time”, “std.string” or “std.integer”.
Examples
Example 1
Check for disallowed type “std_ulogic” and its sub types.
Rule Configuration
• Applies To — Types
• Types — std_ulogic
Allowed Types
Analyzed Code
LIBRARY ieee;
USE ieee.std_logic_arith.all;
PACKAGE my_dummy_pkg IS
subtype my_X01 is std_ulogic; -- Violation 1 (for std_ulogic subtype)
subtype my_X02 is my_X01; -- Violation 2 (for std_ulogic subtype,
my_X02 resolves to disallowed type std_ulogic)
type my_std_ulogic_array02 is array (NATURAL range <>) of my_X01; --
Violation ( "my_std_ulogic_array02" resolves to dis-allowed type
std_ulogic)
type my_std_ulogic_array01 is array (NATURAL range <>) of my_X02; --
Violation ("my_std_ulogic_array01" resolves to dis-allowed type
std_ulogic)
END my_dummy_pkg;
PACKAGE BODY my_dummy_pkg IS
END my_dummy_pkg;
Violations Produced
• Type "ieee.std_ulogic", used for subtype "my_X01", is among disallowed types
"ieee.std_ulogic" -- Violation 1
• Type "my_X01", used for subtype "my_X02", is among disallowed types
"ieee.std_ulogic". "my_X01" is a subtype of "ieee.std_ulogic" – Violation 2
Example 2
Check for disallowed types “array of array” and “multi-dimension array” in VHDL files.
Rule Configuration
• Types — <Multi-Dimension Arrays>, <VHDL array of array>
Allowed Types
Analyzed Code
ENTITY ArrayOfArray IS
END ArrayOfArray;
ARCHITECTURE ArrayOfArrayArch OF x IS
TYPE t1 IS ARRAY(0 TO 1, 0 TO 1) OF bit; --Violation 1 “multi-dim
array”
TYPE t2 IS ARRAY(0 TO 1) OF bit; --“array”
TYPE t3 IS ARRAY(0 TO 1) OF t2; --Violation 2 “array of array”
TYPE t4 IS ARRAY(0 TO 1) OF t1; --Violation 3 “array of multi-dim
array”
TYPE t5 IS ARRAY(0 TO 1, 0 TO 1) of t2; --Violation 4,5 “multi-dim
array of array”
TYPE t6 IS ARRAY(0 TO 1, 0 TO 1) of t1; --Violation 6,7 “multi-dim
array of multi-dim array”
SUBTYPE t7 IS t5; --Violation 8,9 “multi-dim array”
SUBTYPE t8 is t3; --Violation 10 “array of array”
TYPE t9 IS ARRAY(0 TO 1) OF std_logic_vector(10 downto 0); --Violation
11 “array of array”
SIGNAL S : t8; --Violation 12
BEGIN
END ArrayOfArrayArch;
Violations Produced
• Multi-dimensional array declaration for "t1" – Violation 1
• Array of array declaration for "t3" – Violation 2
• Array of array declaration for "S" – Violation 12
Example 3
Check for disallowed type “multi-dimension array” in Verilog files.
Rule Configuration
Allowed Types
• Types — <Multi-Dimension Arrays>

Analyzed Code
module arrayTest ;
bit [3:0] [7:0] joe [1:10]; //10 elements of 4 8-bit bytes //Violation
1
byte a_2D[3][3]; //Violation 2
reg [7:0] a [0:3]; //Violation 3
reg [7:0] b [0:3] [0:3]; //Violation 4
endmodule
Violations Produced
• Multi-dimensional array declaration for "joe" – Violation 1
• Multi-dimensional array declaration for "a_2D" – Violation 2
• Multi-dimensional array declaration for "a" – Violation 3
• Multi-dimensional array declaration for "b" – Violation 4
Related Topics
Allowed Libraries
Assignment Base Rules
Assignment Base Rules

The Assignment base rules check for assignments coding style, or synthesis related issues that
may be caused by using assignments improperly.
Continuous Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Duplicate Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Initialization Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Input Port Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Mixed Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Multiple Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Multiple Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Unassigned Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Vector Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Continuous Assignments
Language support: Verilog Any
Checks for the use of procedural continuous assignments as they are typically non-
synthesizable.
Usage
Common Parameters
Parameters
Examples
Example 1
Analyzed Code
module test;
reg a, b, c, d;
wire e;
initial begin
assign d = a & b & c; // Violation 1
a = 1;
b = 0;
c = 1;
#10 force d = (a | b | c); // Violation 2
#10 release d; // Violation 3
send
endmodule
Violations Produced
• Procedural continuous assign statements are not supported. – Violation 1
• FORCE statements are not supported. – Violation 2
• RELEASE statements are not supported. – Violation 3
Duplicate Assignments
Checks for duplicate assignments.
Usage
Common Parameters
Exclude Partial Overlaps
Description
In a sequential process there may be multiple assignments to a single variable. The variable may
be assigned a value at one point in the process and assigned again later in the process. Such
cases are regarded as “Duplicate Assignments”.
Assignments to the same variable in parallel branches of if-else or case structures would not be
treated as duplicated as in such situations only one of assignment is executed and hence the
values are not overwritten.
Duplicate Assignments can be split into two categories:
• Full overlap
The subsequent assignment always over-writes the previous assignment eg:
out1 <= in1;
…
out1 <= in2;
where “out1” is always assigned a new value and the previous assignment is overwritten.
• Partial overlap
The subsequent assignment overwrites but only under certain conditions eg:
out1 <= in1;
…
if (cond) out1 <= in2;
where “out1” is assigned only if “cond” is true.
The rule allows for exclusion of checking for partial over-writes through parameterization.
Please see the Examples section for further details.
Parameters
• Exclude Partial Overlaps

Specifies whether to exclude partial overlaps from checking. The default is Yes.
o Yes,
o No
Examples
Example 1
Checks for “fully overlapping” assignments.
Rule Configuration
• Exclude Partial Overlaps — Yes
Analyzed Code
library ieee;
entity Example1 is
end Example1;
architecture rtl of Example1 is

signal cst, nst: std_logic_vector (2 downto 0);
begin
next_state_fsm: process (cst)
begin
nst <= "011"; -- Associated Violation 1
nst <= "001"; -- Violation 1 , as this line fully over-writes
assignment on previous line
-- Associated Violation 2
case cst is -- Violation 2, as the assignments in this block
together completely over-write previous assignments
when "000" =>
nst<= "001";
when "001" =>
nst <= "101";
when "101" =>
nst <= "111";
when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
if (cst = "000") then -- No Violation as the over-write occurs only
when cst = 000, it’s a partial over-write
nst <= "001";
end if;
end process;
end rtl;
Violations Produced
• Example1.vhd, 14 : Assignment(s) to 'nst' done on current line fully over-write(s)
previous assignment(s). – Violation 1
• Example1.vhd, 13 : Assignment(s) to 'nst' done on current line is(are) fully over-written
later. – Associated Violation 1
• Example1.vhd, 15 : Assignment(s) to 'nst' done inside current block fully over-write(s)
• Example1.vhd, 14 : Assignment(s) to 'nst' done on current line is(are) fully over-written
Example 2
Checks for both fully and partially overlapping assignments.
Rule Configuration
• Exclude Partial Overlaps — No
Analyzed Code
module Example2 (input [1:0] d, input mclk,
input sel1, input sel2,
output reg [1:0] q);
reg [1:0] cst, nst;
always@(posedge mclk)
begin
q <= 0; // Associated Violation 1, as this assignment in
conditionally over-written later
if (sel1) // Violation 1, as assignments inside this block
conditionally over-write a previous assignment
begin // Associated Violation 2, as this assignment is always
over-written later
q <= d;
end
q <= 1; // Violation 2, as this assignment always overwrites
assignments done inside a previous block
end
always@(negedge mclk) // No violations in this always block as all

assignments are mutually exclusive
begin
if (sel2)
q <= d;
else
q <= 3;
end
always@(cst)
begin
case (cst) // Associated Violation 3, as assignment in this block
are partially over-written by the later block
0 : begin nst <= 2'b00; end
endcase
case (cst) // Violation 3, as assignments in this block partially
overwrite assignments done in the previous block
1 : begin nst<= 2'b10; end
endcase
end
endmodule
Violations Produced
• Example2.v, 8 : Assignment(s) to 'q' done inside current block partially over-write(s)
• Example2.v, 7 : Assignment(s) to 'q' done on current line is(are) partially over-written
• Example2.v, 12 : Assignment(s) to 'q' done on current line fully over-write(s) previous
assignment(s). – Violation 2
• Example2.v, 8 : Assignment(s) to 'q' done inside current block is(are) fully over-written
• Example2.v, 31 : Assignment(s) to 'nst' done inside current block partially over-write(s)
• Example2.v, 25 : Assignment(s) to 'nst' done inside current block is(are) partially over-
written later. – Associated Violation 3
Note
Do not assign to the same signal more than once within the same statement block.
Initialization Assignments
Checks for the use of initialization assignments rather than explicit resets at declaration time.
More specifically this rule checks VHDL – Initial values on signals and variables (e.g. signal x :
std_logic := ‘0’;) and Verilog – Variable declaration assignment (e.g. reg [3:0] h = 4’hf)
Also, checks either all signals/variables for initialization assignments or can be restricted to
combinationally driven output ports only. Generally, sequentially driven outputs can be
initialized by the reset; however the same cannot be done for combinationally driven outputs,
and hence these should be assigned in all paths rather than specifying an initial value.Besides
this, the rule also checks for the presence of initial blocks which are a common mechanism of
specifying initial values in Verilog.
Usage
Common Parameters
Check
Parameters
• Check
Specify the types of initialization styles that need to be checked. The default is
Combinationally driven output ports, All signals/variables and Initial blocks.
o Combinationally driven output ports
o All signals/variables
o Initial blocks
Examples
Example 1
Check for various initialization styles.
Rule Configuration
• Check — Combinationally driven output ports, All signals/variables, Initial blocks
Analyzed Code
module init2 (in1, in2, clk, out1, out2);
input [3:0] in1, in2;
input clk;
output [3:0] out1, out2;
reg [3:0] out1 = 4'b0000; // Violation 1, 5
reg [3:0] out2 = 4'b1111; // Violation 2
reg [3:0] temp1;
reg [3:0] temp2 = 4'ha; // Violation 3
initial // Violation 4
temp1 = 4'b1010;
always @(in1 or in2)
begin
temp1 = in1;
temp2 = in2;
out1 = temp1& temp2;
end
out2 = in1 | in2;
endmodule
Violations Produced
• 'out1' has been initialized at declaration time. – Violation 1
• 'out2' has been initialized at declaration time. – Violation 2
• 'temp2' has been initialized at declaration time. – Violation 3
• Initial block has been used. – Violation 4
• Combinationally driven output port 'out1' has been initialized at declaration time. –
Violation 5
Input Port Assignments

Checks for assignments made to input ports. This rule is applicable to Verilog only because
input port assignments are not allowed in VHDL.
Usage
Common Parameters
Parameters
Examples
Example 1
Check for assignments made to an input port in Verilog.
Rule Configuration
Default parameter values.
Analyzed Code
module test2 (input a, b, output c); // Violation
assign c = b;
assign a = b;
endmodule
Violation Produced
Cannot assign to an input: 'a'.
Mixed Assignments
Mixed Assignments
Checks if a Verilog variable is being assigned using a mixture of blocking and non-blocking
assignments in a single always block. It should be noted that mixed assignments are non-
synthesizable and hence any violation of this rule will result in a synthesizability violation as
well. Note that the effects of synthesis may result in different violations from those expected
from looking purely at the code.
Usage
Mixed Assignments
Common Parameters
Parameters
Examples
Example 1
Check for a mixture of blocking and non-blocking assignments.
Rule Configuration
Analyzed Code
module mixedassign (input [3:0] in1, input cond, output reg [3:0] out1); /
/ Violation 1
always @(cond or in1)begin
if(cond)
out1 = 4'b0000; // Associated Violation 2
else
out1 <= in1; // Associated Violation 3
end
endmodule
Violations Produced
• 'out1' has been assigned using both blocking and non-blocking assignments. – Violation
1
• + 'out1' has been assigned using blocking assignment. – Associated Violation 2
• + 'out1' has been assigned using non-blocking assignment. – Associated Violation 3
Related Topics
Blocking Nonblocking Assignments
Multiple Drivers
Multiple Drivers
Checks for the presence of multiple, simultaneously active drivers on a signal/shared variable
(VHDL) or on a net/variable (Verilog). The active drivers may belong to sequential/
combinatorial process/always blocks or can be concurrent drivers.
Additionally, the condition wherein there are multiple tri-state drivers with non-inverted
conditions is also reported as a potential multiple driver scenario.
Usage
Multiple Drivers
Common Parameters
Parameters
Examples
Example 1
Check for multiple drivers across combinational processes.
Rule Configuration
Analyzed Code
library ieee;
entity top is
port(a1, a2 : in std_logic_vector(7 downto 0);
a3 : out std_logic_vector(7 downto 0));
end;
architecture rtl of top is

begin
operate_proc: PROCESS(a1)
begin
a3 <= a1 and "10101000"; -- Violation
end PROCESS;
test_proc: PROCESS(a2)
begin
a3 <= a2; -- Associated Violation
end process;
end rtl;
Violations Produced
• Unresolved multiple drivers detected on signal ‘a3’. – Violation
Multiple Drivers
• + Multiple drivers for signal ‘a3’ assigned concurrently. – Associated Violation

Example 2
Check for multiple drivers for a tri-state bus occurring due to non-inverted enables.
Rule Configuration
Analyzed Code
module trist (input in1, in2, input sel1, input sel2, output reg out1);
always @( in2 or sel2)
out1 = sel2 ? in2 : 1'bz; // Violation
always @(in1 or sel1)

out1 = sel1 ? in1 : 1'bz; // Associated Violation
endmodule
Violations Produced
• Unresolved multiple drivers detected on signal ‘out1'. – Violation
• + Multiple drivers for signal ‘out1' assigned by a tristate driver. – Associated Violation
Related Topics
Multiple Waveforms
Multiple Waveforms
Checks for the use of multiple waveforms on the right-hand side of a signal assignment, where a
waveform consists of an assignment value expression and an optional assignment delay
expression. Only the first element of a waveform may be synthesizable.
For example, the following clock generator contains 2 waveforms:
clk <= '1', '0' AFTER half_period;
Usage
Multiple Waveforms
Common Parameters
Parameters
Examples
Example 1
Check for multiple waveforms.
Analyzed Code
ENTITY test IS
PORT( x1, x2, x3, x4: IN bit;
y1, y2: OUT bit);
END ENTITY test;
ARCHITECTURE test OF test IS

SIGNAL int: bit;
COMPONENT and2
GENERIC( delay: time := 1 ns;
load: positive);
PORT( a, b: IN bit;
c: OUT bit);
END COMPONENT and2;
-- FOR ALL: and2 USE ENTITY work.and2(basic);
constant delay : TIME := 1 ns ;
signal gate2_int : BIT;
BEGIN
-- Flattened contents of gate2
-- gate2_itant delay : TIME := 1 ns ;
gate2_int <= gate1_int ,gate0_int AFTER delay; -- Violation
END ARCHITECTURE test;
Violation Produced
Found Multiple Waveforms
Multiple Waveforms
Note
Multiple waveforms are non-synthesizable.
Unassigned Objects
Unassigned Objects
Checks that an object (e.g. signal, variable, port) has been assigned a value before it is used.
Usage
Unassigned Objects
Common Parameters
Parameters
Examples
Example 1
conv_proc: PROCESS (read_data, input_data)
BEGIN
IF NOT (read_data = input_data) THEN
--Signal/port “read_data” should be assigned before being read
END IF;
END PROCESS conv_proc;
Violation Produced
Signal/port "data_local" should be assigned before being read.
Related Topics
Unconnected Ports
Undefined Design Units
Unused Declarations
Vector Assignment
Vector Assignment
Checks for the use of hard-coded values to pad/initialize vectors.
When assigning elements of vectors to the same signal value, such as for initializing or
resetting, this should be done in a way which is independent of the size of the vector. This limits
the impact of changing vector sizes. This check looks for the assignment of hard-coded values
when an aggregate assignment (eg others => ‘0’) could have been used.
Please note that aggregate assignments are not flagged even though it may be possible to
represent these as nested aggregate assignments. For example,
(others => “00000000”) can be rewritten as (others => (others => ‘0’)), but this is not flagged
by the tool.
Usage
Vector Assignment
Common Parameters
Parameters
Examples
Example 1
PROCESS sync_proc (clk, rst)
If (rst = ‘0’) then
xmitdt <= “00000000”;
-- Use aggregate style (others => ‘0’) for assigning all bits of vector
xmitdt to the same value ‘0’.
Violation Produced
Use aggregate style (others => '0') for assigning all bits of vector "data_vector" to the same
value '0'
Note
Use (others => <val>) to minimize the impact of changes to the vector size.
Related Topics
Hard Coded Numeric Values
Case Base Rules
Case Base Rules

The Case base rules perform checks related to CASE statement.
Case Statement Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Case Statement Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Checks for disallowed case statement directives such as full_case or parallel_case. It also
checks for scenarios wherein the full_case/parallel_case pragma is specified but the case
statement is not full/parallel respectively.
A Verilog case statement is regarded as “full/complete” if all possible binary patterns are
covered by case items in the case statement.
A case statement is regarded as “parallel” if all case items are unique (that is, the case items do
not overlap and are not duplicated).
Usage
Common Parameters
Disallowed Directive
Parameters
• Disallowed Directive
Specify which directives are not allowed. The default is full_case and parallel_case.
o full_case
o parallel_case
o full_case in Non-full Case Statements
o parallel_case in Non-parallel Case Statements
Examples
Example 1
Check for the disallowed case statement directive “parallel_case” and also for this pragma
specified for a non-parallel case.
Rule Configuration
• Disallowed Directive — parallel_case, parallel_case in Non-parallel Case Statements
Analyzed Code
module test1(in1,out1);
input [2:0] in1;
output [2:0] out1;
wire [2:0] in1,out_local;
reg [2:0] out1;
reg [2:0] in_local;
reg [2:0] in_local_2;
always@(*)
begin
casex(in_local) //pragma parallel_case // Violation 1, 2
3'b0xx: begin out1 = in1 - 1'b1; in_local = in_local + 1'b1; end
3'bx0x: begin out1 = in1 + 1'b1; in_local = in_local + 1'b1; end
3'bxx0: begin out1 = in1; in_local = in_local + 1'b1; end
endcase
end
endmodule
Violations Produced
• Pragma "parallel_case" is disallowed. – Violation 1
• Do not use the parallel_case pragma with non-parallel case statement. – Violation 2
Related Topics
Case Statement Style

Checks for disallowed case statement styles. It checks the following:
*The use of disallowed case statement styles such as incomplete case statements and
overlapping/unreachable case items.
*The size mismatch between the case select and case items.
*The default clause is not being the last case item (in Verilog).
*The use of “others => null” (in VHDL).
*Case statement without a default/others clause.
Through the different configurations of the parameter “Unreachable Case Item Analysis” the
rule can optionally ignore unreachable defaults of a case statement wherein all possibilities have
been explicitly covered or it can ignore defaults altogether. It should be noted that empty case
items (that is, case items without any corresponding statements) do not qualify for the
overlapping/unreachable case items check. It should be noted as well that VHDL language
semantics already cover all case statement style checks except the use of “others => null” and
the absence of the others clause.
Usage
Common Parameters
Disallowed Styles
Unreachable Case Item Analysis
Parameters
• Disallowed Styles
Specify which styles are not allowed. The default is Others/Default clause not last case item
and Case statement without others/default
o Incomplete Case Statement
o Overlapping Case Items
o Others/Default clause not last case item
o Unequal Case Expression and Case Item lengths
o when others => null
o Case statement without others/default
o <don’t care>
• Unreachable Case Item Analysis

Specify how to analyze the unreachable case items. The default is All Case Items.
o All Case Items
o Ignore Others/Default When All Case Choices Are Covered
o Ignore Others/Default Altogether
o <don’t care>
Examples
Example 1
Check for all possible disallowed case statement styles.
Rule Configuration
• Disallowed Styles — Incomplete Case Statement, Overlapping Case Items, Others/
Default clause not last case item, Unequal Case Expression and Case Item lengths, when
others => null, Case statement without others/default
Analyzed Code
module example_case (input [2:0] in1, in2, output reg [2:0] out1, out2);
begin
casex (in1) // Violation 2, 5, 7
3'b00x : out1 = in2;
3'b0x1 : out1 = 3'b111; // Associated Violation 3
3'b01x : out1 = in2; // Associated Violation 4
4'b0100 : out1 = 3'b110; // Violation 1
3'b001 : out1 = in2; // Violation 6
endcase
end
endmodule
Violations Produced
• Case item '4'b0100' (width 4) is of different size than case select expression (width 3). –
Violation 1
• Case statement is not parallel. – Violation 2
• + Case item '0x1' is overlapping with case item '00x', at line 6, for value '001'. –
Associated Violation 3
• + Case item '01x' is overlapping with case item '0x1', at line 7, for value '011'. –
• Case statement is not full. – Violation 5
• Case item statement is not reachable. – Violation 6
• Case statement does not have a ‘default’ branch. – Violation 7
Related Topics
Clock and Reset Base Rules
Clock and Reset Base Rules

The Clock and Reset base rules perform checks related to clocks and resets.
Asynchronous Reset Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Clock Declaration Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Consistent Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Consistent Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Controllable Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Internally Generated Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Mixed Clocks Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Multiple Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Multiple Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Reset Logic Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Untested Edge Trigger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Asynchronous Reset Release

Checks if asynchronous resets are de-asserted synchronously. [Design-wide]
Usage
Common Parameters
Description
This rule checks whether an asynchronous reset of a register is de-asserted (released)
synchronously with respect to the clock used. Any asynchronous reset in the design is therefore
required to be the output of a reset synchronizer circuit as shown in the following figures.
The circuit in Figure 1 represents a synchronizer for an active-low asynchronous reset. A

similar circuit can be created for an active-high reset by using the Q-bar output from the second
flip-flop, instead of the Q output.
The circuit in Figure 2 represents a synchronizer for an active-low asynchronous reset. A

similar circuit can be created for an internal active-high reset by setting, rather than clearing, the
2-stage synchronizer’s flip-flops.
Note
All inputs to the combo logic in Figure 2 must be driven or “hard-wired” high or low. These
inputs cannot be left floating (unconnected).
The circuit in Figure 3 represents a synchronizer for an internal active-high asynchronous reset.
Note that Figure 3 illustrates an active-high register controlled reset input to the synchronizer.
The circuit in Figure 4 represents a synchronizer where CLR and SET are connected to ground.
A violation is generated if an asynchronous reset is not synchronized before being used. The
primary violation points to the source reset signal. The associated violations point to all the
always blocks/processes in the design which use the source reset signal as an asynchronous
reset. The synchronizer should have at least two registers to be recognized as a valid
synchronizer.
Note
This rule does not report any violations produced for a circuit that is detected as a reset
synchronizer circuit.
Also, in addition to the conditions illustrated in the four previous figures to create a reset
synchronizer circuit, there is another condition: To consider any of the previous four figures a
reset synchronizer circuit, its output should be used as a reset signal for any flip-flop, otherwise
this circuit is considered a normal circuit and it raises violations.
This is a design-wide check.
Note
Synthesis effects may result in different violations from those expected when manually
reviewing the source code.
Additional Information:
If an asynchronous reset of a register is de-asserted before the active clock edge, such that the
reset recovery time specification of a register is not met, then the output of the register which is
changing its state due to the reset release can become metastable. Therefore, there should be
sufficient time separating the reset de-assertion and the subsequent active clock edge to ensure
proper register functionality. Further, if the reset is released asynchronous to the active clock
edge, minor differences in propagation delays in the reset tree and the clock tree across the
device can cause some registers to exit their reset states while others are still in their reset states
during the first clock cycle after the reset release. In order to overcome this problem, care
should be taken to ensure that an asynchronous reset is released synchronously. This is
accomplished with the help of a reset synchronizer as shown above. When the output of such a
synchronizer is used to reset internal registers asynchronously, it ensures the registers are reset
asynchronously and released synchronously from their reset states.
Note
If the reset is released on the opposite edge of the clock edge driving the internal registers, it
is not considered as a violation since a sufficient reset recovery time interval will be
assumed.
It may be worthwhile to note that the reset synchronizer must consist of a chain of at least two
flip-flops. This is because the output of the first flip-flop can become metastable due to the
asynchronous reset signal driving its D-input pin. The second flip-flop is necessary to remove
this metastability. The second flip-flop does not suffer from metastability because the transition
of its output occurs on the second active clock edge after reset removal, unlike the first flip-flop
in the synchronizer chain.
Limitations:
If the clock which controls the synchronizer flip-flops and the rest of the design is a gated clock
and is not isolated in a different module, then the tool may not be able to detect the clock signal
driving the synchronizer and the rest of the design is the same signal. Hence, a violation will be
generated. However, if gated clocks are not used or the gated clock is isolated, then this
limitation does not exist.
Parameters
Examples
Example 1
Check if asynchronous resets are synchronously released.
Analyzed Code
module test12(input clk, a, d, output m); // Violation 1
wire e, f, i;
mid1 inst1(.clk(clk), .b(1), .c(a), .e(e), .f(f));
mid2 inst2(.clk(clk), .g(e), .h(f), .i(i));
mid3 inst3(.clk(clk), .j(i), .k(d), .l(m));
endmodule
module mid1(input clk, b, c, output f, output reg e);

always @(posedge clk or negedge c) // Associated Violation 2
if (!c)
e <= 0;
else
e <= b;
assign f = c;
endmodule
module mid2(input clk, g, h, output reg i);

always @(posedge clk or posedge h) // Associated Violation 3, Violation
4
if (h)
i <= 0;
else
i <= g;
endmodule
module mid3(input clk, k, j, output reg l);

always @(posedge clk or posedge j) // Associated Violation 5
if (j)
l<= 0;
else
l <= k;
endmodule
Violations Produced
• Asynchronous reset 'test12.a' is not synchronized before being used. – Violation 1
• + Asynchronous reset 'c' of always block is not released synchronously. – Associated

Violation 2
• + Asynchronous reset 'h' of always block is not released synchronously. – Associated
Violation 3
• Asynchronous reset 'test12.inst2.i' is not synchronized before being used. – Violation 4
• + Asynchronous reset 'j' of always block is not released synchronously. – Associated
Violation 5
Example 2
Check for asynchronous reset being released on a different clock.
Analyzed Code
module test8(input clk1, clk2, rst1, rst2, d, output reg q3);
reg q, q2;
wire rst = rst1 & rst2;
always @(posedge clk1 or posedge rst)
if (rst)
q <= 1;
else
q <= 0;
always @(posedge clk1 or posedge rst) // Violation 1
if (rst)
q2 <= 1;
else
q2 <= q;
always @(posedge clk2 or negedge q2) // Associated Violation 2
if (!q2)
q3<= 1;
else
q3 <= d;
endmodule
Violations Produced
• Asynchronous reset 'test8.q2' is not synchronized before being used. – Violation 1
• + Asynchronous reset 'q2' of always block is not synchronized with respect to the used
clock. – Associated Violation 2
Example 3
Check for asynchronous reset being used on an incorrect active level.
Analyzed Code
module test16(input clk, a, d, output m);
wire e, f, i;
mid1 inst1(.clk(clk), .b(0), .c(a), .e(e), .f(f));
mid2 inst2(.clk(clk), .g(e), .h(f), .i(i));
mid3 inst3(.clk(clk), .j(i), .k(d), .l(m));
endmodule
module mid1(input clk, b, c, output f, output reg e);

always @(posedge clk or posedge c)
if (c)
e <= 1;
else
e <= b;
assign f = c;
endmodule
module mid2(input clk, g, h, output reg i);

always @(posedge clk or posedge h) // Violation 1
if (h)
i <= 1;
else
i <= g;
endmodule
module mid3(input clk, k, j, output reg l);

wire j1 = ~j;
always @(posedge clk or posedge j1) // Associated Violation 2
if (j1)
l<= 0;
else
l <= k;
endmodule
Violations Produced
• Asynchronous reset 'test16.inst2.i' is not synchronized before being used. – Violation 1
• + Asynchronous reset 'j' of always block is used at the opposite active level after being
synchronized. – Associated Violation 2
Related Topics
Internally Generated Resets
Register Reset Control
Clock Declaration Style

Checks that clocks are not part of a bi-directional port or a vector.
Usage
Common Parameters
Disallow
Parameters
• Disallow
Specify which aspects of a clock are disallowed. The default is Bi-directional ports and
Buses for clocks.
o Bi-directional ports
o Buses for clocks
Examples
Example 1
Checks that the clock is not part of a bi-directional port or a vector.
Rule Configuration
Analyzed Code
module test(inout [5:9] clk, input rst, input d, output reg q); //
Violation 1, 2
if (rst)
q<= 0;
else
q <= d;
endmodule
Violations Produced
• Avoid using a bus to define clock 'clk[9]'. – Violation 1
• Avoid using bi-directional port for clock 'clk[9]'. – Violation 2
Related Topics
Edge Detection
Multiple Clocks
Multiple Resets
Mixed Clocks Resets
Clock Used As Data
Edge Trigger Control
Consistent Clocks
Consistent Clocks
Checks that clocks within a specified scope have a consistent polarity. This is optionally a
design-wide check depending on the chosen parameter settings.
Usage
Consistent Clocks
Common Parameters
Hierarchy Level
Applies To
Consistency
Parameters
• Hierarchy Level
Specify the hierarchy level in which to check for a consistent clock polarity. “Entire
Design” means all the design files used in a given DesignChecker analysis. The default is
Process.
o Process, [VHDL Process, Verilog Always]
o Block, [VHDL Architecture or Verilog Module]
o Entire Design
• Applies To
Specify the type of registers to which the check should apply. The default is FSM State
Variable Registers and Other Registers
o FSM State Variable Registers
o Other Registers
• Consistency
Specify whether all clock signals should be used in a consistent way individually or whether
this consistency should be checked even across different signals. The detection of being
same signal or different signals is based on the condition whether the signals under
consideration form a single clock tree or not. The default is Single Clock.
o Single Clock
o Across Clocks
Also, this clock tree detection is based on the selected value of the Hierarchy Level
parameter. For Process, two signals should be the same RTL net to be considered as same
clock. For Block level, if the two signals are derived from the same signal inside the
Consistent Clocks
module/architecture, they are deemed to be the same clock signal. When performing the
check at the design-wide level, full clock trees for the whole design are created and two
clocks are considered same only if they belong to same design clock tree.
Examples
Example 1
Check for same clock used with multiple polarities at a block-level.
Rule Configuration
• Hierarchy Level — Block
• Applies To — Other Registers
• Consistency — Single Clock
Consistent Clocks
Analyzed Code
library ieee;
entity superMix4 is
port (din, din2, din3, rst, clk, load, clk_fsm,clk_fsm2 : in std_logic;
-- Violation 1
dout,dout_2 : out std_logic);
end superMix4;
architecture rtl of superMix4 is

signal clk1 : std_logic;
signal rst1 : std_logic;
signal cst, nst, cst2, nst2 : std_logic_vector (2 downto 0);
begin
derive_clks: process (clk) -- clk1 and clk2 are derived from the
begin -- signal "clk" and hence are the same
clk1 <= clk;
clk2 <= clk;
rst1 <= rst;
rst2 <= rst;
end process;
two_clks: process (clk1, clk2) -- Associated Violation 2, 3
begin
if (clk1'event and clk1 = '1') then
if (rst1 = '1') then
dout<= '1';
else
dout <= din;
end if;
end if;
dout_2 <= '0';
else
dout_2 <= din2;
end if;
end if;
end process;
sync_fsm: process (clk_fsm)

begin
if (clk_fsm'event and clk_fsm = '1') then
if (rst = '1') then
cst <= "000";
else
cst <= nst;
end if;
elsif (clk_fsm2'event and clk_fsm2 = '0') then
if (rst = '0') then
cst2 <= "000";
else
cst2 <= nst2;
end if;
end if;
end process;
Consistent Clocks

begin
case cst is
when "000" =>
nst <= "001";
when "001" =>
nst <= "101";
when "101" =>
nst <= "111";
when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
end process;
next_state_fsm2: process (cst2)

begin
case cst2 is
when "000" =>
nst2 <= "001";
when "001" =>
nst2 <= "101";
when "101" =>
nst2 <= "111";
when "111" =>
nst2 <= "100";
when "100" =>
nst2 <= "010";
when others =>
nst2 <= "000";
end case;
end process;
end rtl;
Violations Produced
• Clock 'clk' is not used at a single edge, inside architecture 'rtl’. – Violation 1
• + Clock 'clk1' is used at 'positive edge’. – Associated Violation 2
• + Clock 'clk2' is used at 'negative edge'. – Associated Violation 3
Example 2
Check FSM Register Clocks for multiple polarities at block level.
Rule Configuration
• Applies To — FSM State Variable Registers
• Consistency — Across Clocks
Consistent Clocks
Analyzed Code
library ieee;
entity superMix6 is
end superMix6;
architecture rtl of superMix6 is -- Violation 1

begin
two_clks: process (clk1, clk2)
begin
dout <= '1';
else
dout <= din;
end if;
end if;
dout_2 <= '0';
else
dout_2 <= din2;
end if;
end if;
end process;
sync_fsm: process (clk_fsm) – Associated Violation 2, 3

begin
cst <= "000";
else
cst <= nst;
end if;
cst2 <= "000";
else
cst2 <= nst2;
end if;
end if;
end process;

begin
case cst is
when "000" =>
nst <= "001";
when "001" =>
Consistent Clocks
nst <= "101";

when "101" =>
nst <= "111";
when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
end process;

begin
case cst2 is
when "000" =>
nst2 <= "001";
when "001" =>
nst2 <= "101";
when "101" =>
nst2 <= "111";
when "111" =>
nst2 <= "100";
when "100" =>
nst2 <= "010";
when others =>
nst2 <= "000";
end case;
end process;
end rtl;
Violations Produced
• FSM Clocks not used at a single edge, inside architecture 'rtl'. – Violation 1
• + FSM Clock 'clk_fsm' is used at 'positive edge’. – Associated Violation 2
• + FSM Clock 'clk_fsm2' is used at 'negative edge'. – Associated Violation 3
Related Topics
Consistent Resets
Consistent Resets
Checks This rule checks that resets within a specified scope have a consistent style
(synchronous/ asynchronous) and polarity. This is optionally a design-wide check depending on
the chosen parameter settings.
Note that the effects of synthesis may result in different violations from those expected from
looking purely at the code. Please see Register and Control Signal inference for more details.
Usage
Consistent Resets
Common Parameters
Disallow
Hierarchy Level
Applies To
Consistency
Parameters
• Disallow
Specify the consistency parameters. You can disallow the mixing of reset styles and/or
polarities. The default is Mixed Synchronous/Asynchronous Styles and Mixed Polarities.
o Mixed Synchronous/Asynchronous Styles
o Mixed Polarities
Mixed Polarity of Asynchronous Resets, Mixed Polarity of Synchronous Resets
Note
Important notes:
• Selecting "Mixed Polarity of Asynchronous Resets" produces violations only if both
occurrences of the reset are Asynchronous.
• Selecting "Mixed Polarity of Synchronous Resets" produces violations only if both
occurrences of the reset are Synchronous.
• Selecting "Mixed Polarities" produces violations on mixed polarity regardless of the
style of both resets (even if one is Asynchronous and the other is Synchronous).
• Hierarchy Level
Specify the hierarchy level in which to check for a consistent reset style. “Entire Design”
means all the design files used in a given DesignChecker analysis. The default is Process.
o Process, [VHDL Process, Verilog Always]
Consistent Resets
o Block, [VHDL Architecture or Verilog Module]

o Entire Design
• Applies To
Variable Registers and Other Registers.
o Other Registers
• Consistency
Specify whether all reset signals should be used in a consistent way individually or whether
this consistency should be checked even across different signals. The detection of being
same signal or different signals is based on the condition whether the signals under
consideration form a single reset tree or not. The default is Single Reset.
o Single Reset
o Across Resets
Also, this reset tree detection is based on the selected value of the Hierarchy Level
parameter. For Process, two signals should be the same RTL net to be considered as same
reset. For Block level, if the two signals are derived from the same signal inside the module/
architecture, they are deemed to be the same reset signal. When performing the check at the
design-wide level, full reset trees for the whole design are created and two resets are
considered same only if they belong to same design reset tree.
Examples
Example 1
Check if same reset is used with mixed style/polarity at the block level.
Rule Configuration
• Disallow — Mixed Synchronous/Asynchronous Styles, Mixed Polarities
• Consistency — Single Reset
Consistent Resets
Analyzed Code
library ieee;
entity superMix4 is
end superMix4;
architecture rtl of superMix4 is -- Violation 1, 4

begin
derive_clks: process (clk)
begin
clk1 <= clk;
clk2 <= clk;
rst1 <= rst;
rst2 <= rst;
end process;
two_clks: process (clk1, clk2) -- Associated Violation 2, 3, 5, 6

begin
dout<= '1';
else
dout <= din;
end if;
end if;
dout_2 <= '0';
else
dout_2 <= din2;
end if;
end if;
end process;

begin
if (rst = '1') then
cst <= "000";
else
cst <= nst;
end if;
if (rst = '0') then
cst2 <= "000";
else
cst2 <= nst2;
end if;
end if;
Consistent Resets
end process;

begin
case cst is
when "000" =>
nst <= "001";
when "001" =>
nst <= "101";
when "101" =>
nst <= "111";
when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
end process;

begin
case cst2 is
when "000" =>
nst2 <= "001";
when "001" =>
nst2 <= "101";
when "101" =>
nst2 <= "111";
when "111" =>
nst2 <= "100";
when "100" =>
nst2 <= "010";
when others =>
nst2 <= "000";
end case;
end process;
end rtl;
Violations Produced
• Reset 'rst' is used with mixed polarity, inside architecture 'rtl' – Violation 1
• + Reset 'rst1' is used as an 'active high' reset – Associated Violation 2
• + Reset 'rst2' is used as an 'active low' reset – Associated Violation 3
• Reset 'rst' is used with mixed style, inside architecture 'rtl' – Violation 4
• + Reset 'rst2' is used as an asynchronous reset – Associated Violation 5
• + Reset 'rst1' is used as a synchronous reset – Associated Violation 6
Example 2
Check FSM register resets for mixed style/polarity at block level.
Consistent Resets
• Disallow — Mixed Synchronous/Asynchronous Styles, Mixed Polarities
• Consistency — Across Resets
Consistent Resets
Analyzed Code
library ieee;
entity superMix6 is
end superMix6;architecture rtl of superMix6 is -- Violation 1
begin
begin
dout <= '1';
else
dout <= din;
end if;
end if;
dout_2 <= '0';
else
dout_2 <= din2;
end if;
end if;
end process;
sync_fsm: process (clk_fsm) -- Associated Violation 2, 3

begin
cst<= "000";
else
cst <= nst;
end if;
cst2 <= "000";
else
cst2 <= nst2;
end if;
end if;
end process;

begin
case cst is
when "000" =>
nst <= "001";
when "001" =>
nst <= "101";
when "101" =>
Consistent Resets
nst <= "111";

when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
end process;

begin
case cst2 is
when "000" =>
nst2 <= "001";
when "001" =>
nst2 <= "101";
when "101" =>
nst2 <= "111";
when "111" =>
nst2 <= "100";
when "100" =>
nst2 <= "010";
when others =>
nst2 <= "000";
end case;
end process;
end rtl;
Violations Produced
• FSM Resets used with mixed polarity, inside architecture 'rtl'. – Violation 1
• + FSM Reset 'rst1' is used as an 'active high' reset. – Associated Violation 2
• + FSM Reset 'rst2' is used as an 'active low' reset. – Associated Violation 3
Example 3
Check mixed reset polarity for asynchronous resets.
• Disallow — Mixed Polarity of Asynchronous Resets
• Hierarchy Level — Process
Consistent Resets
Analyzed Code
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
ENTITY polarity_async IS
PORT (rst, clk : IN std_logic); –- Violation 1
END polarity_async;
ARCHITECTURE rtl OF polarity_async IS

SIGNAL cst1, nst1, cst2, nst2 : std_logic_vector (2 DOWNTO 0);
BEGIN
PROCESS (clk, rst) –- Associated Violation 2, 3
BEGIN
if (rst = '0') then
cst1<= "000";
elsif (clk'event and clk = '0') then
cst1 <= nst1;
end if;
if (rst = '1') then
cst2 <= "000";
cst2 <= nst2;
end if;
END PROCESS;
END rtl;
Violations Produced
• Reset 'rst' is used with mixed polarity, inside architecture 'rtl'. – Violation 1
• + Reset 'rst' is used as an 'active high' reset. – Associated Violation 2
• + Reset 'rst' is used as an 'active low' reset. – Associated Violation 3
Example 4
Check mixed reset polarity for synchronous resets.
• Disallow — Mixed Polarity of Synchronous Resets
Consistent Resets
Analyzed Code
module polarity_sync (din, rst, clk, dout1, dout2);
input din, rst, clk; // Violation 1
output dout1, dout2;
reg dout1, dout2;
always @(posedge clk) // Associated Violation 2

begin
if (rst == 1'b0)
dout1 <= 1'b0;
else
dout1 <= din;
end

begin
if (rst == 1'b1)
dout2<= 1'b0;
else
dout2 <= din;
end
endmodule
Violations Produced
• Reset 'rst' is used with mixed polarity, inside module 'polarity_sync'. – Violation 1
• + Reset 'rst' is used as an 'active low' reset. – Associated Violation 2
• + Reset 'rst' is used as an 'active high' reset. – Associated Violation 3
Related Topics
Controllable Resets
Controllable Resets
Checks if the reset signal is tied high (VCC) or tied low (GND) (i.e. the reset is always active or
always inactive) or is undriven. This is a design-wide check.Note that the effects of synthesis
may result in different violations from those expected from looking purely at the code. Please
see Register and Control Signal inference for more details.
Usage
Controllable Resets
Common Parameters
Disallowed Resets
Parameters
• Disallowed Resets
Specify which of fixed / undriven values are not allowed. The default is Tied High (VCC)
and Tied Low (GND).
o Tied High (VCC)
o Tied Low (GND)
o Undriven
Examples
Example 1
Rule Configuration
• Disallowed Resets — Tied High (VCC), Tied Low (GND), Undriven
Controllable Resets
Analyzed Code
module test30(input clk, rst, d, output q, q3, q2, q4);
test30_lca inst1(clk, rst, d, q, q3);
test30_lca inst2(clk, rst, d, q2, q4);
endmodule
module test30_lca(input clk, rst, d, output q, q3);

wire int_, int_2;
assign int_2 = 0;
bot2 inst2(int_2, int_); // Violation 7
bot inst(clk, int_, d, q);
bot3 inst3(clk, int_, d, q3);
endmodule
module bot(input clk, rst, d, output reg q);

if (rst)
q <= 0;
else
q <= d;
endmodule
module bot3(input clk, rst, d, output reg q);

wire set, s_rst, s_set, en; // Violation 5
assign set = 0; // Violation 1
assign s_rst = 1; // Violation 3
always @(posedge clk or posedge rst or negedge set) // Associated
Violation 2, 4, 6, 9
if (rst)
q<= 0;
else if (!set)
q <= 1;
else if (s_rst)
q <= 0;
else if (s_set)
q <= 1;
else if (en)
q <= d;
endmodule
module bot2(input in1, output out1);
assign out1 = !in1;
endmodule
Violations Produced
• Reset 'set' is tied low. –Violation 1
• Asynchronous reset 'set' of always block is tied low. – Associated Violation 2
• Reset 's_rst' is tied high. –Violation 3
• Synchronous reset 's_rst' of always block is tied high. – Associated Violation 4
• Reset 's_set' is undriven. –Violation 5
• Synchronous reset 's_set' of always block is undriven. – Associated Violation 6
• Reset 'test30_lca.inst2.in1' is tied low. –Violation 7
Controllable Resets
• Synchronous reset 'rst' of always block is tied low. – Associated Violation 8

• Asynchronous reset 'rst' of always block is tied low. – Associated Violation 9
Related Topics
Edge Detection
Edge Detection
Checks the coding style used in VHDL edge detection conditions.
Usage
Edge Detection
Common Parameters
Condition Style
Disallow Other Signals/Variables
Parameters
• Condition Style
Specify allowed edge detection condition style. The default is 'EVENT only.
o VHDL Edge Function [rising_edge(clk) or falling_edge(clk)]
o 'EVENT only [clk'event and clk='1']
o 'EVENT & 'LASTVALUE [clkÈVENT and clk=’1’ and clk`LAST_VALUE=’0’]
• Disallow Other Signals/Variables
Indicate whether the specified edge detection condition style/s may be used for any signal/
variable or must only be used for clock signals. The default is No.
o Yes [Specified edge conditions allowed for clocks only]
o No [Specified edge conditions allowed for non-clock signals]
Examples
Example 1
Analyzed Code
synch_proc: process (clk, rst)
begin
if (rst = '0') then
………
else
if (clk'event and clk = '1') then
– Use ‘EVENT and ‘LASTVALUE attributes to detect clock edges
……
end if;
end if;
end process;
Violation Produced
Use "rising_edge/falling_edge" functions to detect clock edges
Edge Detection
Tip
Use the allowed clock condition style
Related Topics
Untested Edge Trigger
Gated Clocks
Gated Clocks
Checks for the usage of gated clocks in the design. Gated clocks can cause clock skews and are
sensitive to glitches which can lead to incorrect data being registered. This is a design-wide
check.
Usage
Gated Clocks
Common Parameters
Ignore
Description
Optionally, gated clocks wherein the enable signal transitions occur only on the inactive edge of
the master clock can be ignored. For this the gated clock needs to be and-ed/or-ed with a
synchronized enable signal as shown below.
Additional Information
An asynchronously changing clock gating enable signal can cause the clock signal to get
truncated violating the setup/hold time of flip-flops or can introduce glitches in the clock signal.
To overcome this problem, it is desired that the enable signal be continuously stable around the
active edge of the used clock and change only with the inactive edge of the clock. This would
ensure that the enable signal is synchronized with the clock signal and does not truncate the
clock pulse or introduce any glitches.
The circuit of Figure 1 exactly achieves this.
Parameters
• Ignore
Specify if specific gated clock styles need to be ignored. The default is <don’t care>.
Gated Clocks
o Gated Clocks with Enable at Inactive Clock Edge

o <don’t care>
Examples
Example 1
Check for clock gating across the design.
Rule Configuration
Analyzed Code
module design_top (in1,design_clk,design_rst,design_en,out1);
input in1,design_clk,design_rst,design_en;
output wire out1;
wire rst,en;
wire [1:0] clk;
clkRstGenerator inst1(.clk(clk),.rst(rst),.en(en), // Violation
.in_clk(design_clk),
.in_rst(design_rst),
.in_en(design_en));
middle m1(in1,clk[0],rst,en,out1);
endmodule
module middle(in1,clk,rst,en,out1);
input wire in1,clk,rst,en;
output reg out1;
always @(posedge clk) // Associated Violation
if(rst)
out1<= 1'b1;
else
out1 <= in1;
endmodule
module clkRstGenerator (clk, rst, en, in_clk, in_rst, in_en);

output reg [1:0] clk;
output reg rst,en;
input wire in_clk,in_rst,in_en;
always@(in_clk,in_rst,in_en)
begin
clk[0] <= !clk[0] & in_clk;
rst <= !rst & in_rst;
en <= !en & in_en;
end
endmodule
Violations Produced
• Clock gating at ‘inst1.clk[0]’. – Violation
• The clock for synchronous block is gated. – Associated Violation
Example 2
Enable transitions not at opposing edge of clock.
Gated Clocks
Rule Configuration
• Ignore — Gated Clocks with Enable at Inactive Clock Edge
Analyzed Code
module test15(input a, b, d1, output h, output reg q, output q2, q4);
wire e;
mid1 inst1(.c(~a), .d(b), .d3(d1), .e(e), .q3(q2), .q4(q4)); //
Violation 1
mid2 inst2(.f(e), .d2(d1), .g(h));
always @(posedge e) // Associated Violation 3
q <= d1;
endmodule
module mid1(input c, d, d3, output e, output reg q3, q4);

wire nc;
assign nc = ~c;
reg dr;
always @(negedge nc)
dr <= d;
wire clk;
assign clk = nc & dr;
always @(posedge clk) begin // No Violation
q4 <= d3;
end
always @(posedge clk) begin // No Violation
q3 <= d3;
end
assign e = !clk;
endmodule
module mid2(input f, d2, output reg g);
always @(posedge f) // Associated Violation 2
g<= d2;
endmodul
Violations Produced
• Clock gating at 'inst1.e'. – Violation 1
• + The clock for synchronous block is not used at the opposite edge of that used for
enable transition. – Associated Violation 2
• + The clock for synchronous block is not used at the opposite edge of that used for
enable transition. – Associated Violation 3
Related Topics
Internally Generated Clocks

Checks for occurrences of internally generated clocks within the design and determines whether
they are isolated.
Usage
Common Parameters
Action
Description
A clock signal is considered to be internally generated if it is the output of a flip-flop. An
internally generated clock is considered to be isolated if the logic generating the clock is
confined to a dedicated design unit, the clock/reset generator. A clock/reset generator is
characterized by the following:
• All its outputs are used as clocks or resets in the design.

• At least one of the clocks is generated in the module (including its sub-hierarchy).
Based on user selection of this rule’s parameters, the tool either disallows internally generated
clocks completely or allows certain isolated internally generated clocks depending upon
whether they are:
1. Isolated at the top level

2. Isolated at the same level where they are used
3. Isolated at any level
4. Isolated at any level and routed to the top level before being used
This is a design-wide check.
Note
In case an internally generated clock is used at multiple locations, only one usage of this
clock will be highlighted.
In this section, clock generators and isolation parameters are explained in greater detail as
understood by the tool.
Clock generators and isolation

A clock generator can be hierarchical or single level. It is a dedicated design unit whose outputs
are only clocks/resets and at least one of its clock outputs is sequentially generated from within
itself (internally generated resets can be combinationally or sequentially generated). If an
internally generated clock is generated in such a design unit, it is considered to be isolated. In

the following two diagrams, the blue and the green rectangles denote design units and the red
rectangles denote flip-flops/sequential logic. The first diagram is an example of a single-level
clock generator, while the second diagram illustrates a clock generator that is composed of
hierarchies. The tool will infer the highest possible hierarchy that contains no other logic other
than clock/reset generation as the clock generator.
Isolation at top-level and routed to top

In the following diagram, since the clock generator is instantiated at the top, both internally
generated clocks are considered to be isolated at the top. Also, the registers 1, 2 and 3
(represented by red rectangles), that use the internally generated clocks, are obviously within
the hierarchy of the top-level design unit that instantiates the clock generator, and hence both
internally generated clocks are also considered to be isolated at the same level where used, for
all the usages. Finally, since the internally generated clocks are routed through the top-level,
they are also considered to be routed to top before being used.
Isolation at same level where used and routed to top

In the following diagram, the red rectangles show registers that use the same internally
generated clock from a clock generator. Since the clock generator is not at the top, the internally
generated clock is not considered to be isolated at the top. However, since the clock is generated
inside a dedicated design unit, it is isolated in general. For registers 1 and 2, the internally
generated clock is considered to be isolated at the same level where used. This is because both
registers 1 and 2 are in the sub-hierarchy of the module that instantiates the clock generator.
Additionally, for register 2, the clock is also routed to top before being used unlike for register
1. For both registers 3 and 4, the clock is not isolated at the same level where used, but it is
routed to top before use.
Parameters
• Action
Specify whether isolated internally generated clocks are allowed or not. The default is
Allow if isolated at Top-Level.
o Allow if isolated at any level
o Allow if isolated at same level where clock is used
o Allow if isolated at Top-Level
o Allow if isolated and routed to top-level
o Disallow
Examples
Example 1
Check that internally generated clocks are not used in the design.
Rule Configuration
Analyzed Code
module test2 (input a, b, output reg c);
reg clk;
always @(posedge a) // Violation
clk <= ~clk;
c<= b;
endmodule
Violations Produced
• Internally generated clock 'clk' in top design unit 'test2' is not allowed. – Violation
• + Clock 'clk' of register 'c' in top design unit 'test2' is internally generated. – Associated
Violation
Example 2
Check that internally generated clocks are not used in the design unless they are isolated and
routed to top before being used.
Rule Configuration
• Action — Allow if isolated and routed to top-level
Analyzed Code
module test5 (input a, g, h, i, output f, w);
wire c, m, n, o, c1, p;
reg r;
mid1 mid1_inst(.b(a), .j(g), .k(h),
.l(i), .c(c), .m(m), .n(n), .o(o));
mid2 mid2_inst(.d(c), .p(p), .q(n),
.r(r), .e(e), .c1(c1), .v(w));
assign p = m;
always @(posedge n)
r <= o;
assign f = c1;
endmodule
module mid1(input b, j, k, l, output reg c, output m, output n, output o);

always @(posedge b) // Violation 3
c <= ~c;
assign m = j;
wire y;
wire c1;
bot1 bot1_inst(.x(k), .y(y));
bot2 bot2_inst(.a(n), .b(o), .c1(c1),
.z(y));
assign c1 = l;
endmodule
module mid2(input d, p, q, r, output e, v, output reg c1);

assign e = d;
always @(posedge d)
c1 <= p;
bot3 bot3_inst(.s(q), .t(r), .u(v),
.b(d));
endmodule
module bot1(input x, output reg y);

always @(posedge x) // Violation 1
y <= ~y;
endmodule
module bot2(input z, c1, output a, output reg b);

assign a = z;
always @(posedge z) // Associated Violation 2
b <= c1;
endmodule
module bot3(input s, t, b, output reg u);

reg t_reg;
always @(posedge b) // Associated Violation 4
u<= t_reg;
always @(posedge s)
t_reg <= t;
endmodule
Violations Produced
• Internally generated clock 'y' in instance 'mid1.bot1_inst' is not isolated and routed to
top. – Violation 1
• + Clock 'z' of register 'b' in instance 'mid1.bot2_inst' is internally generated. –

• Internally generated clock 'c' in instance 'test5.mid1_inst' is not isolated and routed to
top. – Violation 3
• + Clock 'b' of register 'u' in instance 'test5.mid2_inst.bot3_inst' is internally generated. –
Related Topics
Gated Clocks

Checks for occurrences of internally generated resets within the design and determines whether
they are isolated.
Usage
Common Parameters
Action
Reset Style
Ignore
Description
A reset signal is considered to be internally generated if it is the output of some combinational
or sequential logic. Resets derived from top-level inputs solely through buffers or inverters are
not considered to be internally generated. An internally generated reset is considered to be
isolated if the logic generating the reset is confined to a dedicated design unit, the clock/reset
generator. A clock/reset generator is characterized by the following:
• All its outputs are used as clocks or resets in the design.

• At least one of the resets is generated in the module (including its sub-hierarchy).
Based on user selection of this rule’s parameters, the tool either disallows internally generated
synchronous or asynchronous resets completely or allows certain isolated internally generated
resets depending upon whether they are:
1. Isolated at the top level

2. Isolated at the same level where they are used
3. Isolated at any level
4. Isolated at any level and routed to the top level before being used
Refer to the Additional Information section of the Internally Generated Clocks rule for more
details on isolation. The isolation descriptions for internally generated clocks can be
equivalently applied to internally generated resets.
The default behavior of this rule is to detect internally generated resets (synchronous or
asynchronous) that are not isolated at the top level. This is a design-wide check.
An asynchronous reset release circuit Asynchronous Reset Release generates an internal reset,
and optionally such resets can be excluded from this check. Note that the effects of synthesis
may result in different violations from those expected from looking purely at the code. Please
see Register and Control Signal inference for more details.
Parameters
• Action
Specify whether isolated internally generated resets are allowed or not. The default is Allow
if isolated at top-level.
o Allow if isolated at any level
o Allow if isolated at same level where reset is used
o Allow if isolated at top-level
o Allow if isolated and routed to top-level
o Disallow
• Reset Style
Specify the style of the internally generated reset to be detected. The default is <don’t care>.
o Synchronous
o Asynchronous
o <don’t care>
• Ignore
Specify the type of internally generated resets which should be ignored. The default is
<don’t care>.
o Synchronously de-asserted asynchronous resets
o <don’t care>
Examples
Example 1
Check for synchronous internally generated resets.
Rule Configuration
• Reset Style — Synchronous
Analyzed Code
module test1(input a, b, c, clk, output l, m);
wire f;
mid1 mid1_inst(.d(a), .e(b), .f(f), .clk(clk)); // Violation
mid2 mid2_inst(.g(f), .k(c), .h(a), .i(l), .j(m), .clk(clk));
endmodule
module mid1(input d, e, clk, output f);

assign f = d & e;
endmodule
module mid2(input g, k, h, clk, output reg i, j);

if (g)
i<= 0;
else
i <= k;
if (h)
j <= 0;
else
j <= k;
endmodule
Violations Produced
• Internally generated reset 'mid1_inst.f' in top design unit 'test1' is not allowed. –
Violation
• + Synchronous reset 'g' of register 'i' in instance 'test1.mid2_inst' is internally generated.
– Associated Violation
Note
If the Reset Style parameter is set as “Asynchronous”, then the example above will not
produce violations. This is because the internally generated reset in this example is
synchronous. Also, if the Action parameter is set as “Allow if isolated at top-level”, then the
example above will again not produce violations. This is because the internally generated reset
in this example is isolated at the top level.
Example 2
Check for internally generated resets that are not isolated at the top level.
Rule Configuration
• Action — Allow if isolated at top-level
• Reset Style — <don’t care>
Analyzed Code
module test2(input a, b, f, x1, v, j, k, l, clk, output e, r, s,
output i, output reg r1);
wire c, h, q;
assign c = a & b;
mid1 mid1_inst1(.c(c), .g(f), .d(e), .h(h));
assign i = h;
always @(negedge clk)
if (h)
r1 <= 0;
else
r1 <= x1;
mid2 mid2_inst (.u(q), .t(r), .q(q), .p(s), .o(l), .n(k),
.m(j), .w(v), .clk(clk));
endmodule
module mid1(input c, g, output d, h);

assign d = c;
assign h = g;
endmodule
module mid2(input u, w, m, n, o, clk, output reg t, output p, q);

always @(posedge clk or posedge u) // Associated Violation
if (u)
t <= 0;
else
t <= w;
assign p = o;
bot bot_inst(.a1(m), .b1(n), .c1(q));
endmodule
module bot(input a1, b1, output c1);

gen gen_inst(.f1(c1), .d1(a1), .e1(b1)); // Violation
endmodule
module gen(input d1, e1, output f1);

assign f1 = d1 & e1;
endmodule
Violations Produced
• Internally generated reset 'gen_inst.f1' in instance 'mid2.bot_inst' is not isolated at the
top level. – Violation
• + Asynchronous reset 'u' of register 't' in design unit 'mid2' is internally generated. –
Associated Violation
Related Topics
Mixed Clocks Resets
Mixed Clocks Resets

Checks that the same signal is not being used both as a clock and as a reset to a flip-flop or a
latch anywhere in the design.
Usage
Mixed Clocks Resets
Common Parameters
Description
In the below diagram, top-level port In1 is being used as a reset in register F1 and as a clock in
register F2. In this case, two associated violations (represented by red arrows) are populated,
one for F1 for using In1 as a reset and the other for F2 for using In1 as a clock. The primary
violation (represented by green arrows) points to the closest point where the clock and reset
trees merge. Thus, for registers F1 and F2, the top-level port In1 is pointed to in the primary
violation. In the same way, the primary violation corresponding to registers F3 and F4 points to
port Sig1, since this is the point where the clock and reset trees for registers F3 and F4 merge.
In case a given signal is being used as a clock and/or a reset at more than one location, only one
occurrence of the signal as clock and one occurrence of the signal as reset are highlighted.
Mixed Clocks Resets
Note
The effects of synthesis may result in different violations from those expected from looking
purely at the code. Please see Register and Control Signal inference for more details.
Parameters
Examples
Example 1
Check for a signal being used as both a clock and a reset.
Rule Configuration
Mixed Clocks Resets
Analyzed Code
module top(input [16:19] a, output [11:10] q); // Violation 1
wire [4:6] w;
middle1 inst1 (.b({a[19], a[16], a[17]}), .d(w[4:5]));
middle2 inst2 (.f(w), .g(q[11]));
middle3 inst3 (.c(a[17:19]), .h({w[6], q[10]})); // Violation 4
endmodule
module middle1(input [1:3] b, output [11:10] d);

assign d[11] = b[1];
reg q;
always @(posedge b[3] or negedge b[1]) // Associated Violation 3
if (!b[1])
q <= 0;
else
q <= b[2];
assign d[10] = q;
endmodule
module middle2(input [20:22] f, output [1:1] g);

reg q;
always @(posedge f[22] or posedge f[20]) // Associated Violation 5
if (f[20])
q <= 0;
else
q <= f[21];
assign g = q;
endmodule
module middle3(input [4:6] c, output [10:9] h);

assign h[10] = c[4];
reg q;
always @(posedge c[6]) // Associated Violation 2, 6
if (c[4])
q<= 0;
else
q <= c[5];
assign h[9] = q;
endmodule
Violations Produced
• Port 'a[19]' is used both as clock and asynchronous reset. – Violation 1
• + Clock of register 'q' is used as asynchronous reset elsewhere. – Associated Violation 2
• + Asynchronous reset of register 'q' is used as clock elsewhere. – Associated Violation 3
• Port 'inst3.c[4]' is used both as clock and synchronous reset. – Violation 4
• + Clock of register 'q' is used as synchronous reset elsewhere. – Associated Violation 5
• + Synchronous reset of register 'q' is used as clock elsewhere.- Associated Violation 6
Related Topics
Multiple Clocks
Multiple Clocks
Checks if there is a single clock used inside a unit/module or always/process block. In case there
are multiple clocks at a module level, then only one of the corresponding always blocks/
processes for each clock is highlighted.
Usage
Multiple Clocks
Common Parameters
Hierarchical Level
Parameters
• Hierarchical Level
Specify which level(s) of the design to check. The default is Process/Always Block.
o Process/Always Block
o Design Unit
Examples
Example 1
Check for the usage of multiple clocks in a VHDL process.
Rule Configuration
Multiple Clocks
Analyzed Code
library ieee;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity test2 is
generic(n1: natural :=4; n2: natural :=4);
port(input : inout std_logic_vector(n1-1 downto 0);
output : out std_logic_vector(n2-1 downto 0)
);
end test2;
architecture arch of test2 is

begin
process (input(0), input(1), input(2)) begin –- Violation
if (input(2) = '0') then
output(2)<= '0';
elsif (input(0)'event and input(0) = '1') then
output(2) <= input(1);
end if;
if (input(2)'event and input(2) = '1') then
output(1) <= input(3);
end if;
end process;
end;
Violation Produced
Synchronous process block uses multiple clocks 'input(2)' and 'input(0)'.
Multiple Resets
Multiple Resets
Checks that only one reset signal is used in the specified scope. This is optionally a design-wide
check based on the parameter setting. Further, this rule also checks if separate if-conditions
have been enforced for modeling resets.
looking purely at the code. Please see Register and Control Signal inference for more details.
Usage
Multiple Resets
Common Parameters
Reset Style
Scope
Enforce Separate If Conditions
Parameters
• Reset Style
Specify reset style to check. The default is <don’t care>.
o Synchronous
o Asynchronous
o <don’t care>
• Scope
Specify which level/s of the design to check. The default is Process/Always Block.
o Process/Always Block
o Design Unit
o Entire Design
Note
Multiple reset detection depends upon the scope selected. For a process/always
block, 2 different RTL signals will be considered as multiple resets. However, it
could be possible that the 2 RTL signals are actually driven by the same signal. This will
not be detected when the visibility is restricted to process/always block. On similar lines,
multiple resets detected when “Design Unit” is selected may actually belong to the same
reset tree from a design perspective, but this will not be detected because visibility is
restricted to one design unit at a time. When “Entire Design” is selected, a violation
would be produced only if the 2 signals belong to distinct reset trees.
Multiple Resets
• Enforce Separate If Conditions

Specify whether to violate only if mixed sync/async resets are coded in the same condition.
The default is <don’t care>.
o Yes
o Only when Mixed
o <don’t care>
Note
If “Yes” is selected then a violation is produced every time a complex condition,
which can possibly be split into if-else if, is used to code a reset. “Only when mixed”
violates when a complex condition leads to inference of an asynchronous and a
synchronous reset. A <don’t care> selection does not trigger this check at all.
Examples
Example 1
Check for multiple resets in a design unit.
Multiple Resets
Analyzed Code
library ieee;
entity MultRst1 is
port (din, din2, din3, rst, rst1, rst2, clk : in std_logic;
dout, dout_2, dout_3 : out std_logic);
end MultRst1;
architecture rtl of MultRst1 is -- Violation 1

begin
begin
clk1 <= clk;
clk2 <= clk;
end process;
two_clks: process (clk1, clk2) -- Associated Violations 2, 3, 4
begin
if (rst = '1') then
dout<= '1';
else
dout <= din;
end if;
end if;
dout_2 <= '0';
else
dout_2 <= din2;
end if;
end if;
dout_3 <= '0';
else
dout_3 <= din3;
end if;
end if;
end process;
end rtl;
Violations Produced
• Multiple asynchronous resets used in architecture 'rtl'. – Violation 1
• + Reset 'rst' is one of multiple resets used in architecture 'rtl'. – Associated Violation 2
• + Reset 'rst1' is one of multiple resets used in architecture 'rtl'. – Associated Violation 3
• + Reset 'rst2' is one of multiple resets used in architecture 'rtl'. – Associated Violation 4
Example 2
Enforce separate if-conditions when resets are mixed.
Multiple Resets
Rule Configuration
• Reset Style — <don’t care>
• Scope — Design Unit
• Enforce Separate IF Conditions — Only When Mixed

Analyzed Code
module sep_if_1(input d, arst, srst, clk, output reg q);
always@(posedge clk or negedge arst)
if(!arst || srst) // Violation
q<= 0;
else
q <= d;
endmodule
Violation Produced
Separate if conditions are not used to code mixed resets.
Related Topics
Consistent Resets
Multiple Clocks
Reset Logic Function

Checks This rule checks that reset signals are only used to reset registers and latches in the
entire design and are not used in any logic function. This is a design-wide check.
Usage
Common Parameters
Description
In the below diagram, top-level port In1 is being used as a reset in register F1 and in
combinational logic C1. In this case, two associated violations (represented by red arrows) are
populated, one for using the port In1 as a reset in F1, and the other pointing to the closest port
where the signal is used in a logic function (represented by the upward pointing red arrow). The
primary violation (represented by green arrows) points to the closest point where the reset tree
merges with the path leading to the combinational logic. Thus, for register F1 and C1, the top-
level port In1 is pointed to in the primary violation. In the same way, the primary violation
corresponding to register F4 and combinational logic C2 points to port Sig1, since this is the
point where the reset tree merges with the combinational logic path.
In case a given signal is being used as a reset and/or is being used in a logic function at more
than one location, only one occurrence of the signal as reset and one occurrence of the signal in
a logic function are highlighted.
Note
purely at the code. Please see Register and Control Signal inference for more details.
Parameters
Examples
Example 1
Check that reset signals are not used for any purpose other than resetting registers or latches.
Rule Configuration
Analyzed Code
module test (input k, m, a, b, output c, d);
wire w1, w2, w3;
middle1 inst1 (.e(a), .f(b), .g(w1), .h(w2), .i(w3)); // Violation 1
middle2 inst2 (.l(k), .n(m), .j(w1), .s(c));
middle3 inst3 (.p(w2), .q(w3), .r(d)); // Associated Violation 2
endmodule
module middle1 (input e, f, output g, h, i);

assign g = e;
assign h = e;
assign i = ~f;
endmodule
module middle2 (input l, n, j, output reg s);

always @(posedge l) // Associated Violation 3
if (j)
s<= 0;
else
s <= n;
endmodule
module middle3 (input p, q, output r);

assign r = p & q;
endmodule
Violations Produced
• Port 'inst1.e' is used both in a logic function and as a synchronous reset. – Violation 1
• + Port 'inst3.p' that is used in a logic function is also used as a synchronous reset
elsewhere. – Associated Violation 2
• + Synchronous reset of register 's' is also used in a logic function elsewhere. –
Related Topics

Checks the event control logic to determine if there is a maximum of one untested edge trigger.
If there is more than one untested edge trigger, synthesis tools will not be able to infer the clock
for the always block. If there is a single untested edge trigger, this is detected as the clock.
Moreover, if all edge triggers are tested, synthesis tools pick up the last tested edge trigger as the
clock.
looking purely at the code. Please see Design Correctness and Synthesizability for more details.
Usage
Common Parameters
Parameters
Examples
Example 1
This example illustrates an untested edge trigger violation.
Rule Configuration
Analyzed Code
module untested_bad(output reg out_sig, input In_sig, clk_master, clear,
enable);
always @(negedge clk_master or negedge enable or negedge clear) //
Violation
begin : process2
if (!clear)
out_sig = 2'b0;
else
out_sig = In_sig;
end
endmodule
Violation Produced
More than one untested edge trigger. Cannot infer clock for this always statement.
Example 2
This example illustrates a scenario in which the absence of untested edge triggers will not result
in a violation.
Rule Configuration
Analyzed Code
module untested_good(output reg out_sig, input In_sig, clk_master, clear);
always @(negedge clk_master or negedge clear)
// Last tested edge trigger (clk_master) inferred as the clock, so there
is no violation
// even though there is no single untested edge trigger.
begin : process2
if (!clear)
out_sig = 2'b0;
else if(!clk_master)
out_sig = In_sig;
end
endmodule
Violation Produced
None
Related Topics
Edge Detection
Comments Base Rules
Comments Base Rules

The Comments base rules perform checks related to comments in the HDL code.

File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Statements Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Comments and Blank Lines Density

Checks for the density of comments or blank lines in the code. The rule flags violations when
the density is below the threshold chosen by the user. The check can be done for the entire
design as one whole, or per design unit.
Usage
Comments & Blank Lines Density
Common Parameters
Applies To
Density Formula
Minimum Density (%)
Count Design Unit Headers
Include File Header
Parameters
• Applies To
Specify whether the density will be checked for the whole design or per design unit. The
default is Design Unit.
o Design Unit
o Design Hierarchy
Note
Important Notes:
• When calculating the density, DesignChecker only takes into account the used
architectures of a VHDL design unit (that is, the architectures used in instantiating a
design unit). Otherwise, if there are no used architectures, then only the default
architecture is taken into account.
• If there is an Include directive inside a design unit, the lines of the included file
contribute in the calculated values of the design unit.
• Density is calculated for a package header and its body collectively.
• Density is calculated once for a design unit instantiated multiple times in the design
hierarchy and once for a package used by different design units.
• All HDL directives in the files having design units belonging to the design are
counted, except if they are inside design units that are not in the design hierarchy.
• Density Formula
Specify the formula used in calculating the comments density or blank lines density. The
default is Formula 1: Comments Lines / (Comments Lines + HDL Lines).
o Formula 1: Comments Lines / (Comments Lines + HDL Lines)
o Formula 2: Comments Lines / HDL Lines
o Formula 3: Comments Only Lines / (Comments Only Lines + HDL Lines)
o Formula 4: Comments Only Lines / HDL Lines
o Formula 5: Blank Lines / (Blank Lines + HDL Lines)
o Formula 6: Blank Lines / HDL Lines
The variables used in calculating the above formulas are defined as follows:
HDL Lines: Lines having HDL code. The HDL line may have HDL code only or HDL
code and comments.
--
-- signal declarations
--
SIGNAL: buffer_data : std_logic; -- buffer for data
SIGNAL: buffer_address : std_logic; -- buffer for address
BEGIN END ARCHITECTURE;
Comments Only Lines: Lines having only comments without any HDL code.
--
--
BEGIN
END ARCHITECTURE;
Comments Lines: Lines having comments. A comments line may be a line having HDL
code with comments or a line having comments only.
--
--
BEGIN
END ARCHITECTURE;
Blank Lines: Lines having neither HDL code nor comments. Blank lines may only have
spaces, tabs, or just a carriage return.
• Minimum Density (%)

Specify the least comments density value. If the actual comments density is below the
entered value, the rule flags violations. The default is 10.
The entered value must be a positive integer. The minimum value should be greater than
zero. The maximum value is 99 when “Formula 1”, “Formula 3” or “Formula 5” is selected
for the Density Formula parameter (since the density for these formulas cannot be
mathematically evaluated to a value greater than or equal 100).
• Count Design Unit Headers
Specify if the design unit header will contribute to the design unit's density or not. The
default is Yes.
o Yes
o No
Note
Important Notes:
• Design unit header means any commented block(s) defined before the design unit
and after a preceding design unit (if any), or after the beginning of the file (if there is
no preceding design unit).
• The header of an architecture is counted as part of the header of its entity.
• Include File Header

Specify if the file header should be counted as part of the header of the first design unit
defined in the file or not. The default is No.
o Yes
o No
o <not applicable>
Examples
Example 1
Check the comments density per design unit.
Rule Configuration
• Applies To — Design Unit
• Density Formula — Formula 1: Comments Lines / (Comments Lines + HDL Lines)
• Minimum Density (%) — 60
• Count Design Unit Headers — Yes
• Include File Header — Yes

Analyzed Code
module top_v(in1, in2, in3, out1); // Violation 1
//
// ports
//
input in1;
input in2;
input in3;
output out1;
// internal wires
wire out1_temp;
wire out2_temp;
// instance 1
and2_v and2_1(in1, in2, out1_temp);
// instance 2
// instance 3
or2_v or2_1(out1_temp, out2_temp, out1);
endmodule
module or2_v(in1, in2, out1); // Violation 2

/*
ports
*/
input in1;
input in2;
output out1;
assign out1 = in1 || in2; // output assignment

endmodule
module and2_v(in1, in2, out1); // Violation 3

/* ports */
input in1;
input in2;
output out1;
// output is in1 and in2

assign out1 = in1&& in2; // output assignment
endmodule
Violations Produced
• Module 'top_v' has comments density (44%) which is below the acceptable minimum
(60%) – Violation 1
• Module 'or2_v' has comments density (33.3%) which is below the acceptable minimum
• Module 'and2_v' has comments density (40%) which is below the acceptable minimum
Example 2
Check comments density for the design hierarchy.
Rule Configuration
• Applies To — Design Hierarchy
• Density Formula — Formula 1: Comments Lines / (Comments Lines + HDL Lines)
• Count Design Unit Headers — No
• Include File Header — not applicable>
Analyzed Code
ENTITY top IS -- Violation 1
--
-- ports
--
PORT(in1 : IN std_logic;
in2 : IN std_logic;
in3 : IN std_logic;
out1 : OUT std_logic);
END top;
ARCHITECTURE arch OF top IS

-- internal signals declarations
SIGNAL out1_temp : std_logic;
SIGNAL out2_temp : std_logic;
COMPONENT and2
PORT (
in1 : IN std_logic;
in2 : IN std_logic;
out1 : OUT std_logic
);
END COMPONENT;
COMPONENT or2
PORT (
in1 : IN std_logic;
in2 : IN std_logic;
out1 : OUT std_logic
);
END COMPONENT;
FOR and2_1 : and2 USE ENTITY and2(arch1);
FOR and2_2 : and2 USE ENTITY and2(arch2);
FOR ALL : or2 USE ENTITY or2;
-- declarations
BEGIN
-- hds hds_inst
and2_1 : and2
PORT MAP (
in1 => in1,
in2 => in2,
out1 => out1_temp
);
-- hds hds_inst
and2_2 : and2
PORT MAP (
in1 => in1,
in2 => in3,
out1 =>out2_temp
);
-- hds hds_inst
or2_1 : or2
PORT MAP (
in1 => out1_temp,
in2 => out2_temp,
out1 => out1

);
END arch;
--
ENTITY or2 IS
-- ports
in2 : IN std_logic;
END or2;
ARCHITECTURE arch OF or2 IS

BEGIN
out1<= in1 or in2; -- output assignment
END arch;
--
ENTITY and2 IS
-- ports
in2 : IN std_logic;
END and2;
ARCHITECTURE arch1 OF and2 IS

BEGIN
out1 <= in1 and in2;
END arch1;
ARCHITECTURE arch2 OF and2 IS

BEGIN
-- assignment process
PROCESS(in1, in2) -- sensitive to 2 inputs
BEGIN
-- start of process
out1 <= in1 and in2; -- output assignment
-- end of process
END PROCESS;
END arch2; -- end arch2
Violation Produced
Design hierarchy of 'top' has comments density (18.3%) which is below the acceptable
minimum (20%)
Example 3
Check the blank lines density per design unit.
Rule Configuration
• Applies To — Design Unit
• Density Formula — Formula 5: Blank Lines / (Blank Lines + HDL Lines)
• Count Design Unit Headers — Yes
• Include File Header — Yes

Analyzed Code
module top_v(in1, in2, in3, out1); // Violation 1
//
// ports
//
input in1;
input in2;
input in3;
output out1;
// internal wires
wire out1_temp;
wire out2_temp;
// instance 1
// instance 2
// instance 3
or2_v or2_1(out1_temp, out2_temp, out1);
endmodule
module or2_v(in1, in2, out1); // Violation 2

/*
ports
*/
input in1;
input in2;
output out1;
assign out1 = in1 || in2; // output assignment
endmodule
module and2_v(in1, in2, out1); // Violation 3

/* ports */
input in1;
input in2;
output out1;
// output is in1 and in2
assign out1 = in1&& in2; // output assignment
endmodule
Violations Produced
• Module 'top_v' has blank lines density (35.3%) which is below the acceptable minimum
• Module 'or2_v' has blank lines density (25%) which is below the acceptable minimum
• Module 'and2_v' has blank lines density (25%) which is below the acceptable minimum
File Header
File Header
Checks that the file header is exactly matching a predefined template and/or that the file header
contains certain information (such as the author, creation date, and so on).
The file header to be checked is the first commented block of lines which appears in the file
before any HDL code.
Usage
File Header
Common Parameters
Applies To
Fields
Allow Blank Lines
Template
Regular Expression Variables
Match Case
Allow Mismatched Whitespaces
Parameters
• Applies To
This parameter allows choosing either to run the rule on the files that contain the top units
only, non-top units or all units in the design. The default is <Top Units> and <Other Units>.
o <Top Units>
Architectures, Configurations, Entities, Modules
o <Other Units>
• Fields
This parameter allows defining the different fields that must be found as a part or section in
the file header. The default is file_info: #(comment_token)#(text)%(file_name)#(text).
o file_info: #(comment_token)#(text)%(file_name)#(text)
o <user-defined>
File Header
Note
Only selected fields are checked. Each field defines a template in a multi-line text.
The entered text may contain references to system variables in the form %(<system
variable name>) which can be substituted by the tool or it may contain references to
regular expression variables defined by the user in the “Regular Expression Variables”
parameter in the form #(<template variable name>). Fields cannot reference regular
expressions directly, it should reference them using regular expression variables.
Only the following system variables can be used:

a. %(library): The library in which the file exists.
b. %(file_name): The leaf file name.
The comment identifiers themselves (“--”, “/*”, or “*/” for VHDL, “//”, “/*”, or “*/” for
Verilog) must be included in the template text (or via a referenced template variable) in the
way they should appear in the header.
A block of template lines can be marked to be repeated as follows:
o Block repeated 0 or 1 time: block starts with ??< and ends with ??>
o Block repeated 0 or more times: block starts with **< and ends with **>
o Block repeated 1 or more times: block starts with ++< and ends with ++>
The block start and end delimiters must appear alone in a line and must be at the beginning
of that line.
The following example shows that “--” line may be repeated one or more times in the
header.
-- Copyright 2009
++<
--
++>
-- This source file may be used and distributed without restriction.
Nested blocks and empty blocks are not allowed.

• Allow Blank Lines
Specify whether blank lines are allowed in the file header or not. The default is No.
o Yes
o No
File Header
Note
Important notes:
• An error message is displayed if “Template” parameter is set to contain blank lines
while “Allow Blank Lines” parameter is set to “No”.
• A warning message is displayed if the “Allow Blank Lines” parameter is set to “No”
while “Template” parameter contains blank lines.
• Template
This is a multi-line parameter which allows entering the template text that should be exactly
matched with the file header (not only matched with part of the file header). Like the
“Fields” parameter, the entered text may contain references to system variables in the form
%(<system variable name>) which is substituted by the tool, or it may contain references to
regular expression variables defined by the user in the “Regular Expression Variables”
parameter in the form #(<template variable name>). Please refer to the supported system
variables table in the Fields section.
In addition, this parameter can reference a field defined in the “Fields” parameter in the
form &(<field name>). References to fields must appear in separate lines with no preceding
or following text in the same line; however they can be enclosed by a repeated block. The
default is <none>.
o <user-defined>
o <none>
• Regular Expression Variables
This parameter allows defining regular expression variables to be referenced in the “Fields”
or “Template” parameters to allow creating complex header templates. The default is
comment_token="--|//", text=".*" and year="[0-9]{4}"
o <none>
o comment_token="--|//"
o text=".*"
o year="[0-9]{4}"
o <user-defined>
Each variable is entered as a string value in the form <variable name>=”<variable value>”
where <variable name> is a string and <variable value> is any regular expression value.
Variable names are case insensitive. A variable name must start with an alphabetic
character. The rest of the variable name can contain alphanumeric characters or underscores.
File Header
• Match Case
Specify whether the matching between the file header and the template should be case-
sensitive or not. The default is No.
o “Yes” means that the file header matching with the template is case-sensitive.
o “No” means that the file header matching with the template is case-insensitive.
• Allow Mismatched Whitespaces
Specify whether mismatched whitespaces are allowed or not (that is, whitespaces that are
not identical in the file header and the template). The default is Yes.
o “Yes” means that the lines of the file header may contain different number and type
of whitespaces than those in the defined template. Different number means that a
single whitespace in the file header can match one or more whitespaces in the
defined template and vice versa. Different type means that a “Space” (or more) for
example in the file header can match a “Tab” (or more) in the defined template.
o “No” means that whitespaces in the lines of the file header must be exactly the same
in number and type as those in the lines of the defined template.
Examples
Example 1
Check the file header.
Rule Configuration
• Applies To — <Top Units>, <Other Units>
• Fields —
Copyrights:
-- COPYRIGHT (c) #(company), #(year)
-- The copyright to the document herein is the property of
#(company).
--
-- All rights reserved.
Author:
-- Author: #(name)
-- Created: #(date_time)
??<
-- Revision date: #(date)
??>??<
-- Revised by: #(name)
??>
File Header
Description:
-- Description:
--
++<
-- #(text)
++>
Dialect:
-- VHDL Dialect: #(dialect)
• Template —
-------------------------------------------------------------------
&(copyrights)
-------------------------------------------------------------------
&(author)
--
-------------------------------------------------------------------
&(description)
--
-------------------------------------------------------------------
&(dialect)
--
-------------------------------------------------------------------
• Regular Expression Variables — company="ABC", name=".* .*", dialect="VHDL

'87|VHDL '93", date="[0-9]{2}-[0-9]{2}-[0-9]{4}", date_time="[0-9]{2}-[0-9]{2}-[0-
9]{4} [0-9]{2}:[0-9]{2} "
• Match Case — No
• Allow Mismatched Whitespaces — Yes
File Header
Analyzed Code
--------------------------------------------------------------------
-- COPYRIGHT (c) ABC, 2009
-- The copyright to the document herein is the property of ABC.
--
-- All rights reserved.
--------------------------------------------------------------------
--
-- Author: User
-- Created: 05-01-2009 13:24
-- Revision date: 14-07-2009
--
--------------------------------------------------------------------
-- Description:
--
-- This is the top design unit of the whole design hierarchy.
-- It mainly instantiates the sub-components.
--
--------------------------------------------------------------------
-- VHDL: VHDL '93
--
--------------------------------------------------------------------
ENTITY top IS
END ENTITY top;

BEGIN
END ARCHITECTURE rtl;
Violations Produced
• File header does not match the defined template. – Violation
• File header does not contain defined fields. – Violation
• + File header does not contain 'dialect' field. – Associated Violation
Statements Comments
Statements Comments
Checks the existence of comments for specific types of statements. Adding comments to the
HDL code is important for maintainability. This rule can be configured to control which
statements are to be checked and to specify the allowed locations which can have comments.
Usage
Statements Comments
Common Parameters
Applies To
Comments Location
Parameters
• Applies To
Specify the type of statements that must have comments. The default is <statements> and
<declarations>.
o <statements>
<blocks>: Always Blocks [Verilog Only], Functions, Initial Blocks [Verilog Only],
Procedures [VHDL Only], Processes [VHDL Only], Tasks [Verilog Only], VHDL
Blocks [VHDL Only]
Concurrent Assignments [VHDL Only]
Continuous Assignments [Verilog Only]
Instances [Component Instances]
o <declarations>
Constants [VHDL Only]
Internal Nets [Verilog Only – Net declarations which are not ports.]
Internal Regs [Verilog Only – Reg declarations which are not ports.]
Parameters [Verilog Only]
Ports: Block Ports, Component Ports, Entity Ports, Module Ports [In Verilog, a port
may have comments for the port name in the port list or for the port IO declaration
(see Example 1).]
Signals [VHDL Only]
Subtypes [VHDL Only]
Types [VHDL Only]
Variables [VHDL Only]
• Comments Location
Specify the allowed locations that can have a comment for a statement. It is acceptable to
have comments at “any” of the specified locations. Empty comments which do not contain
Statements Comments
any text are not considered as actual comments. The default is Above a group of similar
statements, Above the statement and End of statement line.
o Above a group of similar statements
o Above the statement
o End of statement line
“Above a group of similar statements” indicates that a comment must appear above each
group of statements of the same type (such as concurrent assignments). A group of
statements is defined as a set of statements of the same type existing in a continuous set of
lines. The group is broken if there are blank lines or a statement of a different type. The
comment should appear above the first statement in the group (see the details below on the
parameter value “Above the statement”). This value is not applicable to the “<blocks>”
value in the “Applies To” parameter since it is recommended that each block should have a
separate comment describing it. Example of a group of similar statements broken by a blank
line:
-- Group comment of signal declarations ‘x’, ‘y’ but not ‘z’.
SIGNAL x : std_logic;
SIGNAL y : std_logic;
SIGNAL z : std_logic;
Example of a group of similar statements broken by a different type:

-- Group comment of signal declarations ‘x’, ‘y’ but not ‘z’.
SIGNAL y : std_logic;
CONSTANT c : std_logic := ‘1’;
SIGNAL z : std_logic;
“Above the statement” indicates that a comment must appear above each statement. The
comment above a statement is defined as the continuous set of comments starting in the
preceding lines of the statement (not the same statement line). There may exist at most one
blank line between the end of this set of comments and the beginning of the statement.
Example:
-- This line is not part of signal declaration ‘x’ comment.
-- First line of comment of signal declaration ‘x’.
-- Second line of comment of signal declaration ‘x’.
“End of statement line” indicates that a comment must appear at the end of the last line of
the statement. This value is not applicable to the “<blocks>” value in the “Applies To”
parameter since it is recommended that block statements have comments above the
statement describing the block and not at the end of the statement. Example:
SIGNAL x : std_logic; -- End of line comment.
Statements Comments
Examples
Example 1
Check that there are comments above ports and statement blocks.
Rule Configuration
• Applies To — <blocks>, Ports
• Comments Location — Above the statement

Analyzed Code
module statements_comments (in1, // Violation 1
in2,
/* input 3 */
in3,
out1); // Violation 2
input in1; /* input 1 */

// input 2
input in2;
input in3;
output out1;
reg out1;
reg tmp;
// comment for "Temporary_Output" block
always @(in1, in2)
begin : Temporary_Output
tmp = in1 && in2;
end
// comment too far (more than one line) from "Final_Output" block
always @(tmp, in3) // Violation 3
begin : Final_Output
out1 = tmp&& in3;
end
endmodule
Violations Produced
• No comments found at specified locations for port declaration 'in1 – Violation 1
• No comments found at specified locations for port declaration 'out1' – Violation 2
• No comments found at specified locations for always block 'Final_Output' – Violation 3
Statements Comments
Note
Note the following in Example 1:
• Port “in1”: A violation is flagged. This object only has an end-of-line comment at port
IO declaration.
• Port “in2”: No violations are flagged. This object has a comment above the IO
declaration.
• Port “in3”: No violations are flagged. This object has a comment above the port name in
the ports list.
• Port “out1”: A violation is flagged. This object does not have any comments.
• Always Block “Temporary_Output”: No violations are flagged. This object has a
comment above the block.
• Always Block “Final_Output”: A violation is flagged. This object does not have a
comment (the comment line is too far from the always block).
Related Topics
File Header
Complexity Base Rules
Complexity Base Rules

The Complexity base rules checks for coding styles that may cause the design to be complex.
FSM Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Nesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Number of Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Type Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
FSM Complexity
FSM Complexity
Checks the maximum and/or minimum no. of FSMs/FSM states within the selected scope. This
is optionally a design-wide rule.
looking purely at the code.
Usage
FSM Complexity
Common Parameters
Object
Scope
Maximum
Minimum
Parameters
• Object
Specify the object to which the check applies. The default is FSMs.
o FSMs
o FSM States
• Scope
Specify the scope to which the check applies. The default is Design Unit.
o Entire Design
o Design Unit
o FSM
• Maximum
Specify the maximum number of objects allowed in the selected scope. The default is 50.
o <user-defined>
o <don’t care>
• Minimum
Specify the minimum number of objects allowed in the selected scope. The default is <don’t
care>.
o <user-defined>
FSM Complexity
o <don’t care>
o 0
Examples
Example 1
Check for FSMs in the entire design.
Rule Configuration
• Object — FSMs
• Scope — Entire Design
• Maximum — 2
• Minimum — <don’t care>
FSM Complexity
Analyzed Code
module top (clk, rst, enb); // Violation
input clk, enb, rst;
mid1 inst1 (clk, rst, enb);
endmodule
module mid1(clk, rst, enb);

parameter [2:0]
s0 = 3'h0, s1 = 3'h1, s2 = 3'h2, s3 = 3'h3,
s4 = 3'h4, s5 = 3'h5, s6 = 3'h6, s7 = 3'h7;
reg [2:0] cst, nst;
always @(posedge clk or posedge rst)
begin
if(rst) cst<= 0;
else
casex (cst)
s0: cst <= s1;
s1: cst <= s2;
s2: cst <= s3;
s3: cst <= s4;
s4: cst <= s5;
s5: cst <= s6;
s6: cst <= s7;
default: cst <= s0;
endcase
end
endmodule

parameter [2:0]
s0 = 2'h0, s1 = 2'h1, s2 = 2'h2, s3 = 2'h3;
reg [1:0] cst, nst;
begin
if(rst) cst <= 0;
else
casex (cst)
s0: cst <= s1;
s1: cst <= s2;
s2: cst <= s3;
default: cst <= s0;
endcase
end
endmodule

parameter [2:0]
s0 = 2'h0, s1 = 2'h1, s2 = 2'h2, s3 = 2'h3;
reg [1:0] cst, nst;
begin
if(rst) cst <= 0;
FSM Complexity
else
casex (cst)
s0: cst <= s1;
s1: cst <= s2;
s2: cst <= s3;
default: cst <= s0;
endcase
end
endmodule

parameter [2:0]
s0 = 2'h0, s1 = 2'h1, s2 = 2'h2, s3 = 2'h3;
reg [1:0] cst, nst;
begin
if(rst) cst <= 0;
else
casex (cst)
s0: cst <= s1;
s1: cst <= s2;
s2: cst <= s3;
default: cst <= s0;
endcase
end
endmodule
Violation Produced
Number of FSMs in entire design is 3 which violates a maximum limit of 2.
Example 2
Check for FSM states in an FSM.
Rule Configuration
• Object — FSM States
• Scope — FSM
• Maximum — 4
• Minimum — 2
FSM Complexity
Analyzed Code
module top (clk, rst, enb);
endmodule

parameter [2:0]
s0 = 3'h0, s1 = 3'h1, s2 = 3'h2, s3 = 3'h3,
s4 = 3'h4, s5 = 3'h5, s6 = 3'h6, s7 = 3'h7;
reg [2:0] cst, nst;
begin
if(rst) cst <= 0;
else
casex (cst) // Violation 1
s0: cst <= s1;
s1: cst <= s2;s2: cst <= s3;
s3: cst <= s4;
s4: cst <= s5;
s5: cst <= s6;
s6: cst <= s7;
default: cst <= s0;
endcase
end
begin
if(rst) nst <= 0;
else
casex (nst) // Violation 2
s0: nst<= s1;
s1: nst <= s2;
s2: nst <= s5;
s5: nst <= s6;
s6: nst <= s7;
default: nst <= s0;
endcase
end
endmodule
Violations Produced
• Number of states in FSM with state variable 'cst' is 8 which violates a maximum limit of
4. – Violation 1
• Number of states in FSM with state variable 'nst' is 6 which violates a maximum limit of
4. – Violation 2
Related Topics
FSM Transitions
Number of Objects
Nesting
Nesting
Checks that a specified maximum nesting depth and format for specified constructs is followed.
Controlling the nesting depth and format improves readability and reduces complexity. This is a
design-wide check.
Usage
Nesting
Common Parameters
Applies To
Maximum Nesting Level
Maximum Indentation Level
Indentation Style
Parameters
• Applies To
Specify to which construct/s the check applies. The default is ìfdef Constructs and
Sequential Statements.
o [VHDL only]
VHDL Blocks [nested VHDL blocks], Packages [nested packages eg pkgA "uses"
pkgB]
o [Verilog only]
ìfdef Constructs [nested Verilog ìfdef/ìfndef directives], Event control in tasks
[nested event control statements in a Verilog task], Conditional Operators [nested
conditional operators A?B:C]
o [Common]
If Constructs [nested if statements], Case Constructs [nested case statements], Loop
Constructs [nested loop statements], Sequential Statements [any kind of nested
sequential statements (including assignments & procedural blocks) within in any
sequential or procedural blocks], Design Hierarchy [hierarchy depth]
• Maximum Nesting Level
Specify the maximum allowed number of nested levels. Note that the second occurrence
counts as nesting level 1. The default is 3.
o <user-defined>
o <don’t care>
Nesting
• Maximum Indentation Level

Specify the maximum allowed levels of indentation. The default is <don’t care>.
o <user-defined>
o <don’t care>
o 10
• Indentation Style
Specify an indentation as a step (single space) or a tab. The default is Step.
o Step
o Tab
In case multiple “Applies To” values are selected, the nesting level is incremented for any of the
selected “Applies To” values. So, if “If Constructs” and “Loop Constructs” are selected, then a
loop statement inside a case statement will be considered as having nesting level 2, rather than
1.
A primary violation is produced at the point at which the threshold is exceeded, and associated
violations are produced at all relevant leaf-level constructs. Consider the following structure of
a design unit for the given code snippet.
when "01" =>
for i in 0 to 2 loop
for in1 in 0 to 7 loop
temp1(in1) := in2(in1) xor in3(in1);
delay := 0;
for in2 in in2'range loop
delay := delay + 1;
for in2 in 0 to 7 loop
delay := delay + 1;
end loop ;
end loop;
end loop;
end loop ;
Nesting
A primary violation would be populated corresponding to the green oval (the point at which the
threshold is exceeded), and associated violations would be populated corresponding to the
orange ovals (leaf-level constructs).
Examples
Example 1
Check the nesting depth does not exceed 1.
Rule Configuration
• Applies To — If Constructs
• Maximum Nesting Level — 1
• Maximum Indentation Level — <don’t care>
• Indentation Style — Step
Nesting
Analyzed Code
module nesting;
wire w1, w2, w3, w4;
always begin
if(w1) begin
if(w2) begin
if(w3) begin // Violation
if(w4) begin // Associated Violation
end
end
end
end
end
Violations Produced
• Unresolved multiple drivers detected on signal ‘a3’. – Violation
• + Multiple drivers for signal ‘a3’ assigned concurrently. – Associated Violation
Example 2
Check the nesting depth and indentation does not exceed 1.
Rule Configuration
• Applies To — If Constructs
• Maximum Nesting Level — 1
• Maximum Indentation Level — 1
• Indentation Style — Step
Nesting
Analyzed Code
library ieee;
entity nested2 is
port (in1, in2, in3, in4 : in std_logic_vector(3 downto 0);
out1 : out std_logic_vector(3 downto 0));
end;
architecture arch of nested2 is

begin
indented_if: process(in1, in2, in3)
begin
if(in1(1 downto 0) ="00") then -- Violation 1
if (in1(3 downto 2) = "01") then -- Violation 2
if (in2(1 downto 0) = "10") then -- Violation 3, Violation 4
if (in3(3 downto 2) = "00") then -- Associated Violation 5,
Violation 8
out1<= in4;
end if;
end if;
end if;
end if;
end if;
end if;
end process;
end;
Violations Produced
• An if statement is indented 2 levels, which exceeds the maximum of 1 – Violation 1
• Nesting at an if statement exceeds the maximum of 1 – Violation 4
• + An if statement has 5 levels of nesting – Associated Violation 5
Note
Do not use too many levels of nesting in constructs to simplify HDL code.
Number of Objects
Number of Objects
Checks the maximum and/or minimum number of objects within a given scope. This is
optionally a design-wide check depending on the chosen parameter settings.
Usage
Number of Objects
Common Parameters
Objects
Scope
Maximum
Minimum
Parameters
• Objects
Specify to which objects within the specified scope the check applies. The default is HDL
Statements.
o VHDL
Processes, Generics, ENUM Literals, Subtypes, Architectures, Entities,
Configurations, Packages, when…else Branches
o Verilog
Modules, Module Parameters, Includes [Number of ìncluded files], Define Includes
[Number of ìncluded files containing `define statements], References to Same
Include File [Number of references to the same include file]
o Common
HDL Lines, HDL Statements, Ports, Input Ports, Output Ports, InOut Ports, Design
Units, Case Branches
• Scope
Specify the scope to which the check applies. The default is <Design Units>,
<Subprograms>, Process, Block, Always Block and Initial Block.
o VHDL
Entity (Functional), Entity (Structural), Architecture (Functional), Architecture
(Structural), Configuration, Component, Package Header, Package Body, Process,
Function, Procedure, Block, Enumerated Type, Conditional Signal Assignment
o Verilog
Module (Functional), Module (Structural), Always Block, Initial Block, Task
Number of Objects
o Common
Entire Design, <Design Units>, <Subprograms>, File, FSM, Case Statement
• Maximum
Specify the maximum allowed number of specified objects within the specified scope. The
default is 50.
o <user-defined>
o <don’t care>
• Minimum
Specify the minimum allowed number of specified objects within the specified scope. The
default is <don’t care>.
o <don’t care>
o 0
Note
Selecting a value in the Objects parameter updates the possible values of the Scope
parameter with values applicable to the selected objects.
Examples
Example 1
ENTITY uart_top IS
PORT(
-- 3-bit address bus
addr : IN std_logic_vector (2 DOWNTO 0);
clk : IN std_logic;
cs : IN std_logic;
datin : IN std_logic_vector (7 DOWNTO 0);
nrw : IN std_logic;
rst : IN std_logic;
sin : IN std_logic;
datout : OUT std_logic_vector (7 DOWNTO 0); -
int : OUT std_logic;
sout : OUT std_logic
);
Violation Produced
Entity “uart_top” has 7 input ports which exceeds a maximum of 4
Example 2
Check the minimum number of objects within a Case Statement.
Rule Configuration
• Objects — Case Branches
Number of Objects
• Scope — Case Statement
• Maximum — <don’t care>
• Minimum — 7
Analyzed Code
module fsm18 (clk);
input clk;
parameter [2:0] s0 = 3'h0, s1 = 3'h1, s2 = 3'h2, s3 = 3'h3,
s4 = 3'h4, s5 = 3'h5, s6 = 3'h6, s7 = 3'h7;
reg [2:0] cst;

case (cst) // violation
s0: begin
cst<= cst+1;
end
s1: begin
cst <= cst + 1;
end
s2, s3: begin
cst <= cst + 1;
end
default:
cst <= 0;
endcase
endmodule
Violation Produced
Case statement has 4 case branches which falls below the minimum limit of 7.
Example 3
Check the maximum/minimum number of objects within a Conditional Signal Assignment.
Rule Configuration
• Language — VHDL
• Objects — when… else Branches
• Scope — Conditional Signal Assignment
• Maximum — 5
• Minimum — 2
Number of Objects
Analyzed Code
LIBRARY IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.Numeric_Std.all;
ENTITY top IS
PORT (data_out : out std_ulogic_vector(7 downto 0));
END top;
SIGNAL next_state_s : integer range 1 to 8;
BEGIN
data_out <= "00000001" when (next_state_s = 1) else --Violation
"00000011" when (next_state_s = 2) else
"11111111";
END arch;
Violation Produced
Conditional signal assignment has 8 branches which exceeds the maximum 5.
Note
Number of objects should not exceed the recommended maximum for a given scope.
Type Conversion
Type Conversion
Checks the maximum number of type conversions within a given scope, and makes sure they
adhere to a specified format.
Usage
Type Conversion
Common Parameters
Scope
Applies To
Name Pattern
Maximum
Allowed Forms
Parameters
• Scope
Specify the scope to which the check applies. The default is <Design Units>.
o <Design Units>
Architecture (Functional), Architecture (Structural), Entity (Functional), Entity
(Structural), Module (Functional), Module (Structural), Package body, Package
header
o <Subprograms>
Function, Procedure, Task
o <Blocks>
Always Block, Block, Generate, Initial Block, Process
• Applies To
Specify whether the check applies to declarations of Type Conversion Functions or
references (calls) to Type Conversion Functions. The default is References.
o Declarations [Type Conversion Function declarations]
o References [Calls to Type Conversion Functions]
Note
Type conversion declarations and references should not exceed the recommended
maximum for a given scope.
Type Conversion
• Name Pattern
Specify naming patterns for type conversion functions and/or type conversion expressions.
The naming pattern can be specified in any of the following formats
a. <library>.<package>.<conversion regular expression>
b. <package>.<conversion regular expression>
c. <conversion regular expression>
The default is \\$rtoi, \\$itor, \\$realtobits, \\$bitstoreal, ^TO_ and ^CONV_.
o <IEEE NUMERIC_STD Conversions>
o <IEEE NUMERIC_SIGNED Conversions>
o <IEEE NUMERIC_UNSIGNED Conversions>
o <IEEE STD_LOGIC_1164 Conversions>
o <IEEE STD_LOGIC_ARITH Conversions>
o <IEEE STD_LOGIC_SIGNED Conversions>
o <IEEE STD_LOGIC_UNSIGNED Conversions>
o \\$rtoi
o \\$itor
o \\$realtobits
o \\$bitstoreal
o ^TO_
o ^CONV_
o <user-defined>
• Maximum
Optionally specify the maximum allowed number of type conversion functions within the
specified scope. The default is <don’t care>.
o <don’t care>
o 0
• Allowed Forms
Optionally check if the Type Conversion is performed in a single, separate assignment eg
conv_val <= to_integer(val). The default is Isolated in a Single Assignment.
o <don’t care>
o Isolated in a Single Assignment
Type Conversion
Note
Expected Violations:
• The number of referenced type conversions inside architecture "rtl" is 5, which
exceeds a maximum of 2.
• Type conversion "TO_INTEGER" is not isolated within a single assignment
statement.
Condition Base Rules
Condition Base Rules

The Condition base rules perform checks related to the condition of a conditional statement.
Logical and Bitwise Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Non-Unrollable Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Scalar Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Logical and Bitwise Operators

Checks for the correct usage of the Verilog Logical and Bit-wise operators. Logical operators
(‘&&’, ‘||’ and ‘!’) should be used to join expressions and result is ‘1’, ‘0’ or ‘X’. Bit-wise
operators (‘&’,’|’ and ‘~’) perform the operation of each individual bit in one operand with the
corresponding bit in the other operand.
Usage
Common Parameters
Parameters
Examples
Example 1
assign out = (in & en) && (en & in);
// Do not use logical operators: ‘&&’, ’||’ and ’!’ in assignment
statements
Violation Produced
Do not use "bitwise" operators: "&" in "conditions"
Non-Unrollable Loops
Checks for the usage of non-unrollable loops, since they are not synthesizable. Synthesis tools
typically unroll loops to a limit, and if the loop is still not terminated, it is considered to be non-
unrollable. For DesignChecker, this limit is 5000 iterations.
Usage
Common Parameters
Parameters
Examples
Example 1
Check for the usage of non-unrollable For loops.
Rule Configuration
Analyzed Code
module nonunroll(output reg [255:0] local1, local2,
input [31:0] in1, in2, input [255:0] data);
reg [31:0] index;
integer j, k;
always @ (in1 or in2)

begin
index = in2;
for (j = 0; j < in1[7:0]; j = j + 1) // Not a violation because though
the loop index is non-constant, it can be unrolled a maximum of 256 times.
local1[j] = data[j];
for (k = 0; k < index; k = k + 1) // Violation
local2 [k % 255] = 1'b1;
end
endmodule
Violation Produced
Loop is non-unrollable.
Related Topics
Scalar Conditions
Scalar Conditions
Checks that all Verilog scalar conditions (if, for, while, ternary operator, etc.) result in a 1-bit
value allowing them to be treated as Boolean, thus simplifying the condition expression. For
example “if(cs && ena)”.
Usage
Scalar Conditions
Common Parameters
Parameters
Examples
Example 1
Checks for non-scalar conditions.
Rule Configuration
Analyzed Code
module test;
logic out;
logic clk;
class myclass;
logic a;
logic b;
endclass
myclass cond1;
typedef struct packed {
bit a;
logic b;
}mystructType;
mystructType cond2;
if(cond1) // Violation 1
out = cond2 ? 4 : 5; // Violation 2
endmodule
Violations Produced
• Condition "cond1" must be an expression that results in a 1-bit value. – Violation 1
• Condition "cond2" must be an expression that results in a 1-bit value. – Violation 2
Example 2
Checks for non-scalar conditions.
Scalar Conditions
Rule Configuration
Analyzed Code
program test;
logic inp;
integer out;
function logic[2:4] myfunction(logic inp);

myfunction = inp;
endfunction
initial begin
if(myfunction(inp)) // Violation
out = 2;
end
endprogram
Violation Produced
Condition "myfunction(inp)" must be an expression that results in a 1-bit value.
Related Topics
Allowed Operators
Configuration Base Rules
Configuration Base Rules

The Configuration base rules perform checks related to VHDL Configurations.
VHDL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
VHDL Configurations
VHDL Configurations
Checks a number of aspects of the coding style used for VHDL Configurations. The parameters
allow the tool to check in which circumstances a configuration should be used, whether to use
in-line specifications or separate declarations and whether generics should be mapped within
the configuration. This is a design-wide check.
Usage
VHDL Configurations
Common Parameters
Required
Default Binding
Style
Map Generics
Parameters
• Required
Specify under which circumstances a Configuration is required. The default is Only If > 1
Architecture.
o Always
o Only If > 1 Architecture
o <don’t care>
• Default Binding
Specify is default binding is allowed. The default is Allowed For Gate Level Only.
o Not Allowed
o Allowed For Gate Level Only
o <don't care>
• Style
Specify which style of configuration to use. The default is Configuration Declaration.
o In-Line Specification
o Configuration Declaration
o <don't care>
VHDL Configurations
• Map Generics
Specify if Generics should be mapped within the configuration. The default is Always.
o Always
o <don't care>
Examples
Example 1
configuration top_cfg of top_entity is
for rtl
-- Separate specification used to configure components inside
-- architecture “rtl” instead of “inline” configuration
end for;
end top_cfg;
Violations Produced
• Mapped Generics
Entity "mydesign" has generics: "delay1, delay2", that are not mapped within the
configuration specification of "inst1: mydesign_comp"
[+] Associated Messages:
Entity "mydesign" bound to component "mydesign_comp""
• Embedded vs Separate Configuration
Embedded" specification used to configure components inside architecture "rtl" instead
of "separate configuration"
• Configuration Required for Multiple Architectures
No configuration created for the multi-architecture entity "top"
• Default Configuration
Component Instantiation "inst1: comp" has no primary binding indication, default
binding will be applied
Dead Logic Base Rules
Dead Logic Base Rules

The Dead Logic base rules check for written code that does not have impact in the design.
Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undriven and Unused Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Reachability
Reachability
Checks for any blocks of code which are unreachable in a design unit. The check is based on all
instantiations of the module in the design. Any block of code which can be potentially reached
for any of the instantiations of the module will not be reported.
The rule can optionally ignore unreachable defaults of a case statement wherein all possibilities
have been explicitly covered. The rule can also report IF statement conditions that are always
true.
Usage
Reachability
Common Parameters
Detect
Ignore
Parameters
• Detect
Specify which of the reachability checks to perform. The default is Unreachable Blocks.
o Always True Conditions
o Always True Sub-Conditions
o Unreachable Blocks
• Ignore
Specify the types of unreachable blocks to ignore. The default is <none>.
o Unreachable others/default when all case choices are covered
o Unreachable others/default altogether
o <none>
Examples
Example 1
Check for unreachable blocks in parameterized modules.
Rule Configuration
• Detect — Unreachable Blocks
Reachability
• Ignore — <none>
Analyzed Code
module top (input [3:0] in1, in2, input sel1, sel2, output [3:0] out1,
out2);
middle #(.p1(3)) inst1 (in1, sel1, out1);
middle #(.p1(5)) inst2 (in2, sel2, out2);
endmodule
module middle (input [3:0] in1, input sel, output reg [3:0] out1);
parameter p1 = 0;
always @(in1 or sel)
begin
if(sel)
out1 = 4’b0000;
else if(p1 == 5) // Reachable within inst2
out1 = 4’b1010;
else if (p1 > 2)
out1 = in1;
else
out1 = 4’b1111; // Violation - Unreachable across all instances
of middle
end
endmodule
Violation Produced
Block of code is unreachable in design.
Example 2
Check for always true if conditions.
Rule Configuration
• Detect — Always True Conditions
Reachability
Analyzed Code
LIBRARY ieee;
ENTITY Reachability_AlwaysTrue IS
sel : IN std_logic;
END ENTITY Reachability_AlwaysTrue;
--
ARCHITECTURE arch OF Reachability_AlwaysTrue IS
BEGIN
PROCESS
BEGIN
IF sel <= '1' THEN -- violation
out1<= in1;
ELSE
out1 <= NOT in1;
END IF;
END PROCESS;
END ARCHITECTURE arch;
Violation Produced
Condition is always true.
Example 3
Check for always true if sub-conditions
Rule Configuration
• Detect — Always True Sub-Conditions
Reachability
Analyzed Code
LIBRARY ieee;
ENTITY Reachability_SubCond IS
in2 : IN std_logic;
END ENTITY Reachability_SubCond;
--
ARCHITECTURE arch OF Reachability_SubCond IS
BEGIN
PROCESS
BEGIN
IF (in1 = '0' AND in2 >= '0') THEN -- violation
out1<= '0';
ELSE
out1 <= '1';
END IF;
END PROCESS;
Violation Produced
Expression "(in2>='0')" is always true.
Related Topics
Undriven and Unused Logic

Checks whether there is undriven or unused logic in the design. All state points (registers/
latches) which drive unused logic are also flagged, since these are also part of dead logic. Please
note that nets which are neither driven nor used (i.e., just declared but not referenced anywhere)
are not violated for by this rule.
Usage
Undriven & Unused Logic
Common Parameters
Check For
Check Partial Buses
Parameters
• Check For
Specify whether the rule should detect undriven and/or unused logic in a design unit. The
default is Undriven Logic and Unused Logic.
o Undriven Logic
o Unused Logic
• Check Partial Buses
Specify whether violations are to be produced for partially violating buses (e.g. a bus
wherein some bits are undriven/unused). The default is Yes.
o Yes
o No
Examples
Example 1
Check for undriven and unused logic in the design.
Rule Configuration
• Check For — Undriven Logic, Unused Logic
• Check Partial Buses — Yes
Analyzed Code
module Unused1 (input wire [3:0] in1, input clk, rst, output reg [3:0]
out1, output out2);
reg hanging1, hanging2;
reg reg0, reg1, reg2, reg3, reg4, reg5, reg6;
wire hanging3; // Violation 8
assign out2 = hanging3;
begin
if (rst)
reg0 <= 0;
else
reg0 <= in1[0];
end
begin
if (rst)
reg1 <= 0;
else
reg1 <= in1[1];
end
begin
if (rst)
reg2 <= 0;
else
reg2 <= in1[2];
end
begin
if (rst)
reg3 <= 0;
else
reg3 <= in1[3];
end
always@(posedge clk) // Associated Violation 2, 3, 6, 7

begin
reg4 <= in1[0];
reg5 <= in1[1];
end
always@(*)
begin
hanging1 <= reg4 & reg5; // Violation 1
hanging2 <= ~reg6; // Violation 4
end
always@(posedge clk) // Associated Violation 5

begin
if (rst)
reg6<= 0;
else
reg6 <= reg4 | reg5;
end
begin
out1[0] <= reg0;
out1[1] <= reg1;
out1[2] <= reg2;
out1[3] <= reg3;
end
endmodule
Violations Produced
• Net 'hanging1' is unused. – Violation 1
• + Logic driving 'reg4' is unused. – Associated Violation 2
• Net 'hanging2' is unused. – Violation 4
• Net ‘hanging3’ is undriven. – Violation 8
Note
The violations produced do not point to the declarations of unused signals, but rather point
to the location where these signals are driven. As shown in Example 1, for registers, the
location where the signal is driven is that of its corresponding always block.
Example 2
Another example is illustrated in the following figure.
As seen from the figure above, n1 and n2 are not used in the design and hence constitute unused
logic violations. Moreover, the registers in red are only feeding nets which are unused, and
consequently those registers are unused as well. These are reported as associated violations.
However, the other registers are used since they drive output Z and hence they are not reported,
even though they also drive unused logic n1 and n2.
Example 3
This example illustrates the rule behavior when the “Check Partial Buses” parameter is set to
“No”.
Rule Configuration
• Check For — Undriven Logic, Unused Logic
• Check Partial Buses — No
Analyzed Code
module partialuul (input [3:0] in1, in2, input clk, reset, // Violation 1
output reg [3:0] out1, out2); // Violation 2
always @(posedge clk or posedge reset)
begin
if(reset)
begin
out1[1:0]<= 2'b00; // Out1 is partially driven, hence no violation
for out1
end
else
begin
out1[1:0] <= in1[1:0]; // in1 is partially used, hence no violation
for in1
end
end
endmodule
Violations Produced
• Net 'in2' is unused. – Violation 1
• Net 'out2' is undriven. – Violation 2
Related Topics
Unused Declarations
Declarations Base Rules
Declarations Base Rules

The Declarations base rules check for different types of declarations in the design, and whether
they are declared properly.
Bad VHDL Type Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Class Members Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Class Members Visibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Class Methods Existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Entity Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Explicit Net Declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Interface List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Undefined Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Unused Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Verilog Constant Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
VHDL Deferred Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Bad VHDL Type Usage
Bad VHDL Type Usage

Checks for the incorrect use of types, incompatible bounds and incorrect constraints.
Usage
Bad VHDL Type Usage
Common Parameters
Unsafe Types
Parameters
• Unsafe Types
Specify which type checking to perform. The default is <all>.
o Incorrect Types
o Incompatible Types for Range Bounds
o Bad Constraint
o <all>
Examples
Example
entity top is port (rf2fe_vec: in dword);
signal tx_index: std_logic_vector (14 downto 0);
……
tx_index <= rf2fe_vec (f_txindex_hi downto f_txindex_lo);
-- Type error at ‘rf2fe_vec’. Needed type ‘std_logic_vector’
end rtl;
Violation Produced
Various
Note
Types should be used in a safe way.
Class Members Existence

Language support: SystemVerilog
Checks the existence of specific data member types in specific classes. Certain data member
types should appear in certain SystemVerilog classes to achieve some functionality. The
required data member must appear in the checked class itself or in one of its base classes.
Usage
Common Parameters
Applies To (base class)
Members (base class)
Parameters
• Applies To (base class)
Specify the classes to be checked. Any class which is one of or inherits directly/indirectly
from any of the specified base class names is checked. The default is <none>.
• Members (base class)
Specify the types of the data members that must exist. Each checked class must have one or
more data member where its type is one of or inherits directly/indirectly from the specified
base classes. The default is <none>.
Examples
Example 1
Check that classes which extends from "uvm_monitor" contains data members that extends
from "uvm_analysis_port" class.
Rule Configuration
• Applies To (base class) — uvm_monitor
• Members (base class) — uvm_analysis_port
Analyzed Code
package class_members_existence_pkg;
import uvm_pkg::*;
class My_Analysis_Port extends uvm_analysis_port;
// ...
endclass
class ma_monitor_base extends uvm_monitor; //Violation 1

endclass
class ma_agent_req_monitor extends ma_monitor_base;

// ...
My_Analysis_Port req_ap;
endclass
class ma_agent_rsp_monitor extends ma_monitor_base;

// ...
endclass
endpackage
module class_members_existence();
import class_members_existence_pkg::*;
// ...
endmodule
Violation Produced
Class 'ma_monitor_base' does not have a member of type 'uvm_analysis_port' – Violation 1
Related Topics
Class Methods Existence
Class Members Visibility

Checks that each of the specified classes provides the allowed visibility for the specified data
members. It is desirable to restrict access to class members from outside the class by hiding
their names. This keeps other programmers from relying on a specific implementation, and it
also protects against accidental modifications to class properties that are internal to the class.
Usage
Common Parameters
Members (base class)
Visibility
Parameters
from any of the specified base class names is checked. The default is <all>, i.e. all classes
are checked.
• Members (base class)
Specify the types of the data members that must have the allowed visibility (if exist). Each
checked class must provide the proper visibility for each data member where it is one of or
inherits directly/indirectly from the specified base classes. The default is <all>, i.e. all data
members in the specified classes are checked.
• Visibility
Specify the allowed visibilities. The default is Protected and Local.
o Public: No ‘protected’ or ‘local’ item qualifier is used
o Protected: ‘protected’ item qualifier is used
o Local: ‘local’ item qualifier is used
Examples
Example 1
Ensure that the visibility of data members of types ("uvm_driver", "uvm_monitor" and
"uvm_analysis_port") in classes that extends from "uvm_agent" is "Protected" or "Local".
Rule Configuration
• Applies To (base class) — uvm_agent
• Members (base class) — uvm_driver, uvm_monitor, uvm_analysis_port
• Visibility — Protected, Local

Analyzed Code
package class_members_visibility_pkg;
import uvm_pkg::*;
class ma_driver extends uvm_driver;
// ...
endclass
class ma_agent extends uvm_agent;
// ...
// external interfaces
uvm_analysis_port req_ap; // Violation 1
local uvm_analysis_port rsp_ap;
// internal components
protected ma_monitor m_monitor;
protected ma_driver m_driver;
uvm_sequencer m_sequencer;
endclass
endpackage
module class_members_visibility();
import class_members_visibility_pkg::*;
// ...
endmodule
Violation Produced
Class 'ma_agent' must not provide public visibility for 'req_ap' data member – Violation 1
Related Topics

Checks the existence of specific methods names in specific classes. Certain methods should
appear in certain SystemVerilog classes to achieve some functionality. The required method
must appear in the checked class itself or in one of its base classes.
Usage
Common Parameters
Applies To Exceptions (base class)
Methods
Check
Parameters
• Applies To Exceptions (base class)
Specify the class name(s) to be exclude from the check. The class is excluded from the
check if the class is any of the specified classes, or inherits directly or indirectly from any of
them. The default is <none>.
o <user-defined>
o <none>
• Methods
Specify the methods that must/must not/only can exist in checked classes (based on the
Check parameter setting). The default is <none>.
• Check
Specify how to check class methods. The default is Specified methods must be defined in
checked classes.
o Specified methods must be defined in checked classes.
This means that specified methods must be defined in checked classes, other
methods may or may not be defined.
o Specified methods must not be defined in checked classes.
This means that specified methods must not be defined in checked classes but other
methods may be defined.
o Specified methods only can be defined in checked classes.

This means that specified methods may or may not be defined in the checked classes
but there is no other methods can be defined.
Examples
Example 1
Check the existence of the method "build" in classes that extends "uvm_driver"
Rule Configuration
• Applies To (base class) — uvm_driver
• Methods — build
• Check — Specified methods must be defined in checked classes

Analyzed Code
package class_methods_existence_pkg;
import uvm_pkg::*;
class ma_driver_base extends uvm_driver;
// ...
virtual function void build();
// ...
endfunction: build
endclass
class ma_driver_good extends ma_driver_base;

// ...
endclass
class ma_driver_bad extends uvm_driver; // violation 1

// ...
endclass
endpackage
module class_methods_existence();
import class_methods_existence_pkg::*;
// ...
endmodule
Violation Produced
Class 'ma_driver_bad' does not have 'build' method defined – Violation 1
Related Topics
Entity Declarations
Entity Declarations
Language support: VHDL
Checks that there are no declarations in the entity's declarative region. An entity may have many
types of declarations, like signals, constants, shared variables, functions, procedures, …
The rule violates on the entity if it has any type of declaration except attributes. Only ports,
generics and attributes are allowed in the entity declarative region.
Usage
Entity Declarations
Common Parameters
Parameters
Examples
Example 1
Check the existence of any declaration in the entity.
Rule Configuration
Analyzed Code
ENTITY entity_having_decls IS -- VIOLATION 1
FUNCTION func RETURN bit;
TYPE enum IS (e0, e1, e2);
END entity_having_decls;
ARCHITECTURE arch OF entity_having_decls IS BEGIN

END arch;
Violation Produced
Entity "entity_having_decls" has declarations – Violation 1
Explicit Net Declarations

Checks that all nets are explicitly declared and that implicit nets (which are allowed in the
Verilog language) are considered as violations by the rule.
Usage
Common Parameters
Parameters
Examples
Example 1
new_comp U_new_comp (.out(out1), .in1(c), .in2(a) );
// Implicit net declaration is enforced for “out1”
Violation Produced
Implicit net declaration is enforced for "x"
Note
Declare all nets explicitly.
Related Topics
Verilog Statement Order

Checks that constants are used rather than hard-coded numeric values in vector bounds, ranges
and multi-value vector assignments.
Usage
Common Parameters
Hard Coded Values
Applies To
Description
Pure scalar values are excluded but single-bit elements of vectors can be checked.
The following forms are allowed:
• 0 to/downto/: 0
• 1 to/downto/: 0
• 1 to/downto/: 1
• 1/0 to/: <constant>
• <constant> downto/: 0/1
• <constant_1> to/downto/: <constant_2>
The check also applies to all types of VHDL & Verilog loops: for, while & repeat loops.
• VHDL “for” loops are checked for hardcoded ranges if the “Hard Coded Values”
parameter is set to “Ranges” and the “Apply to” parameter is set to "Variables".
• Verilog “for” loop, Verilog & VHDL “while” loop and Verilog “repeat” loop
conditions/expressions are checked if the “Hard Coded Values” parameter is set to
"Operands".
Parameters
• Hard Coded Values
Specify which aspects should be checked. The default is Operands and Ranges.
o Operands: [Multi-value vector assignment values e.g. “101”]
o Ranges: [Ranges or Vector bounds eg [7:0] or (7 downto 0)]
o Elements: [Single bit element of a vector eg a(2)]

• Applies To
Specify which objects should be checked. The option "Variables" can be used for VHDL
and Verilog. For VHDL, “Variables” refers to regular VHDL variables whereas for Verilog
it refers to all variable data types (eg reg, integer, real, realtime, time). The default is <all
objects>.
o <all objects>
o <all VHDL objects>
o <all Verilog objects>
o Port
o Generics
o Parameters
o Variables
o Signals
o Constants
o Subtypes
o Nets
Examples
Example 1
signal test: std_logic_vector (15 downto 0);
-- Avoid using hard coded numeric values such as “(15 downto 0)” for
-- declaring ranges of the multi-bus test
begin
any_proc: process(….)
begin
test1 <= ‘0’ and “10”;
-- Avoid using hard coded numeric values such as “10” for
-- literals used in assignment expressions
end process;
end rtl;
Violations Produced
• Bounds:
Avoid using hard coded numeric values such as “(15 downto 0)” for declaring ranges of
the multi-bus test
• Assignments:
Avoid using hard coded numeric values such as “10” for literals used in assignment
expressions
Note
Avoid using hard coded numeric values in assignment constant values or in vector
dimensions.
Related Topics
Numeric Width Declarations
Vector Assignment
Interface List
Interface List
Checks a variety of interface lists (for example, Entity Port List, Component Generic List,
Procedure Parameters, and so on) to ensure the IO modes and/or Object Categories (for
example, signal, variable, constant, and so on) are specified.
Usage
Interface List
Common Parameters
Interface Element
Applies To
Action
Parameters
• Interface Element
Specify which aspect/s should be checked.The default is IO Mode.
o IO Mode
o Object Category
• Applies To
Specify to which interface list type/s the check should apply. The default is All.
o Entity Port Lists
o Entity Generic Lists
o Component Port Lists
o Component Generic Lists
o Procedure Parameters
o Function Parameters
o Function Generic Lists
o Procedure Generic Lists
• Action
Specify the required check.The default is Explicitly Specify.
o Explicitly Specify
o Exclude (Omit)
Interface List
Examples
Example 1
Analyzed Code
function arch_func
(
signal a,b:in std_logic;
c : in std_logic;
-- Object category of parameter "c" of function "arch_func"
-- interface list must be explicitly specified
signal f: std_logic
-- The IO mode of parameter "f" in function "arch_func"
-- interface list must be explicitly specified
) return natural is
begin
end function;
Example 2
Rule Configuration
• Interface Element — IO Mode, Object Category
• Applies To — Entity Port List
• Action — Explicitly Specify

Analyzed Code
entity top is port
(
signal my_port : bit
-- IO Mode of port “my_port”, in entity top interface list must be
explicitly specified
clk : IN std_logic;
-- Object category of port “clk”, in entity top interface list must be
explicitly specified
);
end top;
Example 3
Rule Configuration
• Interface Element — IO Mode, Object Category
• Applies To — Entity Port List
• Action — Explicitly (Omit)
Interface List
Analyzed Code
entity top is port
(
signal my_port : bit
-- Object category of port “my_port”, in entity top interface list must
be omitted
clk : IN std_logic;
-- IO Mode of port “clk”, in entity top interface list must be omitted
); end top;
Violations Produced
• The category of parameter "c" of function "arch_func" is not explicitly specified.
• The IO mode of parameter "e" of function "process_func" is not explicitly specified.
Note
Ensure the sub-program parameters category and IO mode are specified.

Checks that the bounds/ranges for declarations are of a numeric size/width.
Usage
Common Parameters
Applies To
Parameters
• Applies To
Specify to which object/s this rule applies. The option “Variables” can be used for VHDL
and Verilog. For VHDL, “Variables” refers to regular VHDL variables whereas for Verilog
it refers to all variable data types (e.g. reg, integer, real, realtime, time). The default is Ports
and Variables.
o Ports
o Variables
o Generics
o Signals
o Constants
o Types/Subtypes
o Parameters
o Nets
Examples
Example 1
Analyzed Code
input [p_width-1:0] write_ptr;
reg [`dc_msb:0] fifo [0:DEPTH-1];
subtype word is std_logic_vector((dbits -1) downto 0);
Violation Produced
Use numeric values when specifying width of port “write_ptr”.
Note
Use numeric width values when specifying declaring objects.
Related Topics

Checks for instantiations of design units which are not defined. For Verilog, this means that
there is simply an instantiation with no corresponding definition. For VHDL, it means that there
is an instantiation and component only. Please note that if a design unit is run in the “single”
mode from DC, it is possible that undefined design units are reported even though the definition
of these design units exists in the library. This is because in the single mode, only the file
containing the selected module is visible to DesignChecker.
Usage
Common Parameters
Parameters
Examples
Example 1
Check for undefined design units (Verilog).
Analyzed Code
module undefinst(input in1, in2, clk, output out1);
undefinedmod inst (.in1(in1), .in2(in2), .clk(clk), .output1(out1)); //
Violation
endmodule;
Violation Produced
Design unit 'undefinedmod' is undefined
Example 2
Check for undefined design units (VHDL).
Analyzed Code
library ieee;
entity undefinst2 is
port (in1, in2, clk : in std_logic; out1 : out std_logic);
end;
architecture arch of undefinst2 is

component nodef is
port (in1, in2, clk : in std_logic; out1 : out std_logic);
end component;
begin
inst : nodef port map (in1 => in1, in2 => in2, clk => clk, out1 =>
out1); -- Violation
end;
Violation Produced
Design unit 'nodef' is undefined
Unused Declarations
Unused Declarations
Checks for objects which have been declared but are never actually used either by being
assigned values or read. This is a design-wide check.
It should be noted that this rule does not consider unused signals in packages, that is, no
violations will be raised in such cases. Note that the effects of synthesis may result in different
violations from those expected from looking purely at the code.
Usage
Unused Declarations
Common Parameters
Detect
Consider Identifier Slices
Parameters
• Detect
Specify which objects should be checked. The default is All.
o Identifiers: Read but not Written
o Identifiers: Written but not Read
o Identifiers: Neither Read nor Written
o Generics: Not Used
o Functions: Not Called
o Procedures: Not Called
o Tasks: Not Called
o Libraries: Not Used
o Constants: Not Used
o Parameters: Not Used
o genvar Declarations: Not Used
Note
“Identifiers” refer to signals, variables, ports and nets only. Further note that
identifiers of non-RTL types like TIME are not violated for.
Unused Declarations
• Consider Identifier Slices

Specify whether identifier slices should be considered in the check. If you set the value as
“No”, there will not be any violations related to slices raised. The default is Yes.
o Yes
o No
Note
If any portion of the signal is written or read, the entire signal will be considered
written or read. This is applicable only when you select “No”.
Examples
Example 1
Check for unread/unwritten identifiers.
Rule Configuration
• Detect — Identifiers: Read but not Written, Identifiers: Written but not Read,
Identifiers: Neither Read nor Written
• Consider Identifier Slices — Yes

Analyzed Code
library ieee;
ENTITY unuseddecl IS
PORT (in1 : IN std_logic_vector (3 DOWNTO 0); -- Violation 1
out1, out2 : OUT std_logic_vector(3 DOWNTO 0)); -- Violation 2, 3
END;
ARCHITECTURE unuseddecl OF unuseddecl IS

SIGNAL temp1, temp2 : std_logic; -- Violation 4, 5
BEGIN
temp1<= in1(0);
out1(3) <= temp2;
END;
Violations Produced
• Input port 'in1(3 downto 1)' is never used (read from) in architecture unuseddecl of
unuseddecl. – Violation 1
• Output port 'out1(2 downto 0)' is never assigned (written to) in architecture unuseddecl
of unuseddecl. – Violation 2
• Output port 'out2' is never assigned (written to) in architecture unuseddecl of
unuseddecl. – Violation 3
• Signal 'temp1' is never used (read from) in architecture unuseddecl of unuseddecl. –
Violation 4
Unused Declarations
• Signal 'temp2' is never assigned (written to) in architecture unuseddecl of unuseddecl. –

Violation 5
Related Topics
Unassigned Objects
Unconnected Ports
Verilog Constant Style

Checks for a consistent coding style for the declaration of constants. The choice is between the
use of `define macros or Parameters. The rule can also optionally check if Constants have been
defined in terms of Text Macros.
Usage
Common Parameters
Constant Definition
Parameter Value Style
Parameters
• Constant Definition
Specify the preferred coding style for Constant definitions. The default is Parameters.
o Parameters
o `define
o <don’t care>
• Parameter Value Style
Specify if Constants should be declared in terms of Text Macros. The default is <don’t
care>.
For example: parameter my_param = `fmy_param_define; Note that the macro must either
have been previously defined AND given a value (e.g. `define B 9) or not defined at all.
o Text Macros
o <don’t care>
Examples
Example 1
`define CC 1 // Use parameters instead of text macros (`define) for the
symbolic constant definition “CC”
Violation Produced
Use parameters instead of text macros(`define) for the symbolic constant definition "A"
VHDL Deferred Constants

Checks the usage of VHDL Deferred Constants.
Usage
Common Parameters
Parameters
Examples
Example 1
Check for the use of deferred constants in package.
Analyzed Code
package pkg is
procedure DW_max(L, R: bit);
constant MaxTimerVal:integer; – Violation
end pkg;
package body pkg is

procedure DW_max(L, R: bit) is
begin end;
constant MaxTimerVal:integer :=2;
end pkg;
use work.all;
use work.pkg.all;
entity bottom is
port (i1, i2: in BIT;
o1: out BIT);
begin end;
architecture arch of bottom is

begin
end;
Violation Produced
Found deferred constant ‘MaxTimerVal’.
Directive Base Rules
Directive Base Rules

The Directive base rules check for coding styles and consistency of Verilog directives.
Verilog `define Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Verilog `timescale Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Verilog `define Style

Checks the coding style for `define macro definitions. You can specify whether `define macros
are allowed to be redefined and the required scope in which macros are reset(undefined). The
required reset mechanism (ùndef or `resetall) can also be specified.
Usage
Common Parameters
Macro Redefinition
Reset Scope
Reset Mechanism
Parameters
• Macro Redefinition
Specify whether macros are allowed to be redefined. The default is Allow if reset within
Scope.
o Allow if reset within Scope: A macro can be redefined provided it is reset first.
o Disallow Redefinition: Any macro redefinition will be considered a violation
whether it is previously reset or not.
• Reset Scope
Specify the scope in which macros must be reset. The default is Module Scope where Macro
is defined.
o Module Scope where Macro is defined
o Module Scope where Macro is redefined
o Any Module Scope
o File Scope
o Any Scope
• Reset Mechanism
Specify which reset mechanism/s should be used. The default is ùndef.
o ùndef
o `resetall
o Any Mechanism
Examples
Violations Produced
• Redefined Macro: Macro redefinition. Macro "MAXIMUM" previously assigned to
"old_value".
• Undefined Macro: Macro has subsequent redefinitions. Macro "B" should be undefined
using ‘undef within its "file/module" scope.
Note
Verilog macros should not be redefined and should preferably be undefined in the same
module.
Verilog `timescale Style

Checks that a consistent `timescale compiler directive has been specified before each module
declaration.
Usage
Common Parameters
Time Unit/Time Precision Value
Scope
Parameters
• Time Unit/Time Precision Value
Specify the required value for the `timescale directive. To check that the `timescale directive
is used, irrespective of its value, specify “<don’t care>”. The default is 1 ns/1 ps.
o 1 ns/1 ps
o <user-defined>
o <don’t care>
• Scope
Specify the required scope in which the directive must occur. The default is per File.
o per File
o per Module
o <don’t care>
Note
Parameter Checks:
• Valid time values are 1, 10 or 100

• Valid time units are s, ms, us, ns, ps or fs (lowercase characters)
• Separator must be “/”
• <time_precision> must be at least as precise as <time_unit>
Examples
Violation Produced
Timescale Directive: Use `timescale “<string>” instead of `timescale “<string>” for defining
timescale compiler directive
Note
Include a consistent `timescale directive before each module declaration.
FSM Base Rules
FSM Base Rules

The FSM base rules check for coding styles, state encodings and transitions of finite state
machines.
FSM Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

FSM State Encoding Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
FSM Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
FSM Coding Style
FSM Coding Style

Checks the coding style used to describe the overall state machine behavior and optionally also
checks the output style (Moore/Mealy).
Usage
FSM Coding Style
Common Parameters
Coding Style
Output Style
Parameters
• Coding Style
Specify the HDL generation style which can be used for registering outputs, transitioning
states and for any combinatorial outputs. The default is Clocked + Separate Combinatorial
Transition/Output.
o Single Clocked Process Only:
Checks there is a single clocked process which includes the clock/reset logic, next
state (transition) and output assignments.
o Clocked + Separate Combinatorial Transition/Output:
Checks there are separate VHDL processes (or Verilog always blocks) as follows:
• a clocked process
• a combinatorial next state decode process (transition)
• a combinatorial output decode process (if necessary)
Checking will not look for a combinatorial output process/block if there are no
combinatorial state output assignments.
o Clocked + Combined Combinatorial Transition/Output:
Checks there are two separate VHDL processes (or Verilog always blocks) as
follows:
• a clocked process
• a combined combinatorial next state decode (transition) and output process
o <don’t care>
FSM Coding Style
• Output Style
Optionally specify the required state machine type. The default is Moore.
o Mealy
o Moore
o Mixed
o <don’t care>
Examples
Example 1
Check whether the FSM is coded using a single clocked process and whether it is a Moore
machine.
Rule Configuration
• Coding Style — Single Clocked Process Only
• Output Style — Moore
FSM Coding Style
Analyzed Code
Library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity test01 is
generic ( S0: INTEGER range 0 to 3:= 0;
S1: INTEGER range 0 to 3:= 1;
S2: INTEGER range 0 to 3:= 2;
S3: INTEGER range 0 to 3:= 3);
port (CLOCK, RESET : in STD_LOGIC;
A, B, C, D, E: in BOOLEAN;
SINGLE, MULTI, CONTIG: out BOOLEAN);
end test01;
architecture BEHV of test01 is

signal CS, NS: INTEGER range 0 to 3;
begin
SYNC_PROC: process (CLOCK, RESET)
begin
if (RESET='1') then
CS <= S0;
elsif (CLOCK'event and CLOCK = '1') then
CS <= NS;
end if;
end process; --End REG_PROC
COMB_PROC: process (CS)

begin
case CS is -- Violation 1, 2
when S0=>
NS<= S1;
if(A) THEN
MULTI <= TRUE;
END IF;
when S1 =>
NS <= S2;
MULTI <= B;
when S2 =>
NS <= S3;
MULTI <= C;
when S3 =>
NS <= S0;
MULTI <= D;
end case;
end process;
end BEHV;
Violations Produced
• FSM is not of type Moore. – Violation 1
• FSM is not coded using Single Clocked Process. – Violation 2
Related Topics
FSM State Encoding Style
FSM Coding Style
FSM Transitions

Checks the encoding style for State Machine descriptions. The encoding style can be set to
“Enumerations” or “Constants” for VHDL and SystemVerilog, and “Parameter”,
“Enumerations”, “`define” or “Localparam” for Verilog and SystemVerilog.
Usage
Common Parameters
State Encoding Style
Parameters
• State Encoding Style
Specify the preferred style(s) for the encoding states of the FSM. The default is
Enumeration.
o Enumeration:
[VHDL enumerated type, Verilog “enum” pragma, SystemVerilog enumerated type]
o Constant:
[VHDL, SystemVerilog const data type]
o Parameter:
[Verilog – parameter declaration for each state]
o `define:
[Verilog – `define directive for each state]
o Localparam:
[Verilog – localparam for each state]
For VHDL, “Enumeration” refers to the use of an enumerated type in VHDL. For example:
type csm_state_type is (reset, load, move …)
For Verilog, “Enumeration” is similar to “Parameter” but refers to the use of the “enum”
pragma in the Parameter definition. For example:
parameter [1:0] // pragma enum current_state_code gray
idle = 2'd0 ,
reading_from_reg = 2'd1 ,
clearing_flags = 2'd2 ;
For SystemVerilog, “Enumeration” refers to the enumerated data type. For example:
enum {RED, YELLOW, GREEN} cs;
Examples
Example 1
Checks for state encoding using “Parameters” in Verilog.
Rule Configuration
• State Encoding Style — Parameter
Analyzed Code
module fsm1 (input [3:0] in1, input clk, rst, output reg [3:0] out1);
parameter S0 = 4'b0001;
reg [3:0] cs;

begin
if(rst)
cs <= S0;
else
begin
case (cs)
S0 : begin
cs <= S1;
out1 <= 4'b0001;
end
S1 : begin
cs <= S2;
out1 <= 4'b0010;
end
S2 : begin
cs <= S3;
out1 <= 4'b0100;
end
4'b1000 : begin //Violation
cs<= S0;
out1 <= 4'b1000;
end
endcase
end
end
endmodule
Violation Produced
FSM states should not be Hardcoded.
Related Topics
FSM Transitions
FSM Coding Style
FSM Transitions
FSM Transitions
Checks for unreachable/dead-end states in finite state machines (FSM) and also detects whether
the FSM has a reset state and default handling.
Usage
FSM Transitions
Common Parameters
Detect
State Variables
Description
This rule detects unreachable states (states without any incoming transitions) and dead-end
states (states without any outgoing transitions) in FSMs (see below for more details).
The rule can also check if there is a default handling for the FSM, based on the size of the state
variable. It should be noted that a violation for default handling will not appear for a state
variable of size n if all the 2^n choices for the state variable are covered or if there is a default
branch. This rule also checks if there is a well-defined reset state for initializing the FSM.
The following explains how the tool infers FSM transitions and externally reachable states:
1. SM transition:
An FSM transition is characterized by a definite pair of states (s0, s1), where s0 is said to
have an outgoing transition to s1 (and correspondingly s1 an incoming transition from
s0), if and only if the state transition to s1 happens under the condition that the current
state is s0 and s0 != s1. The following code snippet is an example where a transition
from s0 to s1 takes place:
if (state == s0)
if (condition)
state <= s1;
2. Externally reachable state:

A state s0 is said to be externally reachable if and only if the state s0 can be reached
independently irrespective of the current state. The following code shows an example of
an externally reachable state s0:
always @(posedge clock)
if (some_input)
state <= s0;
A reset state is also an externally reachable state. The tool does not consider any state in an FSM
to have an outgoing transition to an externally reachable state unless there is an explicit
transition to that state as outlined in point 1 (above). State reachability analysis starts from an
FSM Transitions
externally reachable state and in the absence of such a state, all the states of the FSM will be
reported as unreachable.
Note
purely at the code.
Parameters
• Detect
Specify which types of transitions should be checked. The default is Transitions Without
Default Handling, States Without Incoming Transitions and States Without Outgoing
Transitions.
o Transitions Without Default Handling
o States Without Incoming Transitions
o States Without Outgoing Transitions
o <don’t care>
• State Variables
Specify whether the state variable has a specific reset value. The default is Reset to Known
State.
o Reset to Known State
o <don’t care>
Examples
Example 1
Check for transitions without incoming/outgoing transitions and without default handling.
Rule Configuration
• Detect — Transitions Without Default Handling, States Without Incoming Transitions,
States Without Outgoing Transitions
FSM Transitions
Analyzed Code
module dut (clk, rst, a, b, p);
input clk;
input rst;
input a, b;
output p;
reg p;
parameter ST0=1, ST1=2, ST2=4, ST3=8, ST4=16; reg [4:0] state_0;
reg [4:0] state_0;

begin
if (rst)
state_0 = ST0;
else begin
case (state_0) // Violation 1, 2, 3
ST0 : begin state_0 = ST1; p = a; end
ST1 : begin state_0 = ST2; p = a; end
ST2 : begin state_0 = a ? ST0 : ST4; p = a; end
ST3 : begin state_0 = ST1; p = b; end
endcase
end
end
endmodule
Violations Produced
• FSM does not have a default handling for transitions. – Violation 1
• The state 'ST3' of FSM state variable 'state_0' has no incoming transitions. – Violation 2
• The state 'ST4' of FSM state variable 'state_0' has no outgoing transitions. – Violation 3
Related Topics
FSM Coding Style
Gates Base Rules
Gates Base Rules

The Gates base rules perform checks related to logical gates in the design.
Clock Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Gate Level Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Clock Buffers
Clock Buffers
Checks that clock signals have not been explicitly buffered/inverted in the source code. This is a
design-wide check.
Usage
Clock Buffers
Common Parameters
Description
This rule points to only one use of the buffered/inverted signal as a clock, even though the
buffered/inverted clock may be used in multiple different registers through the design hierarchy.
In case of use of multiple buffers/inverters for a clock signal, only the one nearest to the use will
be violated for.
This rule checks for buffers/inverters inserted in the clock tree prior to its use as clock. Please
refer to figure 1 below.
In case the buffering of the clock signal and its use occurs in different design units,
DesignChecker points to the instance whose port is driven by the buffered clock.
Clock Buffers
For example, in the figure on the left below, since the port driven by the buffer is an input,
hence the buffer would have to be searched in the instantiating design unit. In this case, the
register representing the usage would be present inside the hierarchy of this instance.
Similarly, in the figure on the right, the port driven by the buffer is an output port, and hence the
buffer has to be searched in the master of the instance. In this case, the register representing the
usage would be present inside the hierarchy of the instantiating design unit.
The red arrow represents the clock port referred to in the violation message.
Parameters
Examples
Example 1
Clock buffering in single design unit.
Clock Buffers
Analyzed Code
library ieee;
entity clockbuffer1 is
port (in1 : in std_logic_vector(3 downto 0);
clk, reset : in std_logic;
end;
architecture clockbuffer1 of clockbuffer1 is

signal clk_buf : std_logic;
begin
clk_buf <= clk; -- Primary violation 1
process(clk_buf, reset) –- Associated violation 2
begin
if(reset = '1') then
out1<= (others => '0');
elsif(clk_buf'event and clk_buf = '1') then
out1 <= in1;
end if;
end process;
end;
Violations Produced
• Clock signal 'clk' is buffered/inverted. – Primary Violation 1
• + Clock 'clk_buf' of register 'out1' is buffered/inverted. – Associated Violation 2
Example 2
Design-wide clock buffering.
Analyzed Code
module clockbuffer2 (input [3:0] in1, input clk, reset, output [3:0]
out1);
wire clk_inv;
assign clk_inv = ~clk; // Clock buffer is the driver of the clock port in
violation message
ff inst1 (.clk(clk_inv), .reset(reset), .in1(in1), .out1(out1)); //
Primary violation 1
endmodule
module ff (input [3:0] in1, input clk, reset, output reg [3:0] out1);
always @(posedge clk or posedge reset) // Associated violation 2
begin
if(reset)
out1<= 4'b0000;
else
out1 <= in1;
end
endmodule
Violations Produced
• Clock port 'clockbuffer2.inst1.clk' is buffered/inverted. – Primary Violation 1
Clock Buffers
• + Clock 'clk' of register 'clockbuffer2.inst1.out1[3:0]' is buffered/inverted. – Associated

Violation 2
Related Topics
Gated Clocks
Gate Level Instances

Checks if specified gate-level components, Verilog Primitives or UDPs occur in the design.
Optionally, the rule can allow gate-level components which are isolated. This is a design-wide
check.
Usage
Common Parameters
Logic Type
Action
Parameters
• Logic Type
Specify which type/s of gate-level components are disallowed. The default is Primitives and
UDPs.
For Verilog, you can choose to disallow all built-in Primitives and/or UDPs.
For VHDL, specify the gate-level objects/components which are disallowed. You can also
specify Packages or objects within Packages.
For VHDL and Verilog, you can disallow all parts in a specific library or specific parts in a
library.
o Primitives
o UDPs
o <user-defined>
<user-defined> values can be specified in the following forms. Library names are optional.
o [<library>.]all [default Verilog library name is “verilog”]
o [<library>.]designUnit [default Verilog library name is “verilog”]
o [<library>.]<package>.all [VHDL only]
o [<library>.]<package>.<component> [VHDL only]
A string of cell names can be entered, delimited by spaces. Alternatively, a path can be
specified to a file containing a list of cell names delimited by white space.
• Action
Specify whether isolated gate-level components are allowed. The default is Allow if isolated
in separate modules.
o Allow if isolated in separate modules

o Disallow
Note
The parameter value “Allow if isolated in separate modules” applies only to gate-
level components and not to Primitives/UDPs. The latter will always be violated for
irrespective of whether they are isolated or not.
Isolation means that one or more gate-level components are instantiated inside a “wrapper”
module. A wrapper module is characterized by the following:
o It is composed of gate-level instances and wrappers only i.e. it does not contain any
non-gate-level instances.
o All outputs of the wrapper are driven by the outputs of wrappers/gate-level instances
i.e. there is no combinational logic at the output of the wrapper. However, logic is
permitted at the inputs of the wrapper and between components of the wrapper.
Examples
Example 1
Checking for non-isolated gate-level instances in the design.
Rule Configuration
• Logic Type — work.gate_comp_pkg.all
• Action — Allow if isolated in separate modules
Analyzed Code
library ieee;
package gate_comp_pkg is
component gate_inst is
port (in1 : in std_logic; out1 : out std_logic);
end component;
end package;
library ieee;
use work.gate_comp_pkg.all;
entity top is
port (in1, in2 : std_logic; out1, out2, out3 : out std_logic);
end;
architecture arch of top is

component wrapper is
port (in1 : std_logic; out1 : out std_logic);
end component;
begin
disallowed_inst : gate_inst port map (in1, out1); -- Violation 1
wrapper_inst : wrapper port map (in2, out2);
out3<= in1 and in2;
end;
library ieee;
use work.gate_comp_pkg.all;
entity wrapper is
port (in1 : std_logic; out1 : out std_logic);
end;
architecture arch of wrapper is

begin
isolated_inst : gate_inst port map (in1, out1); -- This is an isolated
gate-level instance
end;
Violation Produced
Encountered non-isolated gate instance 'disallowed_inst' bound to component 'gate_inst' –
Violation 1
Related Topics
Structural Core
Hierarchy Base Rules
Hierarchy Base Rules

The Hierarchy base rules perform checks related to the hierarchy of instances in the design.
Feedthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Snake Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Feedthrough
Feedthrough
Check for feedthroughs in the design.
Usage
Feedthrough
Common Parameters
Description
A feedthrough occurs when an output of a module is exactly the same as an input. This is a
design-wide check since input-to-output path may pass through instances. Here the longest
feedthrough path is reported as the primary violation and in the associated violations
intermediate points are reported. For example, in the following design:
There is a feedthrough path from port 'b' to port 'e' in design unit 'Mid' and there is a smaller
feedthrough path from port 'c' to port 'd' in design unit 'Bot'. But the smaller feedthrough is
actually just a part of the longer feedthrough path. Hence in the primary violation feedthrough
path from port 'b' to port 'e' is reported and in associated violations points corresponding to ports
'c' and 'd' are reported.
Parameters
Examples
Example 1
Checking for feedthrough paths in designs.
Rule Configuration
Feedthrough
Analyzed Code
library IEEE;
use work.all;
entity test04 is
port(
inp11 : in BIT; -- Violation 1
op11 : out BIT
);
end test04;

component test01 is
port(
inp21 : in BIT;
op21 : out BIT
);
end component;
begin
inst1 : test01 -- Violation 2, violation 5
port map(inp11, op11);
end arch;
Verilog file
module test01 (inp21, op21);

input inp21;
output op21;
reg a11;
assign a11 = inp21;
mid inst1 (a11, op21); // violation 3, violation 4
endmodule
module mid(input reg inp41, output op41);

assign op41 = inp41;
endmodule;
Violations Produced
• Feedthrough detected from input port 'inp11' to output port 'op11' in top design unit
'test04' – Violation 1
• Feedthrough passes through port 'test04.inst1.inp21' – Associated Violation 2
• Feedthrough passes through port 'test04.inst1.inst1.inp41' – Associated Violation 3
• Feedthrough passes through port 'test04.inst1.inst1.op41' – Associated Violation 4
• Feedthrough passes through port 'test04.inst1.op21' – Associated Violation 5
Example 2
Intermediate combinational logic in a feedthrough path.
Rule Configuration
Feedthrough
Analyzed Code
module top (input a, d, output reg b, c); // violation 1
assign b = a;
assign c = ~d;
endmodule;
Violation Produced
Feedthrough detected from input port 'a' to output port 'b' in top design unit 'top' – Violation 1
Note
Since there was an inverter (considered as combinational element) in path from 'c' to 'd' is
not being inferred as feedthrough.
Related Topics
Re-entrant Outputs
Re-entrant Outputs
Re-entrant Outputs
Checks for the output of an instance being connected to an input of the same instance, either
directly or through the hierarchy. A connection which involves only buffers/inverters is
considered to be direct. If the output is coming back to the same instance as an input,
potentially, the output port and/or the input port may not be required at all.
Usage
Re-entrant Outputs
Common Parameters
Parameters
Examples
Example 1
Check for a re-entrant output spanning multiple modules.
Rule Configuration
Analyzed Code
module test2 (input a, output f, f1);
middle inst1 (a, f);
middle inst2 (a, f1);
endmodule
module middle (input a, output f);

wire w;
bottom inst(.b(a), .d(w), .c(w), .e(f)); // Violation, Associated
Violation
endmodule
module bottom (input b, d, output e, c);

assign c = b;
assign e = d;
endmodule
Violations Produced
• Output ‘middle.inst.c’ is re-entrant through input ‘middle.inst.d’ – Violation
• + Re-entrant output passes through middle.inst.d. – Associated Violation
Re-entrant Outputs
Example 2
Another example is represented by the figure below:
In this example, the primary violation will point to the instance bottom_module where the
output is coming back as an input (specified by red circles). The associated violations point to
the multiple ports through which the re-entrant path passes through top_module and
middle_module1 (specified by green circles). There is a smaller re-entrant output in
middle_module2, but since it is a subset of the longer re-entrant path, it will not be reported.
Snake Paths
Snake Paths
Checks for the presence of combinational paths longer than a limit which can be specified by
the user. It is difficult for timing optimizers to optimize the critical path of a design, if it spans
multiple levels of hierarchy. This rule checks for the presence of long combinational paths, also
called snake paths, so that the user may break the path at an appropriate point by inserting
registers.
The user can set the maximum levels of permissible user hierarchy that a path can span. Any
path longer than this will be reported. Note that the effects of synthesis may result in different
Usage
Snake Paths
Common Parameters
Max. Allowed Hierarchy Levels
Treat Latches as Registers
Parameters
• Max. Allowed Hierarchy Levels
Specify a positive integer that indicates the levels of combinational hierarchical crossings
which, if exceeded, would result in a snake path violation. The default is 10.
• Treat Latches as Registers
This parameter indicates whether latches should be treated as registers or not. If this
parameter is set to “Yes”, paths will terminate on encountering a latch since it is treated as a
register; if set to “No”, it will go beyond the latch. The default is Yes.
Note
The tool does not detect snake paths through combinational logic which is unused. For the
reporting of snake paths, the tool only considers combinational logic that eventually drives a
top-level design unit output port, register, memory, latch or tri-state. This behavior ensures that
a violation is not reported for combinational logic that is supposed to get optimized out because
it does not impact the design. However, the tool preserves all sequential elements and reports
snake paths through combinational logic that drives them.
Snake Paths
Examples
Example 1
The figure below illustrates an example of snake paths. It should be noted that an increment in
the level implies the following:
• Crossing a user hierarchy

• A combinatorial driver
For instance, in the figure below, there will be no difference between the level of port x1 and
that of port x2, because although there are intermediate crossings of user hierarchy, there is no
combinatorial driver in between, and hence there is no increment in the level. On the other hand,
the sub-path between C and x1 is of level 1, because there is one combinatorial driver along this
path. A series of combinatorial drivers within a single module also get counted as a single
combinatorial driver only.
A path is defined as a unique set of combinatorial elements and end-points. In the figure above,
there are 8 different paths. The figure illustrates how B > C1 > C3 > C4 > C5 > Y and B > C2 >
C5 > Y constitute 2 different paths even though the end-points of both are the same.
It is important to note that in case the selected policy contains multiple configured snake path
rules with conflicting configurations, DesignChecker selects the lowest level of hierarchy and
considers latches as non-combinational elements (which means that the path terminates on
encountering a latch). The check will be then performed based on this configuration.
Example 2
Check for snake paths longer than or equal to 4 levels.
Snake Paths
Rule Configuration
• Max. Allowed Hierarchy Levels — 4
• Treat Latches as Registers — Yes
Snake Paths
Analyzed Code
module test7 (input q, r, s, t, u, v, rst, output x, y, z, output reg w);
// Violation 1, 8
wire w2, w4, w5, w6, w7;
reg w1, w3;
always @(posedge r)
begin
if (rst)
begin
w1 <= 0;
w3 <= 0;
w <= 0;
end
else
begin
w1 <= q;
w3 <= w2;
w <= w4;
end
end
middle1 inst1(.d(s), .e(s), .f(w2), .g(t), .i(w5), .h(w6)); //

Associated Violation 2, 5, 9, 12
middle2 inst2(.j(w4), .k(w7), .l(w5), .rst(rst), .m(r),
n(w7), .p(y), .o(x)); // Associated Violation 6, 7, 13, 14
assign w2 = u & v;
assign w7 = w2 & w3;
assign z = w7 & y;
assign w4 = w1 & w6 & w5;
endmodule
module middle1(input d, e, f, g, output h, i);

wire w1;
assign w1 = f & g;
assign h = d;
bottom inst(.a(e), .b(w1), .c(i)); // Associated Violation 3, 4, 10, 11
endmodule
module middle2(input j, k, l, rst, m, n, output o, output reg p);

wire w1;
assign o = j& k;
always @(posedge m)
if (rst)
p <= 0;
else
p <= w1;
bottom inst(.a(l), .b(n), .c(w1));
endmodule
module bottom(input a, b, output c);

assign c = a & b;
endmodule
Violations Produced
• Snake path with combinational logic in 5 levels detected from 'test7.u' to 'test7.inst2.o'. –
Violation 1
Snake Paths
• + Snake path includes 'test7.inst1.f'. – Associated Violation 2

• + Snake path includes 'test7.inst1.inst.b'. – Associated Violation 3
• + Snake path includes 'test7.inst1.inst.c'. – Associated Violation 4
• + Snake path includes 'test7.inst1.i'. – Associated Violation 5
• + Snake path includes 'test7.inst2.j'. – Associated Violation 6
• + Snake path includes 'test7.inst2.o'. – Associated Violation 7
• Snake path with combinational logic in 5 levels detected from 'test7.v' to 'test7.inst2.o'. –
Violation 8
• + Snake path includes 'test7.inst1.f'. – Associated Violation 9
• + Snake path includes 'test7.inst1.inst.b'. – Associated Violation 10
• + Snake path includes 'test7.inst1.inst.c'. – Associated Violation 11
• + Snake path includes 'test7.inst1.i'. – Associated Violation 12
• + Snake path includes 'test7.inst2.j'. – Associated Violation 13
• + Snake path includes 'test7.inst2.o'. – Associated Violation 14
Related Topics
Register IO
Related Combinatorial Logic
Instance Base Rules
Instance Base Rules

The Instance base rules perform checks related instantiation statements, and their port/generic
mappings.
Cascading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Generic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Unconnected Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Cascading
Cascading
Checks for cascaded instances of the same design unit.
For VHDL, the bound entity or component declaration must be visible.
For Verilog, the bound module must be visible.
Usage
Cascading
Common Parameters
Design Unit Name
Parameters
• Design Unit Name
Specify the names of design units to check for, or choose <any>. Names are case-sensitive
for Verilog and case-insensitive for VHDL. The default is <any>.
Examples
Example 1
Check for cascading of '<any>' design unit.
Rule Configuration
• Design Unit Name — <any>
Analyzed Code
n1 : nor_gate_1 port map (r,s,nq.sop,q.sop);
n2 : nor_gate_1 port map (q.sop,nq.sop,f.sop);
Violations Produced
• Instance 'n1' and instance 'n2' of design unit 'nor_gate_1' are cascaded. –Violation 1
• + The instances 'n1' and 'n2' are connected through net 'q.sop'. – Associated Violation 2
• + The instances 'n1' and 'n2' are connected through net 'nq.sop'. – Associated Violation 3
Example 2
Check for cascading of generated instances in for-generate loops.
Rule Configuration
• Design Unit Name — <any>
Cascading
Analyzed Code
`resetall
`timescale 1ns/10ps
`define N 4
typedef logic [`N:0] dtype_t;
module dff_pos_edge (output logic q,input d, clk);

always_ff @ (posedge clk)
q <= d;
endmodule
module top_module (clk, inp, Enable, outp);

input clk, inp;
input [`N-1:0] Enable;
output outp;
dtype_t ena;
always_ff @ (negedge clk)
ena[0] <= Enable[0];
genvar i;
generate
for(i= 0; i < 3; i = i + 1)
begin: forloop
if (i)
begin: b1
begin : b2
dff_pos_edge MyInst (ena[i+1],Enable[i],ena[i]); //
Violation, Associated Violation
end
end
end
endgenerate
dff_pos_edge MyInst2 (ena[1],Enable[1],ena[2]);
endmodule
Violations Produced
• Instance 'forloop[1].b1.b2.MyInst' and instance 'forloop[2].b1.b2.MyInst' of design unit
'dff_pos_edge' are cascaded. – Violation
• + The instances 'forloop[1].b1.b2.MyInst' and 'forloop[2].b1.b2.MyInst' are connected
through net 'ena[2]'. – Associated Violation
Restriction
Avoid cascading instances of the same design unit.
Generic Mapping
Generic Mapping
Checks the style of generic/ parameter mapping associations (Named or Positional/Ordered).
Usage
Generic Mapping
Common Parameters
Mapping Style
Threshold
Disallow
Parameters
• Mapping Style
Specify the required generic/ parameter map association style – Named or Positional/
Ordered. The default is Named.
o Named
o Positional
• Threshold
Specify the minimum number of generic/ parameter associations that trigger the check. The
mapping style check is not done if the number of generic/ parameter associations is below
the threshold. The default is 5.
• Disallow
Specify the disallowed styles in generic usages. The default is <none>.
o Generic Initialization in Component Declaration
o Generic Initialization in Packages
o Generic Initialization in Subprograms
o Multiple Mappings per Line
o <none>
Examples
Example 1
Check for the generic mapping style with threshold.
Rule Configuration
• Mapping Style — Named
Generic Mapping
• Threshold — 4
Analyzed Code
LIBRARY ieee;
ENTITY child IS
PORT(in1 : IN std_logic; in2 : IN std_logic;
out1 : OUT std_logic; out2 : OUT std_logic; out3 : OUT std_logic);
END child;
--
ENTITY top IS
END top;

SIGNAL in1, in2, out1, out2, out3 : std_logic;
COMPONENT child IS
PORT(in1 : IN std_logic; in2 : IN std_logic;
out1 : OUT std_logic; out2 : OUT std_logic; out3 : OUT
std_logic);
END COMPONENT child;
BEGIN
C1: child GENERIC MAP(in1, in2, out1);
C2: child GENERIC MAP(in1, in2, out1, out2, out3); -- Violation
END arch;
Violation Produced
One or more generic mapping, of "child", has positional association.
Example 2
Check for the parameter mapping style with threshold.
Rule Configuration
• Threshold — 4
Generic Mapping
Analyzed Code
module child1(in1, in2, out1);
input [0:7] in1;
input [0:7] in2;
input [0:7] out1;
parameter DATA_WIDTH = 8;
parameter ADDRESS_WIDTH = 8;
parameter CONTROL_WIDTH = 8;
// ...
endmodule
module child2(in1, in2, out1);

input [0:7] in1;
input [0:7] in2;
input [0:7] out1;
parameter DATA_WIDTH = 8;
parameter ADDRESS_WIDTH = 8;
parameter CONTROL_WIDTH = 8;
parameter DELAY = 10;
// ...
endmodule
module top;
wire x, y, z;
child1 #(16, 16, 8) C1();
child2 #(16, 16, 8, 0) C2(); // Violation
// ...
endmodule
Violation Produced
One or more parameter mapping, of "child2", has positional association.
Example 3
Check for generic initialization in component declaration.
Rule Configuration
• Threshold — 4
• Disallow — Generic Initialization in Component Declaration.
Generic Mapping
Analyzed Code
entity test1 is
generic ( n,m: integer );
port(in1,in2: integer;
output : out integer);
end;

begin
output <= in1 + in2;
end;
entity gencomp1 is
output1,output2 : out integer);
end;
architecture arch of gencomp1 is

component test1 is -- Violation
generic ( n: integer := 2;
m : integer := 4);
end component;
begin
inst1 : test1 generic map (10,20) port map(in1,in2,output1);
inst2 : test1 generic map (30,40) port map(in1,in2,output2);
end;
Violation Produced
Generic(s) initialization in component declaration is disallowed.
Related Topics
Port Mapping
Port Mapping
Port Mapping
Checks the style of port mapping associations (named or positional/ordered). It also checks for
the use of expressions and non-explicit widths in port maps, and checks for signals connected to
more than one input of the same instance.
Usage
Port Mapping
Common Parameters
Mapping Style
Threshold
Disallow
Parameters
• Mapping Style
Specify the required port map association style. The default is Named.
o Named
o Positional
• Threshold
Specify the minimum number of port associations that trigger the check. This is used to
control the mapping style check only, and has no effect on the disallowed parameter. The
default is 5.
Note
The mapping style check is not done if the number of port associations is below the
threshold.
• Disallow
Specify which constructs are not allowed within Port Maps. The default is <all>.
o Interconnected ports and signals with different names
o Logical Expressions
Aggregates, <Other Logical Expressions>
o Multiple Mappings per Line
o Non-Explicit Width Vectors
o Signals connected to more than one input of the same instance
Port Mapping
o <all>
o <none>
Examples
Example 1
Check for the mapping style with threshold.
Rule Configuration
• Threshold — 5
• Disallow — <none>
Port Mapping
Analyzed Code
LIBRARY ieee;
ENTITY mux IS
PORT (
s0, s1 : IN std_logic;
I0 , I1 , I2 , I3 : IN std_logic;
q : OUT std_logic
);
END mux;
ARCHITECTURE structural OF mux IS

COMPONENT andgate
PORT (
a, b, c : IN std_logic;
d : OUT std_logic
);
END COMPONENT;
COMPONENT inverter
PORT (
a : IN std_logic;
b : OUT std_logic
);
END COMPONENT;
COMPONENT orgate
PORT (
a, b, c, d : IN std_logic;
e : OUT std_logic
);
END COMPONENT;
SIGNAL s0_inv, s1_inv, x0, x1, x2, x3: std_logic;
BEGIN
inv1 : inverter PORT MAP (s0, s0_inv);
inv2 : inverter PORT MAP (a => s1, b => s1_inv);
and1 : andgate PORT MAP (a => I0, b => s1_inv, c => s0_inv, d => x0);
and2 : andgate PORT MAP (a => I1, b => s1_inv, c => s0 , d => x1);
and3 : andgate PORT MAP (a => I2, b => s1 , c => s0_inv, d => x2);
and4 : andgate PORT MAP (a => I3, b => s1 , c => s0 , d => x3);
or1 : orgate PORT MAP (a, b, c, d, e); -- Violation
END structural;
Violation Produced
One or more port mapping, of "orgate", has positional association.
Example 2
Check for signals connected to more than one input of the same instance.
Rule Configuration
• Mapping Style — Positional
Port Mapping
• Threshold — 1
• Disallow — Signals connected to more than one input of the same instance
Analyzed Code
module portmap (input in1, output out1);
middle inst (in1, in1, out1); // Violation
endmodule
module middle (input in1, in2, output out1);

assign out1 = in1&& in2;
endmodule
Violation Produced
Net 'in1' is connected to two inputs, 'in1' and 'in2' of instance 'inst'.
Example 3
Check for non-explicit width vectors.
Rule Configuration
• Threshold — 1
• Disallow — Non-Explicit Width Vectors

Analyzed Code
LIBRARY ieee;
ENTITY explicit_width IS
GENERIC ( Width : integer := 8);
PORT (
a : IN std_logic_vector(Width-1 DOWNTO 0);
b : IN std_logic_vector(Width-1 DOWNTO 0);
c : OUT std_logic_vector(Width-1 DOWNTO 0)
);
END explicit_width;
ARCHITECTURE structure OF explicit_width IS

COMPONENT xorgate IS
PORT (
x , y : IN std_logic_vector(7 DOWNTO 0);
z : OUT std_logic_vector(7 DOWNTO 0)
);
END COMPONENT;
SIGNAL try8 : std_logic_vector(7 DOWNTO 0);
BEGIN
xor0 : xorgate PORT MAP (x => a,y => b,z => c ); -- Violation 1, 2, 3
xor1 : xorgate PORT MAP (x(3 DOWNTO 0) => a(7 DOWNTO 4),x(7 DOWNTO
4) => a(3 DOWNTO 0),y => b(7 DOWNTO 0), z => c (7 DOWNTO 0));
END structure;
Port Mapping
Violations Produced
• Vector ""a"", used in port mapping of ""xorgate"", should have explicit widths. –
Violation 1
• Vector ""b"", used in port mapping of ""xorgate"", should have explicit widths. –
Violation 2
• Vector ""c"", used in port mapping of ""xorgate"", should have explicit widths. –
Violation 3
Example 4
Check for disallowed logical expressions except aggregates in port mapping.
Rule Configuration
• Threshold — 5
• Disallow — <Other Logical Expressions>
Port Mapping
Analyzed Code
library ieee;
entity alu is
port(
A : in std_logic_vector (3 downto 0 );
B : in std_logic_vector (3 downto 0 );
clk : in std_logic;
control : in std_logic_vector (1 downto 0 );
reset : in std_logic;
result : out std_logic_vector (7 downto 0 )
);
end alu ;
architecture logic of alu is

-- Component Declarations
component controler
port (
clk : in std_logic;
control : in std_logic_vector (1 downto 0 );
reset : in std_logic;
add : out std_logic;
mul : out std_logic;sub : out std_logic;
result : out std_logic
);
end component;
signal Reg1 : std_logic := '1';

signal Reg2 : std_logic := '1';
signal output : std_logic;
begin
-- Instance port mappings.
inst_controller : contoller;
Port map (
clk => clk,
reset => reset,
control => (others => '1'),
add => (Reg1 and Reg2), -- Violation 1
mul => (Reg1 or Reg2), -- Violation 2
sub => (Reg1 - Reg2), -- Violation 3
result => output
);
end logical
Violations Produced
• Avoid using expressions in port maps – Violation 1
Example 5
Check for disallowed Interconnected ports and signals with different names.
Port Mapping
Rule Configuration
• Threshold — 5
• Disallow — Interconnected ports and signals with different names.

Analyzed Code
LIBRARY ieee;
ENTITY Gate IS
port(a,b: in std_logic_vector(1 downto 0);
END ENTITY Gate;
--
ARCHITECTURE gateArch OF Gate IS
component andGate is
port(in1,in2: std_logic_vector(1 downto 0);
output : out std_logic);
end component;
function Transcod_1(Value: integer) return integer is

begin
return 1;
end Transcod_1;
signal y : std_logic;
signal in1,in2 : std_logic := '0';
signal out1,result : std_logic := '0';
signal x,s1,s2 : std_logic_vector(2 downto 0) := 000;
BEGIN
RegA1: andGate port map ( in1=>a , in2=>b ,result=>out1); -- Violation
1,2,3
RegA2: andGate port map ( in1=>x , in2=>y , result=>open); -- Violation
4,5
RegA3: andGate port map ( in1=>open , in2=>open , result=>open);
--ignore open
RegA4: andGate port map ( (in1(0),(others => '1')) , in2(1 downto 0) ,
output);
RegA5: andGate port map ( in1=>(in1(0),(others => '1')) , in2=>in2(1
downto 0) , output=>output);
RegA6: andGate port map ( (in1 and in1) , (in2(1 downto 0),y) ,
Transcod_1(output));
RegA7: andGate port map ( in1=>(in1(0),(others => '1')) , in2=>in2(1
downto 0) , output=>output);
END ARCHITECTURE gateArch;
Violations Produced
• Signals on the left and right side of portmapping should be the same – Violation 1
Port Mapping
Related Topics
Generic Mapping
Unconnected Ports
Unconnected Ports
Checks port mapping to ensure that ports are connected to other instances or constant values.
Input ports should be driven (i.e. connected to an output or a constant value). Output ports and
bidirectional ports should be connected. It also detects floating connections (a floating
connection is one wherein the port is connected to an undriven/unused net possibly through a
chain of buffers/inverters)
Usage
Unconnected Ports
Common Parameters
Applies To
Detect Floating Connection
Parameters
• Applies To
Specify which Ports must be connected. VHDL Buffers are treated as outputs. The default is
Input Ports, Output Ports and Bidirectional Ports.
o Input Ports
o Output Ports
o Bidirectional Ports
• Detect Floating Connection
Specify whether floating as well as unconnected ports need to be detected. The default is
No.
Examples
Example 1
Check for unconnected input ports.
Rule Configuration
• Applies To — Input Ports
• Detect Floating Connection — No
Unconnected Ports
Analyzed Code
module top (d, q);
input d;
output q;
bot B1 (.in1(d), .in2( ), .out1(q)); // violation
endmodule
module bot (in1, in2, out1);

input in1;
input in2;
output out1;
assign out1 = in2;
endmodule
Violation Produced
Unconnected input port 'in2' in instance 'B1'.
Example 2
Checks for unconnected and floating output ports.
Rule Configuration
• Applies To — Output Ports
• Detect Floating Connection — Yes

Analyzed Code
module top (in1, in2, q);
input in1;
input in2;
output q;
wire w2; // associated violation
assign q = in2;
bot B1 (.in1(in1), .in2(in2), .out1(w2)); // violation
endmodule
module bot (in1, in2, out1);

input in1;
input in2;
output out1;
assign out1 = in2;
endmodule
Violations Produced
• Floating output port 'out1' in instance 'B1'. - Violation
• + Net 'w2' is floating (unused). – Associated Violation
Related Topics
Unassigned Objects
Unused Declarations
Label Base Rules
Label Base Rules

The Label base rules check correctness of statement labels.
Statement Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Statement Labels
Statement Labels
Checks that specified constructs have labels.
Usage
Statement Labels
Common Parameters
Label
End Label
Minimum Number of Lines
Parameters
• Label
Specify which constructs require labels. For the option “EXIT Statement in Loop”, the rule
will check that the EXIT statement specifies the label of the loop it is exiting (e.g. EXIT
this_loop) rather than checking that the exit statement itself has a label. Note that unlabelled
VHDL assignments are only checked if they are concurrent assignments – sequential
assignments within processes are not checked. The default is <all>.
o <all>
o <Verilog specific>
Always Blocks, Clocking Blocks, Final Blocks, Fork-Join Blocks, Initial Blocks,
Sequential Begin-End Blocks, Verilog Case Statements, Verilog Generate Blocks
o <VHDL specific>
CASE Statements, EXIT Statement in Loops, Processes, VHDL Concurrent
Statements [Concurrent assignments, Procedural block calls, Assert, VHDL Block,
VHDL Generate]
o IF Statements
o Loops
o <don’t care>
• End Label
Specify which constructs require corresponding labels at the end of the construct. The
default is <all>.
o <all>
Statement Labels
o <Verilog mandatory labeled constructs>

Class Methods, Classes, Interfaces, Modules, Program Blocks, SV Packages, Tasks,
Varilog Functions
o <Verilog optionally labeled constructs>
Always Blocks, Clocking Blocks, Final Blocks, Fork-Join Blocks, Initial Blocks,
Sequential Begin-End Blocks, Verilog Case Statements, Verilog Generate Blocks
o <VHDL mandatory labeled constructs>
Architecture, Block, Component, Configuration, Entity, Generate, Package, Package
Body, Procedure, VHDL Function
o <VHDL optionally labeled constructs>
Case Statements, If Statements, Loops, Processes
o <don’t care>
• Minimum Number of Lines
Specify the size of the smallest construct to be checked. Constructs with fewer lines than
this threshold will not be checked. The default is <don’t care>.
o <user-defined>
o <don’t care>
Examples
Example 1
ARCHITECTURE flow OF top IS
BEGIN
-- Architecture concurrent statements
data_out <= div_data WHEN clk_div_en = '1' ELSE ser_if_data;
--Concurrent statements should be labeled
END flow;
Violations Produced
• Exit Loop Label
Use explicit loop label when exiting loops.
• Concurrent Statement Label
Concurrent statements should be labeled.
Tip
Add labels to those constructs which require them.
Related Topics
Naming
Logic Optimization Base Rules
Logic Optimization Base Rules

The Logic Optimization base rules perform checks related to optimizing design’s logic.
Case instead of if-else-if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Case instead of if-else-if

Checks if there exists a mutually exclusive if-else-if structure which can be converted to a case
statement.
Usage
Common Parameters
Threshold
Description
If-else-if structures represent priority logic which gets synthesized as a ladder of multiplexers as
shown below.
However, since the branches of this if-else-if are mutually exclusive, the same functionality can
be achieved by using a case statement, which would get synthesized to a single multiplexer as
shown below. Please note that a case statement represents parallel logic.
Parameters
• Threshold
Specify the minimum number of mutually exclusive if-else-if branches (including final else)
which should be considered for case conversion. The minimum value for this parameter is 3
because it represents the smallest if-else-if structure (if-else if-else). The default is 4.
Examples
Example 1
Check for parallel if-else-if branches with threshold 4.
Rule Configuration
• Threshold — 4
Analyzed Code
module top (clk, reset, in1, out2);
input clk;
input reset;
input [1:0] in1;
output [1:0] out2;
reg [1:0] out2;

begin
if (in1 == 2'b00) // Violation 1, Associated Violation 2
out2 <= 1;
else if (in1 == 2'b01) // Associated Violation 3
out2 <= 2;
out2 <= 3;
out2 <= 1;
else
out2 <= 3; // Associated Violation 6
end
endmodule
Violations Produced
• Transformation possible from group of 5 'if' statements into 'case' statement with
expression 'in1'. – Violation 1
• + Choice '00' inferred for case transformation. – Associated Violation 2
• + Choice 'default' inferred for case transformation. – Associated Violation 6
Example 2
Check for parallel if-else-if branches with threshold 4.
Rule Configuration
• Threshold — 4
Analyzed Code
LIBRARY ieee ;
ENTITY top_StateTransition2 IS
PORT(
clk_master : IN std_logic ;
rst_master : IN std_logic
);
END top_StateTransition2 ;
--
LIBRARY ieee ;
ARCHITECTURE rtl OF top_StateTransition2 IS
TYPE state_type IS (
state1,
state2,
state3,
state4,
state5,
state6,
state7
);
SIGNAL current_state_cs, next_state_ns, ps : state_type ;
BEGIN
----------------------------------------------------------------------
nextstate : PROCESS (
current_state_cs
)
----------------------------------------------------------------------
BEGIN
IF ((current_state_cs = state1) and (ps = state1)) THEN -- Violation
1, Associated Violation 2
next_state_ns <= state3;
ELSIF ((current_state_cs = state3) and (ps = state2))THEN –-
ELSIF ((current_state_cs = state4) and (ps = state3)) THEN –-
ELSE
next_state_ns <= state1; -- Associated Violation 7
END IF;
END PROCESS nextstate;
END rtl;
Violations Produced
• Transformation possible from group of 6 'if' statements into 'case' statement with
expression '{current_state_cs, ps}'. – Violation 1
• + Choice 'default' inferred for case transformation. – Associated Violation 7
Related Topics
Naming Base Rules
Naming Base Rules

The Naming base rules check the names of different design objects.
Capitalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Classes Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
File Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Mixed Case Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Named Object Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Unique Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Capitalization
Capitalization
Checks the capitalization (upper/lower case or initial caps) of literals, attributes, scientific
notations and physical unit names. The rule also checks IEEE references and VHDL reserved
words.
Usage
Capitalization
Common Parameters
Applies To
Case
Parameters
• Applies To
Specify to which identifier/s the convention applies. The default is <all>.
o <all>
o Attributes
o IEEE References
o Literals
o Physical Units
o Scientific Notations
o VHDL Reserved Words
• Case
Specify the required capitalization convention.The default is Lowercase.
o Lowercase
o Uppercase
o Initial Caps
Examples
Violations Produced
• Attribute "event" must be in lowercase
• VHDL reserved word "if" must be in uppercase
• IEEE reference "std_logic" must be in uppercase
Capitalization
• Physical unit "PS" must be in lowercase

• Literal "0e3ac" must be in uppercase
• Scientific notation "e" must be in uppercase
Note
Make attributes, IEEE references, literals, physical unit names, scientific notations, and
VHDL reserved words in the proper capitalization.
Related Topics
Naming
Classes Naming
Classes Naming
Checks for the naming convention of classes/handles based on their base class. The naming
pattern can be chosen from standard predefined conventions, or specified using simple or
regular expression syntax.
Usage
Classes Naming
Common Parameters
Check
Applies To Exceptions (OVM Base Class)
Pattern
Pattern Type
Match Case
Parameters
• Check
o Classes:
Classes’ names should comply with naming conventions specified in the "Pattern"
Parameter. This is the default value.
o Handles:
Handles’ names should comply with naming conventions specified in the "Pattern"
Parameter.
Specify the classes/handles to be checked. Any class which is one of or inherits directly/
indirectly from any of the specified base class names is checked. The default is <any>.
• Applies To Exceptions (OVM Base Class)
Specify the types of classes/object handles to exclude from applying the check. If the object
handle's type is any of the specified types, or inherits directly or indirectly from any of them,
the object handle is excluded from the check. The default is <none>.
• Pattern
Specify the naming pattern. Choose from those supplied or specify using simple or regular
expression syntax. The default is <Initial Caps>.
o <Lowercase>: [All Lower-case characters]
o <Uppercase>: [All Upper-case characters]
Classes Naming
o <Initial Caps>: [First character is uppercase, remainder can be either case]

o <user-defined>
• Pattern Type
If you have entered your own Pattern string, you can specify which expression format to
use. If you are using full Regular Expression syntax, set this parameter to “Regular
Expression”, otherwise set it to “Simple Expression”. The default is Simple Expression.
• Match Case
Specify whether the Simple or Regular Expression is case sensitive or not. The default is
Yes.
Examples
Example 1
Check that the names of testbench classes that extend "uvm_test" follow the specified naming
convention "*_test"
Rule Configuration
• Check — Classes
• Applies To (base class) — uvm_test
• Applies To Exceptions (base class) — <none>
• Pattern — *_test
• Pattern Type — Simple Expression
Analyzed Code
package classes_naming_pkg_1;
import uvm_pkg::*;
virtual class test_base extends uvm_test; // violation 1
endclass
class static analysis_fifo_Class extends uvm_analysis_port ;

endclass
class Class_analysis_fifo extends analysis_fifo_Class;

analysis_fifo_Class handle__oVm2=new();
endclass
endpackage
module classes_naming_1();
import classes_naming_pkg_1::*;
// ...
endmodule
Classes Naming
Violation Produced
Class declaration "test_base" violates naming convention: use "*_test" for class names
Example 2
Check that the names of testbench handles follow the specified naming convention "*_handle"
Rule Configuration
• Check — Handles
• Applies To (base class) — <any>
• Applies To Exceptions (base class) — <none>
• Pattern — *_handle
Analyzed Code
package classes_naming_pkg_2;
import uvm_pkg::*;
virtual class test_base extends uvm_test;
endclass
class static analysis_fifo_Class extends uvm_analysis_port ;

endclass
class Class_analysis_fifo extends analysis_fifo_Class;

analysis_fifo_Class handle__oVm2=new(); // violation 1
endclass
endpackage
module classes_naming_2();
import classes_naming_pkg_2::*;
// ...
endmodule
Violation Produced
Class handle "handle_oVm2" violates naming convention: use "*_handle" for class handle
names.
Related Topics
Naming
File Name
File Name
Checks that HDL files follow a consistent naming convention depending on their content. For a
given file type, the required file name can be specified using simple or regular expressions.
System variables can also be used to relate the file name to its contents. For example, a Verilog
file may typically be named after the module contained within it, for example, “%(module).v”.
Usage
File Name
Common Parameters
File Type
File Name Pattern
Pattern Type
Match Case
Parameters
• File Type
Specify to which identifier/s the naming pattern/convention applies. The default is Entity or
Module.
o Entity
o Architecture
o Package Header
o Package Body
o Configuration
o Module
o Include Files
o Interface
o Package
o Program Block
o Class
o Any
For a filename to be checked, the contents of the file should exactly match the values
selected in the “File Type” parameter. For example, if the value is set to “Entity” then the
File Name
file must contain only one or more entities. If the file contains any other design objects, for
example an architecture, then that file will not be checked. Similarly, if the values selected
are “Entity” and “Architecture”, then only those files which contain one or more entities and
one or more architectures (of any entities) will be checked. A file with only entities or only
architectures will not be checked.
When the File Type is set to “Any”, then the contents of the files are not checked at all. All
files of the specified language are candidates for this check.
File Type set to “Include Files” means all include files which are included in the source
files. Any Verilog/SystemVerilog specific parameter values selected along with “Include
files” implies – Include files which contain the specified design objects. For example, if
“Package” is selected along with “Include Files”, it means all included files which contain
one or more packages. Please note that included files which contain other design units in
addition to packages will not be considered for this check.
Parameter value “Any” cannot be selected along with any of the design objects. Exception is
“Include Files” which can be selected with “Any”. This combination represents all included
files. Please note that “Any” is redundant in this case, and the same behaviour would be
obtained if only “Include Files” is selected.
A design object in an include file is not considered in the source file context. So for
example, if “File Type” is set to “Package” + “Interface” and a source file contains an
interface and an include file included by this source file contains a package, then the source
file will not be a candidate for this check.
• File Name Pattern
Specify the naming pattern. Choose from those supplied or specify using Simple Expression
or Regular Expression syntax. The default is Lowercase.
o Lowercase
o Uppercase
o Initial Caps
o <user-defined>
An error will be produced if the File Name Pattern contains system variables which are not
related to the values selected in the “File Type” pattern. For example, “Entity” is selected in
the “File Type” parameter and the “File Name Pattern” contains %(package).
• Pattern Type
Specify which expression format is being used in the Pattern string. If you are using full
Regular Expression syntax, set this parameter to “Regular Expression”, otherwise set it to
“Simple Expression”. The default is Regular Expression.
• Match Case
Yes.
File Name
Examples
Example 1
Check if the name of file contains an entity.
Rule Configuration
• File Type — Entity, Architecture
• File Name Pattern — %(entity).vhd
Analyzed Code
LIBRARY ieee;
ENTITY abcd IS
END ENTITY abcd;
ARCHITECTURE abcd_a OF abcd IS

BEGIN
END ARCHITECTURE abcd_a;
Violation Produced
File "FileName_1_vhd.vhd" violates naming convention: use "%(entity).vhd" for entity,
architecture file names
Example 2
Check if the name of file contains a configuration.
Rule Configuration
• File Type — Configuration
• File Name Pattern — %(config).vhd
Analyzed Code
CONFIGURATION abcd_config OF abcd IS
FOR abcd_a
END FOR;
END abcd_config;
File Name
Violation Produced
File "FileName_2_vhd.vhd" violates naming convention: use "%(config).vhd (i.e.
abcd_config.vhd)" for configuration file names
Example 3
Check for multiple matching candidates for a system variable.
Rule Configuration
• File Type — Entity, Architecture
• File Name Pattern — %(entity).vhd
Analyzed Code
LIBRARY ieee;
ENTITY abcd IS
END ENTITY abcd;

BEGIN
ENTITY abcd1 IS
END ENTITY abcd1;
Violation Produced
Expected name for file "FileName_3_vhd.vhd" cannot be uniquely determined due to the use of
"%(entity)" in file name pattern
Example 4
Check if the name of file contains the package body.
Rule Configuration
• File Type — Package Body
• File Name Pattern — %(epackage).vhd
File Name
Analyzed Code
PACKAGE BODY xyz1 IS
END xyz1;
Violation Produced
File "FileName_4_vhd.vhd" violates naming convention: use "%(package).vhd" for package
body file names
Example 5
Check if the name of file contains an entity, architecture, package header and package body.
Rule Configuration
• File Type — Entity, Architecture, Package Header, Package Body
• File Name Pattern — %(architecture).vhd
Analyzed Code
LIBRARY ieee;
ENTITY abcd IS
END ENTITY abcd;
--
BEGIN
ENTITY abcd1 IS
END ENTITY abcd1;
PACKAGE xyz2 IS
END xyz2;
PACKAGE xyz3 IS
END xyz3;
PACKAGE BODY xyz2 IS

END xyz2;
Violation Produced
File "FileName_5_vhd.vhd" violates naming convention: use "%(architecture).vhd" for entity,
architecture, package header, package body file names
Example 6
This example shows an Include file scenario in SystemVerilog.
File Name
Rule Configuration
• File Type — Program Block
• File Name Pattern — %(progblk)_src.sv
Analyzed Code
Include File
class a;
endclass
Source File
`resetall
`timescale 1ns/10ps
ìnclude "FileName_6_1_v.v"
program abcd;
endprogram
Violation Produced
Source File violates naming convention: use "%(progblk)_src.sv" for program block file names
Note
Since the include file contents are not expanded in the source file, hence the source file in
this case contains only a program block, and hence is a candidate for this check.
Example 7
Check the Include file name.
Rule Configuration
• File Type — Include Files, Interface, Class
• File Name Pattern — %(class)_%(interface).sv
Analyzed Code
Include File
File Name
class a;
endclass
interface b;
endinterface
Source File
`resetall
`timescale 1ns/10ps
ìnclude "FileName_7_1_v.v"
program abcd;
endprogram
Violation Produced
Include file violates naming convention: use "%(class)_%(interface).sv" for interface, class file
names.
Related Topics
Partition Design Units
Inferred Elements Naming

Checks the names used for synthesis-related elements like clocks and resets adhere to the
specified naming convention. The naming pattern can be chosen from standard pre-defined
conventions, or specified using simple or regular expression syntax. Note that the effects of
synthesis may result in different violations from those expected from looking purely at the code.
Usage
Common Parameters
Applies To
Pattern
Use Extended Identifiers
Pattern Type
Match Case
Through Hierarchy
Parameters
• Applies To
Specify to which types of synthesis-related elements the naming pattern/convention applies.
The default is All.
o Synchronous Resets
Active High Synchronous Resets, Active Low Synchronous Reset
o Asynchronous Resets
Active High Asynchronous Resets, Active Low Asynchronous Resets
o Presets
Active High Presets, Active Low Presets
o Clocks
Positive Edge Clocks, Negative Edge Clocks
o Processes
Sequential Processes, Combinational Processes
o FSM State Variables
FSM Current State Variables, FSM Next State Variables
o Generators
Clock Generators, Reset Generators
o Tristate Enables
Active High Tristate Enables, Active Low Tristate Enables
o Tristate Outputs
o Registers
Positive Edge Triggered Registers, Negative Edge Triggered Registers
o VHDL Output Drivers
Complete Assignments Only, Other Assignments
o Architectures
Behavioral Architecture, Dummy Architecture, RTL Architecture, Structural
Architecture
• Pattern
Specify a naming pattern. The default is <Lowercase>.
o <Lowercase>
o <Uppercase>
o <Initial Caps>
o <user-defined>
• Use Extended Identifiers
Specify whether the check should allow extended/escaped identifiers or not. In case
allowed, then whether the name should be checked as-is or after stripping the leading
backslash and the trailing space (for Verilog) or trailing backslash (for VHDL). The default
is Allow.
o Allow
o Disallow
o Use Pattern As Is
• Pattern Type
Pattern type for user defined pattern. The default is Simple Expression.
o Simple Expression
o Regular Expression
• Match Case
Yes.
• Through Hierarchy
Specify whether control signal naming check is to be performed through hierarchy or not.
The default is Yes.
Description
Consider the below notes:

• Sequential processes are processes/always blocks which infer at least one flip-flop. On
the other hand, combinatorial processes are processes/always blocks which do not infer
even a single flip-flop. A process/always block inferring a latch would be considered as
combinatorial.
• Resets/presets of latches are not covered by this rule. These controls are only checked
for flip-flops.
• The “Through Hierarchy” parameter is relevant only to control signals viz. all variants
of Presets, Resets and Clocks. This value set to “Yes” with any other value in the
“Applies To” parameter is illegal.
• A preset signal is one which asynchronously sets the value of a flip-flop to 1. It should
be noted that it is possible that a preset for one bit may be a reset for another. For
example:
always @(posedge clk or posedge res)
if (res)
out1 <= 2’b01;
::::::::::::
In this case, the signal “res” would serve as an asynchronous reset for out1[1] but as a
preset for out1[0]. Hence, if there are conflicting patterns for asynchronous resets and
presets, this rule will produce at least one violation in this scenario.
• Clock generators and reset generators are detected as per the isolation rules mentioned in
the Internally Generated Clocks rule.
• VHDL forbids the reading of output ports. Hence a common practice followed to
overcome this restriction is to declare an output driver. The logic that is to drive the
output port now drives the output driver. The output port in turn is driven by the output
driver through a buffer. Since the output driver is an internal signal, hence it can
obviously be read. Formally, an output driver is defined as an internal signal which
directly drives an output.
For example
out1 : out std_logic_vector(3 downto 0);
if (out1 = “1010”) then -- illegal, outputs cannot be read
:::::::::::
This can be recoded as

signal out1_i : std_logic_vector(3 downto 0);
out1_i <= in1 and in2;
out1 <= out1_i;
if (out1_i = “1010”) then -- legal, internal signals can be read
:::::::::::
The following are not considered as output drivers.

in1 : in std_logic_vector(3 downto 0);
out1 <= in1;
if (in1 = “1010”) then
:::::::::::
Since in1 is not an internal signal, it is not considered as an output driver.

variable var1 : std_logic_vector(3 downto 0);
var1 := in1 and in2;
out1 <= var1;
if (var1 = “1010”) then
:::::::::::
Since var1 is a variable and output drivers are internal signals only.
signal temp : std_logic_vector(3 downto 0);
temp <= in1 and in2;
out1 <= temp;
Since temp is not read anywhere (other than the output port assignment), it is not
considered an output driver.
• Complete Assignments Only/Other Assignments parameterization for Output Drivers –
It is possible to select which types of output drivers have to be checked for. With the
parameter value “Complete Assignments Only” the following constraints have to be
met.
o Direct assignment to the output (no function calls, conversion functions) involved.
o No slices used in the output assignment (even complete slices are not considered)
Thus the following is considered as “Complete Assignments”
out1 <= temp;
While the following are not considered as “Complete Assignments” and are covered
under “Other Assignments”
out1 <= temp(1 downto 0); -- slices used

out2(3 downto 2) <= temp1; -- slices used
out3 <= to_std_logic(temp1); -- indirect assignment through
conversion function
out4(7 downto 0) <= temp4(7 downto 0); --out4 and temp4 both
declared (7 downto 0).
out5 <= temp3 & in1; -- Indirect assignment. Please note &
represents concatenation.
• Architecture Classification Criterion:

Among different architectures, behavioral architecture has the highest priority. RTL,
structural, and dummy come next, in order. That is, behavioral > RTL > structural >
dummy
An architecture consists of two regions, namely declarative region and the architecture
body. Overall architecture type is determined by the types and corresponding priorities
of these two regions. The final architecture type is the higher of the two. For example if
an architecture contains some RTL construct in declarative region but the architecture
body is structural, the overall architecture will be RTL.
Following are the definitions of different architecture types:
Behavioral Architectures: If the architecture body is non-synthesizable, its type will be
behavioral. If there is some non-synthesizable construct in the declarative region which
is not being used in the body of the architecture, the resultant architecture can be
synthesized and hence the type will not be behavioral.
RTL Architectures:
If the architecture is not behavioral and it contains constructs which are not purely
structural, the architecture will be marked as RTL. Declarations of complex types can
make the declaration region as RTL. Use of procedural statements or use of complex
types can make the body region as RTL. In either case or both the final architecture is
RTL. Please note that here complex type means any data type other than "BIT",
"BIT_VECTOR", "STD_LOGIC", "STD_LOGIC_VECTOR", "STD_ULOGIC", and
"STD_ULOGIC_VECTOR".
Structural Architectures:
If there are only component instantiations and/or concurrent assignment statements
involving simple types, the architecture body is structural. Furthur, if there are only
component declarations and/or simple signal declarations (with/without initialization
assignments), the declaration is structural.
So the following are considered as structural assignments
out1 <= in1;
out2(0) <= status;
However, the following are not

out2 <= func(curr_status);
proc_call(out3, state);
Dummy Architectures: For an architecture body to be dummy it should be completely

empty. The declaration region of the dummy architecture can contain unused simple
signal declarations but not initialization assignments.
Examples
Example 1
This example checks if the clock signals follow the naming pattern '*_clock'.
Rule Configuration
• Applies To — Clocks
• Pattern — *_clock
• Extended Identifiers — Disallow
• Hierarchy — No
Analyzed Code
module test67 (clk, rst);
input clk, rst; // Violation
reg [3:0] cst, nst;

begin
if(rst)
cst<= 0;
else
cst <= nst;
end
endmodule
Violation Produced
Clock signal 'clk' violates naming convention: use '*_clock' for clock signal names.
Example 2
This example checks if the synchronous resets follow the naming pattern rst_0, rst_1 etc.
Rule Configuration
• Applies To — Active High Synchronous Resets
• Pattern — rst_[0-9]+
• Pattern Type — Regular Expression
Analyzed Code
module test67 (clk, rst);
input clk, rst; // Violation
reg [3:0] cst, nst;
begin
if(rst)
cst<= 0;
else
cst <= nst;
end
endmodule
Violation Produced
Active High synchronous reset 'rst' violates naming convention: use 'rst_[0-9]+' for active high
synchronous reset names.
Example 3
This example checks if the active high preset signals follow the naming pattern *_%(entity)
Rule Configuration
• Applies To — Active High Presets
• Pattern — *_%(entity)
Analyzed Code
LIBRARY ieee;
ENTITY testproc IS
port (clk, pre_1 : in std_logic); -- Violation
END ENTITY testproc;
ARCHITECTURE behav OF testproc IS

signal current, next_state : INTEGER;
BEGIN
process (clk, pre_1)
begin
if (pre_1 = '1') then
current<= 1;
current <= next_state;
end if;
end process;
END ARCHITECTURE behav;
Violation Produced
Active high preset signal 'pre_1' violates naming convention: use '*_%(entity)' for active high
preset signal names.
Example 4
This example checks if the combinational processes/always blocks are named as '*_Comb'. It
should match case and it should disallow extended identifiers.
Rule Configuration
• Applies To — Combinatorial Processes
• Pattern — *_Comb
• Match Case — Yes
Analyzed Code
module test01 (in,out,sel,sel2,sel3);
input [0:2] in;
input sel,sel3,sel2;
output [0:2] out;
reg [0:2] out;
always @* // Violation 1
begin : b1_comb
if(sel3)
out[0] <= 0;
else if (sel)
out[0] <= in[0];
end
always @* // Violation 2
begin : \b2
if(sel3)
out[0]<= 0;
else if (sel2)
out[0] <= in[0];
end
endmodule
Violations Produced
• Combinational process 'b1_comb' violates naming convention: use '*_Comb' for
combinational process names. – Violation 1
• Combinational process '\b2 ' violates naming convention: use 'basic identifier' for
combinational process names. – Violation 2
Example 5
This example checks that the active low tristate enables and connected ports follow the regular
expression '.*_tri_ena_low', and the tristate output follows simple expression '*_TriOut'. Both
should match case and disallow extended identifiers.
Rule Configuration 1
• Applies To — Active Low Tristate Enables
• Pattern — *_tri_ena_low
• Hierarchy — Yes
• Applies To — Tristate Outputs
• Pattern — *_TriOut
Analyzed Code
module top (input a, b); //Violation3
mid1 inst1(a, b);
endmodule;
module mid1 (
input c, d); // Violation2
reg t; // Violation1
assign t = ~c ? d : 1'bz;
endmodule;
Violations Produced
• Tristate output 't' violates naming convention: use '*_TriOut' for tristate outputs. –
Violation 1
• Port 'c' in design unit 'mid1' which is being used as active low tristate enable at tri-state
buffer 'mid1.t' violates naming convention: use '.*_tri_ena_low' for ports connected to
active low tristate enables. – Violation 2
• Port 'a' in top design unit 'top' which is being used as active low tristate enable at tri-state
buffer 'top.inst1.t' violates naming convention: use '.*_tri_ena_low' for ports connected
to active low tristate enables. – Violation 3
Example 6
This example checks that all the registers in the design follow the simple expression '*_Reg', all
the positive edge triggered registers follow the simple expression '*_HighReg' and all the
negative edge triggered registers follow the regular expression '*_LowReg'.
• Applies To — Registers
• Pattern — *_Reg
• Applies To — Positive Edge Triggered Registers
• Pattern — *_HighReg
• Applies To — Negative Edge Triggered Registers
• Pattern — *_LowReg
Analyzed Code
module top (input in1,
in2,
clk,
output reg out1, // Violation 1, 2
out2);// Violation 3, 4
always @(posedge clk) out1<= in1;
always @(negedge clk) out2 <= in2;
endmodule
Violations Produced
• Register 'out1' violates naming convention: use '*_Reg' for registers. – Violation 1
• Positive edge triggered register 'out1' violates naming convention: use '*_HighReg' for
positive edge triggered registers. – Violation 2
• Register 'out2' violates naming convention: use '*_Reg' for registers. – Violation 3
• Negative edge triggered register 'out2' violates naming convention: use '*_LowReg' for
negative edge triggered registers. – Violation 4
Example 7
This example checks that the FSM current state variables are named as '*_curr_state' and all the
next state variables are named as '*_next'.
• Applies To — FSM Current State Variables
• Pattern — *_curr_state
• Applies To — FSM Next State Variables
• Pattern — *_next
Analyzed Code
Library IEEE;
entity test02 is
port (CLOCK, RESET : in STD_LOGIC);
end test02;

signal CS, NS: INTEGER range 0 to 3; // Violation 1, 2
CONSTANT S0:integer := 0;
begin
SYNC_PROC: process (CLOCK, RESET)
begin
if (RESET='1') then
CS<= S0;
CS <= NS;
end if;
begin
case CS is
when S0 | S3 =>
NS <= S1;
when S1 =>
NS <= S2;
when S2 =>
NS <= S3;
end case;
end process; -- End COMB_PROC
end BEHV;
Violations Produced
• FSM current state 'CS' violates naming convention: use '*_curr_state' for current state
variables. – Violation 1
• FSM next state 'NS' violates naming convention: use '*_next' for next state variables. –
Violation 2
Example 8
This example checks that the clock generators in the design follow the simple expression
'*_ClkGen'.
Rule Configuration
• Applies To — Clock Generators
• Pattern — *_ClkGen
Analyzed Code
module top (input a, b, output reg c);
wire gen_clk;
mid1 inst1(a, gen_clk);
dummy inst2(gen_clk, b, c);
endmodule
module mid1(input a2, output reg b2); // Violation 1

always @(posedge a2)
b2<= ~b2;
endmodule
module dummy(input clk, inp, output reg out);

out = inp;
endmodule
Violation Produced
Clock generator 'mid1' violates naming convention: use '*_ClkGen' for clock generators.
Example 9
This mixed design example checks that all the ports that are connected to clock signals in the
design follow the naming convention '*_clockPort'.
Rule Configuration
• Applies To — Clocks
• Pattern — *_clockPort
Analyzed Code
VHDL
use work.all;
entity top is
port(
CLOCK : in BIT // Violation2
);
end top;
architecture arch of top is

component mid1 is
port(
clk1 : in BIT
);
end component;
component mid2 is
port(
clk2 : in BIT
);
end component;
begin
inst1 : mid1
port map(CLOCK);
inst2 : mid2
port map(CLOCK);
end arch;
Verilog
module mid1 (clk1); // Violation1

input clk1;
reg temp;
always @(posedge clk1)
temp = ~temp;
endmodule
module mid2 (clk2); // Violation4

input clk2;
bot inst3(clk2);
endmodule
module bot (clk3); // Violation3

input clk3;
reg temp;
always @(posedge clk3)
temp = ~temp;
endmodule
Violations Produced
• Port 'clk1' in design unit 'mid1' which is being used as clock signal at register
'mid1.temp' violates naming convention: use '*_clockPort' for ports connected to clock
signals. – Violation 1
• Port 'CLOCK' in top design unit 'top' which is being used as clock signal at register
'top.inst1.temp' violates naming convention: use '*_clockPort' for ports connected to
clock signals. – Violation 2
• Port 'clk3' in design unit 'bot' which is being used as clock signal at register 'bot.temp'
violates naming convention: use '*_clockPort' for ports connected to clock signals. –
Violation 3
• Port 'clk2' in design unit 'mid2' which is being used as clock signal at register
'mid2.inst3.temp' violates naming convention: use '*_clockPort' for ports connected to
clock signals. – Violation 4
Example 10
This example checks that VHDL output drivers follow the naming convention '*_OpDriver'.
Rule Configuration
• Applies To — VHDL Output Drivers
• Pattern — *_OpDriver
Analyzed Code
entity counter is
port (sum : out INTEGER;
overflow4bit : out boolean;
in1, in2 : in INTEGER RANGE 0 to 15);
end;
architecture only of counter is

signal sum_int : INTEGER; -- Violation
begin
ctr: process(in1, in2)
begin
sum_int<= in1 + in2;
if (sum_int > 15) then
overflow4bit <= TRUE;
else
overflow4bit <= FALSE;
end if;
sum <= sum_int;
end process;
end only;
Violation Produced
Output Driver 'sum_int' violates naming convention: use '*_OpDriver' for output driver names.
Example 11
This example performs naming checks for behavioral architectures.
Rule Configuration
• Applies To — Behavioral Architectures
• Pattern — *_arch_behv
Analyzed Code
entity bot is
port (
I0 ,I1 : in bit;
O : out bit);
end entity;
architecture bot_arch of bot is -- violation 2

component leaf
port (
I0,I1: in bit;
O : out bit);
end component;
begin
process(I1, I0)
begin
if (I1 = '1') then
if (I1'event) then -- violation 1
O<= '1';
end if;
elsif (I0'event and (I0 = '1')) then
O <= '0';
end if;
end process;
end bot_arch;
Violations Produced
• Non-Synthesizable Clocking Style – Violation 1
• Behavioral architecture 'bot_arch' violates naming convention: use '*arch_behv' for
behavioral – Violation 2
Example 12
This example performs naming checks for RTL architectures.
Rule Configuration
• Applies To — RTL Architectures
• Pattern — *_RTL
Analyzed Code
package pkg is
type dim1 is array (0 to 2) of bit;
type arr1 is array (0 to 2) of dim1;
end pkg;
library work;
use work.pkg.all;
entity mid1 is
port (
I0 ,I1 : in bit;
O : out bit);
end entity;
architecture rtl of mid1 is -- violation 1

signal temp1: arr1;
signal temp2: arr1;
begin
process (I1) begin
if (I1'event and I1 = '1') then
temp1<= temp2;
end if;
end process;
end rtl;
Violation Produced
RTL architecture 'rtl' violates naming convention: use '*_RTL' for RTL architecture names.
Example 13
This example performs naming checks for RTL architectures.
Rule Configuration
• Applies To — Structural Architectures
• Pattern — *_struct
Analyzed Code
entity top is
port (
clk , data1 : in bit ;
data : in bit;
out1 : out bit;
out2 : out bit
);
end top;
architecture struct of top is -- Violation 1

signal temp1: bit_vector( 0 to 1);
signal temp3: bit_vector( 0 to 1) := "11";
component mid1
port (
I0,I1: in bit;
O : out bit);
end component;
begin
temp1<= temp2;
U1: mid1
port map( I0 => data1,
I1 => data,
O => out2);
end struct;
Violation Produced
Output Driver 'sum_int' violates naming convention: use '*_OpDriver' for output driver names.
Example 14
This example performs naming checks for Dummy architectures.
Rule Configuration
• Applies To — Dummy Architecture
• Pattern — *_Dummy
Analyzed Code
entity top is
port (
data : in bit;
out1 : out bit;
out2 : out bit
);
end top;
architecture \Empty 123\of top is -- Violation 1

begin
end \Empty 123\;
Violation Produced
Dummy architecture '\Empty 123\' violates naming convention: use '*_Dummy' for dummy
architecture names.
Example 15
This example performs naming checks for architectures.
Rule Configuration
• Applies To — Architectures
• Pattern — *_Arch
Analyzed Code
entity top is
port (
data : in bit;
out1 : out bit;
out2 : out bit
);
end top;
architecture sruct of top is -- Violation 2

component mid1
port (
I0,I1: in bit;
O : out bit);
end component;
begin
U1: mid1
port map( I0 => data1,
I1 => data,
O => out2);
end sruct;
entity mid1 is
port (
I0 ,I1 : in bit;
O : out bit);
end entity;
architecture tl of mid1 is -- Violation 1

signal temp0: bit;
signal temp1: bit;
signal temp2: bit;
begin
temp1<= temp0 and temp2;
end tl;
Violations Produced
• Architecture 'tl' violates naming convention: use '*_Arch' for architecture names –
Violation 1
• Architecture 'sruct' violates naming convention: use '*_Arch' for architecture names –
Violation 2
Related Topics
Naming
Mixed Case Naming
Mixed Case Naming

Checks that names do not differentiate by case alone. For VHDL, it checks that an identifier
name is always used with the same mix of case. For Verilog, it checks that different identifiers
do not use the same name but differs only in the mix of case used.
To ensure that the naming conventions are followed throughout your design (declaration &
usage), you need to configure both rules “Naming” & “Mixed Case Naming”.
Usage
Mixed Case Naming
Common Parameters
Parameters
Examples
Example 1
ENTITY top IS
PORT (nrw: out std_logic ); -- Do not allow mixing of case identifier
“nrw” when used
END top;
ARCHITECTURE flow of top

BEGIN
Nrw <= ‘0’; -- Identifiers “nrw” and “Nrw” are differentiated by case
END
Violations Produced
• VHDL Name Case
Do not allow mixing of case for identifier “XY" when used
Identifiers "XY" and "xy" are used within same design with mixed case
• Verilog Name Case
Avoid declaring Identifiers that are differentiated by case
Identifiers "XY" and "xy" are used within same design with mixed case
Related Topics
Capitalization
Name Spaces
Name Spaces
Checks that the same name is not used for more than one identifier in a name space. “Name
Space” with respect to this rule refers to packages and architectures in VHDL, and modules in
Verilog.For example, the same name should not be used to identify a signal in one part of the
name space and also used as a process label elsewhere in that name space. Port names having
the same names as connected signals are excluded from the check.
Usage
Name Spaces
Common Parameters
Exclusions
Parameters
• Exclusions
Specify the items to exclude from the check. The default is Enum Type Values.
o Enum Type Values
o Local Declarations across Subprograms
o Local Declarations across VHDL Generate Blocks
o Functions
o Procedures/ Tasks
o <none>
Note
If "Local Declarations across Subprograms" or "Local Declarations across VHDL
Generate Blocks" is excluded, the check will ignore repeated declarations that are
only located inside different subprograms/generate blocks. However, if a repeated
declaration is located outside the subprograms/generate blocks, this will result in a
violation.
Examples
Example 1
Check for the use of the same name in a single name space.
Rule Configuration
• Exclusions — <none>
Name Spaces
Analyzed Code
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
PACKAGE package_test IS
function bv_increment(a : in std_logic_vector(31 downto 2)

) return std_logic_vector ;
function bv_inc(a : in std_logic_vector

) return std_logic_vector;
END package_test;
PACKAGE BODY package_test IS

type one is array (NATURAL range <> ) of std_logic; -- Violation
function bv_increment(index1: in std_logic_vector(31 downto 2)

)return std_logic_vector is
variable carry_in : std_logic;
variable result : std_logic_vector(31 downto 2);
constant one : integer:=0; -- Associated Violation
constant Bit4 : integer:=0;
begin
carry_in := '1';
for index in 2 to 31 loop
result(index) := index1(index) xor carry_in;
carry_in := index1(index) and carry_in;
end loop;
return result;
end; --function
function bv_inc(a : in std_logic_vector

) return std_logic_vector is
variable carry_in : std_logic;
variable result : std_logic_vector(a'length-1 downto 0);
--constant one : integer:=0;
type Bit4 is ('X','0','1','Z');

type B_Vector is array(NATURAL range<>) of Bit4;
type Word is array (NATURAL range <>) of BIT;

type Memory is array (NATURAL range <>) of Word (31 downto 0);
begin
carry_in := '1';
for index1 in 0 to a'length-1 loop
result(index1) := a(index1) xor carry_in;
carry_in := a(index1) and carry_in;
end loop;
return result;
end; --function
END package_test;
Violations Produced
• Do not use identifier name "one" since it exists in the same namespace – Violation
Name Spaces
• Identifier name "one" already used in the same namespace – Associated Violation
Named Object Name
Named Object Name

Checks for a match between the UVM/OVM object handle name and the object instance name.
Usage
Named Object Name
Common Parameters
Applies To (UVM/OVM Base Class)
Applies To Exceptions (UVM/OVM Base Class)
Description
This rule checks that a defined object handle name is the same as the object hierarchal name.
Matching of names is case-insensitive. The hierarchical name is specified in the new argument
list.
UVM “uvm_object”
function uvm_object::new (string name="");

…
endfunction
Inherited classes usually accept the object name in the new operator and pass it to the super
(parent) class’s new operator. The check looks for the initial object name since the object can
theoretically have different hierarchal names during the object’s life cycle by setting the
corresponding class data member. The check does not apply to a vector of handles.
Parameters
• Applies To (UVM/OVM Base Class)
Specify the types of object handles to check. The object is checked if the object handle's
type is any of the specified types, or inherits directly or indirectly from any of them. The
default is uvm_object.
o uvm_object
o ovm_object
o <user-defined>
• Applies To Exceptions (UVM/OVM Base Class)
Specify the types of object handles to exclude from the check. The object is excluded from
the check if the object handle's type is any of the specified types, or inherits directly or
indirectly from any of them. The default is <none>.
Named Object Name
o <user-defined>
o <none>
Examples
Example 1
Check that object component name of all uvm_object objects - except uvm_component objects
- is similar to object handle name.
Rule Configuration
• Applies To (UVM/OVM Base Class) — uvm_object
• Applies To Exceptions (UVM/OVM Base Class) — uvm_component

Analyzed Code
package uvmNamedObjectName_pkg;
import uvm_pkg::*;
class uvmNamedObjectName;
function init ();
uvm_report_object uvm_report_object_inst = new("wrong_name", this);
// violation 1
uvm_component uvm_component_inst = new("wrong_name", this);
my_uvm_subscriber my_uvm_subscriber_inst = new("wrong_name", this);
endfunction
endclass
endpackage
module uvmNamedObjectNameModule();
import uvmNamedObjectName_pkg::*;
// ...
endmodule
Violation Produced
Object name ‘wrong_name’ must be the same as the object handle name
‘uvm_report_object_inst' – Violation 1
Naming
Naming
checks that the names used for particular identifiers adhere to the naming convention specified
for those identifiers. The naming pattern can be chosen from standard predefined conventions,
or specified using simple or regular expression syntax.
It should be noted that this rule only produces violations for the declarations of incorrectly
named identifiers, not for the usages of these identifiers.
To ensure that the naming conventions are followed throughout your design (declaration and
usage), you need to configure both the “Naming” and “Mixed Case Naming” rules.
Usage
Naming
Common Parameters
Applies To
Pattern
Use Extended Identifiers
Pattern Type
Match Case
Parameters
• Applies To
Specify to which identifier/s the naming pattern/convention applies. The default is
<identifiers> which includes <all SystemVerilog Identifiers>, <all Verilog Identifiers> and
<all VHDL Identifiers>.
o <Identifiers>
<SystemVerilog Specific Identifiers> (Class Member Variables, Class Methods,
Classes, Clocking Blocks, Constant Declarartions, Enum Typedefs, Interfaces,
Modports, Modport Instances, Non-Enum Typedefs, Program Blocks), <Verilog
Specific Identifiers> (Always Blocks, Sequential Begin-End Labels, Fork-Join
Labels, Initial Blocks, Internal Nets, Internal Regs, Local Params, Macros,
Modules, Parameters, Tasks), <VHDL Specific Identifiers> (Architectures,
Components, Configurations, Constants, Entities, Exit Labels, Generics, Next
Labels, Null Labels, Ports: Mode BUFFER, Ports: Mode LINKAGE Procedure Call
Labels, Procedures, Processes, Report Labels, Signals, Sub-Program Parameters:
Mode IN, Sub-Program Parameters: Mode INOUT, Sub-Program Parameters:
Mode OUT, User-Defined Types, VHDL Block Labels, Wait Labels), Assert Labels,
Assignment Labels, Case Labels, Enum Literals, Functions, Generate Block labels,
If Labels, Instances, Integers, Loop Labels, Packages, Ports, Return Labels,
Variables
Naming
o <Busses>
|VHDL Constant Busses, Other Busses
o Feedthrough Ports
o Internal Signals
o Ports: Mode IN
o Ports: Mode INOUT
o Ports: Mode OUT
o Unconnected Output Port Stubs [Signals attached to dangling ports]
o Vectors
• Pattern
Specify the naming pattern. Choose from those supplied or specify using simple or regular
expression syntax. To specify a list of allowed names (for example to check for particular
architecture names), use a regular expression of the form “^(name1|name2|name3)$”. The
default is <Lowercase>.
o <Lowercase> [All Lower-case characters]
o <Uppercase> [All Upper-case characters]
o <Initial Caps> [First character is uppercase, remainder can be either case]
o <user-defined>
• Use Extended Identifiers
Specify whether the check should also allow extended/escaped identifiers or whether the
specified pattern should be used exactly as specified. The default is Allow.
o Allow
o Disallow
o Use Pattern As Is
• Pattern Type
If you have entered your own Pattern string, you can specify which expression format to
use. If you are using full Regular Expression syntax, set this parameter to “Regular
Expression”, otherwise set it to “Simple Expression”. The default is Regular Expression.
• Match Case
Yes.
Naming
Note
The system variables specified must be applicable for specified 'Applies To' values. For
example, a simple expression containing '%(module)' can never be applied for checking
'VHDL' specific context like 'configuration' naming. In the same way, 'VHDL' specific system
variables are invalid in the context of 'verilog' specific naming checks like 'always block'
naming. These will result in validation error. Apart from language based validations, there can
be cases where a particular system variable is actually meaningless in the context. For example,
'%(instance)' has no meaning in the context of checking 'Port' names. These will result in special
violations denoting which of the system variables are invalid in this particular context.
Examples
Example 1
This example checks if components have the same name as their related entity by referring to
the binding information in the configuration declaration or statement. The system variable
%(explicit_bound_unit) will find the unit the component instance is bound to explicitly. If no
configuration specification or declaration exists, then there is no explicit binding indication, and
the system variable will return empty.
Rule Configuration
• Applies To — Components
• Pattern — *_%(explicit_bound_unit)
• Use Extended Identifiers — Use Pattern As Is

Analyzed Code
architecture logic of componentname is
component inv
port (
my_in : in std_logic;
my_out : out std_logic
);
end component;
for all : inv use entity work.ent(rtl); -- Violation
begin inst_inv: inv port map ( my_in => my_in, my_out=>my_out);
end logic;
Violation Produced
Component “inv” violates naming convention: use "*_%(explicit_bound_unit)" for component
names.
Naming
Example 2
Check for configuration names that have entity and/or architecture names using %(entity) and
%(architecture).
Rule Configuration
• Applies To — Configurations
• Pattern — cfg_%(entity)_%(architecture)
• Use Extended Identifiers — Use Pattern As Is
Analyzed Code
configuration cfg_test of ent isonfiguration cfg_test of ent is --
Violation
for rtl
end for;
end cfg_test; -- for all : inv use entity work.ent(rtl);
configuration Cfg_ent_seq of ent is

for seq
end for;
end Cfg_ent_seq;
Violation Produced
Configuration “cfg_test” violates naming convention: Use “cfg_%(entity)_%(architecture) for
configuration names
Example 3
Check that signal names are written in uppercase.
Rule Configuration
• Applies To — Signals
• Pattern — <Uppercase>
• Use Extended Identifiers — Allow
Naming
Analyzed Code
ARCHITECTURE rtl OF top is
SIGNAL i: std_logic; -- Violation
END rtl;
Violation Produced
Signal declaration “i” violates naming convention: use <Uppercase> for signal declarations
Example 4
Check that class member function names adhere to the pattern applied.
Rule Configuration
• Applies To — Class Methods
• Pattern — %( class)_myFunc*
• Use Extended Identifiers — Allow

Analyzed Code
module classVector;
class p;
function myFunc();
endfunction
int a ,b;
endclass
endmodule
Violation Produced
Class Method name "myFunc" violates naming convention: Use "%(class)_myFunc*" for class
method names
Example 5
Check that User Typedefs (enum and non-enums) names comply with naming conventions.
Rule Configuration
• Applies To — Enum Typedefs, Non Enum Typedefs
• Pattern — <Initial Caps>
• Use Extended Identifiers — Disallow
Naming

Analyzed Code
module svTypes;
parameter p1=6;
parameter p2=8;
wire [p1+p2:0] arr;
typedef bit[7:0] mybyte;
typedef enum integer {Sat, Sun, Mon, Tues, Wed, Thu, Fri} mydays;
typedef struct packed{
mybyte op;
mybyte addr;
} op_code;
typedef union {
mybyte addr;
mybyte data;
} pkt;
endmodule
Violations Produced
• Declaration "mybyte" violates naming convention: use "<Initial Caps>" for type
declarations
• Enum Typedef name "mydays" violates naming convention: use "<Initial Caps>" for
enum typedef names
• Declaration "op_code" violates naming convention: use "<Initial Caps>" for type
declarations
• Declaration "pkt" violates naming convention: use "<Initial Caps>" for type declarations
Other Violation Messages:
• State Variable Naming
FSM state variable declaration "var_current" violates naming convention: use "cs_*" for
state variable names
• Escape Characters
Avoid using escaped character names such as: "data\*_in"
• Instance Naming
Instance name “inst" violates naming convention: use “U_*" for labeling instances
• Integer Naming
Integer declaration “my.int" violates naming convention: use “*_int" for integer
declarations
• Package Naming
Package “my_pkg" violates naming convention: Use “*_pkg" for package names
• Port Naming
Port declaration “my_port" violates naming convention: use “port_*" for port names
Naming
• Unconnected Output Port

Unconnected output port "out3_nc" violates naming convention: use
"%(instance)_%(port)_nc" for unconnected output port names
• Primary Unit Naming
Design unit “my_du" violates naming convention: use “unit_*" for primary unit names
• Process Naming
Block label “my_label" violates naming convention: use “block_*" for block names
• Process Name Exists
Processes should be labeled
• Clock Naming
Clock Declaration “my_clk” violates naming convention: use “clk_*" for clock names
• Reset Naming
Reset signal declaration “my_rst" violates naming convention: use “rst_*" for resets
• Sub-Program Naming
Subprogram “my_task" violates naming convention: Use “task_*" for subprogram
names
• VHDL Signal Naming
Signal declaration “my_sig" violates naming convention: use “sig_*" for signal names
• VHDL Variable Naming
Variable declaration “my_var" violates naming convention: use “var_*" for variable
declarations
• VHDL Constant Naming
Declaration “my_const" violates naming convention: use “const_*" for constant
declarations
• VHDL Type Naming
Declaration “my_type" violates naming convention: use “type_*" for type declarations
• VHDL Reserved Words
Use “uppercase” letters for VHDL reserved word “type”
• Verilog Declaration Naming
Declaration “my_decl" violates naming convention: use “*_wire" for “wire"
declarations
• Verilog `Define Naming
Define “my_def" violates naming convention: Use “def_*" for define declarations
• Verilog Parameter Naming
Declaration “my_param" violates naming convention: use “param_*" for parameter
definitions
Naming
• VHDL Configuration Naming

Configuration “my_config" violates naming convention: Use “config_*" for
configuration names
• VHDL Generic Naming
Declaration “my_generic” violates naming convention: use “generic_*" for generic
name declarations
Related Topics
Capitalization
FSM Coding Style
Statement Labels
Mixed Case Naming
Unique Names
Unique Names
Checks that state names within FSM descriptions and/or instance names within structural
descriptions are unique within the scope of the entire design. The restriction provided through
this check is due to language differences for scope and visibility. Having unique names inside
designs eases coding for translation without causing problems if changing from one language to
another. This is a design-wide check. Note that the effects of synthesis may result in different
Usage
Unique Names
Common Parameters
Unique
Parameters
• Unique
Specify which objects to check. The default is FSM State Names and Instance Names.
Note
Important Notes
• This rule operates in a case-insensitive manner independent of the design language.
Hence, a violation will be produced even if there are two instances in a pure Verilog
design, one named “inst” and the other named “INST”.
• In case of instance names, a violation will be produced even if there are two
instances by the same name in the same design unit but in different scopes. For
example, a violation is produced if an instance named “inst” is present in the
architecture scope and another is present in a concurrent block in the same
architecture.
• Violations will not be produced for the same FSM state names being used in two
independent state machines in the same design unit.
• For FSM state name violations, in case the declaration of the state lies within the
same design unit as its use (for example, a constant declaration in the architecture
scope/parameter/localparam), then violations for that state will point to the
declaration of the state. On the other hand, if the declaration of the state lies in a
different design unit from its use (for example, an enumerated type declared in a
package), then the violation for that state will point to the start of the design unit in
which the FSM is present.
The difference in location is because in the first case, the declaration can only be
used within the design unit scope and, hence, the declaration also indicates the
Unique Names
corresponding design unit in which the FSM is present. However, in the second case,
the declaration does not indicate the design unit in which the FSM is present;
furthermore, multiple design units may refer to the same declaration. Hence, in this
case, the start of the design unit in which the FSM is present is pointed to.
Examples
Example 1
Check for the uniqueness of FSM state names and instances.
Rule Configuration
Unique Names
Analyzed Code
module test67 (output reg out, input [7:0] inp, input clk, enb, cnd, rst);
parameter [2:0] s0 = 3'h0, s1 = 3'h1, s2 = 3'h2, s3 = 3'h3; // Violation 3,
5, Associated Violation 2, 8
reg [3:0] cst, nst;

begin
if(rst)
cst <= 0;
else
casex (cst[2:0])
s0: begin out <= 1; if (enb) cst <= s1; end
default: begin out <= 7; if (enb) cst <= s0; end
endcase
end

begin
if(rst)
nst <= 1;
else
casex (nst[2:0])
s0: begin if (enb) nst <= s1; end
s3: begin if (enb) cst <= s0; end
default: begin if (enb) nst <= s0; end
endcase
end
genvar i;
generate
for(i=0; i<7; i=i+1)
begin : b1
mid inst1 (clk,rst, enb); // Violation 9
mid #(1,2,3,4,5,6)inst2 (clk,rst, enb); // Violation 11
end
endgenerate
endmodule
module mid(input clk, input rst, input enb);

parameter [2:0] S0 = 3'h0, S1 = 3'h1, S2 = 3'h2, S3 = 3'h3, S4 = 3'h4, S5
= 3'h5; // Violation 1, 7, Associated Violation 4, 6
reg [3:0] nst;

begin
if(rst)
nst <= S1;
else
casex (nst[2:0])
S0: begin if (enb) nst <= S1; end
Unique Names

default: begin if (enb) nst <= S0; end
endcase
end
bottom INST1(clk); // Associated Violation 10
bottom Inst2(clk); // Associated Violation 12
endmodule
module bottom(input clk);

endmodule
Violations Produced
• FSM State name ‘S0’ inside module ‘mid’ is not unique throughout the design. –
Violation 1
• + FSM State name ‘s0’ inside module ‘test67’ is not unique throughout the design. –
• FSM State name ‘s1’ inside module ‘test67’ is not unique throughout the design. –
Violation 3
• + FSM State name ‘S1’ inside module ‘mid’ is not unique throughout the design. –
• FSM State name ‘s2’ inside module ‘test67’ is not unique throughout the design. –
Violation 5
• + FSM State name ‘S2’ inside module ‘mid’ is not unique throughout the design. –
• FSM State name ‘S3’ inside module ‘mid’ is not unique throughout the design. –
Violation 7
• + FSM State name ‘s3’ inside module ‘test67’ is not unique throughout the design. –
• Instance name ‘inst1’ inside module ‘test67’ is not unique throughout the design. –
Violation 9
• + Instance name ‘INST1’ inside module ‘mid’ is not unique throughout the design. –
• Instance name ‘inst2’ inside module ‘test67’ is not unique throughout the design. –
Violation 11
• + Instance name ‘Inst2’ inside module ‘mid’ is not unique throughout the design. –
Related Topics
Mixed Case Naming
Order Base Rules
Order Base Rules

The Order base rules check that certain constructs appear with a specific order.
Operator Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Vector Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Operator Order
Operator Order
Checks for the use of parentheses to ensure that multiple operators within equations are
evaluated in an explicit order. Consecutive occurrences of some operators that result in an
identical value irrespective of order of evaluation are excluded from this check. For example: “
M <= a AND b AND c;” would not cause a violation.
Usage
Operator Order
Common Parameters
Parameters
Examples
Example 1
Check that parentheses are used to enforce the order of operator evaluation.
Rule Configuration
Analyzed Code
my_proc: PROCESS (a, b)
VARIABLE tmp : std_logic
BEGIN
if (b = a) then
tmp := tmp*10 + 1; -- Violation
end if;
END PROCESS my_proc;
Violation Produced
Use parentheses to force the order of operations in equations.
Example 2
Rule Configuration
Analyzed Code
module opOrder(input d1, d2, clk, rst, output reg q) ;
q <= rst ? 0 : d1 | d2 ; // Violation
endmodule
Operator Order
Violation Produced
Example 3
Rule Configuration
Analyzed Code
module opOrder2(input int in1, in2, output int out1) ;
always@(in1 or in2)
out1 = -in1-in2 ; // Violation
endmodule
Violation Produced
Related Topics
Allowed Operators
Vector Order
Vector Order
Checks that vector dimensions consistently use an ascending or descending order. The rule can
also check the minimum starting index.
Usage
Vector Order
Common Parameters
Style
Applies To
Low Index Bound
Parameters
• Style
Specify the required order for multi-bit buses: Descending or Ascending. For example, (x
downto 0) for VHDL, [x:0] for Verilog. The default is Descending.
o Descending [e.g. (x downto 0) for VHDL, [x:0] for Verilog]
o Ascending [e.g. (0 to x) for VHDL, [0:x] for Verilog]
o <don’t care>
• Applies To
Specify the objects for which vector dimensions are checked. The default is All.
o Vector Bounds:
Will produce violations on the usage of the array.
o Array Bounds:
Will produce violations on the array declaration only not the usage.
o Integer Range Constraints
o Real Range Constraints
o String Vector Bounds
• Low Index Bound
Specify whether the minimum index value for the vector should start at 0 or 1.
o 0
o 1
o <don’t care>
Vector Order
Examples
Example 1
Check Vector Bounds and Low Index Bounds.
Rule Configuration
• Style — Descending
• Applies To — Vector Bounds, Real Range Constraints
• Low Index Bound — 0

Analyzed Code
ENTITY top IS
PORT (clk : IN std_logic;
rst : IN std_logic;
in1 : IN std_logic_vector(0 to 7); -- Violation 1
in2 : IN std_logic_vector(8 downto 1); -- Violation 2
END top;

BEGIN
END arch;
Violations Produced
• Dimension/Range definition "(0 to 7)", for "in1", does not comply to descending order
convention – Violation 1
• Bus dimension "(8 downto 1)", for "in2", does not start at low index zero – Violation 2
Example 2
Check Array Bounds.
Rule Configuration
• Applies To — Array Bounds
• Low Index Bound — 0

Analyzed Code
module top;
reg x[0:11]; // Violation 1
wire [0:7] y[0:5]; // Violation 2
// . . .
endmodule
Violations Produced
• Dimension/Range definition "[0:11]", for "x", does not comply to descending order
Vector Order
• Dimension/Range definition "[0:5]", for "y", does not comply to descending order
Example 3
Check Bounds for Vectors, Arrays and Strings.
Rule Configuration
• Style — Ascending
• Applies To — Vector Bounds, Array Bounds, String Vector Bounds
• Low Index Bound — <don’t care>

Analyzed Code
library ieee;
entity top is
port (
reset_n : in std_logic;
clk : in std_logic;
inp : in std_logic;
string_signal : in string (15 downto 1); -- Violation 1
outp : out std_logic
);
end entity top;

TYPE array_decl is array (31 downto 0) of std_logic; -- Violation 3
signal array_signal : array_decl;
signal vec_signal : std_logic_vector (31 downto 0); -- Violation 2
begin
p_shifter1 : process (reset_n, clk)
begin
if reset_n = '0' then
array_signal <= (others => '0');
vec_signal <= (others => '0');
elsif rising_edge(clk) then
array_signal <= array_signal(30 downto 0) & inp; -- Violation
4
if(string_signal (2 downto 1) = "OK") then -- Violation 6
vec_signal <= vec_signal(30 downto 0) & inp; -- Violation 5
end if;
end if;
end process p_shifter1;
end architecture rtl;
Violations Produced
• Dimension/Range definition "(15 downto 1)", for "string_signal", does not comply to
ascending order convention – Violation 1
• Dimension/Range definition "(31 downto 0)", for "vec_signal", does not comply to
Vector Order
• Dimension/Range definition "(31 downto 0)", for "array_decl", does not comply to
• Dimension/Range definition "(30 downto 0)", for "array_signal", does not comply to
• Dimension/Range definition "(30 downto 0)", for "vec_signal", does not comply to
• Dimension/Range definition "(2 downto 1)", for "string_signal", does not comply to
Example 4
Check Bounds for Vectors and Arrays.
Rule Configuration
• Applies To — Vector Bounds, Array Bounds

Analyzed Code
LIBRARY ieee;
ENTITY vectorOrderEnt IS
END ENTITY vectorOrderEnt;
ARCHITECTURE vectorOrderArch OF vectorOrderEnt IS

TYPE dataVector IS ARRAY (0 TO 4) OF Unsigned(0 TO 10); --violation 1,2
SIGNAL dataSignal : dataVector(0 TO 4); --violation 3
BEGIN
dataSignal(1 TO 4) <= dataSignal(0 TO 3); --violation 4,5
END ARCHITECTURE vectorOrderArch;
Violations Produced
• Dimension/Range definition "(0 to 4)", for "dataVector", does not comply to descending
order convention --violation 1
• Dimension/Range definition "(0 to 10)", for "dataVector", does not comply to
descending order convention --violation 2
• Dimension/Range definition "(0 to 4)", for "dataSignal", does not comply to descending
Vector Order
Example 5
Check Bounds for Vectors.
Rule Configuration
• Applies To — Vector Bounds

Analyzed Code
LIBRARY ieee;
ENTITY vectorOrderEnt IS
END ENTITY vectorOrderEnt;
ARCHITECTURE vectorOrderArch OF vectorOrderEnt IS

TYPE dataVector IS ARRAY (0 TO 4) OF Unsigned(0 TO 10); --violation 1
SIGNAL dataSignal : dataVector(0 TO 4); --violation 2
BEGIN
dataSignal(1 TO 4) <= dataSignal(0 TO 3); --violation 3,4
END ARCHITECTURE vectorOrderArch;
Violations Produced
• Dimension/Range definition "(0 to 10)", for "dataVector", does not comply to
descending order convention --violation 1
Partition Base Rules
Partition Base Rules

The Partition base rules check proper separation of specific design objects.
Partition Design Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Partition Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Structural Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Partition Design Parameters

Checks that the specified items are separated into different files from the rest of the design. This
makes it easier to locate and change their values.
Usage
Common Parameters
Design Types
File Name
File Name Type
Match File Name Case
Package Name
Parameters
• Design Types
Specify the required file partitioning. The default is Constants or Parameters.
o Constants
o Functions
o Procedures
o Types/Subtypes
o Components
o Parameters
o Define Directives
• File Name
Specify the required file name template. The default is <none>.
o <user-defined>
o <none>
• File Name Type
Specify which expression format is being used in the File Name string. If you are using full
Regular Expression syntax, set this parameter to “Regular Expression”, otherwise set it to
“Simple Expression”.
• Match File Name Case

Yes.
• Package Name
Specify a package name in which the constructs specified in the “Design Types” parameter
should appear. The default is <don’t care>.
o <user-defined>
o <don’t care>
o <any>
Note
The “File Name” template string or the “Package Name” should be specified. Both
these parameter values cannot be empty simultaneously. Also, both parameter values
cannot be specified simultaneously.
Examples
Example 1
Check that constants are defined only inside file “*_consts.vhd”.
Rule Configuration
• Design Types — Constants
• File Name — *_consts.vhd
• File Name Type — Simple Expression
• Match File Name Case — Yes
• Package Name — <don’t care>

Analyzed Code
--Architecture declarations
CONSTANT CLK_PRD: time := 100 ns; -- Violation
-- Constant “CLK_PRD” defined inside design file.
-- Place constant declarations in separate file “*_consts.vhd”
Violation Produced
Constant “CLK_PRD” defined inside design file. Place constant declarations in separate file
“*_consts.vhd”
Example 2
Check that constants are defined only in the package “mypkg”.
Rule Configuration
• Design Types — Constants
• File Name — <none>
• File Name Type — Simple Expression
• Match File Name Case — No
• Package Name — mypkg

Analyzed Code
package pkg is
type enum_type is ( none, club, spade, heart, diamond );
constant const: integer range 1 to 16 := 11; -- Violation 1
end pkg;
library ieee;
use work.pkg.all;
entity top1 is
port (
reset_n : in std_logic;
clk : in std_logic;
inp : in std_logic;
outp : out std_logic
);
end entity top1;
architecture rtl of top1 is

-- type declarations
type array_decl is array (31 downto 0) of std_logic;
-- array signal declarations
signal array_signal : array_decl;
constant const_rtl: integer range 1 to 16 := 11; -- Violation 2
begin
p_shifter1 : process (reset_n, clk)

begin
if reset_n = '0' then
array_signal<= (others => '0');
array_signal <= array_signal(30 downto 0) & inp;
end if;
end process p_shifter1;
end architecture rtl;
Violations Produced
• Constant "const" is not defined inside package(s) "mypkg" – Violation 1
• Constant "const_rtl" is not defined inside package(s) "mypkg" – Violation 2

• User-Defined Types
Type “my_type” is preferably defined in a package
• Define Directive Definition
“my_macro” defined inside design file. Place define directives in separate file
“defines.v”
• Parameter Definition
Parameter "maximum" defined inside design file. Place parameter definitions in separate
file
• Constant Definition
Constant "HIGH" defined inside design file. Place constant declarations in separate file
• Function Definition
Function “my_func” defined inside design file. Place function declarations in separate
file “functions.vhd”
Tip
Put Constants and Parameters in separate files from the design.
Related Topics

Checks that the specified combination of objects appear in each file. This is a design-wide
check.
Usage
Common Parameters
Design Objects per File
Objects of Other Type in File
Ignored Design Objects in File
Parameters
Note
Selecting VHDL and Verilog dialects as value for the “Language” parameter is
disallowed.
• Design Objects per File

Design units that should be present in a separate file. The default is Single Entity and All Its
Architectures for VHDL and Single Module for Verilog.
o VHDL
• Single Entity
• Single Architecture
• Single Configuration
• Single Entity and All Its Architectures
• Single Entity and All Its Configurations
• Single Entity, All Its Architectures and All Its Configurations
• Single Package Header
• Single Package Body
• Single Package Header and Its Package Body
o Verilog
• Single Module
• Single Interface
• Single SystemVerilog Package

• Single Program Block
• Single Class Declaration
• Implementation of a Single Class
• Single Class Declaration and Its Complete Implementation
• Objects of Other Type in File
Specify whether other design unit types are allowed or not to be present in the same file with
design units specified in Design Objects per File parameter. The default is Allow.
o Allow
o Disallow
• Ignored Design Objects in File
Design units to be ignored from the check. The default is <none>.
o Class within the Scope of Another Design Object
o Package Framing Classes (without Ignoring the Framed Classes)
o <none>
Examples
Example 1
Check that each entity with its architectures are placed in a separate file.
Rule Configuration
• Design Objects per File — Single Entity and All Its Architectures
• Objects of Other Type in File — Disallow
• Ignored Design Objects in File — <none>

Analyzed Code
PACKAGE pkg IS –- Violation 1
END pkg;
ENTITY top IS
END ENTITY top;

BEGIN
Violation Produced
The package header 'pkg' should be declared in a separate file. – Violation 1
Example 2
Check that each module is placed in a separate file.
Rule Configuration
• Design Objects per File — Single Module
• Objects of Other Type in File — Disallow
• Ignored Design Objects in File — <none>

Analyzed Code
module mod;
endmodule
class C; // Violation 1
endclass
Violation Produced
The class 'C' should be declared in a separate file. – Violation 1
Related Topics

Checks that related combinatorial logic is kept in a single module. This provides more scope for
optimization of combinatorial logic because, typically, synthesis tools do not perform too much
logic optimization across design unit boundaries. This is a design-wide check. Note that the
effects of synthesis may result in different violations from those expected from looking purely
at the code.
Usage
Common Parameters
Treat Latches as Combinational Elements
Parameters
• Treat Latches as Combinational Elements
Determines whether latches should be treated as combinational elements or not. Having this
parameter set to “Yes” implies that DesignChecker will go beyond latches to check if
combinatorial logic is kept within the same module. The default is No.
Description
It should be noted that in order to reduce the number of violations, DesignChecker tries to group
violations together at a module level.
The diagram below illustrates a scenario in which DesignChecker unites the combinational
drivers driving a set of registers in the same module. So, as shown in the example,
DesignChecker would group the registers F1 and F2 in a single violation, since the
combinational clouds driving these registers have some commonality (combinational cloud C3
in this case). On the other hand, the combinational logic driving the register F5 shares no
commonality with that driving F1 and F2 and hence will not be grouped with the latter.
The diagram below illustrates a different case in which the path between F1 and F3 is not
reported as a violation, simply because there is just one cloud of combinational logic involved
in the path between these registers. For related combinatorial logic violations, at least 2
independent combinational clouds in different modules must be present, as seen in the path
between F2 and F4.
Furthermore, DesignChecker reports the register/top-level port which terminates the

combinatorial path as the primary violation (represented by the green arrow in the above
figure), and each module boundary crossed in the combinatorial path is reported as an
associated violation (represented by the red arrows in the above figure). Multiple signals in a
single-module boundary crossing are grouped in a single associated violation.
It should also be noted that combinational logic between two registers can be spread across
multiple modules via feedthroughs. To help with debug, the violations report the entire cone of
logic between the driving and the driven registers, including the feedthroughs and registers at
the boundaries. Identifying the registers connected on either side of the combinational logic
helps locate where best to move the combinational logic after merging. In the figure below, C1
and C2 represent a combinational logic cloud spread across multiple modules between two
registers, F1 and F2. C1 and C2 could be combined into a single combinational logic cloud C3
and placed in the module containing register F2. If there is no register after a combinational
logic cloud, the top-level input or output port will be considered as the logic cone boundary and
any reported violations will include the top level port.
Examples
Example 1
Check for related combinatorial logic across the design.
Rule Configuration
• Treat Latches as Combinational Elements — No
Analyzed Code
module test16(input a, b, c, m, n, o, output l, u); // Violation 1, 7,
Associated Violation 6, 12
wire w1, w2, w3, w4;
middle1 inst1 (.d(a), .e(b), .f(c), .g(w1), .h(w2), .v(m),
.w(n), .x(o), .p(w3), .q(w4)); // Associated Violation
4, 5, 10, 11
middle2 inst2 (.i(w1), .j(w2), .k(l), .r(w3), .s(w4), .t(u)); //
Associated Violation 2, 3, 8, 9
endmodule
module middle1(input d, e, f, v, w, x, output g, h, p, q);

assign g = d& e;
assign h = f;
assign p = v & w;
assign q = x;
endmodule
module middle2(input i, j, r, s, output k, t);

assign k = i & j;
assign t = r & s;
endmodule
Violations Produced
• Combinational logic that drives output port(s): 'l' in top design unit 'test16' is not
grouped in a single design unit. – Violation 1
• + Related combinational logic either crosses module boundary through or reaches output
port(s): 'k' in instance 'test16.inst2'. – Associated Violation 2
• + Related combinational logic either crosses module boundary through or reaches input
port(s): 'i', 'j' in instance 'test16.inst2'. – Associated Violation 3
port(s): 'g', 'h' in instance 'test16.inst1'. – Associated Violation 4
port(s): 'd', 'e', 'f' in instance 'test16.inst1'. – Associated Violation 5
port(s): 'a', 'b', 'c' in top design unit 'test16'. – Associated Violation 6
• Combinational logic that drives output port(s): 'u' in top design unit 'test16' is not
grouped in a single design unit. – Violation 7
port(s): 't' in instance 'test16.inst2'. – Associated Violation 8
port(s): 'r', 's' in instance 'test16.inst2'. – Associated Violation 9
port(s): 'p', 'q' in instance 'test16.inst1'. – Associated Violation 10
port(s): 'v', 'w', 'x' in instance 'test16.inst1'. – Associated Violation 11
port(s): 'm', 'n', 'o' in top design unit 'test16' – Associated Violation 12
Related Topics
Snake Paths
Register IO
Structural Core
Structural Core
Checks that the top-level design unit is purely structural and does not contain any procedural
constructs like always blocks, complex assignments etc. Only instantiations and simple
continuous assignments are considered structural by default. However, additional constructs
like function/procedure calls, concatenations/aggregates can be configured to be considered as
structural constructs.
Usage
Structural Core
Common Parameters
Additional Structural Constructs
Parameters
• Additional Structural Constructs
Specify any additional constructs which the tool should consider as structural. The default is
<none>.
o Concurrent sub-program calls
o Conditional Operators/Conditional Signal Assignments
o Concats and Aggregates
o Gate Instances
o <none>
Please note that any construct deemed as structural is not traversed and hence the tool would
not violate if a non-structural construct is used inside a structural construct. For example, if
“Concurrent sub-program calls” are considered structural and the function contains complex
assignments, no violation would be produced.
Examples
Example 1
Checks for the presence of procedural constructs in the top-level design unit.
Rule Configuration
• Additional Structural Constructs — <none>
Structural Core
Analyzed Code
module structcore (input in1, in2, output reg out1);
always @(in1 or in2) // Violation
out1<= in1 & in2;
endmodule
Violation Produced
Procedural construct encountered in top-level module 'structcore'.
Related Topics
Race Condition Base Rules
Race Condition Base Rules

The Race base rules check code that may cause race conditions in the design.
Clock Used As Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Combinatorial Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Register Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Clock Used As Data
Clock Used As Data

Checks for potential race conditions that could be caused by the use of clock signals as data.
Optionally, a violation is also produced in case a clock signal happens to be a primary output of
the design (that is, output of the top design unit), since it can potentially be used as data outside
the design.
In case a given signal is being used as a clock and/or is being used as data at more than one
location, only one occurrence of the signal as clock and one occurrence of the signal as data are
highlighted. This is a design-wide check.
Usage
Clock Used As Data
Common Parameters
Check
Parameters
• Check
Specify the types of usage of clock as data. The default is Clock used as data internal to
design and Clock driving top-level output port.
Examples
Example 1
Check for clocks being used as data.
Rule Configuration
Clock Used As Data
Analyzed Code
module test1(clk1,clk2,reset,data_en,d, q1,q2); // Associated Violation
input clk1,clk2,reset,data_en,d;
output q1,q2;
reg q1,q2;
always @(posedge clk1 or posedge reset)

begin
if(reset)
q1 <= 1'b0;
else if(data_en)
q1 <= d;
end
always @(posedge clk2 or posedge reset) // Violation

begin
if(reset)
q2<= 1'b0;
else if(data_en)
q2 <= clk1 && d; // The Clock is being used as data.
end
endmodule
Violations Produced
• Clock used as data at register 'test1.q2'. – Violation
• + Clock signal ‘clk1’ is being used as data. – Associated Violation
Combinatorial Feedback
Checks for the presence of combinatorial feedback paths within a module as well as across a
hierarchy. Combinatorial feedback paths cause race conditions which makes the output
unpredictable. Note that the effects of synthesis may result in different violations from those
expected from looking purely at the code.
Usage
Common Parameters
Feedback Type
Treat Latches as Combinational Elements
Parameters
• Feedback Type
Specify which feedback type should be checked. The default is <all>.
o Cyclic Loops within the Same Structural Element
Checks for the presence of a combinatorial feedback path confined to a single design
unit.
o Cyclic Loops between Different Structural Elements
Checks for the presence of a combinatorial feedback path across multiple design
units.
o <all>
Note
The tool also detects feedback loops in combinational logic which is unused.
• Treat Latches as Combinational Elements

This parameter determines whether combinatorial feedback loops involving latches should
be reported or not. The default is No.
Examples
Example 1
This example illustrates the detection of combinatorial feedback paths within a design unit and
across the design.
Rule Configuration
• Feedback Type — Cyclic Loops within the Same Structural Element, Cyclic Loops
between Different Structural Elements
• Treat Latches as Combinational Elements — No

Analyzed Code
module testloop (input a, b, c, d, output g, h);
wire w1, w2, w3;
middle inst (.c(w1), .d(b), .e(w2)); // Violation 4, Associated
Violation 5
assign w1 = a && w2;
assign g = w1;
assign w3 = h || b; // Violation 1
assign w4 = w3 && c; // Associated Violation 2
assign h = w4 ^ d; // Associated Violation 3
endmodule
module middle(input c, d, output e);

assign e = c || d;
endmodule
Violations Produced
• Combinational feedback loop detected at 'w3'. – Violation 1
• + Combinational feedback loop passes through 'w4'. – Associated Violation 2
• + Combinational feedback loop passes through 'h'. – Associated Violation 3
• Combinational feedback loop detected at 'testloop.inst.c'. – Violation 4
• + Combinational feedback loop passes through 'testloop.inst.e'. – Associated Violation 5
Related Topics
Latch Inference
Register Race
Register Race
Checks whether a race condition may be introduced in the circuit due to the presence of
blocking assignments to registers.
Blocking assignments to a register in a sequential block may introduce a race condition, if this
register is read in a different sequential block. This is because both sequential blocks will be
triggered at the same time, and so the order of reading the register and assigning to it, is not
deterministic. So it is not known whether the old or the current value of the register in question
will be read. Usage of non-blocking assignments to registers ensures that a race condition does
not arise, because at the time of triggering itself, the old values are stored, which means that the
old value is always read.
Usage
Register Race
Common Parameters
Parameters
Examples
Example 1
This example illustrates a register race that occurred due to the presence of a blocking
assignment and a read value of a register on the same clock.
Rule Configuration
Register Race
Analyzed Code
module regrace3 (input [3:0] in1, in2, input clk, output reg [7:0] out1,
out2);
reg [4:10] x, x1;
always @(posedge clk) // Violation 3, Associated Violation 7

begin
x[4:7] = in1;
out2[7:4] = x1[4:7];
end
always @(posedge clk) // Violation 1, 5

begin
x[8:10] = in1;
x1[4:9] = {in2, in1[3:1]};
x1[10] = in1[0];
end
always @(posedge clk) // Associated Violation 2, 4, 6

begin
out1<= x;
out2[3:0] = x1[8:10];
end
endmodule
Violations Produced
• Blocking assignment made to register 'x[8:10]', which is read in another sequential
block. – Violation 1
• + Reading register 'x[8:10]', which is assigned blockingly in another sequential block,
will lead to a race. – Associated Violation 2
• Blocking assignment made to register 'x[4:7]', which is read in another sequential block.
– Violation 3
• + Reading register 'x[4:7]', which is assigned blockingly in another sequential block,
• Blocking assignment made to register 'x1[4:10]', which is read in another sequential
block. – Violation 5
• + Reading register 'x1[8:10]', which is assigned blockingly in another sequential block,
• + Reading register 'x1[4:7]', which is assigned blockingly in another sequential block,
Example 2
This example illustrates a potential register race due to the presence of a blocking assignment
and a read value of a register on different clocks.
Rule Configuration
Register Race
Analyzed Code
module regrace4 (input [3:0] in1, input clk1, clk2, output reg [3:0]
out1);
reg [3:0] x;
always @(posedge clk1) // Violation

begin
x = in1;
end
always @(posedge clk2) // Associated Violation

begin
out1<= x;
end
endmodule
Violations Produced
• Blocking assignment made to register 'x[3:0]', which is read in another sequential block.
– Violation
• + Potential race for register ‘x[3:0]', which is written blockingly and read on different
clocks. – Associated Violation
Range Base Rules
Range Base Rules

The Range base rules check proper usage of vector widths and ranges.

Matching Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Non-Static Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Constrained Ranges and Bounds

Checks that all vectors have bounds and that integer and natural numbers have ranges. In
addition, Verilog nets can be checked that assigned values are sized. In this case single-bit
signals are ignored and literal assignments to multi-bit nets will result in a violation. The
following bases are considered: b, d, o, h.
Usage
Constrained Ranges & Bounds
Common Parameters
Applies To
Range / Bound
Range Type
Parameters
• Applies To
Specify to which object/s the check applies. The default is <all>.
o Ports
o Generics
o Signals
o Variables
o Types
o Nets [Verilog only]
o For loop Indexes
o <all>
• Range / Bound
Specify to which types the check applies. The default is <all>.
o Vector Bounds
o Integer Ranges [Includes: Integer, Positive, Natural]
o Real Ranges
o Assigned Value Size [Verilog only]
o <all>
• Range Type
Optionally check specified range has Positive or Natural range values. The default is <don’t
care>.
o Positive
o Natural
o <don’t care>
Examples
Example 1
Checks that type declarations of base type Integer have ranges.
Rule Configuration
• Range/Bound — Integer Ranges
• Range Type — <don’t care>

Analyzed Code
package my_package is
TYPE new_int_type is array (0 downto 1) of integer; -- Violation
end package;
Violation Produced
Integer types must have ranges.
Example 2
Check for any loop integer index ranges that are not positive/natural depending on user input.
Ignore any non-integer ranges.
Rule Configuration
• Applies To — For Loop indexes
• Range/Bound — Integer Ranges
• Range Type — positive
Analyzed Code
For I in result ‘RANGE loop
--loop body
end loop;
for I in –7 to 0 loop --Violation

--loop body
end loop;
Violation Produced
For loop index integer range should be positive

• Integer types must have ranges.
• Integer types must have natural ranges.
• Real types must have ranges.
Note
Specify the range, bound, or size of a specific type of statement.
Related Topics
Matching Range
Matching Range
Checks that bit widths are matching on the left and right hand sides of assignments and
operands of logical and arithmetic operators. Furthermore, this rule checks the bit widths
between the formals and actuals of instances and sub-programs. In addition, out-of-bound
indexes, vector reference to scalars, and the consistency between port and net declarations in
Verilog are also checked. Optionally, the rule can be configured to skip the following:
mismatches in sizes of operands of overloaded operators, increments of a variable/signal which
result in only a single-bit overflow, and size mismatches of signed/unsigned expressions.
It should be noted that VHDL language semantics already cover all mismatching range checks
except out-of-bounds indexes. The effects of synthesis may result in different violations from
those expected from looking purely at the code.
Usage
Matching Range
Common Parameters
Match
Ignore
Parameters
• Match
Specify the scope for bit-width matching. The default is Explicit Widths in Assignments,
Explicit Widths in Associations, Operands of comparison operators, Port & Net
Declarations (Verilog only) and Disallow Vector Reference to Scalars.
o Explicit Widths in Assignments
o Explicit Widths in Associations
o Operands of comparison operators
o Operands of arithmetic/bitwise operators
o Out of Bounds Indexes
o Port & Net Declarations (Verilog only)
o Disallow Vector Reference to Scalars
• Ignore
Specify the type of bit-width mismatches which can be ignored. The default is <none>.
o Size mismatches of operands of overloaded operators
Matching Range
o Increments to signals/variables resulting in single-bit overflow

o Size mismatches of signed/unsigned expressions
o Size mismatches of natural/integer expressions
o <none>
Description
Important Notes:
• To be able to set the value “Size mismatches of operands of overloaded operators” for
the Ignore parameter, note the following:
It would not be possible to select this value unless at least one of the values “Operands
of comparison operators” or “Operands of arithmetic/bitwise operators” from the
“Match” parameter is also selected.
• To be able to set the value “Increments to signals/variables resulting in single-bit
overflow” for the Ignore parameter, note the following:
It would not be possible to select this value unless “Explicit Widths in Assignments”
value from the “Match” parameter is also selected.
Increment to a signal/variable is of the form:
<sig> <= <sig> + <constant>
This normally results in a size-mismatch violation because the addition of the constant
can lead to an overflow.
However, when this value is selected, if the potential overflow does not exceed one bit,
no violation is reported.
In other words, when this value is selected, no size mismatch violations are produced if
all of the following conditions are fulfilled:
o The signal/variable on the left and right of the assignment is exactly the same.
o The increment factor is a constant.
o The increment does not result in an overflow of more than one bit.
• The value “Size mismatches of signed/unsigned expressions” is applicable to VHDL
only. When this value is selected, signed/unsigned matches will be ignored for the
following “Match” parameter checks:
Matching Range
• The value “Size mismatches of natural/integer expressions” is applicable to VHDL only.

When this value is selected, natural/integer matches will be ignored for the following
“Match” parameter checks:
Examples
Example 1
Check for various bit-width mismatches.
Rule Configuration
Analyzed Code
module match (in1, in2, in3, out1, out2, out3);
input [3:0] in1, in2, in3;
output [3:0] out1, out2, out3;
reg [4:0] out3; // Violation 1
function [3:0] func;

input [2:0] in1;
begin
if(in1[0] == 1'b0)
func = in1 + 1;
else
func = in1 - 1; // Violation 2
end
endfunction
assign out1 = {in1[0], in1[3]}; // Violation 3

begin
if(in1 == 3'b000) // Violation 4
begin
out3[4:1] = func(in2); // Violation 5
out3[0] = 3'b010; // Violation 6
end
end
endmodule
Violations Produced
• Port 'out3' has mismatching vector ranges between its I/O declaration ([3:0]) and its
internal wire declaration ([4:0]). – Violation 1
• Bit widths differ on left (4) and right (3) of assignment. – Violation 2
• Bit widths differ on left (4) and right (3) of relational operator '=='. – Violation 4
Matching Range
• Bit widths differ between formal 'in1' (3) and actual 'in2' (4) for call to function 'func'. –
Violation 5
Related Topics
Non-Static Ranges
Non-Static Ranges
Checks for the usage of non-static slices in expressions, since they are not synthesizable. It is
applicable to VHDL only, since Verilog does not allow non-static ranges. Any violation of this
rule will result in the synthesizability violation as well.
Usage
Non-Static Ranges
Common Parameters
Parameters
Examples
Example 1
Check for the usage of non-static ranges in assignment.
Rule Configuration
Analyzed Code
library ieee;
entity nonStatRange is
port (in1, in2 : in std_logic_vector(31 downto 0);
sel1, sel2 : in integer range 0 to 15;
end;
architecture arch_nonStatRange of nonStatRange is

begin
sm_proc: process(in1, in2) is
variable local_var1, local_var2 : std_logic_vector (1 DOWNTO 0);
begin
local_var1 := in1 (sel1 + 1 downto sel1); --This is not a violation,
since the range is actually static although the left and right indices are
not.
local_var2 := in2 (sel1 + sel2 downto sel1); -- Violation
end process;
end;
Violation Produced
Use of non-static part-select.
Register Base Rules
Register Base Rules

The Register base rules check for aspects related to the design’s registers.
Asynchronous Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Asynchronous Load Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Blocking Nonblocking Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Latch Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Register Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Register Controllability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Register IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Register Reset Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Register Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
SV Always Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Asynchronous Block
Asynchronous Block
Checks that asynchronous Verilog always blocks are coded in a synthesizable manner. Always
blocks should not contain more than one sequential statement or constructs other than IF-ELSE.
The rule can optionally also detect:
Synchronous always blocks which have asynchronous resets and empty always blocks (block
controls a null statement or a begin-end block containing no statements).
Usage
Asynchronous Block
Common Parameters
Detect
Parameters
• Detect
Specify which additional check to perform. The default is <all>.
o Multiple sequential statements
o Empty block
o <all>
Examples
Example 1
always @(posedge clk or negedge rst )
begin : proc2
div_data=div_msb_lsb[0] ; // Violation
sample = 1 ;
end
Violation Produced
Asynchronous always block contains more than one sequential statement. This may not be
synthesizable. Use a cascade of if-else-if.
Note
Asynchronous always block contains more than one sequential statement, this may not be
synthesizable.
Asynchronous Load Signals

Checks for flip-flops which have asynchronous load signals. An asynchronous load signal is the
one which sets the value of a register to a non constant value independent of the clock edge.
Usage
Common Parameters
Parameters
Examples
Example 1
Check for usage of asynchronous load signals.
Analyzed Code
always @(posedge clk or posedge reset or posedge load) // Violation
begin
if(reset)
out1<= 4'b0000;
else if(load)
out1 <= in1;
else
begin
if(sreset)
out1 <= 4'b0000;
else
out1 <= in2;
end
end
Violation Produced
Register 'out1' has an active high asynchronous load, 'load'.
Related Topics

Language support: Verilog Only (including SystemVerilog)
Checks that the specified Verilog assignment operator (blocking/nonblocking) is used for the
given type of assignments. These may be sequential assignments to registers or latches, or
combinational assignments. The scope of these assignments may be pure combinational blocks,
sequential blocks or combinational blocks which infer latches.
Usage
Common Parameters
Applies To
Assignment Type
Assignment Operator
Description
Blocking and nonblocking assignment operators have different semantics. Whereas the
blocking assignment completes the assignment immediately, the nonblocking assignment
simply evaluates the right hand side expression at the beginning of the time step while the
update takes place only at the end of the time step. Use of blocking assignments can cause
problems when a variable being assigned in one procedural block is also being read in another
and both the events are scheduled in the same time step, for example on the same clock edge.
This can lead to unpredictable results, because which procedural block will be executed first by
the simulator is not deterministic. However, if nonblocking assignments are used, then the
results will be deterministic because the values that will be assigned at the end of the time step
are the ones that are present at the start of the time step before any statements have been
executed. Further, pipeline registers in a single always block can only be modeled using
nonblocking assignments. So it is generally desirable to model sequential logic (latches/flip-
flops) using nonblocking assignments. On the other hand, for combinational logic, generally the
update is required immediately and hence blocking assignments are recommended.
Parameters
• Applies To
Specify the type of always block that the rule is to be applied to. The default is Sequential
Block.
o Pure Combinational Block
o Combinational Block Inferring Latches
o Sequential Block
Note
A combinational block inferring latches is one which models one or more latches,
irrespective of the rest of the logic modeled by that block. A pure combinational
block on the other hand, is one which does not model any latches.
• Assignment Type
Specify the type of assignment that is to be checked. The default is Sequential Assignment
and Combinational Assignment.
o Sequential Assignments
o Combinational Assignments
Note
Sequential Assignment represents assignments to both latches and flip-flops.
• Assignment Operator
Specify the assignment operator that is to be checked. The default is Nonblocking.
o Blocking
o Nonblocking
Note
Typically, a given variable can be assigned at multiple points in an always block.
The operator for all these assignments has to be the same (blocking/nonblocking),
otherwise this is non-synthesizable. Hence, it is sufficient to point to one of the
assignments of this variable which violates the rule configuration. The tool points to the
first assignment of that variable.
Examples
Example 1
Check that register and latch assignments in a sequential block are nonblocking.
Rule Configuration
• Applies To — Sequential Block
• Assignment Type — Sequential Assignments
• Assignment Operator — Nonblocking
Analyzed Code
module blknonblk1 (input [3:0] in1, in2, input clk, reset,
output reg [3:0] out1, out2);
begin
if(reset)
begin
out1 = 4'b0000; // Violation 1
out2 = in1; // Violation 2
end
else
out1 = in2;
end
endmodule
Violations Produced
• Register assignments in a sequential block should be nonblocking. – Violation 1
• Latch assignments in a sequential block should be nonblocking. – Violation 2
Example 2
Check that all assignments in a combinational block inferring latches are blocking.
Rule Configuration
• Applies To — Combinational Block Inferring Latches
• Assignment Type — Sequential Assignments, Combinational Assignments
• Assignment Operator — Blocking

Analyzed Code
module blknonblk2 (input [3:0] in1, in2, input [1:0] sel,
always @(in1 or in2 or sel)
begin
if(sel == 2'b00)
out1 <= in1 & in2; // Violation 1
else if (sel == 2'b01)
out1 <= in1 | in2;
else if (sel == 2'b10)
out1 <= in1 ^ in2;
if(in1[0] == 1'b0)
out2 <= in1; // Violation 2
else
out2<= in2;
end
endmodule
Violations Produced
• Latch assignments in a combinational block inferring latches should be blocking. –
Violation 1
• Combinational assignments in a combinational block inferring latches should be

blocking. – Violation 2
Related Topics
Register Race

Checks that all registers use only the allowed clock edge. Optionally, this check can be limited
to FSM state variable registers only.
Usage
Common Parameters
Allowed Clock Edge
Applies To
Parameters
• Allowed Clock Edge
Specify the allowed clock edge polarity.
• Applies To
Specify the components to which the rule should apply. The default is FSM State Variable
Registers and Other Registers.
o Other Registers
Examples
Example 1
Check that all clock usages are at positive edge only.
Rule Configuration
• Allowed Clock Edge — Positive
• Applies To — FSM State Variable Registers, Other Registers
Analyzed Code
LIBRARY ieee;
ENTITY EdgeControl IS
PORT(
d1, d2, clk_neg, clk_pos, rst: in std_logic;
q1, q2: out std_logic
);
END ENTITY EdgeControl;
--
ARCHITECTURE arch1 OF EdgeControl IS
begin
PROCESS(clk_neg, clk_pos, rst) -- Violation
BEGIN
if (clk_pos'event and clk_pos='1') then
if(rst = '1') then
q1<= '0';
else
q1 <= d1;
end if;
end if;
if (rst = '0') then
q2 <= '1';
elsif (clk_neg'event and clk_neg='0') then
q2 <= d2;
end if;
end process;
END ARCHITECTURE arch1;
Violation Produced
Clock 'clk_neg' is used at 'negative edge'.
Example 2
Checks that all the FSM registers are using negative clock edges only.
Rule Configuration
• Allowed Clock Edge — Negative
Analyzed Code
module fsm (out, inp, clk, enb, cnd, rst);
output out;
reg out;
input [7:0] inp;
input clk, enb, cnd, rst;
parameter [2:0] s0 = 3'h0, s1 = 3'h1, s2 = 3'h2, s3 = 3'h3,

s4 = 3'h4, s5 = 3'h5, s6 = 3'h6, s7 = 3'h7;
reg [2:0] cst, nst;
always @(posedge clk or posedge rst) // Violation 1
if (rst)
cst<= s0;
else
cst <= nst;
always @(cst or inp or enb)

casex (cst)
s0: begin out = inp[0]; if (enb) nst = s2; end
endcase
Violation Produced
FSM Clock 'clk' is used at 'positive edge'.
Related Topics
Consistent Clocks
Input Synchronizer
Input Synchronizer
Checks primary inputs driving combinatorial logic before being synchronized. It supports
cascading flip-flops synchronizer style with asynchronous set/reset.
Usage
Input Synchronizer
Common Parameters
Minimum Synchronizer Stages
Description
You can specify the number of required synchronizer stages using the “Minimum Synchronizer
Stages” parameter.
This rule raises a violation if a primary input is found to drive combinatorial logic directly or
after being synchronized with an insufficient number of synchronizer stages.
The rule distinguishes between “not synchronized input ports” and “not sufficiently
synchronized input ports” as follows.
• Any input port synchronized with N-stage synchronizer (minimum value for N = 1), and
N is still below the number of synchronizer stages specified in the configured rule, then
it is considered as “not sufficiently synchronized input port”.
• In some cases, the clock enable signal may be used to synchronize a signal instead of
using N-stage synchronizer, yet, it still requires validation. This is depicted in analysis
results using the following violation: “Some input ports might not be synchronized with
a sufficient number of stages before driving combinatorial logic, Perhaps it is indirectly
synchronized by a clock enable signal.”
Parameters
• Minimum Synchronizer Stages
Specify the minimum number of flip-flops that will be considered a synchronizer. A signal
that is an output of a number of flip-flops that are equal or greater than the value of this
parameter is considered synchronized. The default is 2.
o <positive integer>
Examples
Example 1
This example detects primary inputs driving combinatorial logic before being synchronized
with a 2-stage synchronizer.
Input Synchronizer
Rule Configuration
• Minimum Synchronizer Stages — 2
Analyzed Code
`resetall
`timescale 1ns/10ps
module input_synchronizer_doc(input in_drives_comb, //Violation 1

in_1stage, //Violation 2
in_2stages,
clk,
rst,
output out1);
// intermediate flip flop signals

reg mid_1stage;
reg mid1_2stages, mid2_2stages;
// combinatorial logic
assign out1 = in_drives_comb&& mid_1stage && mid2_2stages;
// stage 1 flip flops

if(rst)
begin
mid_1stage <= 0;
mid1_2stages <= 0;
end
else
begin
mid_1stage <= in_1stage;
mid1_2stages <= in_2stages;
end
// stage 2 flip flops

’always @(posedge clk or posedge rst)
if(rst)
mid2_2stages <= 0;
else
mid2_2stages <= mid1_2stages;
endmodule
Violations Produced
• Input port 'in_drives_comb' is not synchronized before driving combinatorial logic. –
Violation 1
• Input port 'in_1stage' is not synchronized before driving combinatorial logic. – Violation
2
Example 2
This example detects the following:
• Primary inputs driving combinatorial logic before being synchronized.
Input Synchronizer
• Primary inputs driving combinatorial logic before being synchronized with sufficient
number of stages.
• Primary inputs driving combinatorial logic before being synchronized with sufficient
number of stages but enable signal is used, so perhaps it is indirectly synchronized by a
clock enable signal.
Rule Configuration
• Minimum Synchronizer Stages — 3
Input Synchronizer
Analyzed Code
LIBRARY ieee;
ENTITY Synchronizer IS
PORT(
input,clk : IN std_logic;
rst : IN std_logic;
syncSig : OUT std_logic
);
END Synchronizer ;
ARCHITECTURE SynchronizerArch OF Synchronizer IS

SIGNAL sync1,sync2 : std_logic;
BEGIN
clock_enable_pulse_process : PROCESS(clk, rst)
BEGIN
IF (rst = '0') THEN
sync1 <= '1';
sync2 <= '1';
ELSIF clk'EVENT AND clk = '1' THEN
sync1 <= input;
sync2 <= sync1;
END IF;
END PROCESS;
syncSig <= sync2;
END SynchronizerArch;
LIBRARY ieee;
ENTITY Top IS
PORT(
input1 : IN std_logic; --Violation 1
clk : IN std_logic;
enable : IN std_logic;
rst : IN std_logic;
sout : OUT std_logic
);
END Top ;
ARCHITECTURE archTop OF Top IS

SIGNAL reg_withEnableSignal : std_logic;
SIGNAL inputReg1, syncInputReg1 : std_logic;
component Synchronizer
PORT( input,clk : IN std_logic;
rst : IN std_logic;
syncSig : OUT std_logic
);
end component;
BEGIN
-- "2 stage" synchronizer for input2 before driving comb. logic

sync : Synchronizer port map
Input Synchronizer
( input => input2,

clk => clk,
rst => rst,
syncSig => syncInputReg1 );
-- Clock enable signal for input3 before driving comb. logic

process(rst, clk) begin
if (rst = '1') then
reg_withEnableSignal<= '0';
elsif (rising_edge(clk)) then
if (enable = '1') then
reg_withEnableSignal <= input3;
end if;
end if;
end process;
sout <= reg_withEnableSignal and syncInputReg1 and input1;
END archTop;
Violations Produced
• Input port 'input1' is not synchronized before driving combinatorial logic. – Violation 1
• Input port 'input1' is not synchronized with a sufficient number of stages before driving
combinatorial logic. – Violation 2
• Input port 'input1' is not synchronized with a sufficient number of stages before driving
combinatorial logic, Perhaps it is indirectly synchronized by a clock enable signal. –
Violation 3
Latch Inference
Latch Inference
Checks for inference of latches resulting from some conditions under which a signal holds its
previous value. The rule detects latches inferred from combinatorial logic (for example, signal
<= signal feedback latch due to a missing else). Registers with an inferred signal <= signal
feedback due to a missing else are not detected by this rule.
Usage
Latch Inference
Common Parameters
Parameters
Examples
Example 1
This example detects latches in conditional operators in Verilog.
Rule Configuration
Analyzed Code
module verlatch (input in1, sel, output out1); // Violation
assign out1 = sel ? in1 : out1;
endmodule
Violation Produced
Latch(es) inferred for net ‘out1’.
Example 2
This example detects latches in VHDL sequential processes.
Rule Configuration
Latch Inference
Analyzed Code
library ieee;
entity vhdlatch is
port (in1, in2, in3, in4 : in std_logic; out1 : out std_logic;
end;
architecture arch of vhdlatch is

begin
process (in1, in2, in3, in4) -- Violation
begin
if(in4 = '0') then
out2(3)<= in1;
out2(0) <= in2;
else
out2 <= (others => in3);
end if;
end process;
end;
Violation Produced
Latch(es) inferred for net 'out2(2 downto 1)'.
Related Topics
Register Control Signals

Checks for any registers with asynchronous preset and clear inputs. Any register with an invalid
state, due to having asynchronous preset and clear inputs at the same time, is reported. Note that
the effects of synthesis may result in different violations from those expected from looking
purely at the code.
Usage
Common Parameters
Detect
Parameters
• Detect
Specify the type of registers to be checked. The default is Registers with asynchronous
preset and clear.
Examples
Example 1
Check for registers with asynchronous preset and clear inputs.
Rule Configuration
• Detect — Registers with asynchronous preset and clear
Analyzed Code
LIBRARY ieee;
entity Reg_rst_prst is
port( CLR, PR, CLK : in std_logic;
D1 : in std_logic;
Q1 : out std_logic
);
end entity Reg_rst_prst;
architecture arch of Reg_rst_prst is

begin
D_FF1: Process(CLR, PR, CLK) -- Q1 -- Violation
begin
if CLR = '1' then
Q1<= '0';
elsif PR = '1' then
Q1 <= '1';
elsif rising_edge(CLK) then
Q1 <= D1;
end if;
end process D_FF1;
end architecture arch;
Violation Produced
The register "Q1" has both asynchronous preset and clear.
Related Topics
Register Controllability
Checks whether all state bits (registers/latches) can be controlled from the inputs. A state bit
might suffer from a dead-end value, which means that the bit drives a constant unless an
asynchronous reset is applied. A state bit might also suffer from a stuck-at-fault, which means
that the bit always drives a constant value, irrespective of any changes in the inputs, including
resets. Note that the effects of synthesis may result in different violations from those expected
from looking purely at the code.
Usage
Common Parameters
Check For
Check Partial Buses
Parameters
• Check For
Specify the type of control violation to be reported. The default is Dead-End Value and
Stuck-at-Fault.
• Check Partial Buses
Specify whether violations are to be produced for partially violating buses (e.g. a bus
wherein only some bits are dead-end/stuck-at). The default is Yes.
Note
Important Notes:
• In case of VHDL records and SV structs, a violation on a field of the record/struct
will be considered a partial bus violation.
• In case a bus is completely stuck-at, but partially stuck-at-0 and partially stuck-at-1,
then no violation will be produced for this bus if “Check Partial Buses” is set to
“No”. See Example 3.
• In case a bus is completely stuck-at a particular value, but is partially driven from
different always blocks/processes, then no violation will be produced for this bus if
“Check Partial Buses” is set to “No”. See Example 3.
Examples
Example 1
This example illustrates a dead-end value scenario.
Rule Configuration
• Check For — Dead-End Value

Analyzed Code
module deadend(output reg [3:0] out1, input clk, reset,
input [3:0] in1);
wire [3:0] p1;
assign p1 = in1[3:0] | ~in1[3:0];
always @(posedge clk or posedge reset) // Violation
begin
if(reset)
out1<= 4’b0000;
else
out1 <= p1;
end
endmodule
Violation Produced
State bit(s) ‘out1’ may reach a dead end value of 1.
Example 2
This example illustrates a stuck-at-0 fault scenario.
Rule Configuration
• Check For — Stuck-at-Fault

Analyzed Code
module stuckat (output reg [3:0] out1, input clk, reset,
input [3:0] in1);
parameter p1 = 2’b00;
begin
if(reset)
out1<= 4’b0000;
else
out1 <= {in1[3:2], p1};
end
endmodule
Violation Produced
State bit(s) ‘out1[1:0]’ has/have stuck-at-0 fault.
Example 3
This example illustrates the rule behavior when the “Check Partial Buses” parameter is set to
“No”.
Rule Configuration
• Check For — Dead-End Value, Stuck-at-Fault
• Check Partial Buses — No

Analyzed Code
module partialrc (input [3:0] in1, in2, input clk, reset,
output reg [3:0] out1, out2, out3, out4);
begin
if(reset)
begin
out1<= 4'b0000;
out2 <= 4'b1010; // Out2 is partially stuck-at-0 and partially
stuck-at-1, hence no violation
out3[1:0] <= 2'b00; // Out3 is partially stuck-at in different
always blocks, hence no violation
out4 <= 4'b0000; // Out4 is partially stuck-at, hence no violation
end
else
begin
out1 <= 4'b1111;
out2 <= 4'b1010;
out3[1:0] <= 2'b00;
out4[1:0] <= in1[1:0];
end
end

begin
if(reset)
out3[3:2] <= 2'b00;
else
out3[3:2] <= 2'b00;
end
endmodule
Violation Produced
State bit(s) 'out1' may reach a dead end value of 1.
Related Topics
Register IO
Register IO
Checks if the specified input and output ports have been registered. By default, asynchronous
controls are excluded from this check but the rule can be manually configured to have them
checked. Similarly, non-clocked blocks can be skipped from this check. This is a design wide
check.
Usage
Register IO
Common Parameters
Detect Multiple Registrations
Applies To
Applies To Non-Clocked Blocks
Check Inputs
Check Outputs
Check Asynchronous Controls
Treat Latches as Registers
Description
For output ports, the register needs to be inferred within the module, whereas for input ports, a
register can be inferred either within the module or for the net which is connected to the input
port from outside.
As seen in the figure below, In1 and In2 are input ports. For In2, the register is inferred within
the module, whereas for In1, the register is inferred for the net to which it is externally
connected. Both cases are not considered Register IO violations. On the other hand, O2 which is
an output port, requires the register to be inferred inside the module, and in the absence of this,
a violation will be produced for O2 even though it is externally connected to a register.
Register IO
It should be noted that in case of direct paths through hierarchy, the Register IO violation will
not be flagged for intermediate points, even though the conditions mentioned above are
violated. As shown in the figure below, the violation will be populated only for the port
indicated by the red arrow. It will not be populated for the ports indicated by the green arrows.
A necessary condition for producing a Register IO violation is that a port must drive (or be
driven by) combinational logic other than buffers. The mere presence of buffers would not
qualify for Register IO violations because buffers can be removed or added by synthesis tools
without any change of functionality. However, inverters are treated as combinational logic and
their presence would result in Register IO violations. Also, latches are treated as either registers
or combinational logic depending upon the value of the corresponding rule parameter that has
been provided for latches.
Parameters
• Detect Multiple Registrations
Specify whether a violation should be raised if an input is registered more than once. The
default is No.
Note
Setting this parameter to “Yes” affects both the “Check Asynchronous Controls” and
“Treat Latches as Registers” parameters, as they will also be automatically set to
“Yes”.
• Applies To
Specify the type of blocks to which this rule is to be applied. The default is Top-Level Block
and Sub-Blocks.
Register IO
It is important to note that if the Top-Level Block parameter is selected and the Sub-Blocks
parameter is not selected, all Register IO violations appear at the top-level IOs only. In such
a case, if a top-level port drives some combinational logic that is not present at the top-level
design unit itself but is present somewhere inside the design hierarchy, then a primary
Register IO violation appears for the top-level port and a corresponding associated violation
appears for the port of the instance in which the combinational logic being driven is actually
present.
Also, if the Sub-Blocks parameter is selected and the Top-Level Block parameter is not
selected, then top-level IOs are not considered for Register IO violations and only sub-block
level (non top-level) IOs are checked. Hence, if a design unit with no instances is selected
for check, then this design unit is treated as a top-level block, and the IOs of this top-level
block will be checked only if the Top-Level Block parameter is selected and not if the Sub-
Blocks parameter is individually selected.
Note that if both the Top-Level Block and Sub-Blocks parameters are selected, violations
will appear for all unregistered ports of the top-level design unit and its instances except
those ports which lie on direct paths through the hierarchy (as illustrated in the Description
section above). So in this case the tool does not violate for any port that is neither driving
nor is being driven by combinational logic and this includes such ports of the top-level
design unit as well. Note that in this case, a violation is not produced for a top-level port that
has only direct hierarchical connections. This is because if the user selects both the
parameters Top-Level Block and Sub-Blocks, they will get a violation anyway for the port
of the instance that is closest to the combinational logic (because Sub-Blocks parameter is
selected) even if no combinational logic is adjacent to the top-level port and there is no
chance of a miss in pointing out the design issue.
However, if the user selects the parameter Top-Level Block only, there is a possibility that
combinational logic lying somewhere deep down the design hierarchy is adjacent to some
port that is in turn connected to a top-level port via direct connections, and the tool does not
violate for either the top-level port (because combinational logic is not adjacent to this port)
or the port inside the design hierarchy (because Sub-Blocks parameter is not selected).
Hence, in such a case, a violation is still produced for the top-level port in question with an
associated violation for the port of the instance that is driving (or is being driven by) the
combinational logic.
• Applies To Non-Clocked Blocks
Specify whether pure combinational blocks should be checked. The default is No.
• Check Inputs
Specify the type of inputs which need to be checked.The default is All Inputs.
o All Inputs
o FSM Inputs
o <none>
Register IO
• Check Outputs
Specify the type of outputs which need to be checked.The default is All Outputs.
o All Outputs
o FSM Outputs
o <none>
• Check Asynchronous Controls
Specify whether asynchronous controls should be checked. The default is No.
• Treat Latches as Registers
Specify whether latches should be treated as registers or as combinatorial elements. The
default is Yes.
Examples
Example 1
Check that all outputs and inputs are registered.
Rule Configuration
Analyzed Code
module regio (input in1, in2, input clk, reset,
output out1, out2);
reg temp;
temp <= in1;
bottom inst (temp, in2, clk, reset, out1, out2); // Violation 1
endmodule
module bottom (input in1, in2, input clk, reset,

output reg out1, out2); // Violation 2
always @(in1)
out1<= in1 & in2;
out2 <= in1 | in2;
endmodule
Violations Produced
• Input 'inst.in2' is used without being registered. – Violation 1
• Output 'out1' is used without being registered. – Violation 2
Related Topics

Checks the style (synchronous/asynchronous) and the polarity (active high/active low) of
register resets. The rule can be configured to check that all registers in a design have a reset (of
any style) or have a specific style (synchronous/asynchronous). The reset polarity can also be
checked if required. Note that multi-dimensional signal/reg declarations modeled as memories
are not considered in this check. The effects of synthesis may result in different violations from
those expected from looking purely at the code.
Usage
Common Parameters
Applies To
Reset Mode
Reset Polarity
Ignore Non-Required Reset Mode
Skip
Parameters
• Applies To
Variable Registers, Pipeline Registers, Input Registers and Other Registers.
o Input Registers
Means that an input port is connected to the d-input of the register.
Note
If a register is connected to an internal signal it will not be considered as an input
register (even if an input port is connected to that internal signal).
o Other Registers
• Reset Mode
Specify the reset mode to be used for all registers. The default is Synchronous.
o Synchronous
o Asynchronous
o <any>
Means that the register must simply have a reset. The exact reset mode
(synchronous/asynchronous) does not matter.
• Reset Polarity
Specify the reset polarity to be used.The default is <don’t care>.
o Active High
o Active Low
o <don’t care>
Means that the polarity is not checked.
• Ignore Non-Required Reset Mode
Specify whether it is valid for a register to have both reset modes (that is, both the required
mode and non-required mode).The default is No. If this parameter is set to “Yes”, the check
would flag missing required mode but ignore any occurrences of non-required reset mode. If
set to “No”, the occurrences of non-required reset modes would also get flagged.
• Skip
Specify if there are certain types of always blocks/processes which should be skipped (not
checked). The default is <none>.
o Clocked Blocks Which Do Not Contain Any Reset
Implies that reset mode violations should not be reported for registers in clocked
blocks which do not contain any resets at all. Refer to Example 2.
o <none>
Additional Information about Pipeline Registers:
Pipeline registers are characterized by the following:
o Chain of registers 2 or more in number wherein the output of one register feeds the
input of the other without any intervening logic.
o Note that if two registers are connected using a buffer (internal signal), it will not be
considered as a pipeline chain.
o These registers need to have the same clock, however, the rest of the controls may
differ.
o The potential start of any pipeline register chain is a register which does not feed a
register directly.
Examples
Example 1
Check whether all registers have a synchronous reset, and report occurrences of non-required
reset styles.
Rule Configuration
• Applies To — FSM State Variable Registers, Pipeline Registers, Input Registers, Other
Registers
• Reset Mode — Synchronous
• Reset Polarity — <don’t care>
• Ignore Non-Required Reset Mode — No
• Skip — <none>
Analyzed Code
module syncasyncreset (input clk, arst, srst, input [3:0] in1, in2,
always @(posedge clk or posedge arst) // Violation 1, 2

if(arst)
begin
out1<= 4'b0000;
out2 <= 4'b0000;
end
else
begin
if(srst)
out1 <= 4'b0000;
else
begin
out1 <= in1;
out2 <= in2;
end
end
endmodule
Violations Produced
• Input Register 'out1' must not be initialized using asynchronous reset. – Violation 1
• Input Register 'out2' has not been initialized using synchronous reset. – Violation 2
Example 2
In this example, DesignChecker should skip clocked blocks which do not contain a reset.
Rule Configuration
Registers
• Reset Mode — Asynchronous
• Reset Polarity — <don’t care>
• Skip — Clocked Blocks Which Do Not Contain Any Reset

Analyzed Code
entity noreset is
port (in1, in2 : in bit_vector(3 downto 0);
clk, reset : in bit;
out1, out2, out3 : out bit_vector(3 downto 0));
end;
architecture arch of noreset is

begin
process (clk) –- No Violation (This process does not contain any reset,
so there is no violation for out1.)
begin
if(clk'event and clk = '1') then
out1 <= in1;
end if;
end process;
process (clk, reset) –- Violation (This process contains an

asynchronous reset, so there is a violation for out3 here.)
begin
out2<= (others => '0');
elsif(clk'event and clk = '1') then
out2 <= in2;
out3 <= in1;
end if;
end process;
end;
Violation Produced
Input Register 'out3' has not been initialized using asynchronous reset.
Example 3
In this example, DesignChecker should violate for all instances of 'active low' reset.
Rule Configuration
Registers
• Reset Mode — <any>
• Reset Polarity — Active High
• Skip — <none>
Analyzed Code
library ieee;
entity superMix3 is
port (din, din2, din3, rst, rst1, clk, load, clk_fsm,clk_fsm2 : in
std_logic;
dout,dout_2,dout_3 : out std_logic);
end superMix3;
architecture rtl of superMix3 is

begin
begin
clk1 <= clk;
clk2 <= clk;
end process;

begin
if (rst = '0') then –- Violation 1
dout <= '1';
else
dout <= din;
end if;
end if;
if (rst1 = '0') then -- Violation 2
dout_2<= '0';
else
dout_2 <= din2;
end if;
end if;
end process;

begin
case cst is
when "000" =>
nst <= "001";
when "001" =>
nst <= "101";
when "101" =>
nst <= "111";
when "111" =>
nst <= "100";
when "100" =>
nst <= "010";
when others =>
nst <= "000";
end case;
end process;

begin
case cst2 is
when "000" =>
nst2 <= "001";
when "001" =>
nst2 <= "101";
when "101" =>
nst2 <= "111";
when "111" =>
nst2 <= "100";
when "100" =>
nst2 <= "010";
when others =>
nst2 <= "000";
end case;
end process;

begin
cst <= nst;
cst2 <= nst2;
dout_3 <= din3;
end if;
end process;
end rtl;
Violations Produced
• Synchronous Reset 'rst' is used as an 'active low' reset. – Violation 1
• Asynchronous Reset 'rst1' is used as an 'active low' reset. – Violation 2
Related Topics
Edge Detection
Register Types
Register Types
Checks that data is registered using permissible types like signals, variables and shared
variables only.
Usage
Register Types
Common Parameters
Disallowed Types
Parameters
• Disallowed Types
Specify the types that are not allowed to register data. The default is Variables and Shared
Variables.
o Variables
o Shared Variables
o Signals
Examples
Example 1
Check that only signals are allowed to register data.
Rule Configuration
• Disallowed Types — Variables, Shared Variables
Register Types
Analyzed Code
library ieee;
entity regtypes is
clk, reset, sel : in std_logic;
end;
architecture arch of regtypes is

begin
process (clk, reset) – Associated Violation 2
variable temp : std_logic_vector(3 downto 0); -- Primary Violation 1
begin
temp := (others => '0');
elsif(clk'event and clk = '1') then
if (sel = '1') then
temp := in1;
else
temp := in2;
end if;
end if;
out1<= temp;
end process;
end;
Violations Produced
• Do not use variable ‘temp’ as a register. – Primary Violation 1
• + Variable 'temp' is used to register data. – Associated Violation 2
SV Always Blocks
SV Always Blocks
The SystemVerilog language defines new types of always blocks like always_latch and
always_comb to indicate the design intent to simulation, synthesis and formal verification tools.
This rule checks if there is any discrepancy between the type of always block and the logic that
is inferred inside it; for example, an always_comb block for which a latch gets inferred.
Usage
SV Always Blocks
Common Parameters
Parameters
Examples
Example 1
Check for combinational logic being inferred inside an always_latch block.
Rule Configuration
Analyzed Code
module combinalwayslatch(in1,in2,clk,out1);
input wire [2:0] in1;
output reg [2:0] out1;
input wire clk,in2;
always_latch // Violation
if(in2 == 1'b0)
out1 = in1;
else if (in2 == 1'b1) // out1 is assigned in all possible paths, so no
latch is inferred.
out1 = ~in1;
endmodule
Violation Produced
Combinational Logic inferred for net 'out1' inside always_latch block.
Example 2
Check for latches being inferred inside an always_ff block.
Rule Configuration
SV Always Blocks
Analyzed Code
module latchinalwaysff(in1,rst,clk,en,out1);
input wire [1:0] in1;
output reg [1:0] out1;
input wire clk,en,rst;
always_ff@(posedge clk or posedge rst or posedge en) // Violation
begin
if(rst)
out1[1] = 1'b1;
else if (en)
out1[1] = in1[1]; // Latch inferred for out1[1].
else
out1[0] = in1[0];
end
endmodule
Violation Produced
Latch inferred for net 'out1[1]' inside always_ff block.
Report Base Rules
Report Base Rules

The Report base rules report different design info.
Arithmetic Gate Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

Design Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
FSM Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Memory Element Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
String Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Checks for arithmetic elements (that is, Adders/Subtractors, Multipliers and Counters) in the
design.
Usage
Common Parameters
Report
Parameters
• Report
Specify which arithmetic elements in the design should be reported. The default is Adders,
Multipliers and Counters. Note that the value “Adders” checks for both adders and
subtractors in the design.
Description
This rule reports the arithmetic elements detected in the design:
Adders/Subtractors and Multipliers

In addition to adders, subtractors are also reported since a subtraction operation is the same as
an addition operation with two’s complement. For adders, the adder size is reported. For
multipliers, the output and input sizes are reported.
It should be noted that adders and multipliers are not inferred for scalar inputs. Both inputs need
to be vectors greater than 1-bit in size.
Counters
DesignChecker can detect both synchronous (clock-dependent) and combinatorial/
asynchronous counters. Only a case of increment/decrement by 1 is detected as a counter. Also,
counters less than 3-bit in size are not inferred. The pattern for synchronous and combinatorial/
asynchronous counters is as follows:
Synchronous Counters
The code snippet below illustrates the pattern which is inferred as a synchronous counter. The
example below contains all the possible controls for a synchronous counter, but not all of them
are mandatory. Even a synchronous increment/decrement by 1 would be inferred as a counter.
always@(posedge clk or posedge areset or posedge aset)

begin
if(areset)
out1 <= 4’b0000;
else if (aset)
out1 <= 4’b1111;
else if(clk_en)
if(sreset)
out1 <= 4’b0000;
else if (sset)
out1 <= 4’b1111;
else if(sload)
out1 <= data;
else if(cnt_en)
if(updn)
out1 <= out1 + 1;
else
out1<= out1 – 1;
end
Asynchronous (Combinatorial) Counters
The following code snippet illustrates the pattern of an asynchronous counter.
always @(mode or updn or a or k)

begin
if(mode)
d <= k;
else if (updn)
d <= a + 1;
else
d <= a – 1;
end
A latch-based counter is also inferred as a combinatorial counter.
always @(rst or updn or mode or k)

begin
if(rst)
d <= 0;
else if(mode)
d <= k;
else if (updn)
d <= a + 1;
end
Examples
Example 1
Check the arithmetic elements in the design.
Rule Configuration
• Report — Adders, Multipliers, Counters
Analyzed Code
module addmultctr (input [3:0] in1, in2, in3, input clk, load, reset,
output reg [3:0] out1, output reg [7:0] out2, out3);

begin
out1[3:0] = in1 + in2; // Violation 1
out2 = in1 * in2; // Violation 2
end

begin
if(reset)
out3 = 0;
else if(load)
out3 = in3;
else
out3 = out3 + 1; // Violation 3
end
endmodule
Violations Produced
• Adder detected. – Violation 1
# Adder Size: 4
• Signed multiplier detected. – Violation 2
# Output Size: 8
# Input Sizes: 4, 4
• Counter inferred for net 'out3'. – Violation 3
# Counter Type: Synchronous
Design Report
Design Report
Reports different items in the design which can be used to measure design complexity,
understandability, etc. It allows you to create customizable reports about the design. The rule’s
parameters accept text embedded with variables. In the report, these variables are substituted
with the corresponding values for the checked design. For each top-level design unit, a violation
is produced, and the variables are substituted differently according to the corresponding top-
level design unit and its underlying design.
Usage
Design Report
Common Parameters
Report Summary
Report Details
Parameters
• Report Summary
Define the report summary which will be displayed as the violation message (in one line).
The default is Report for design: "%(rpt_top_design_unit)".
This parameter accepts any text which references any of the variables defined in the
“Reported Items” section below. At least rpt_top_design_unit variable must be referenced.
• Report Details
Define the report content (supports multiple lines).The default is:
Design "%(rpt_top_design_unit)" has the following information:
%(rpt_num_top_ports_in) top-level input ports
%(rpt_num_top_ports_out) top-level output ports
%(rpt_num_hier_levels) hierarchical levels
%(rpt_num_design_units) entities/modules
%(rpt_num_processes) process/always blocks
%(rpt_num_includes) included files
%(rpt_num_hdl_lines) HDL lines
%(rpt_num_hdl_statements) HDL statements
This parameter accepts any text which references any of the variables defined in the
“Reported Items (Variables)” section below.
Design Report
• Reported Items (Variables)

Elements to be reported can be accessed by referencing different variables. A variable can
be referenced by using the format %(variable_name). The supported variables are:
Variable Name Description
rpt_top_design_unit The name of the design hierarchy’s top design unit.
rpt_top_library The library name of the design hierarchy’s top design unit.
rpt_num_top_ports_in The total number of input ports or pins for the top design
unit (which is reported by rpt_top_design_unit variable).
rpt_num_top_pins_in Ports or pins of ports with VHDL “buffer” or “linkage” port
modes and VHDL/Verilog “inout” port mode are also
counted.
See the note on pins below.
rpt_num_top_ports_out The total number of output ports or pins for the top design
unit (which is reported by rpt_top_design_unit variable).
rpt_num_top_pins_out Ports or pins of ports with VHDL “buffer” or “linkage” port
modes and VHDL/Verilog “inout” port mode are also
counted.
See the note on pins below.
rpt_num_hier_levels The maximum number of design hierarchy levels. The top
design unit is considered as one hierarchal level. For
example, a design with “top” design unit which instantiates
a “leaf” design unit has “2” hierarchical levels.
rpt_num_design_units The number of design units (entities/modules) in the design
hierarchy. Multiple instances of the same design unit are
only counted once.
rpt_num_processes The number of VHDL “process” and Verilog “always”
blocks defined in the design units of the design hierarchy. If
a design unit is instantiated multiple times in the design
hierarchy, the processes defined in this design unit are
counted only once (and not for each instantiation).
rpt_num_includes The number of unique files included by the files involved in
the design hierarchy. If the same file is included many times,
it is counted once.
rpt_num_hdl_lines The number of HDL lines that describe all design units (and
any used packages) in the design hierarchy. The lines of
Verilog directives and VHDL “library” and “use” clauses
are counted. Blank lines or lines containing comments only
are not counted.
Design Report
Variable Name Description

rpt_num_hdl_statements The number of HDL statements that describe all design units
in the design hierarchy. Declarations are not considered as
HDL statements so they are not counted; this also applies to
design unit declarations which means that declaring an
empty Verilog module or VHDL architecture results in a
design with a number of HDL statements that equals zero.
rpt_num_comments_lines The number of lines which contain comments text. These
lines could have comments text only or comments with HDL
code. Empty commented lines are not counted.
rpt_num_comments_only_lines The number of lines which contain comments only. Empty
commented lines are not counted.
rpt_comments_density The density of comments in the design calculated by the
following formula: %(rpt_num_comments_lines) /
(%(rpt_num_comments_lines) + %( rpt_num_hdl_lines)).
rpt_num_blank_lines The number of blank lines. These are lines that have neither
HDL code nor comment. Blank lines may only have spaces,
tabs, or just a carriage return.
Note
A “pin” represents a “bit” so, for example, a port defined as std_logic_vector(7
DOWNTO 0) has 8 pins. In case the number of pins is unknown (because of an
unresolved type size due to the absence of its definition), then the variables are
substituted with the value “unknown” along with an indication to the unresolved type
size. For example: “<unknown – unknown type ‘bus_type’ of port ‘p_bus’>”. The
number of pins for VHDL numeric types (such as integer, positive, etc.) is calculated as
log2 of the maximum value the port can have, and for signed types one bit is added. The
number of pins for enumerated types is calculated as log2 of the number of enumerated
values.
Examples
Example 1
Report the number of input/output pins for the top-level design unit and the number of design
units.
Rule Configuration
• Report Summary — Report for design with top-level unit "%(rpt_top_design_unit)".
• Report Details — Top-level design unit “%(rpt_top_design_unit)” has

%(rpt_num_top_pins_in) input pins and %(rpt_num_top_pins_out) output pins.
The design has %(rpt_num_design_units) design units and %(rpt_num_hier_levels)
hierarchical levels (depth).
Design Report
Analyzed Code
LIBRARY ieee;
ENTITY top IS -- Violation
PORT (in1 : IN std_logic(3 DOWNTO 0);
out1 : OUT std_logic(7 DOWNTO 0));
END ENTITY;

BEGIN
i1: leaf PORT MAP(in1, out1(7 DOWNTO 4));
i2: leaf PORT MAP(in1, out1(3 DOWNTO 0));
END ARCHITECTURE;
-- ---------------------------------------------------------
LIBRARY ieee;
ENTITY leaf IS
PORT (in1 : IN std_logic(3 DOWNTO 0);
out1 : OUT std_logic(3 DOWNTO 0));
END ENTITY;
ARCHITECTURE rtl OF leaf IS

BEGIN
PROCESS(in1)
BEGIN
out1<= in1;
END PROCESS;
END ARCHITECTURE;
Violation Produced
Report for design with top-level unit "top".
Top-level design unit “top” has 4 input pins and 8 output pins.
The design has 2 design units and 2 hierarchical levels (depth).
FSM Report
FSM Report
reports all the finite state machines inferred in the design along with their state variables and
number of states. A tabulated report mentions the state names and the corresponding literals. A
“state” for an FSM is defined as a constant value against which the FSM state variable is
compared, or a constant value which the FSM state variable is assigned.
It should be noted that the valid states for an inferred finite state machine are those states which
are reachable from the reset state. In the absence of an explicit reset state, the FSM will be
reported as not having any externally reachable states. Also, a valid FSM is characterized by the
presence of appropriate state transitions that occur on a clock edge. If no clocked transitions can
be found in the HDL code, the tool will not identify the code as representing an FSM. Note that
the effects of synthesis may result in different violations from those expected from looking
purely at the code.
Usage
FSM Report
Common Parameters
Parameters
Examples
Example 1
Report the finite state machines inferred in the design.
Rule Configuration
FSM Report
Analyzed Code
Library IEEE;
entity test01 is
port (CLOCK, RESET : in STD_LOGIC;
A, B, C, D, E: in BOOLEAN;
SINGLE, MULTI, CONTIG: out BOOLEAN);
type enum_1 is (S0, S1, S2, S3);
end test01;

signal CS, NS: enum_1;
beginSYNC_PROC: process (CLOCK, RESET)
begin
if (RESET='1') then
CS <= S0;
CS <= NS;
end if;

begin
case CS is -- Violation
when S0 =>
NS<= S1;
if(A) THEN
MULTI <= TRUE;
END IF;
when S1 =>
NS <= S2;
MULTI <= B;
when S2 =>
NS <= S3;
MULTI <= C;
when S3 =>
NS <= S0;
MULTI <= D;
end case;
end process; -- End COMB_PROC
end BEHV;
Violation Produced
Detected a 4-state FSM with state variable CS[1:0].
# State Encoding Table
# State Name Literal
# S0 00
# S1 01
# S2 10
# S3 11
FSM Report
Related Topics
FSM Coding Style
FSM Transitions

Reports the occurrence of tri-state drivers in the design along with their enables. Also, this rule
detects RTL code which models a memory. It should be noted that memory inference is tool-
specific and hence the actual memories reported by a given tool and their characteristics may
vary from tool to tool.
Usage
Common Parameters
Report
Parameters
• Report
Specify whether to report RTL which models a memory, and/or tri-states in the design along
with their enables. The default is Memories and Tri-States.
Examples
Example 1
Report memories and tri-states in the design.
Rule Configuration
• Report — Memories, Tri-States
Analyzed Code
module mem (input [7:0] in1, in2, input [2:0] addr,
input rden, wren, clk, sel1, sel2, sel3,
output reg [7:0] out1, output [3:0] out2); // Violation 2, 3
reg [7:0] mem1 [7:0]; //Violation 1

begin
if(wren)
out1<= mem1[addr];
else if (rden)
mem1[addr] <= in1;
end
assign out2[3:2] = sel1 ? in1[3:2] : 'bz;

assign out2[1:0] = sel2 ? in1[1:0] : 'bz;
assign out2 = ~sel3 ? in2 : 'bz;
endmodule
Violations Produced
• Memory inferred for net 'mem1', depth = 8, width = 8. – Violation 1
# No. of read accesses= 0
# No. of write accesses= 0
# No. of read-write accesses= 1
• Tristate bus detected for net 'out2[1:0]'. – Violation 2
# Enables
# 1. sel2
# 2. not(sel3)
• Tristate bus detected for net 'out2[3:2]'. – Violation 3
# Enables
# 1. sel1
# 2. not(sel3)
Related Topics
Multiple Drivers
String Report
String Report
Reports the occurrence of specific strings in HDL files.
Usage
String Report
Common Parameters
Expression(s)
Match Case
Violation Message
Parameters
• Expression(s)
Specify a regular expression. Design file contents are matched with the expressions and
each occurrence is reported. The default is <none>.
o <user-defined>
o <none>
• Match Case
Specify whether string matching is case sensitive or not.The default is Yes.
• Violation Message
Specify the information to be reported in the violation message. The default is Expression,
matching string.
o Expression, matching string
o Expression, matching string & full line
Examples
Example 1
Disallow coverage on/off pragmas.
Rule Configuration
• Expression(s) — ^[ \t]*//[ \t]*coverage[ \t]+(on|off)
• Violation Message — Expression, matching string & full line
String Report
Analyzed Code
module top;
reg temp;
// coverage off - Violation 1
reg temp1;
//COVERAGE on - Violation 2
endmodule
Violations Produced
• String "// coverage off" matches expression "^[ \t]*//[ \t]*coverage[ \t]+(on|off)". Full
line: // coverage off – Violation 1
• String "//COVERAGE on" matches expression "^[ \t]*//[ \t]*coverage[ \t]+(on|off)".
Full line: //COVERAGE on – Violation 2
Sensitivity Base Rules
Sensitivity Base Rules

The Sensitivity base rules perform checks relates to process/always sensitivity list.
Event Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Sensitivity List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Event Controls
Event Controls
Checks for the presence of potentially non-synthesizable event controls.
Usage
Event Controls
Common Parameters
Description
Some of the event controls that this rule checks are actually non-synthesizable. Such event
control specifications produce a synthesizability violation as well. The rest are considered
synthesizable by the tool, however, they are violated for, since all tools may not consider these
as synthesizable. The following event controls are flagged by this rule:
• Complex expressions found in the sensitivity list of a combinational always block

(Synthesizable)
• Complex expressions found in the sensitivity list of a sequential (edge-triggered) always
block (Non-synthesizable)
• REPEAT event control specifications (Non-synthesizable)
• Tasks having event control specifications (Non-synthesizable)
• Sensitivity list containing both edge and non-edge specifications (Non-synthesizable)
• Always block sensitive to both the positive and negative edges of the same signal (Non-
synthesizable)
• Event control expressions in assignments (Synthesizable)
Note
purely at the code.
Parameters
Examples
Example 1
Check for potentially non-synthesizable event controls.
Event Controls
Analyzed Code
module eventctrl (input in1, in2, clk, reset, output reg out1, out2,
out3);
always @(in1 | in2) // Violation 1
out1 <= in1 & in2;
always @(clk)
out2 <= @(clk) in1 | in2; // Violation 2
always @(clk)
begin
repeat (4) @(in1); // Violation 3
out1 = in1;
end
endmodule
Violations Produced
• Complex expression specified in the sensitivity list. – Violation 1
• Event control specification encountered in assignment. – Violation 2
• Repeat event control specification encountered. – Violation 3
Related Topics
Sensitivity List
Sensitivity List
Checks that the sensitivity list of a VHDL process or Verilog block includes the required signals
and does not include any unnecessary signals. It also checks for the appearance of duplicate
elements or slices of vector signals in the sensitivity list.
Usage
Sensitivity List
Common Parameters
Check For
Parameters
• Check For
Specify which group(s) of signals to check for. The default is Missing Signals, Unneeded
Signals, Sliced Signals and Duplicate Signals
o Missing Signals
o Unneeded Signals
o Sliced Signals
o Duplicate Signals
Note
It is important to note the following:
• The “Duplicate Signals” parameter checks for completely duplicate signals only. It
does not check for scenarios like (a[3:0] or a[2:1]) or (a[3:0] or a [6:2]).
• The “Unneeded Signals” parameter checks for completely unneeded signals as well
as partially unneeded signals. If “Sliced Signals” are disallowed, DesignChecker
shows violations only on completely unneeded signals, otherwise it shows violations
on completely and partially unneeded signals.
Examples
Example 1
Check for extra, missing, sliced and duplicate signals.
Rule Configuration
• Check For — Missing Signals, Unneeded Signals, Sliced Signals, Duplicate Signals
Sensitivity List
Analyzed Code
module senslist1 (input [3:0] in1, in2, input sel, output reg [3:0] out1);
always @(in2 or sel or sel) // Violation 1, 2, 3
begin
if(sel)
begin
out1[0]<= in2[0];
out1[3:1] <= 3'b110;
end
else
out1 <= in1;
end
endmodule
Violations Produced
• Duplicate signal(s) 'sel' encountered in the sensitivity list. – Violation 1
• Sensitivity list of process/always statement includes unneeded signal(s) 'in2[3:1]'. –
Violation 2
• Incomplete sensitivity list for process/always statement. Signal(s) 'in1' is/are needed. –
Violation 3
Style Base Rules
Style Base Rules

The Style base rules perform checks related to coding styles.
Assignment Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Dangling Else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Declaration Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Enclosed Block Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
File References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Indentation Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Statement Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Verilog Statement Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Assignment Alignment
Checks that a group of assignment statements or declaration initializations are aligned together.
A group of assignments/declarations should have all of its statements in consecutive lines. A
new line or a comment line splits the statements into two groups that are checked separately.
Only statements that appear at the beginning of the line and end at the same line are checked.
Statements spanning multiple lines or appearing at the same line after another statement are not
checked.
For two statements to be aligned they should fulfill the following:
- Their assignment operators should be aligned. If the assignment operators have different sizes
(e.g., "=" and "<="), then operator ends should be aligned.
- The beginning of their right hand side should be aligned.
Usage
Common Parameters
Applies To
Tab Width
Parameters
• Applies To
Specify the types of assignment statements to be checked. Declaration initializations can
also be checked. The default is Sequential Assignments.
o Concurrent Assignments
o Continuous Assignments
o Sequential Assignments
o Declaration Initializations
• Tab Width
Specify the equivalent number of spaces of a single tab character. Each tab character found
in the statement is considered equivalent to a number of space characters specified by this
parameter. The default is 3.
o <user-defined> [Integer ranging from 0 to 10]
Examples
Example 1
Check the alignment of sequential assignment statements.
Rule Configuration
• Applies To — Sequential Assignments
• Tab Width — 3
Analyzed Code
LIBRARY ieee;
ENTITY address_decode IS
PORT(
addr : IN std_logic_vector (2 DOWNTO 0);
clk_div_en : OUT std_logic;
clr_int_en : OUT std_logic;
ser_if_select : OUT std_logic_vector (1 DOWNTO 0);
xmitdt_en : OUT std_logic
);
END address_decode ;
ARCHITECTURE rtl OF address_decode IS

BEGIN
-----------------------------
decode_proc: PROCESS(addr)
-----------------------------
BEGIN
-- Defaults
clk_div_en <= '0'; -- Associated Violation 1.1
xmitdt_en <= '0'; -- Associated Violation 1.2
clr_int_en <= '0'; -- Associated Violation 1.3
ser_if_select <= "11"; -- Violation 1
CASE addr IS
WHEN "000" =>
clk_div_en <= '1';
WHEN "001" =>
clk_div_en <= '1';
WHEN "100" =>
ser_if_select <= addr(1 downto 0); -- Violation 2
WHEN "101" =>
ser_if_select <= addr(1 downto 0);
WHEN "110" =>
ser_if_select <= addr(1 downto 0);
WHEN "111" =>
clr_int_en <= '1';
WHEN OTHERS =>
clk_div_en <= '0'; -- Violation 3
ser_if_select <= "11";
clr_int_en <= '0'; -- Associated Violation 3.2
END CASE;
END PROCESS decode_proc;
END rtl;
Violations Produced
• All assignments within this group should be aligned to this assignment statement –
Violation 1
• + Assignment operator has to be shifted 3 spaces to the right – Associated Violation 1.1
Violation 2
Violation 3
• + Assignment right-hand-side has to be shifted 3 spaces to the left – Associated
Violation 3.1
• + Assignment right-hand-side has to be shifted 2 spaces to the left – Associated
Violation 3.2
Example 2
Check the alignment of declaration initializations.
Rule Configuration
• Applies To — Declaration Initializations
• Tab Width — 3
Analyzed Code
`resetall
`timescale 1ns/10ps
module declarations;
parameter WIDTH = 3; -- Associated Violation 1.1
parameter HEIGHT = 7; -- Violation 1
// ...
endmodule
Violations Produced
Violation 1
• + Assignment operator has to be shifted 1 space to the right – Associated Violation 1.1
Dangling Else
Dangling Else
Detects any dangling Else statements. The dangling Else problem occurs in Verilog when the
Begin/End block statement is not used. As a result, when using nested If statements, it is not
clear which If statement is associated with the dangling Else.
Usage
Dangling Else
Common Parameters
Parameters
Examples
Example 1
Check for dangling Else statements.
Rule Configuration
Analyzed Code
module Dangling_Else (a, b);
input a, b;
always @ (*)
begin
if (a)
if (b)
$display ("a and b");
else // Violation
$display ("Not a");
end
endmodule
Violation Produced
If/Else association may be ambiguous.
Declaration Style
Declaration Style
Checks the layout style for Declarations. It checks whether declarations are formatted with each
on a separate line or, in the case of Ports, with each group of ports of the same mode (input,
output etc) on a separate line. Code is more readable if each declaration appears on a separate
line.
Usage
Declaration Style
Common Parameters
Apply To
Declaration Format
Parameters
• Apply To
Specify to which objects the rule applies. The default is <all>
o Ports
o Generics
o Signals
o Variables
o Constants
o Files
o Parameters
o <all>
• Declaration Format
Specify the layout for Interface Declarations. The default is Each Declaration On Separate
Line.
o Each Declaration On Separate Line
o Each Group Starts On Separate Line
Examples
Example 1
Check if signals and files are declared on separate lines.
Declaration Style
Rule Configuration
• Apply To — Signals, Files
• Declaration Format — Each Declaration On Separate Line

Analyzed Code
ARCHITECTURE spec OF status_registers IS
-- Declarations
SIGNAL xmitting_reg, done_xmitting_reg : std_logic; -- Violation 1
file VEC_FILE1_1 : text is in "stim9.vec";signal v1 : bit;file
VEC_FILE1_2 : text is in "stim4.vec"; -- Violation 2
END spec;
Note
Place each declaration on a separate line to improve readability.
Violations Produced
• Multiple signals declared on one line, declarations should be on separate lines. -
Violation 1
• Multiple files declared on one line, declarations should be on separate lines. – Violation
2
Enclosed Block Style

Checks that specified Verilog statements are enclosed within ‘begin’ and ‘end’ statements.
Usage
Common Parameters
Applies To
Parameters
• Applies To
Specify to which construct the rule applies. The default is <all>.
o Always Blocks
o Case Statements
o If Statements
o Initial Blocks
o Loop Statements
Examples
Example 1
Analyzed Code
if (!rst) begin
current_state <= idle;
end
else
begin
current_state <= next_state;
end
Note
Enclose blocks and/or statements within ‘begin’ - ‘end’ pairs.
Violation Produced
Enclose if statement branch within a 'begin'..'end' pair
File References
File References
Checks the path style of referenced files. It also checks the length and uniqueness of the file
names.
Usage
File References
Common Parameters
Applies To
Path
Platform
Max. File Name Length
Make Unique
Uniqueness Width
Case Sensitive
Parameters
• Applies To
Specify to which object/s the rule applies.The default is ìnclude Directives and File
Declarations.
• Path
Specify the required style for referenced file paths. The default is File Name Only.
o File Name Only
o Relative Path
o Absolute Path
• Platform
o DOS
o Unix
• Max. File Name Length
Specify the maximum file name length using. The default is <don’t care>.
o 20
o <don’t care>
o Used-Entered
File References
• Make Unique
Specify if file names are unique. The default is No.
• Uniqueness Width
Specify number of characters considered when checking for file name uniqueness. The
default is <don’t care>.
o 15
o <don’t care>
o Used-Entered
• Case Sensitive
Specify if case sensitivity is considered when checking for file name uniqueness, this is only
applicable on Unix platforms. The default is Yes.
Examples
Example 1
Check that filename references do not use absolute pathnames and filenames are unique within
15 characters.
Rule configuration
• Applies To — File Declarations
• Path — File Name Only, Relative Path
• Platform — DOS, Unix
• Max. File Name Length — <don’t care>
• Make Unique — Yes
• Uniqueness Width — 15
• Case Sensitive — Yes

Analyzed Code
Read_file: process
file inputF1 : TEXT open READ_MODE is “my_input_file_f1.txt”;
file inputF2 : text IS IN :c:\myfolder\my_input_file_f2.txt”; --
Violation
Begin
--process body
end
Violations Produced
Referenced file “c:\myfolder\my_input_file_f2.txt" must not be specified by an absolute path.
Referenced file “my_input_file_f2" must have a unique filename within the first 15 characters.
File References
Example 2
Check that filename references do not use absolute pathnames.
Rule configuration
• Language — VHDL any
• Applies To — File Declarations
• Path — File Name Only, Relative Path
• Make Unique — No
• Uniqueness Width — 15
• Case Sensitive — Yes

Analyzed Code
Read_file: process
file inputF1 : TEXT open READ_MODE is “my_input_file_f1.txt”;
file inputF2 : text IS IN :c:\myfolder\my_input_file_f2.txt”; --
Violation
Begin
--process body
end
Violation Produced
Referenced file “c:\myfolder\my_input_file_f2.txt" must not be specified by an absolute path.
Example 3
Rule configuration
• Language — Verilog
• Applies To — ìnclude Directives
• Path — File Name Only
• Make Unique — No
• Uniqueness Width — <don’t care>
• Case Sensitive — No
File References
Analyzed Code
ìnclude "./inc/timescale.v"
Violation Produced
Referenced file "./inc/timescale.v" must be specified by a file name onlyHint:Use the
Note
Use the recommended path style for referenced files.
Indentation
Indentation
Checks that statements are indented by the specified number of indentation spaces.
Usage
Indentation
Common Parameters
Applies To
Spaces Number Limit
Spaces Number
Tab Width
Check Comments
Description
Code should be indented by a certain pattern in order to enhance its readability. This rule checks
the indentation of different types of statements. The rule works as follows:
• It checks that each statement is indented relative to its enclosing scope (parent
statement) according to the specified number of indentation spaces.
• It checks the indentation of certain keywords within some statements.
• Moreover, it checks that a comment located above a statement has the same indentation
of the associated statement.
This rule checks that each statement of any of the selected type(s) in the “Applies To” parameter
is indented by a specified number of spaces. This indentation is measured relative to the
enclosing statement (i.e. the parent statement) of the statement. In other words, the rule checks
the difference between the indentation of a statement and the indentation of its enclosing scope.
In general, the indentation of a line is calculated as the number of “spaces” at the beginning of
the line. If the beginning of the line contains a “Tab” or more, then each tab is converted to its
equivalent number of spaces (as specified by the “Tab Width” parameter).
The indentation of a “statement” is calculated as the indentation of the first line of the statement.
For VHDL, the indentation of the “enclosing scope” is calculated as the indentation of the line
containing the “BEGIN” keyword. This applies to PROCESS, ARCHITECTURE, BLOCK,
etc. Similarly, it is measured as the indentation of “THEN” for “IF Statement”, “ELSE” for
ELSE blocks, LOOP for loops, WHEN for CASE Statement and so on. An exception of this
rule is applied for declarative statements; where they appear before the “BEGIN” keyword. In
this case, the indentation of the enclosing scope is measured as the indentation of the first line of
the statement.
For Verilog/SystemVerilog, the indentation of the “enclosing scope” is calculated as the

indentation of the first line of the statement. However, when the statements inside “enclosing
Indentation
scope” are bounded by a “Sequential Block (begin-end)” or “Parallel Block (fork-join)” then the
indentation of the enclosing scope is calculated as the line containing the “begin” or “fork”
keyword.
As a result of the previous note, when “Sequential Blocks” or “Parallel Blocks” is selected in
the “Applies To” parameter, then all statements of these types are checked. However, such
statements that are considered as block boundaries for other statements as indicated in the
previous note are not checked. On the other hand, they can be checked as “keywords”
associated with their statements.
Parameters
• Applies To
Specify the statements for which the indentation should be checked. This parameter
contains many types of statements grouped into the following groups: VHDL Statements,
VHDL Declarations, Verilog Statements, and Verilog Declarations. The default is <VHDL
Statements>, <VHDL Declarations>, <Verilog Statements> and <Verilog Declarations>.
o <VHDL Statements>: [Contains VHDL non-declaration statements]
• VHDL ASSERTION
• VHDL ASSIGNMENT
• VHDL BLOCK
o First line of VHDL BLOCK
o Keyword BEGIN within VHDL BLOCK
Keyword BEGIN within VHDL BLOCK: Aligned
Keyword BEGIN within VHDL BLOCK: Indented
o Keyword END within VHDL BLOCK
Keyword END within VHDL BLOCK: Aligned
Keyword END within VHDL BLOCK: Indented
• VHDL CASE
o First line of VHDL CASE
o Keyword END within VHDL CASE
Keyword END within VHDL CASE: Aligned
Keyword END within VHDL CASE: Indented
o Keyword WHEN within VHDL CASE
Keyword WHEN within VHDL CASE: Aligned
Keyword WHEN within VHDL CASE: Indented
Indentation
• VHDL EXIT
• VHDL GENERATE
o First line of VHDL GENERATE
o Keyword BEGIN within VHDL GENERATE
Keyword BEGIN within VHDL GENERATE: Aligned
Keyword BEGIN within VHDL GENERATE: Indented
o Keyword END within VHDL GENERATE
Keyword END within VHDL GENERATE: Aligned
Keyword END within VHDL GENERATE: Indented
• VHDL IF
o First line of VHDL IF
o Keyword ELSE within VHDL IF
Keyword ELSE within VHDL IF: Aligned
Keyword ELSE within VHDL IF: Indented
o Keyword END within VHDL IF
Keyword END within VHDL IF: Aligned
Keyword END within VHDL IF: Indented
o Keyword END within VHDL IF
Keyword END within VHDL IF: Aligned
Keyword END within VHDL IF: Indented
• VHDL INSTANCE
• VHDL LOOP
o First line of VHDL LOOP
o Keyword END within VHDL LOOP
Keyword END within VHDL LOOP: Aligned
Keyword END within VHDL LOOP: Indented
o Keyword LOOP within VHDL LOOP
Keyword LOOP within VHDL LOOP: Aligned
Keyword LOOP within VHDL LOOP: Indented
• VHDL NEXT
• VHDL NULL
• VHDL PROCEDURE Call
• VHDL PROCESS
o First line of VHDL PROCESS
Indentation
o Keyword BEGIN within VHDL PROCESS

Keyword BEGIN within VHDL PROCESS: Aligned
Keyword BEGIN within VHDL PROCESS: Indented
o Keyword END within VHDL PROCESS
Keyword END within VHDL PROCESS: Aligned
Keyword END within VHDL PROCESS: Indented
• VHDL REPORT
• VHDL RETURN
• VHDL WAIT
o <VHDL Declarations>: [Contains VHDL declaration statements]
• VHDL ALIAS Declaration
• VHDL ATTRIBUTE Declaration
• VHDL COMPONENT Declaration
• VHDL CONSTANT Declaration
• VHDL FILE Declaration
• VHDL SIGNAL Declaration
• VHDL SUBPROGRAM Body
o First line of VHDL SUBPROGRAM Body
o Keyword BEGIN within VHDL SUBPROGRAM Body
Keyword BEGIN within VHDL SUBPROGRAM Body: Aligned
Keyword BEGIN within VHDL SUBPROGRAM Body: Indented
o Keyword END within VHDL SUBPROGRAM Body
Keyword END within VHDL SUBPROGRAM Body: Aligned
Keyword END within VHDL SUBPROGRAM Body: Indented
• VHDL SUBPROGRAM Declaration
• VHDL TYPE Declaration
• VHDL VARIABLE Declaration
o <Verilog Statements>: [Contains Verilog non-declaration statements]
• Verilog Always Block
o First line of Verilog Always Block
o Keyword “begin” within Verilog Always Block
Keyword “begin” within Verilog Always Block: Aligned
Keyword “begin” within Verilog Always Block: Indented
Indentation
o Keyword “end” within Verilog Always Block

Keyword “end” within Verilog Always Block: Aligned
Keyword “end” within Verilog Always Block: Indented
o Keyword “fork” within Verilog Always Block
Keyword “fork” within Verilog Always Block: Aligned
Keyword “fork” within Verilog Always Block: Indented
o Keyword “join” within Verilog Always Block
Keyword “join” within Verilog Always Block: Aligned
Keyword “join” within Verilog Always Block: Indented
• Verilog Case
o Case-Choice within Verilog Case
Case-Choice within Verilog Case: Aligned
Case-Choice within Verilog Case: Indented
o First line of Verilog Case
o Keyword “endcase” within Verilog Case
Keyword “endcase” within Verilog Case: Aligned
Keyword “endcase” within Verilog Case: Indented
• Verilog Continuous Assignment
• Verilog Disable
• Verilog Event Trigger
• Verilog If
o First line of Verilog If
o Keyword “begin” within Verilog If
Keyword “begin” within Verilog If: Aligned
Keyword “begin” within Verilog If: Indented
o Keyword “else” within Verilog If
Keyword “else” within Verilog If: Aligned
Keyword “else” within Verilog If: Indented
o Keyword “end” within Verilog If
Keyword “end” within Verilog If: Aligned
Keyword “end” within Verilog If: Indented
o Keyword “fork” within Verilog If
Keyword “fork” within Verilog If: Aligned
Keyword “fork” within Verilog If: Indented
o Keyword “join” within Verilog If
Keyword “join” within Verilog If: Aligned
Indentation
Keyword “join” within Verilog If: Indented

• Verilog Initial Block
o First line of Verilog Initial Block
o Keyword “begin” within Verilog Initial Block
Keyword “begin” within Verilog Initial Block: Aligned
Keyword “begin” within Verilog Initial Block: Indented
o Keyword “end” within Verilog Initial Block
Keyword “end” within Verilog Initial Block: Aligned
Keyword “end” within Verilog Initial Block: Indented
o Keyword “fork” within Verilog Initial Block
Keyword “fork” within Verilog Initial Block: Aligned
Keyword “fork” within Verilog Initial Block: Indented
o Keyword “join” within Verilog Initial Block
Keyword “join” within Verilog Initial Block: Aligned
Keyword “join” within Verilog Initial Block: Indented
• Verilog Instance
• Verilog Loop
o First line of Verilog Loop
o Keyword “begin” within Verilog Loop
Keyword “begin” within Verilog Loop: Aligned
Keyword “begin” within Verilog Loop: Indented
o Keyword “end” within Verilog Loop
Keyword “end” within Verilog Loop: Aligned
Keyword “end” within Verilog Loop: Indented
o Keyword “fork” within Verilog Loop
Keyword “fork” within Verilog Loop: Aligned
Keyword “fork” within Verilog Loop: Indented
o Keyword “join” within Verilog Loop
Keyword “join” within Verilog Loop: Aligned
Keyword “join” within Verilog Loop: Indented
• Verilog Parallel Block
o First line of Verilog Parallel Block
o Keyword “join” within Verilog Parallel Block
Keyword “join” within Verilog Parallel Block: Aligned
Keyword “join” within Verilog Parallel Block: Indented
Indentation
• Verilog Parameter Override

• Verilog Procedural Assignment
• Verilog Sequential Block
o First line of Verilog Sequential Block
o Keyword “end” within Verilog Sequential Block
Keyword “end” within Verilog Sequential Block: Aligned
Keyword “end” within Verilog Sequential Block: Indented
• Verilog Specify Block
o First line of Verilog Specify Block
o Keyword “endspecify” within Verilog Specify Block
Keyword “endspecify” within Verilog Specify Block: Aligned
Keyword “endspecify” within Verilog Specify Block: Indented
• Verilog Task Enable
• Verilog Wait
o <Verilog Declarations>: [Contains Verilog declaration statements]
• Verilog Data Declaration
• Verilog Function
o First line of Verilog Function
o Keyword “endfunction” within Verilog Function
Keyword “endfunction” within Verilog Function: Aligned
Keyword “endfunction” within Verilog Function: Indented
• Verilog Genvar Declaration
• Verilog Net Declaration
• Verilog Parameter Declaration
• Verilog Port Declaration
• Verilog Task
o First line of Verilog Task
o Keyword “endtask” within Verilog Task
Keyword “endtask” within Verilog Task: Aligned
Keyword “endtask” within Verilog Task: Indented
For most of the statements, only the indentation of the first line of the statement is checked.
Indentation
For some statements, the indentation of lines containing specific keywords is also checked.
For each keyword, it is possible to define the allowed indentation. This can be done by
selecting/unselecting two nodes under the specified keyword node in the “Applies To” tree.
One of them is used to allow the line containing the keyword to be indented while the other
allows the line to be aligned. Accordingly, the following combinations are available:
a. Checking “Aligned” only: This means that the line containing this keyword shall be
aligned to the first line of the statement being checked.
b. Checking “Indented” only: This means that the line containing this keyword shall be
indented relative to the first line of the statement.
c. Checking both “Indented” and “Aligned”: This means that the line containing the
keyword is allowed either to be aligned to or indented from the first line of the
statement.
d. Unchecking both “Aligned” and “Indented”: This means that it is not required to
check the indentation of the line containing the specified keyword.
For all statements, it is possible to check the indentation of the comment above the
statement (See “Check Comments” parameter below).
“Verilog Data Declaration” includes data declarations of the following types: 'bit', 'logic',
'reg', 'byte', 'shortint', 'int', 'longint', 'integer', 'time', 'shortreal', 'real', 'realtime', 'struct',
'union', 'enum', 'string', 'chandle', 'event', ‘virtual interface’, ‘type reference’ and ‘class
object handles’.
“Verilog Parameter Declaration” includes declarations of types ‘parameter’, ‘localparam’ &
‘specparam’.
• Spaces Number Limit
Specify how the indentation of statements should be checked. The default is Equals.
o “Equals” means that the indentation must match the specified number of spaces.
o “At least” means that the indentation must be at least the specified number of spaces
or more. Also, it implies that indentation is consistent.
o “At most” means that the indentation must be at most the specified number of spaces
or less. Also, it implies that indentation is consistent.
o “Range” means that the indentation must be within a certain range. Also, it implies
that indentation is consistent.
The meaning of indentation being consistent is defined as follows: all statements selected in
the “Applies To” parameter must have the same number of spaces for their indentation
level. This is done regardless of the type of indentation character used (see the “Tab Width”
parameter).
When checking the consistency of indentation, the “majority” rule is used. If the indentation
of a statement has the same number as the majority, then it is considered correct (while
others are considered incorrect). The scope used to determine the majority is the “file”. In
Indentation
other words, the indentation of all statements is checked to be consistent within each file
separately. More than one file may have different indentations; in this case, the majority is
also calculated separately per each file.
The indentation values of keywords within statements (for example: "BEGIN" keyword
within VHDL PROCESS) do not contribute to calculating the majority value. Also, the
indentation of comments does not contribute to calculating the majority.
On the other hand, the indentation of keywords within statements is checked for consistency
when they are actually indented (not aligned).
• Spaces Number
Specify the number of allowed indentation spaces. If the indentation contains a “tab”, then
the equivalent number of “spaces” must be specified here, and hence this shall be calculated
according to the “Tab Width” parameter. The default is 3.
o <user-defined>
If the value of the “Spaces Number Limit” parameter is “Range”, then the value of this
parameter should specify the required range. The range is entered as
“<minimum>:<maximum>”. For example, if the required range is from 2 to 4 spaces, then
the value of the parameter shall be “2:4”. Other than that, the value of the parameter should
be a positive integer or zero.
• Tab Width
Specify the equivalent number of spaces of a single tab character. Each tab character found
in the indentation of a statement is considered equivalent to a number of spaces characters
specified by this parameter. This is used to measure the indentation of a statement in spaces.
The default is 3.
o <user-defined> [Integer ranging from 0 to 10]
• Check Comments
Specify whether it is required to check the indentation of comments above the checked
statements or not. The default is No.
The comments checked are those found above the statements that are being checked
(according to the value of the “Applies To” parameter). Each line of comment is checked to
have the same indentation of the statement below it. In other words, a comment is checked
to be aligned with the statement below it.
For each statement, the comment lines that are checked are the continuous set of comment
lines located just above the statement. It is allowed to have a blank line between this set of
lines and the first line of the statement. See the below examples.
Indentation
Example:
-- These 3 comment lines are not considered as comments of the
-- assignment statement below. This is because there is a blank line
-- separating them from other comment lines above the statement.
-- This line is considered as a comment of the assignment statement.
-- This line is also considered a comment for the assignment
-- statement.
-- This is the continuous set of comment lines above the statement.
x <= ‘1’;
Example:
-- Although there is a single blank line below, this line and the
-- following lines are still considered as comments of the assertion
-- statement below
assert y = ‘0’;
Examples
Example 1
Check that the indentation equals a specified value.
Rule Configuration
• Applies To — <VHDL Statements>, <VHDL Declarations>
• Spaces Number Limit — Equals
• Spaces Number — 2
• Tab Width — 2
Indentation
Analyzed Code
-- VHDL Entity for BCDCounter
LIBRARY ieee ;
ENTITY BCDCounter IS
GENERIC(
prop_delay : time := 10 ns
);
PORT(
cnten : IN std_logic ;
clear : IN std_logic ;
clk : IN std_logic ;
load : IN std_logic ;
dat_in : IN std_logic_vector (3 DOWNTO 0) ;
carry_in : IN std_logic_vector (3 DOWNTO 0) ;
count : OUT std_logic_vector (3 DOWNTO 0) ;
zero : OUT std_logic
);
END BCDCounter ;
-- VHDL Architecture for BCDCounter
LIBRARY ieee ;
architecture spec of BCDCounter is

begin
--------------------------
-- BCD Counter Process -- Violation 1
--------------------------
vhdl_bcd_countv : PROCESS (clk)
VARIABLE int_count : std_logic_vector(3 DOWNTO 0) := "0000" ; --
Violation 2
BEGIN
IF RISING_EDGE(clk) THEN
zero <= '1' ; -- Violation 3
IF clear = '1' THEN
int_count := "0000" ;
ELSIF load = '1' THEN
int_count := dat_in ;
ELSIF cnten = '0' THEN
IF (int_count = "0000") AND (carry_in /= "0000") THEN int_count
:= "1001" ;
ELSE
int_count := unsigned(int_count) - 1 ;
END IF;
ELSE
int_count := int_count ;
END IF;
END IF; -- Violation 4
zero<= (int_count(3) OR int_count(2)) OR (int_count(1) OR
int_count(0));
count <= int_count AFTER prop_delay ;
Indentation
END PROCESS vhdl_bcd_countv ;

end spec;
Violations Produced
• 'Comment' is not aligned to 'Process Statement'. – Violation 1
• 'Variable Declaration' is indented by 0 spaces relative to its enclosing scope. It must be
indented by 2 spaces. – Violation 2
• 'Assignment Statement' is indented by 3 spaces relative to its enclosing scope. It must be
indented by 2 spaces. – Violation 3
• Keyword 'END' is neither aligned to 'If Statement' nor indented by 2 spaces relative to it.
– Violation 4
Example 2
Check that the indentation does not fall below a specified value and is consistent.
Rule Configuration
• Applies To — <Verilog Statements>, <Verilog Declarations>
• Spaces Number Limit — At least
• Spaces Number — 2
• Tab Width — 2
Indentation
Analyzed Code
module accumulator(
clock,
clr,
inc,
ip,
ld,
op
);
// Internal Declarations
input clock;
input clr;
input inc;
input [7:0] ip;
input ld;
output [7:0] op;
wire [7:0] ip;
wire ld;
wire clr;
wire inc;
wire clock;
reg [7:0] op;
always @ (posedge clock)
begin
// Asynchronous Reset // Violation 1
if(clr)
begin
// Reset Actions
op = 0; // Violation 2
end
else begin
// Block 1
if ((ld == 1))
op = ip; // Violation 3
else
if ((inc == 1))
op = op+1;
else
op = op;
end
end // Violation 4
endmodule // accumulator
Violations Produced
• 'Comment' is not aligned to 'If Statement'. – Violation 1
• 'Assignment Statement' is indented by 3 spaces relative to its enclosing scope. It must be
consistent with other statements indented by 2 spaces. – Violation 2
• 'Assignment Statement' is indented by 1 space relative to its enclosing scope. It must be
indented by at least 2 spaces. – Violation 3
• Keyword 'end' is neither aligned to 'Always Block' nor indented by at least 2 spaces
relative to it. – Violation 4
Indentation
Related Topics
Indentation Style
Indentation Style
Indentation Style
Indentation for code should use a specified character. This rule specifies the allowed indentation
character (“space” or “tab”) and violates if the disallowed character is used or if a mix of
“space” and “tab” is used for indenting a line.The rule checks Indented lines, Non-empty lines
which contain code or comments and All source files and included files. Note that if design-unit
level checking is used, the violations are produced only for the lines of the design units involved
in the checked design hierarchy and also the lines which are not related to any design unit (for
example, lines of file headers, etc.).
Usage
Indentation Style
Common Parameters
Allowed Character
Parameters
• Allowed Character
Specify the allowed character that must be used for indentation. The default is Space.
o Space
o Tab
Examples
Example 1
Check that all non-empty indented lines are indented using a “space” character.
Rule Configuration
• Allowed Character — Space
Indentation Style
Analyzed Code
LIBRARY ieee;
ENTITY indentation_style IS
PORT (in1 : IN std_logic;
in2 : IN std_logic; -- Violation 1
END ENTITY indentation_style;
ARCHITECTURE rtl OF indentation_style IS

BEGIN
out1 <= in1 AND in2; -- Violation 2
Violations Produced
• Indentation mixes the use of 'tab' and 'space' characters which is not allowed. The 'space'
character should be used instead – Violation 1
• Indentation uses 'tab' character which is not allowed. The 'space' character should be
used instead – Violation 2
Related Topics
Indentation
Length
Length
Checks that specified objects do not exceed their maximum permitted lengths.
Usage
Length
Common Parameters
Applies To
Max. Length
Min. Length
Parameters
• Applies To
Specify to which objects the check applies. The default is HDL Lines.
o Common
• Clock
• File Names
Refers to the entire file name including extension (e.g. my_file.vhd). It also
refers to the actual name of the file rather than the file type in VHDL designs.
• HDL Lines
• Instances
• Ports
• Resets
• Integers
• Labels
Checks the length of the labels of the following objects:
VHDL: Case statement, Exit statement, If statement, Loop statement, Next
statement, Null statement, Return statement, Wait statement, Assert statement
(concurrent & sequential), Report statement, Assignment statement, Procedure
call statement, VHDL block statement, & Generate block statement
Verilog: Fork-join block, Begin-end block
• FSM Current States
• FSM Next States
• Functions
Length
o VHDL
• Architectures
• Configurations
• Constants
• Entities
• Enum Literals
• Generics
• Packages
• Procedures
• Processes
• Signals
• User-Defined Types
• Variables
o Verilog
• Always Blocks
• Initial Blocks
• Modules
• Internal Nets
• Parameters
• Internal Regs
• Tasks
• Max. Length
Specify the maximum allowed length. The default is 72.
o <don’t care>
o <user-defined>
o 72
Note
The value <don’t care> will allow users to disable the checking for maximum length
in case they are interested in checking minimum length only.
Length
• Min. Length
Specify the minimum allowed length. The default is <don’t care>.
o <don’t care>
o <user-defined>
o 3
Examples
Example 1
Analyzed Code
signal test_signal_length_1_has_a_very_long_name : std_logic;
-- Signal name “test_signal_length_1_has_a_very_long_name” violates
-- maximum length of “32” characters
end rtl;
Violation Produced
Signal name “long_name” violates maximum length of “32” characters
Mixed Combinational Sequential Code

Detects conditional assignments to constants, generics and enums within a clocked process. The
rule can optionally ignore synchronous resets, presets, load, clear and enable signals.
Usage
Common Parameters
Ignore
Parameters
• Ignore
Specify whether synchronous resets can be ignored.The default is <none>.
o Synchronous control signals
o <none>
Examples
Example 1
This example violates on constant assignments and excludes assignments inside sync resets.
Rule Configuration
• Ignore — Synchronous control signals
Analyzed Code
ENTITY example3 IS
port (
clk : in std_logic;
rst_n : in std_logic;
load_a_r : in std_logic;
mux_sel_a_r : in std_logic_vector(2 downto 0);
datapath1_r : in std_logic_vector(7 downto 0);
datapath2_r : in std_logic_vector(7 downto 0);
output_r : out std_logic_vector(7 downto 0)
);
END ENTITY example3;
ARCHITECTURE rtl OF example3 IS

CONSTANT CONST_A : std_logic_vector(7 downto 0) := "00001111";
CONSTANT STUFFING_PATTERN : std_logic_vector(7 downto 0) := "01010101";
CONSTANT AIS_FLAG : std_logic_vector(7 downto 0) := "10101010";
BEGIN
example3_p : process (clk, rst_n)
begin
if (rst_n = '0') then
output_r <= (others => '0');
if (load_a_r = '1') then
output_r <= CONST_A; -- Allow sync reset exceptions
else
case mux_sel_a_r is
when "000" =>
output_r <= datapath1_r;
when "001" =>
output_r <= datapath2_r;
when "010" =>
output_r <= STUFFING_PATTERN; -- Violation 1,
STUFFING_PATTERN is a constant
when "100" =>
output_r <= AIS_FLAG; -- Violation 2, AIS_FLAG is a
constant
when others =>
output_r <= (others => '0'); -- Violation 3
end case;
end if;
end if;
end process example3_p;
Violations Produced
• VHDL sequential process contains conditional constant assignments. This can result in
mismatching simulation vs. synthesis behavior. – Violation 1
Statement Style
Statement Style
Checks that there is no more than one statement on each line. Declarations are excluded unless
there is a declaration on the same line as another statement. “Else” keywords and the Verilog,
“begin” keyword can be excluded from this check.
Usage
Statement Style
Common Parameters
Exceptions
Parameters
• Exceptions
Specify which keywords should be excluded from the check.The default is begin.
o if
o else
o elsif
o else if
o begin
o <none>
Examples
Example 1
Analyzed Code
module top (clk_master, …..);
...
assign x = inX; assign y = inY; assign z = inZ; // Use a separate line
for each HDL statement
end module
Violation Produced
Use a separate line for each HDL statement.
Related Topics
Declaration Style

Checks that Port declarations appear in the required order and that any Verilog internal net
declarations appear after any declarations for I/O ports.
Usage
Common Parameters
Module Port Order
Port & Net Order
Parameters
• Module Port Order
Specify the required relative order for Port declarations.The default is Input Ports, Output
Ports and Inout Ports.
o Input Ports
o Output Ports
o Inout Ports
o <don’t care>
• Port & Net Order
Specify the required relative order for Port declarations and whether implicit net
declarations are allowed. The default is Nets Declared After Ports and Net Order follows
Port Order.
o Nets Declared After Ports
o Net Order follows Port Order
o Disallow Implicit Declarations
o <don’t care>
Examples
Example 1
Analyzed Code
1. module top (clk_master, ….., in1);
2.
3. wire in1; // Internal net declaration(s) must lie just after all IO
declarations ending at line: 8
4. input in1;
5. input in2;
6. wire in2;
7. output o2;
8. wire out2;
9. end module
Violations Produced
• Port Order
Declaration of port “in1” does not follow the order: "input, output, inout"
• Internal Net Order
Internal net declaration(s) must lie just after all IO declarations ending at line: 8
Related Topics
VHDL Statement Order

Checks that ports appear in the required order in the entity. Also this rule ensures that
declarations and statements of architecture/block/generates follow the specified order. This rule
can also check for the presence of use clauses in the architecture declarative region and that the
order of ports in the entity and its component is the same.
Usage
Common Parameters
Entity Port Order
Declaration Order
Statement Order
Additional Checks
Parameters
• Entity Port Order
Specify the required relative order for entity port declarations. The default is Input Ports,
Output Ports, Inout Ports and Buffer Ports.
o Input Ports
o Output Ports
o Inout Ports
o Buffer Ports
o Clock Ports
o Reset Ports
Note
Clock and Reset Ports:
• Clock/Reset Port detection will depend upon the synthesizability of the design
unit. If the design unit is non-synthesizable, then clock/reset ports will be treated
as normal input ports.
• This is not a design-wide check and hence for clock/reset port detection, the
corresponding ports have to be used as clocks/resets within the same design unit.
• Reset ports include both asynchronous as well as synchronous resets.
o <don’t care>
• Declaration Order
Specify the required relative order for declarations in concurrent scopes - architecture, block
and generate. The default is Types and Sub-types, Attributes Declarations, Constants,
Signals, Shared Variables, Subprograms, Components, Configurations and Attributes
Specifications.
o Types and Sub-types
o Attributes Declarations
o Constants
o Signals
o Shared Variables
o Subprograms
o Components
o Configurations
o Attributes Specifications
o <don’t care>
• Statement Order
Specify the required relative order for statements in concurrent scopes - architecture, block
and generate. The default is Generate Statements, Processes, Concurrent Assignments and
Block Statements.
o Generate Statements
o Processes
o Concurrent Assignments
Includes simple/selected/conditional signal assignments and concurrent procedure
calls.
o Block Statements
o <don’t care>
Check for port order match in entities and their components and “use” clauses in
architecture declarative region. The default is Disallow USE clause in architecture
declarative region.
o Component port order should match Entity port order
o Disallow USE clause in architecture declarative region
o <don’t care>
Algorithm for detection of order violation

DesignChecker optimizes the number of violations produced so that the user is provided
with the complete set of out-of-order items in the minimum no. of violations. The algorithm
followed here is as follows:
a. In the given list of items, find out the item that is most out-of-place with respect to
the other items in the list. Being out-of-place implies that there is a lower priority
item ahead in the list, or a higher priority item later in the list.
b. Violate for this item. The reference for this violation is either a lower priority item
ahead in the list (before which the object being violated for should be placed) or a
higher priority item later in the list (after which the object being violated for should
be placed).
c. Remove this item from the list. This item will not figure in any of the subsequent
processing. This is done to ensure that the object which is violated for, does not
appear as a reference for any other subsequent violations.
d. Repeat steps a, b and c until all items are in their correct place, or all items have been
violated for (in which case the list would be empty).
Tip
Important Notes
• Only those components which have been instantiated would be considered for the
entity-component port match check. If there are unused components in the
architecture declarative region, these will not be candidates for this check.
• This check will not apply to undefined design units, since there is no reference entity
to compare against.
• It is possible that the ports in the component are a sub-set of the ports in the entity.
The ports missing from the component definition will not be considered for this
check. These ports will be assumed to be present in the required order.
Examples
Example 1
Check for the required order of entity ports, declarations and statements.
Rule Configuration
• Entity Port Order — Input Ports, Output Ports, Clock Ports
• Declaration Order — Constants, Signals
• Statement Order — Concurrent Assignments, Processes
Analyzed Code
library ieee;
entity stmtorder1 is
clk : in std_logic; -- Primary Violation 5
out1 : out std_logic_vector(3 downto 0); -- Associated Violation
8
out2 : out std_logic;
enable : in std_logic); -- Associated violation 6,Primary
Violation 7
end;
architecture arch of stmtorder1 is

signal temp : std_logic; -- Associated Violation 2
constant vcc : std_logic := '1'; -- Primary Violation 1
begin
process(clk) -- Associated Violation 4
begin
if(enable = vcc) then
end if;
end if;
end process;
out2 <= in1(0) when enable = vcc -- Primary Violation 3

else in2(0);
end;
Violations Produced
• Constant 'vcc' does not maintain the relative order 'Constant - Signal' – Primary
Violation 1
• [+] Place constant 'vcc' before signal 'temp' – Associated Violation 2
• Concurrent assignment does not maintain the relative order 'Concurrent assignment -
Process' – Primary Violation 3
• +] Place concurrent assignment before process – Associated Violation 4
• Clock 'clk' does not maintain the relative order 'Input port - Clock' – Primary Violation 5
• [+] Place clock 'clk' after input port 'enable' – Associated Violation 6
• Input port 'enable' does not maintain the relative order 'Input port - Output port' –
Primary Violation 7
• [+] Place input port 'enable' before output port 'out1' – Associated Violation 8
Example 2
Check for matching component and entity port order, and for use clause in architecture
declarative region.
Rule Configuration
• Entity Port Order — <don’t care>
• Declaration Order — <don’t care>
• Statement Order — <don’t care>
• Additional Checks — Component port order should match Entity port order, Disallow
USE clause in architecture declarative region
Analyzed Code
library ieee;
entity stmtorder2 is
clk : in std_logic;
enable : in std_logic);
end;
architecture arch of stmtorder2 is
component middle is
out1 : out std_logic_vector(3 downto 0); -- Violation 2
clk : in std_logic; -- Violation 3
end component;
use ieee.std_logic_unsigned.all; -- Violation 1
begin
inst : middle port map (in1, in2, out1, clk, enable);
end;
library ieee;
entity middle is
clk : in std_logic;
end;
architecture arch of middle is

begin
process(clk)
begin
if(enable = '1') then
out1<= in1 and in2;
end if;
end if;
end process;
end;
Violations Produced
• Use clause should not appear in the declarative region of an architecture – Violation 1
• Position of port 'out1' is different in the component (3) than in the entity (4) – Violation
2
• Position of port 'clk' is different in the component (4) than in the entity (3) – Violation 3
Related Topics
Sub-Program Base Rules
Sub-Program Base Rules

The Sub-Program base rules check coding style of functions/tasks and their calls.
Operator Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Parameter Association List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Sub-Program Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Sub-Program Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Operator Overloading
Checks that none of the standard operators have been overloaded
Usage
Common Parameters
Parameters
Examples
Example 1
Check for overloaded operators.
Analyzed Code
library IEEE;
use IEEE.std_logic_arith.all;
package pkg is
function "-"(L, R: INTEGER) return INTEGER;
end pkg;
package body pkg is

function "-"(L,R:INTEGER) return INTEGER is -- Violation 1
begin
if(L>R) then
return L-R;
else
return R-L;
end if;
end "-";
end pkg;
Violation Produced
The standard operator ‘-‘ should not be overloaded – Violation 1
Related Topics
Allowed Operators
Parameter Association List

Checks that sub-program calls use the appropriate type of association between the formal and
actual parameters.
Usage
Common Parameters
Applies To
Association
Ignore If Unique Types
Threshold
Parameters
• Applies To
Specify to which sub-program type/s the check should apply. The default is Function call
and Procedure call.
• Association
Specify the type of required parameter association. The default is Named.
o Named
o Positional
• Ignore If Unique Types
Specify whether checking sub-program calls should be skipped if all their parameter
associations have unique types. The default is No.
• Threshold
Specify the minimum number of function/procedure call parameters that triggers the check.
The check is not done if the number of parameters is below the threshold. The default is 5.
o <user-defined>
o 5
Note
The parameter "Ignore If Unique Types" cannot be set to "Yes" while "Association" is set to
"Positional", and vice versa.
Examples
Example 1
Check for function call parameter lists that do not use named association, if the number of
associations is at least 3.
Rule configuration
• Applies To — Function call
• Association — Named
• Ignore If Unique Types — No
• Threshold — 3
Analyzed Code
LIBRARY ieee;
ENTITY param_list_example IS
PORT(din : IN std_logic;
dout1, dout2, dout3 : OUT natural);
END ENTITY param_list_example;
--
ARCHITECTURE arch OF param_list_example IS
FUNCTION big(SIGNAL a, b : IN integer; c, d, e : IN std_logic;
SIGNAL f : IN std_logic_vector(3 DOWNTO 0)) RETURN natural
IS
BEGIN
-- ...
END FUNCTION;
FUNCTION small(SIGNAL a, b : IN integer) RETURN natural IS BEGIN

-- ...
END FUNCTION;
SIGNAL u, v : integer;
SIGNAL w, x, y : std_logic;
SIGNAL z : std_logic_vector(3 DOWNTO 0);
dout1 <= big(u, v, w, x, y, z); -- Violation
dout2<= big(a => u, b => v, c => w, d => x, e => y, f => z);
dout3 <= small(u, v);
-- ...
Violation Produced
Use named association in function calls.
Sub-Program Body
Sub-Program Body
This rule can check a number of aspects related to sub-programs. Checks include: having at
least one exit point, not having multiple exit points, the return statement being the last
statement, sub-programs not being recursive and not accessing (read or assign to) variables/
signals which are not local to the scope of the sub-program, the return statement not returning
any expression, and code sharing through procedure calls in concurrent statements not being
available.
Usage
Sub-Program Body
Common Parameters
Sub-Program
Allow Assign To
Disallow
Parameters
• Sub-Program
Specify to which sub-program type(s) the check should apply. The default is Functions and
Procedures / Tasks.
• Allow Assign To
Specify whether assignments are allowed to local and/or non-local variables/signals within
the sub-program. The default is Local Variables.
o Local Variables
o Non-local Variables
o <don’t care>
• Disallow
Specify which aspects are not allowed within a sub-program. The default is Multiple exit
points/return statements, Exit point/return statement not the last statement, Missing exit
point/return statement, Recursion and Referencing non-local variables.
o Multiple exit points/return statements
o Exit point/return statement not the last statement
o Missing exit point/return statement
o Recursion
o Referencing non-local variables
Sub-Program Body
o Code Sharing
o Expression return statements
o Incomplete Outputs Assignments
o Signal Parameters with OUT Mode [VHDL Only]
o <don’t care>
Examples
Example 1
Check for referencing non-local variables in Verilog.
Rule Configuration
• Sub-Program — Functions
• Allow Assign To — <don’t care>
• Disallow — Referencing non-local variables

Analyzed Code
module subprog1 (input [3:0] in1, in2, output reg [3:0] out1);
function [3:0] add; // Violation
input arg1;
begin
add = arg1 + in2;
end
endfunction

out1<= add(in1);
endmodule
Violation Produced
Function 'add' uses signal/variable 'in2' declared outside the scope.
Example 2
Check for the following: multiple return statements, the return statement being the last
statement in the function, the function output being undefined in one of the paths in the VHDL
function, and returned expressions.
Rule Configuration
• Disallow — Multiple exit points/return statements,

Exit point/return statement not the last statement,
Sub-Program Body
Expression return statements,

Incomplete Outputs Assignments
Analyzed Code
library ieee;
ENTITY subprog2 IS
PORT (in1, in2 : IN std_logic_vector(3 DOWNTO 0);
sel1, sel2 : IN std_logic;
out1 : OUT std_logic_vector(3 DOWNTO 0));
END subprog2;
ARCHITECTURE subprog2 OF subprog2 IS
FUNCTION logicop (in1, in2 : IN std_logic_vector; c1, c2 : IN std_logic)

RETURN std_logic_vector IS -- Violation 1, 2, 3
BEGIN
IF(c1 = '1') THEN
RETURN (in1 OR in2); -- Violation 4
ELSIF(c2 = '1') THEN
RETURN (in1 AND in2); -- Violation 5
END IF;
END FUNCTION;
BEGIN
PROCESS (in1, in2, sel1, sel2)
BEGIN
out1<= logicop(in1, in2, sel1, sel2);
END PROCESS;
END subprog2;
Violations Produced
• Function "logicop" has multiple return statements – Violation 1
• The return statement should be the last statement in function "logicop"" – Violation 2
• Function 'logicop' has its output undefined in one or more paths. – Violation 3
• Function ""logicop"" should not return an expression – Violation 4
• Function ""logicop"" should not return an expression – Violation 5
Example 3
Check for code sharing through procedure calls in concurrent statements.
Rule Configuration
• Sub-Program — Procedures / Tasks
• Disallow — Code Sharing
Sub-Program Body
Analyzed Code
ENTITY codesharing IS
END codesharing;
ARCHITECTURE rtl OF codesharing IS

PROCEDURE BadChange(SIGNAL AffectedSignal : OUT std_logic_vector(7 DOWNTO
0);
value : IN integer ) IS
BEGIN
AffectedSignal <= std_logic_vector(to_signed(value,8)); -- Associated
Violation
END BadChange;
SIGNAL internal : std_logic_vector(7 DOWNTO 0);
BEGIN
BadChange(internal,1); -- First call
BadChange(internal,2); -- Violation
my_out<= my_in XOR internal;
END rtl;
Violations Produced
• Code sharing disallowed: signal "internal" was already assigned through a previous
concurrent procedure call statement – Violation
• + Do not assign values to signals in procedure ""BadChange"" since it is called as a
concurrent statement – Associated Violation
Sub-Program Logic
Sub-Program Logic
Checks that a given sub-program type (Functions, Procedure/Task) contains combinatorial or
sequential logic.
A sub-program is said to infer sequential logic if a register or latch is inferred within the sub-
program irrespective of any other logic in the sub-program. On the other hand, if a sub-program
does not infer a register or latch, it is considered to infer combinatorial logic. Further, a register
is considered to be inferred within a sub-program if a clock edge specification is encountered
within the sub-program body.
Usage
Sub-Program Logic
Common Parameters
Sub-Program
Allowed Inference
Parameters
• Sub-Program
Specify the Sub-Program type/s to which the check applies. The default is Functions and
Procedures/Tasks.
• Allowed Inference
Specify which style of coding is allowed within the specified type/s of Sub-program. The
default is Combinatorial Logic.
o Sequential Logic
o Combinatorial Logic
Examples
Example 1
Check for combinatorial logic inference in Functions.
Rule Configuration
• Allowed Inference — Combinatorial Logic
Sub-Program Logic
Analyzed Code
entity dff is
port(d, clk, reset : in bit;
q : out bit);
function func (signal clk,d : in bit) return bit is -- Violation 1
variable q : bit;
begin
if (clk'event and clk = '1') then
q := d;
end if;
return q;
end func;
end dff;
architecture behave OF dff IS

begin
process(clk)
begin
q<= func(clk,d);
end process;
end behave;
Violation Produced
Function 'func' infers sequential logic
Verification Base Rules
Verification Base Rules

The Verification base rules perform checks related to OVM/UVM.
Allowed Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Class Methods Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Allowed Classes
Allowed Classes
Checks specified allowed or disallowed inherited or instantiated UVM/OVM classes.
Usage
Allowed Classes
Common Parameters
Classes
Action
Check
Parameters
• Classes
Specify the class name(s) that must not be inherited (i.e. used as base classes). The
parameter has the value <none> which means no base class is disallowed (as if the rule is
disabled). The default is <none>.
o <user-defined>
o <none>
• Action
The parameter has the values Allow, Disallow (default). The Allow value means that the set
of UVM/OVM classes specified in the Classes parameter are the only ones that can be
inherited or instantiated. Conversely, the Disallow value means that the set of UVM/OVM
classes specified in the Classes parameter must not be inherited or instantiated. The default
is Disallow.
o Allow
o Disallow
• Check
The parameter has the values Derived Classes (default), Defined Members. The Derived
Classes value means that any classes inherit from allowed/disallowed classes are checked.
The rule will check for direct or indirect OVM/UVM base class of a user-defined class (not
simply the direct base class). The Defined Members value means that any handles created
directly from the type of the allowed/disallowed classes are checked; other handles created
from classes which inherit from allowed/disallowed classes are not checked. The default is
Derived Classes.
o Derived Classes
o Class Handles
Allowed Classes
Examples
Example 1
Reports UVM classes that are derived from uvm_sequencer.
Rule Configuration
• Classes — uvm_sequencer
• Check — Derived Classes

Analyzed Code
class ma_sequencer_base extends uvm_sequencer; //Violation 1
// ...
endclass
class ma_sequencer extends ma_sequencer_base; //Violation 2

// ...
endclass
Violations Produced
• Class ‘ma_sequencer_base’ inherits from a disallowed class ‘uvm_sequencer’. –
Violation 1
• Class ‘ma_sequencer’ inherits from a disallowed class ‘uvm_sequencer’. – Violation 2
Example 2
Reports UVM classes having data member(s) whose types are other than uvm_analysis_port,
uvm_analysis_export, tlm_fifo or tlm_analysis_fifo.
Rule Configuration
• Classes — uvm_analysis_port, uvm_analysis_export, tlm_fifo, tlm_analysis_fifo
• Action — Allow
• Check — Defined Members

Analyzed Code
package allowed_classes_pkg_2;
import uvm_pkg::*;
class ma_agent extends uvm_agent; //Violation
// ...
uvm_sequencer #(ma_in_tran, ma_out_tran) m_sequencer;
endclass
endpackage
module Allowed_Classes_2();
import allowed_classes_pkg_2::*;
// ...
endmodule
Allowed Classes
Violation Produced
Member ‘m_sequencer’ is defined from a disallowed class ‘uvm_sequencer’. – Violation 1
Class Methods Call
Class Methods Call

Checks that the specified class methods are called (or not called) by the specified calling class
methods. Optionally, this rule can check that the called class method is the first statement in the
calling methods. Further, this rule can check that the called method is not called by any method
other than the valid calling methods, and that the called method necessarily appears in all
specified calling methods.
Usage
Class Methods Call
Common Parameters
Calling Methods
Called Methods
Check
Parameters
o <none>
o <all>
• Calling Methods
Specify the names of the calling methods within the specified base classes to check for
called methods.The default is <all>.
• Called Methods
Specify the names of the methods whose calls need to be checked. The default is <none>.
• Check
Specify the characteristic of the called methods in the context of the calling methods. The
default is Specified called methods must appear in all specified calling methods.
o Specified called method must appear as the first statement in all specified calling
methods
o Specified called methods are allowed to be called in any of the specified calling
methods only
o Specified called methods must appear in all specified calling methods
Class Methods Call
o Specified called methods must not appear in any of the specified calling methods
Examples
Example 1
Checks that all “new” methods in all classes have a call to dummy_method as its first statement.
Rule Configuration
• Applies To (base class) — <all>
• Calling Methods — new
• Called Methods — dummy_method
• Check — Specified called method must appear as the first statement in all specified
calling methods
Analyzed Code
class analysis_fifo_bad extends analysis_fifo;
ovm_printer my_ovm_printer_3 = new();
function new(); // violation 1
report_summarize();
run_test();
dummy_method_2();
endfunction: new
function new_1();
report_summarize();
run_test();
dummy_method_2();
endfunction: new_1
endclass
Violation Produced
Class "analysis_fifo_bad" must have "dummy_method" method called from "new" method as
its first statement. – Violation 1
Related Topics
Factory Registration
Checks that UVM or OVM components and objects are registered with the factory using any of
the chosen registration styles. [UVM/OVM Designs only]
Usage
Common Parameters
Registry Style
Parameters
Specify the types of object handles to check. The object handle is checked if its type is any
of the specified types, or inherits directly or indirectly from any of them. The default is
uvm_object.
o uvm_object
o uvm_component
o ovm_object
o <user-defined>
Specify the types of object handles to exclude from the check. The object handle is excluded
from the check if its type is any of the specified types, or inherits directly or indirectly from
any of them. The default is <none>. Note that the value “<none>” cannot be selected along
with any other value.
o <none>
o <user-defined>
• Registry Style
Specify the required UVM/OVM factory registry style. The default is <UVM Component
Registration Styles>.
o <OVM Object Registration Styles>
òvm_object_param_utils, òvm_object_param_utils_begin, òvm_object_registry,
òvm_object_registry_internal, òvm_object_registry_param, òvm_object_utils,
òvm_object_utils_begin, òvm_sequence_param_utils,
òvm_sequence_param_utils_begin, òvm_sequence_utils,
òvm_sequence_utils_begin, ovm_object_registry
o <OVM Component Registration Styles>
òvm_component_param_utils, òvm_ component_param_utils_begin,
òvm_component _registry, òvm_component _registry_internal,
òvm_component_registry_param, òvm_component_utils,
òvm_component_utils_begin, òvm_sequencer_param_utils,
òvm_sequencer_param_utils_begin, òvm_sequencer_utils,
òvm_sequencer_utils_begin, ovm_component_registry
o <UVM Object Registration Styles>
ùvm_object_param_utils, ùvm_object_param_utils_begin, ùvm_object_registry,
ùvm_object_utils, ùvm_object_utils_begin, ùvm_sequence_param_utils,
ùvm_sequence_param_utils_begin, uvm_object_registry
o <UVM Component Registration Styles>
ùvm_component_param_utils, ùvm_ component_param_utils_begin, ùvm_
component_registry, ùvm_ component_utils, ùvm_component_utils_begin, uvm_
component_registry
Examples
Example 1
Check that all classes that extend uvm_component are registered with the factory using a UVM
component factory registration style.
Rule Configuration
• Applies To (UVM/OVM Base Class) — uvm_component
• Applies To Exceptions (UVM/OVM Base Class) — <none>
• Registry Style — <UVM Component Registration Styles>

Analyzed Code
import uvm_pkg::*;
class stim_gen extends uvm_component; // violation 1
//...
endclass
Violation Produced
UVM Component "stim_gen" is not registered with the factory using any of the allowed UVM
factory registration styles – Violation 1
Related Topics
Named Object Name
Object Construction
Object Construction
Object Construction
Checks the construction of UVM and OVM object handles whose types are specified by the two
parameters "Applies To (UVM/OVM Base Class)" and "Applies To Exceptions (UVM/OVM
Base Class)". The check requires the UVM/OVM library to be available with the design. The
rule can also check Coverage Group construction. The "Construction Location" parameter
specifies where to search for construction. The rule can also check that handles returned from
OVM build methods (create_component and create_object) are cast using $cast.
Usage
Object Construction
Common Parameters
Look In
Look In Exceptions
Construction Location
Cast Build Method Return
Parameters
Specify the types of object handles to check. The object is checked if the object handle's
type is any of the specified types, or inherits directly or indirectly from any of them.
<Coverage Groups> value is provided for checking coverage groups. The default is
uvm_object.
o uvm_object
o ovm_object
o <Coverage Groups>
o <user-defined>
Specify the types of object handles to exclude from the check. The object is excluded from
the check if the object handle's type is any of the specified types, or inherits directly or
indirectly from any of them. The default is <none>. Note that the value “<none>” cannot be
selected along with any other value.
o <none>
o <user-defined>
Object Construction
• Look In
Specify which class types are checked for their defines class handles. The default is
uvm_component.
o uvm_component
o ovm_component
o <All>
• Look In Exceptions
Specify which class types are to be excluded from the check for their defines class handles.
The object is excluded from the check if the object handle's type is in any of the specified
classes, or inherits from any of them. The default is <none>.
• Construction Location
Specify the location in which to look for object construction. The default is inside new() and
inside build().
o inside new()
o inside build()
o inside build_phase()
• Cast Build Method Return
Specify whether to check that handles returned from build methods (create_component and
create_object) are cast using $cast. The default is <don’t care>.
o Yes
o <don’t care>
Examples
Example 1
Check all uvm_object object handles, except uvm_subscriber object handles.
Rule Configuration
• Applies To (UVM/OVM Base Class) — uvm_object
• Applies To Exceptions (UVM/OVM Base Class) — uvm_subscriber
• Look In — uvm_component
• Look In Exceptions — <none>
• Construction Location — inside build()
• Cast Build Method Return — <don’t care>
Object Construction
Analyzed Code
package object_construction_pkg;
import uvm_pkg::*;
class uvm_registered_component extends uvm_component;

ùvm_component_registry("uvm_registered_component",
uvm_registered_component)
endclass
class uvmObjectConstruction extends uvm_component;

uvm_object uvm_object_inst; // Violation 1
uvm_registered_component uvm_registered_component_inst; // Violation 2
uvm_subscriber uvm_subscriber_inst;
uvm_report_object uvm_report_object_inst; //Violation 3
function new();
uvm_registered_component_inst =
create_component("uvm_registered_component",
"uvm_registered_component_inst");
endfunction
function build();
uvm_report_object_inst = new();
endfunction
endclass
endpackage
module object_construction();
import object_construction_pkg::*;
// ...
endmodule
Violations Produced
• Object handle "uvm_object_inst" is not constructed inside build() using new – Violation
1
• Object handle "uvm_registered_component_inst" is not constructed inside build() using
create_component or type_id::create – Violation 2
• Object handle 'uvm_report_object_inst' is not constructed inside build() using
create_object or type_id::create – Violation 3
Vital Base Rules
Vital Base Rules

The Vital base rules check for VITAL standard compliance.
VITAL Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
VITAL Ports
VITAL Ports
Checks that the VITAL (top-level entity) port declarations use appropriate modes (i.e. they are
not LINKAGE or GUARDED), appropriate names (i.e. do not contain underscore “_”
character) and appropriate types (std_logic, std_logic_vector, std_ulogic etc). Specifically,
scalars type checked are std_ulogic or std_logic (or other subtypes of std_ulogic), vectors type
checked are std_logic_vector or std_ulogic_vector
Usage
VITAL Ports
Common Parameters
Check VITAL Port Names
Disallowed VITAL Port Modes
VITAL Scalar Port Types
VITAL Array Port Types
Additional Checks
Parameters
• Check VITAL Port Names
Specify whether the VITAL Port names should adhere to naming convention that they
should not contain underscore character (“_”). The default is Yes.
o Yes
o No
• Disallowed VITAL Port Modes
Specify which Port Modes are not allowed for VITAL ports. The default is Guarded and
Linkage.
o Guarded
o Linkage
o <don’t care>
• VITAL Scalar Port Types
Specify which Scalar Types are allowed for VITAL ports. The default is std_logic ,
std_ulogic and Any other subtype of std_ulogic.
o std_logic
o std_ulogic
o Any other subtype of std_ulogic
VITAL Ports
o <don’t care>
Note
If a scalar port is of a user-defined subtype of std_ulogic, a violation will be
produced even if the parameter value “Any other subtype of std_ulogic” is selected.
This value only pertains to subtypes of std_ulogic defined in the IEEE package (like
UX01, X01 etc.)
• VITAL Array Port Types

Specify which Array Types are allowed for VITAL ports. The default is std_logic_vector ,
std_ulogic_vector.
o std_logic_vector
o std_ulogic_vector
o signed
o unsigned
o <don’t care>
Specify whether mixture of std_logic/std_ulogic based types is disallowed. The default is
<don’t care>.
o Disallow mixture of std_logic/std_ulogic types
o <don’t care>
Note
• A validation error is issued if you try to select <don’t care> option along with another
option for the disallowed Vital Port Modes, and disallowed Vital Port Types parameters.
• This rule will run only if a single unambiguous top can be detected.
• Record ports always will cause “Port Types” violations irrespective of the constituent
elements.
Examples
Example 1
Check VITAL port modes, names and types.
Rule Configuration
• Check VITAL Port Names — Yes
• Disallowed VITAL Port Modes — Guarded
VITAL Ports
• VITAL Scalar Port Types — std_logic, Any other subtype of std_ulogic
• VITAL Array Port Types — std_ulogic_vector

Analyzed Code
LIBRARY ieee;
package pkg is
type atlantic_t is record
sop : std_logic;
dat : std_logic_vector(63 downto 0);
end record;
end package;
LIBRARY ieee;
USE work.pkg.all;
ENTITY Vital_Port_use_pkg_3 IS
port(
a : IN std_logic bus; -- Violation 1
a1: IN atlantic_t; -- Violation 2
a2: in std_logic_vector(1 downto 0); -- Violation 3
b_1: INOUT std_logic; --Violation 4
\c\ : LINKAGE std_ulogic -- Violation 5
);
END ENTITY Vital_Port_use_pkg_3;
architecture behavioral of Vital_Port_use_pkg_3 is

begin
end behavioral;
Violations Produced
• Vital Top-Level port ‘a’ should not be a GUARDED bus – Violation 1
• Vital Top-Level port ‘a1’ is of type ‘atlantic_t’,which is not an allowed type/subtype
declared in package std_logic_1164 – Violation 2
• Vital Top-Level port ‘a2’ is of type ‘STD_LOGIC_VECTOR’, which is not an allowed
type/subtype declared in package std_logic_1164 – Violation 3
• Vital Top-Level port ‘b_1’ should not have underscore character(_) in its name –
Violation 4
• Vital Top-Level port ‘\c\’ is of type ‘STD_ULOGIC’, which is not an allowed type/
subtype declared in package std_logic_1164 – Violation 5
VITAL Ports
Related Topics
Naming
Allowed Types
Appendix A
Simple Expressions
Simple Expressions support the use of the wildcard “*” to represent any number of upper or
lowercase letters (a-z & A-Z), digits (0-9) and underscores.
Simple Expressions also support the use of built-in system variables and environment variables.
Environment variables are entered as $(ENV_VAR) where ENV_VAR is the name of the
environment Variable. For example: *_$(ENV_VAR).
Built-in system variables are entered as %(SYS_VAR) where SYS_VAR is the name of the
System Variable. For example: %(entity)_ent.
System variables & environment variables can both be used within the same pattern. For
example: %(entity)_*_$(ENV_VAR)
The following system variables can be used in Simple Expressions to refer to object names:
System Description Applicable Rules Examples
Variable Name
%(entity) Refers to the VHDL entity in Naming, Inferred See “Example 1”
which the object is defined. Elements Naming below
(e.g. entity of a port)
Refers to the entity name File Name, Partition
defined in the file. Design Parameters
%(architecture) Refers to the VHDL Naming, Inferred
architecture in which the Elements Naming
object is defined. (e.g.
architecture of a signal)
Refers to the architecture File Name, Partition
name defined in the file. Design Parameters
%(module) Refers to the Verilog module Naming, Inferred See “Example 2”
in which the object is Elements Naming below
defined. (e.g. module of a
reg)
Refers to the module name File Name, Partition
Simple Expressions

Variable Name
%(package) Refers to the VHDL package Naming See “Example 3”
in which the object is below
defined. (e.g. package of a
function)
Refers to the package name File Name, Partition
%(config) Refers to the configuration File Name, Partition
%(component) Refers to the VHDL Naming, Partition See “Example 4”
component name to which Design Parameters below
the instance is bounded (only
instances in VHDL). (e.g.
component of an instance)
%(bound_unit) Refers to the VHDL design Naming (applicable See “Example 5”
unit name to which the only to Instances and below
instance is bounded using Components)
default or explicit (through
configurations) binding.
(e.g. unit bound to the
component)
%(explicit_boun Refers to the VHDL design Naming (applicable See “Example 6”
d_unit) unit name to which the only to Instances and below
instance is bounded only Components)
using explicit (through
%(port) Refers to the formal port Naming (applicable See “Example 7”
name of the checked actual only on unconnected below
unconnected output port. output port stubs)
%(instance) Refers to the instance name Naming (applicable
(label) which the checked only on unconnected
actual unconnected output output port stubs)
port appears in.
%(output_port) Refers to the name of the Naming See “Example 8”
output that an internal/local below
signal is being copied to.
%(interface) Refers to the interface name File Name See “Example 9”
defined in the file. below
%(progblk) Refers to the program block File Name See “Example 10”
name defined in the file. below
Simple Expressions

Variable Name
%(class) Refers to the class name File Name See “Example 11”
Example 1: Using the Internal Variables %(entity) & %(architecture)
This example is to demonstrate using the %(entity) & %(architecture) variables in configuring a
rule and running it on a VHDL file that contains named procedures and functions.
Base Rule
• Naming
Rule Configuration
• Applies To — Procedures, Functions
• Pattern — %(entity)_%(architecture)_*
Code
entity my_entity is
port( in1: in bit; out1: out bit);
end entity;
architecture behave of my_entity is
procedure FFResetAsyncN (signal clk, values: in std_logic; --VIOLATION
signal xOut: out std_logic) is
begin
end procedure FFResetAsyncN;
begin
end;
Violations Produced
• Procedure “FFResetAsyncN” violates naming convention: Use

“%(entity)_%(architecture)_*” for procedure names
System Variables Expected Values
• %(entity) = “my_entity”
• %(architecture) = “behave”
Example 2: Using the Internal Variable %(module)
Below is an example to check running a configured rule on a Verilog file that contains named
tasks and functions using the %(module) variable.
Simple Expressions
Base Rule
• Naming
Rule Configuration
• Applies To — Tasks, Functions
• Pattern — *_%(module)
Code
module Era_3 (data_in, b, clk, rst, t);

input [7:0] data_in, b;
input clk, rst;
output [1:0] t;
integer RADDR;
reg [7:0] m_temp_map;
wire rega;
function myFunction; //VIOLATION
input P_ap;
integer P_ap;
reg [1:0] i;
endfunction
endmodule
Violations Produced
• Function “myFunction” violates naming convention: Use “*_%(module)” for function

names.
• %(module) = “Era_3”
Example 3: Using the Internal Variable %(package)
This example is to show using the %( package) variable in configuring a rule and running it on a
VHDL file that contains named procedures and functions.
Base Rule
• Naming
Rule Configuration
Simple Expressions
• Pattern — *_%(package)_*
Code
package mytest IS
constant seven : integer := 7;
subtype byte is std_logic_vector(7 downto 0);
type word is array (0 to 3) of byte;
type stream is array (integer range <>) of word;
type state is (s0, s1, s2, s3, s4);
type bool is (False, True);
function add (a, b : byte) return byte;
end mytest;
package body mytest is
function add (a, b : byte) --VIOLATION
return byte is
begin
return a + b;
end add;
end mytest;
Violations Produced
• Function “add” violates naming convention: Use “*_%(package)_*” for function names.
• %(package) = “mytest”
Example 4: Using the Internal Variable %(component)
Below is an example to show how you can use the variable %(component) in configuring a rule
and running it on a VHDL file that instantiates components.
Base Rule
• Naming
Rule Configuration
• Applies To — Instances
• Pattern — %(component)_*
Code
Simple Expressions
u1 : ent1 -- u1 doesn’t follow the naming convention, VIOLATION

generic map (N => 8)
port map (a, m, l, d, r, s);
ent1_u2 : ent1 -- ent1_u2 follows the naming convention, no
violation
port map (b, l, m, e, s, r);
Violations Produced
• Instance name “u1” violates naming convention: use “%(component)_*” for labeling
instances.
• %(component) = “ent1”
Example 5: Using the Internal Variable %(bound_unit)
This example is to check running a configured rule on a VHDL file that instantiates components
using the %(bound_unit) variable.
Base Rule
• Naming
Rule Configuration
• Applies To — Components, Instances
• Pattern — %(bound_unit)_*
Code
ent1_u1 : ent1 -- ent1_u1 follows the naming convention, no violation

generic map (N => true)
Violations Produced
• Instance name "u2" violates naming convention: use "%(bound_unit)_*" for labeling
instances.
• %(bound_unit) = “ent2”
Simple Expressions
Example 6: Using the Internal Variable %(explicit_bound_unit)
This example is to demonstrate using the %(explicit_bound_unit) variable in configuring a rule

and running it on a VHDL file that instantiates components and binds them using
configurations.
Base Rule
• Naming
Rule Configuration
• Pattern — %(explicit_bound_unit)_*
Code
FA_u1: entity work.FA(rtl_asic) -- FA_u1 follows the naming convention, no

violation
port map (A => A_exponent(N-1),B => B_exponent(N-1), C_in => Carry_out(N-
1) , S_out => Sum_out(N), C_out=>Carry_out(N));
Mentor_u1: entity work.FA(rtl_asic) -- Mentor_u1 doesn’t follow the naming
convention, VIOLATION
Violations Produced
• Instance name "Mentor_u1" violates naming convention: use

"%(explicit_bound_unit)_*" for labeling instances.
• %(explicit_bound_unit) = “FA”
Example 7: Using the Internal Variables %(port) & %(instances)
This example is to express using the %( port) & %( instance) variables in configuring a rule and
running it on a VHDL file that contains output port stubs.
Base Rule
• Naming
Rule Configuration
Simple Expressions
• Applies To — VHDL Any
• Pattern — %(instance)_%(port)_*
Code
ENTITY ent1 IS
port (a, b : in std_logic;
c : out std_logic );
END ENTITY ent1;
ARCHITECTURE arch OF ent1 IS
BEGIN
PROCESS (a,b)
BEGIN
c <= a and b;
end PROCESS;
Entity ent4 is
port (a4, b4 : std_logic;
c4 : out std_logic );
END ENTITY ent4;
ARCHITECTURE behave OF ent4 IS
Signal stub1, U2_c_stub2: std_logic;
COMPONENT ent1
END COMPONENT;
BEGIN
U1: ent1
Port map (a4, b4, stub1); --VIOLATION
U2: ent1
Port map (a4, b4, U2_c_stub2);
END ARCHITECTURE behave;
Violations Produced
• Unconnected output port "stub1" violates naming convention: use

"%(instance)_%(port)_*" for unconnected output port names.
• %(instance) = “U1”
• %(port) = “c”
Example 8: Using the Internal Variables %(output_port)
This example allows you to run a configured rule on a VHDL file that contains signals using the
%(output_port) variable.
Base Rule
• Naming
Simple Expressions
Rule Configuration
• Applies To — Internal Signals
• Pattern — %(output_port)_*
Code
Entity Sample is
Port (a, b : in std_logic;
C,d : out std_logic);
End entity Sample;
Architecture behave of Sample is
Signal signal1, d_signal2: std_logic;
Begin
signal1 <= a AND b;
d_signal2 <= a OR b;
C <= signal1; --VIOLATION
d <= d_signal2;
end architecture behave;
Violations Produced
• Internal signal “signal1” violates naming convention: use “%(output_port)_*” for

internal signal names.
• %(output_port) = “C”
Example 9: Using the Internal Variables %(interface)
This example allows you to check running a configuration rule on a Verilog file that contains an
interface using the %(interface) variable.
Base Rule
• File Name
Rule Configuration
• Applies To — Interface
• Pattern — %(interface).sv
Code “interf.sv”
Simple Expressions
interface intf();
reg data;
reg clk;
endinterface
Violations Produced
• File “interf.sv” violates naming convention: Use “%(interface).sv” for interface file
names.
• %(interface) = “intf”
Example 10: Using the Internal Variables %(progblk)
This example is to check running a configured rule on a Verilog file that contains a program
block using the %(progblk) variable.
Base Rule
• File Name
Rule Configuration
• Applies To — Program Block
• Pattern — %(progblk).sv
Code “myprog.sv”
program test (output cmd, input enable, input cmd_in);

assign cmd = enable ? cmd_in : 'x;
endprogram
Violations Produced
• File “myprog.sv” violates naming convention: Use “%(progblk).sv” for program block
file names.
• %(progblk) = “test”
Example 11: Using the Internal Variables %(class)
Below is an example to check running a configured rule on a Verilog file that contains a class
using the %(class) variable.
Simple Expressions
Base Rule
• File Name
Rule Configuration
• Applies To — Include Files, Class
• Pattern — %(class).sv
Code
Include File “myclass”
class simple_data;
integer data;
bit isValid;
endclass
Source File “top.sv”
ìnclude "myclass.sv"
module top (input in1, en, cmd_in, output out1, out2);
test mytest(.cmd(out2), .enable(en), .cmd_in(cmd_in));
intf myintf();
mastermod master (.a(myintf), .b(out1));
slavemod slave (.a(myintf), .b(in1));
endmodule
module mastermod (intf a, input b);
always @(posedge a.clk)
a.data <= b;
endmodule
module slavemod (intf a, output reg b);
b <= a.data;
endmodule
Violations Produced
• Include File “myclass.sv” violates naming convention: Use “%(class).sv” for class file
names.
• (class) = “simple_data”
Simple Expressions
Appendix B
Regular Expressions
Regular expressions follow the GNU regular expression format.

Syntax
Regular Description
Expression
Syntax
.(period) Matches any single character. For example: h.t matches hat, hit, hot and
hut.
[] Matches any one of the characters in the brackets, or any of an ANSI range
of characters separated by a hyphen -. For example: h[aeiou][a-z] matches
hat, hip, hit, hop and hut; [A-Za-z] matches any single letter; x[0-9]
matches x0,x1, …, x9.
[^] Matches any characters except for those after the caret ^. For example:
h[û]t matches hat, hit and hot but not hut.
^ Matches the start of a line (column 1).
$ Matches the end of a line (but not the line break character). Use this for
restricting matches to characters at the end of a line. For example: end$
only matches end when it is the last word on a line, and ênd only matches
end when it's the first word on a line.
\< Matches the start of a word. For example \<clk_ would find strings starting
with the characters clk_.
\> Matches the end of a word. For example _clk\> would find strings ending
with the characters _clk. You can combine the \< and \> operators (for
example: \<clk\>) to explicitly find the complete word clk.
\b Matches the start or end of a word. This is equivalent to \< or \>. For
example: \bclk\b also finds the complete word clk.
\B Matches a string within a word. For example: data\Bbus\Bout finds the
string bus within the string databusout.
\w Matches any character than can be used in a word.
\W Matches any character that cannot be used in a word (for example space).
() Groups a tagged expression for use in replacement expressions. A regular
expression can have up to nine tagged expressions numbered by their
order in the regular expression. The corresponding replacement expression
is \d for d in the range 1 to 9. For example: If ([a-z]+) ([a-z]+) matches
way wrong, \2 \1 would replace it with wrong way.
Regular Expressions
Regular Description
Expression
Syntax
* Matches zero or more of the preceding characters or expressions. For
example: ho*p matches hp, hop and hoop.
? Matches zero or one of the preceding characters or expressions. For
example: ho?p matches hp and hop but not hoop.
+ Matches one or more of the preceding characters or expressions. For
example: ho+p matches hop and hoop but not hp.
{count} Matches the specified number of the preceding characters or expressions.
For example: ho{2}p matches hoop but not hop.
{min,} Matches at least the specified number of the preceding characters or
expressions. For example: ho{1}p matches hop and hoop but not hp.
{min,max} Matches between min and max of the preceding characters or expressions.
For example: ho{1,2}p matches hop and hoop but not hp or hooop.
| Matches either the expression to its left or its right. For example: hop|hoop
matches hop or hoop.
\ Escapes the special meaning of the above expressions so that they can be
matched as literal characters. Hence to match a literal \, you must use \\.
For example: \< matches the start of a word but \\< matches \<.
Examples
• To check that a string contains A-Z, a-z or underscores and has at least one character:
^[A-z0-9_]+$
• To check that a string starts with zero or one underscores then a single alphanumeric
followed by any number of alphanumerics or underscores:
^_?[A-z0-9][A-z0-9_]*$
• To check that names use the prefix "U_<name>" or "I<number>_<name>" the

expression would be of the form:
^(U|I[0-9]+)_[A-z0-9_]+$
Appendix C
System and Environment Variables
System variables and environment variables are used to specify context based values.
Simple Expressions also support the use of built-in system variables and environment variables.
Environment variables are entered as $(ENV_VAR) where ENV_VAR is the name of the
environment Variable. For example: *_$(ENV_VAR).
Built-in system variables are entered as %(SYS_VAR) where SYS_VAR is the name of the
System Variable. For example: %(entity)_ent.
The following system variables can be used in Simple/Regular Expressions to refer to object
names:
Variable Name
%(entity) Refers to the VHDL entity in Naming, Inferred See “Example 1”
which the object is defined. Elements Naming below
(e.g. entity of a port)
Refers to the entity name File Name, Partition
%(architecture) Refers to the VHDL Naming, Inferred
architecture in which the Elements Naming
object is defined. (e.g.
architecture of a signal)
Refers to the architecture File Name, Partition
%(module) Refers to the Verilog module Naming, Inferred See “Example 2”
in which the object is Elements Naming below
defined. (e.g. module of a
reg)
Refers to the module name File Name, Partition
%(package) Refers to the VHDL package Naming See “Example 3”
in which the object is below
defined. (e.g. package of a
function)
Refers to the package name File Name, Partition

Variable Name
%(config) Refers to the configuration File Name, Partition
%(component) Refers to the VHDL Naming See “Example 4”
component name to which below
the instance is bounded (only
instances in VHDL). (e.g.
component of an instance)
%(bound_unit) Refers to the VHDL design Naming (applicable See “Example 5”
unit name to which the only to Instances and below
instance is bounded using Components)
default or explicit (through
(e.g. unit bound to the
component)
%(explicit_boun Refers to the VHDL design Naming (applicable See “Example 6”
d_unit) unit name to which the only to Instances and below
instance is bounded only Components)
using explicit (through
%(port) Refers to the formal port Naming (applicable See “Example 7”
name of the checked actual only on unconnected below
unconnected output port. output port stubs)
%(instance) Refers to the instance name Naming (applicable
(label) which the checked only on unconnected
actual unconnected output output port stubs)
port appears in.
%(output_port) Refers to the name of the Naming See “Example 8”
output that an internal/local below
signal is being copied to.
%(interface) Refers to the interface name File Name See “Example 9”
%(progblk) Refers to the program block File Name See “Example 10”
name defined in the file. below
%(class) Refers to the class name File Name See “Example 11”
%(clock) Refers to the clock name for Inferred Elements See “Example 12”
a particular register Naming below
Invalid Uses of System Variables:
System variables used in the simple expressions must be valid in the context and applicable in
scope of the language concerned. For example '%(module)' and '%(entity)' can never be
applicable in any context. These kinds of simple expressions with mixed language system
variable specification will result in validation error. Similarly if the language is set to 'Verilog'
and the simple expression contains 'VHDL' specific system variables, for example
'%(component)', will result in validation error. In the same way combination of language
'VHDL' and 'Verilog' specific system variables will also result in validation error.
For regular expressions, if some invalid system variable is used, DesignChecker will not error
out, and it will substitute whatever part of the pattern that is valid and substitutable. Rationale
behind it being, in regular expression DesignChecker doesn’t know if the invalid part is
intentionally introduced by the user.
Example 1: Using the Internal Variables %(entity) & %(architecture)
This example is to demonstrate using the %(entity) & %(architecture) variables in configuring a
rule and running it on a VHDL file that contains named procedures and functions.
Base Rule
• Naming
Rule Configuration
• Pattern — %(entity)_%(architecture)_*
Code
entity my_entity is
port( in1: in bit; out1: out bit);
end entity;
architecture behave of my_entity is
procedure FFResetAsyncN (signal clk, values: in std_logic; --VIOLATION
signal xOut: out std_logic) is
begin
end procedure FFResetAsyncN;
begin
end;
Violations Produced
• Procedure “FFResetAsyncN” violates naming convention: Use

“%(entity)_%(architecture)_*” for procedure names
• %(entity) = “my_entity”
• %(architecture) = “behave”
Example 2: Using the Internal Variable %(module)
Below is an example to check running a configured rule on a Verilog file that contains named
tasks and functions using the %(module) variable.
Base Rule
• Naming
Rule Configuration
• Applies To — Tasks, Functions
• Pattern — *_%(module)
Code
module Era_3 (data_in, b, clk, rst, t);

input [7:0] data_in, b;
input clk, rst;
output [1:0] t;
integer RADDR;
reg [7:0] m_temp_map;
wire rega;
function myFunction; //VIOLATION
input P_ap;
integer P_ap;
reg [1:0] i;
endfunction
endmodule
Violations Produced
• Function “myFunction” violates naming convention: Use “*_%(module)” for function

names.
• %(module) = “Era_3”
Example 3: Using the Internal Variable %(package)
This example is to show using the %( package) variable in configuring a rule and running it on a
VHDL file that contains named procedures and functions.
Base Rule
• Naming
Rule Configuration
• Pattern — *_%(package)_*
Code
package mytest IS
constant seven : integer := 7;
subtype byte is std_logic_vector(7 downto 0);
type word is array (0 to 3) of byte;
type stream is array (integer range <>) of word;
type state is (s0, s1, s2, s3, s4);
type bool is (False, True);
function add (a, b : byte) return byte;
end mytest;
package body mytest is
function add (a, b : byte) --VIOLATION
return byte is
begin
return a + b;
end add;
end mytest;
Violations Produced
• Function “add” violates naming convention: Use “*_%(package)_*” for function names.
• %(package) = “mytest”
Example 4: Using the Internal Variable %(component)
Below is an example to show how you can use the variable %(component) in configuring a rule
and running it on a VHDL file that instantiates components.
Base Rule
• Naming
Rule Configuration
• Language — HDL Any
• Applies To — Instances
• Pattern — %(component)_*
Code

Violations Produced
• Instance name “u1” violates naming convention: use “%(component)_*” for labeling
instances.
• %(component) = “ent1”
Example 5: Using the Internal Variable %(bound_unit)
This example is to check running a configured rule on a VHDL file that instantiates components
using the %(bound_unit) variable.
Base Rule
• Naming
Rule Configuration
• Pattern — %(bound_unit)_*
Code

generic map (N => true)
Violations Produced
• Instance name "u2" violates naming convention: use "%(bound_unit)_*" for labeling
instances.
• %(bound_unit) = “ent2”
Example 6: Using the Internal Variable %(explicit_bound_unit)
This example is to demonstrate using the %(explicit_bound_unit) variable in configuring a rule

and running it on a VHDL file that instantiates components and binds them using
configurations.
Base Rule
• Naming
Rule Configuration
• Pattern — %(explicit_bound_unit)_*
Code
FA_u1: entity work.FA(rtl_asic) -- FA_u1 follows the naming convention, no

violation
Mentor_u1: entity work.FA(rtl_asic) -- Mentor_u1 doesn’t follow the naming
convention, VIOLATION
Violations Produced
• nstance name "Mentor_u1" violates naming convention: use

"%(explicit_bound_unit)_*" for labeling instances.
• %(explicit_bound_unit) = “FA”
Example 7: Using the Internal Variables %(port) & %(instances)
This example is to express using the %( port) & %( instance) variables in configuring a rule and
running it on a VHDL file that contains output port stubs.
Base Rule
• Naming
Rule Configuration
• Applies To — Unconnected Output Port Stubs
• Pattern — %(instance)_%(port)_*
Code
ENTITY ent1 IS
END ENTITY ent1;
ARCHITECTURE arch OF ent1 IS
BEGIN
PROCESS (a,b)
BEGIN
c <= a and b;
end PROCESS;
Entity ent4 is
port (a4, b4 : std_logic;
c4 : out std_logic );
END ENTITY ent4;
ARCHITECTURE behave OF ent4 IS
Signal stub1, U2_c_stub2: std_logic;
COMPONENT ent1
END COMPONENT;
BEGIN
U1: ent1
Port map (a4, b4, stub1); --VIOLATION
U2: ent1
Port map (a4, b4, U2_c_stub2);
END ARCHITECTURE behave;
Violations Produced
• Unconnected output port "stub1" violates naming convention: use

"%(instance)_%(port)_*" for unconnected output port names.
• %(instance) = “U1”
• %(port) = “c”
Example 8: Using the Internal Variables %(output_port)
This example allows you to run a configured rule on a VHDL file that contains signals using the
%(output_port) variable.
Base Rule
• Naming
Rule Configuration
• Applies To — Internal Signals
• Pattern — %(output_port)_*
Code
Entity Sample is
Port (a, b : in std_logic;
C,d : out std_logic);
End entity Sample;
Architecture behave of Sample is
Signal signal1, d_signal2: std_logic;
Begin
signal1 <= a AND b;
d_signal2 <= a OR b;
C <= signal1; --VIOLATION
d <= d_signal2;
end architecture behave;
Violations Produced
• Internal signal “signal1” violates naming convention: use “%(output_port)_*” for

internal signal names.
• %(output_port) = “C”
This example allows you to check running a configuration rule on a Verilog file that contains an
interface using the %(interface) variable.
Base Rule
• File Name
Rule Configuration
• File Type — Interface
• File Name Pattern — %(interface).sv
Code
interface intf();
reg data;
reg clk;
endinterface
Violations Produced
• File “interf.sv” violates naming convention: Use “%(interface).sv” for interface file
names.
• %(interface) = “intf”
Example 10: Using the Internal Variables %(progblk)
This example is to check running a configured rule on a Verilog file that contains a program
block using the %(progblk) variable.
Base Rule
• File Name
Rule Configuration
• File Type — Program Block
• File Name Pattern — %(progblk).sv

Code “myprog.sv”
program test (output cmd, input enable, input cmd_in);

assign cmd = enable ? cmd_in : 'x;
endprogram
Violations Produced
• File “myprog.sv” violates naming convention: Use “%(progblk).sv” for program block
file names.
• %(progblk) = “test”
Example 11: Using the Internal Variables %(class)
Below is an example to check running a configured rule on a Verilog file that contains a class
using the %(class) variable.
Base Rule
• File Name
Rule Configuration
• File Type — Include Files, Class
• File Name Pattern — %(class).sv

Code
Include File “myclass”
class simple_data;
integer data;
bit isValid;
endclass
Source File “top.sv”
ìnclude "myclass.sv"
module top (input in1, en, cmd_in, output out1, out2);
test mytest(.cmd(out2), .enable(en), .cmd_in(cmd_in));
intf myintf();
mastermod master (.a(myintf), .b(out1));
slavemod slave (.a(myintf), .b(in1));
endmodule
module mastermod (intf a, input b);

a.data <= b;
endmodule
module slavemod (intf a, output reg b);

b <= a.data;
endmodule
Violations Produced
• Include File “myclass.sv” violates naming convention: Use “%(class).sv” for class file
names.
• %(class) = “simple_data”
In this example, we check for register naming with pattern that contain system variable
%(clock).
Base Rule
• Inferred Elements Naming

Rule Configuration
• Applies To — Registers
• Pattern — *_%(clock)
• Expression Type — Simple

Code
library ieee;
use ieee.numeric_std.all;
entity ent is
port (
in1 : in std_logic;
clk : in std_logic;
out1: out std_logic);
end ent;
architecture rtl of ent is
begin
process (clk)
begin
if (clk'event AND clk = '1') then
out1 <= in1;
end if;
end process;
end;
Violations Produced
• Register 'out1' violates naming convention: use '*_%(clock) (i.e. *_clk)' for registers.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.
4. RESTRICTIONS ON USE.
4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.
4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.
4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.
4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.
4.5. The provisions of this Section 4 shall survive the termination of this Agreement.
5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
(including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
9. THIRD PARTY CLAIMS.
9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.
9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.
9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.
10. INFRINGEMENT.
10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.
10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
11. TERMINATION AND EFFECT OF TERMINATION.
11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.
11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.
12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.
13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.
16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.
Rev. 170330, Part No. 270941

Mentor Graphics Corporation, Base Rules Reference Guide, Release v2018.2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mentor Graphics Corporation, Base Rules Reference Guide, Release v2018.2

Загружено:

Авторское право:

Доступные форматы

Base Rules Reference Guide

© 2018 Mentor Graphics Corporation

Mentor Graphics Corporation

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Base Rules Reference Guide, v2018.2 3

Internally Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4 Base Rules Reference Guide, v2018.2

Hierarchy Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Base Rules Reference Guide, v2018.2 5

Register Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

6 Base Rules Reference Guide, v2018.2

Figure 1-1. Base Rule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Base Rules Reference Guide, v2018.2 7

8 Base Rules Reference Guide, v2018.2

Base Rules Reference Guide, v2018.2 9

10 Base Rules Reference Guide, v2018.2

DesignChecker Base Rule Configuration Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

DesignChecker Base Rule Configuration

Base Rules Reference Guide, v2018.2 11

Figure 1-1. Base Rule Configuration

12 Base Rules Reference Guide, v2018.2

Parameters Common to all Base Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Base Rules Reference Guide, v2018.2 13

Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

14 Base Rules Reference Guide, v2018.2

Verilog `timescale Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Base Rules Reference Guide, v2018.2 15

Register Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

16 Base Rules Reference Guide, v2018.2

Sub-Program Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Parameters Common to all Base Rules

Base Rules Reference Guide, v2018.2 17

18 Base Rules Reference Guide, v2018.2

Allow Base Rules

Base Rules Reference Guide, v2018.2 19

20 Base Rules Reference Guide, v2018.2

• Maximum Allowed Dimension

• Types Internally Coded As Vectors

• Maximum Allowed Dimensions — 1

• Other Qualifiers — <don’t care>

Base Rules Reference Guide, v2018.2 21

• Maximum Allowed Dimensions — 0

• Other Qualifiers — <don’t care>

22 Base Rules Reference Guide, v2018.2

Base Rules Reference Guide, v2018.2 23

24 Base Rules Reference Guide, v2018.2

Base Rules Reference Guide, v2018.2 25

26 Base Rules Reference Guide, v2018.2

• Allowed Characters — LF, CR, ASCII characters (32-126)

• Check Comments — Yes

always @(posedge clk or posedge load )

Base Rules Reference Guide, v2018.2 27

28 Base Rules Reference Guide, v2018.2

o Synthesizable Wait (wait until)

Base Rules Reference Guide, v2018.2 29

• Global Signals: Signals defined in a package.

30 Base Rules Reference Guide, v2018.2

ARCHITECTURE rtl OF top5 IS

TYPE MYVECTOR IS ARRAY (7 downto 0) OF bit;

CONSTANT WIDTH : integer := 8;

Base Rules Reference Guide, v2018.2 31

32 Base Rules Reference Guide, v2018.2

Base Rules Reference Guide, v2018.2 33

• Allowed Scoped — interface