HDL Coding Guidelines - Part 2

When Compiling (VHDL):

1. A configuration declaration is needed for each architecture in the design
2. Design-internal references must use library work
3. Use selected names in binding indications and ’use’ clauses only
4. Testbench and DUT should be compiled into the same library
5. Avoid more package references than needed
   

Partitioning VHDL Code

1. VHDL units should take into account later floorplanning
2. Asynchronous parts should be placed into separate entities
3. Keep all objects and subprograms in the nearest possible scope
4. Keep local objects invisible outside a package
5. Transfer stable component declarations into components packages
6. Re-use functionality of standard packages as much as possible
7. Size of VHDL Units should be reasonable for synthesis
8. A VHDL unit should not exceed 500 lines of code
9. A process or subprogram should not exceed 100 lines of code
10. Component instantiations should not exceed 4 levels of hierarchy
11. An architecture should not contain more than 10 processes
12. Structural and behavioral code should not be mixed
13. Define project packages early in the project

Storing VHDL Code

1. Configuration must be in a separated file except the latest level of hierarchy
2. Only verified VHDL code allowed for check-in
3. Store each VHDL unit into a separate file except package header and body
4. Hide old VHDL files
   

Naming Conventions

1. All primary unit names must be unique in the project library
2. Identifier casing should be uniform in all VHDL code
3. Length of entity names should not exceed 32 characters
4. An instance name must not contain the substring ’pfiller’
5. An instance name must not start with bondpad
6. Identifier naming must be based on English language
7. Use meaningful identifier names
8. Separate identifier components using underscores
9. Signal assignments for renaming purposes should be avoided
10. The names of clocks and resets should be unique in the whole design
11. Naming conventions for VHDL units
12. Naming conventions for VHDL files
13. Naming conventions for VHDL objects
14. Choose short instance names
15. Keyword casing should be uniform in all VHDL code
16. Use standard top-levels xmpl, xmpl_top, and xmpl_chip
17. Use an intermediate signal for reading from an output port
18. Example for unit and file naming conventions
19. Abbreviations for naming conventions

Data-Types

1. Use unresolved data types if possible
2. Hard/firm macros: Data types at ports: std_(u)logic(_vector)
3. Generics must have type integer for synthesis
4. Soft macros: Data types at ports: std_(u)logic(_vector)
5. Avoid custom data types (e.g., multidimensional arrays, records, enumeration types)
6. Self-defined conversion functions must assert un-mappable input values
7. Use complex data types inside architectures
8. Use a small number of self-defined global data types
   

Design Rules

1. Asynchronous reset is mandatory for sequential processes
2. Do not use internal three-state busses
3. Use the predefined templates for component instantiation
4. Refer to one edge of clock, only
5. Do not use combinational feedback loops
6. Avoid feedthroughs
7. Strength stripping should be performed on chip level
8. Do not assign the value 'X'
9. Balance clock to delta accuracy
10. Pull-ups and pull-downs have to be modeled on chip level
11. Gate instantiation must be encapsulated by separate unit
12. A FSM must be described in a separate entity/architecture pair
13. Instantiate the power pads for each power domain
14. Spend extensive efforts for documentation of interfaces
15. Spacer cells needed between pads
16. Signals that cross clock domains must be synchronized by synchronization cells
17. Avoid gated clocks unless absolutely necessary
18. Avoid latches unless absolutely necessary
19. All outputs of synchronous modules should be registered
20. Process only one clock in RTL-units
21. Do not use the value of type’left for initializing of a signal or variable during reset
22. Avoid unused ports, busses must be split accordingly
23. Use case-statements instead of if-statements when the conditions are mutually exclusive
24. All signals and variables should be read at least once
25. Static ports should not exist
26. Avoid unnecessary computations within loops
27. Insert test-enable for scan-test
28. Use vector operations instead of loops
29. Avoid unnecessary repetition of function calls
30. Use efficient description for the wrap around of counters
31. Build interface consistency checks into the model
32. For soft-core development use generics, do not use constants
    

Testbenches

1. Global signals may be used for testing purposes only
2. Variables of access types should be modified only in procedures defined in packages
3. A testbench has neither ports nor generics
4. Use abstract, compact coding style in testbench and simulation models
5. In case of accelerated simulation or emulation, the testbench must be synthesizable
6. Stop the simulation from within the testbench
7. Use assertion messages extensively
   

Text-IO

1. Binary file-IO may not be used
2. Use relative path names for files accessed through text-IO
3. Communication between modules using text-IO is forbidden
4. No characters with a lower rank than space may occur in text-IO
5. Check the success of a read operation
6. Use std.textio only, where really necessary
7. Store file data to a VHDL variable, if read multiple times
   

Readability

1. In association lists of generic maps and port maps use named association
2. Language for comments and code documentation is English
3. Comments should be related to the lines of code below
4. Trailing comments are only allowed for declarative lists
5. Comment each process, each subprogram and global aspects
6. Processes should be labeled
7. Aliases are not recommended
8. Do not define a subprogram for a subtype only
9. The names of clocks and resets should be unique in the whole design
10. Use a separate library clause for each declared resource library
11. Use a separate use clause for each declared package
12. Maximum line-length is 100 characters
13. Order of ports in entity, component and instance should be the same
14. Do not have unused signals
15. In association lists of subprogram calls use named association
16. Indentation should be consistent in all VHDL code
17. Align comments vertically
18. Align declaration lists vertically
19. Align association lists vertically
20. Use closing labels for entity, architecture, process, loop, generate, etc.
21. Indicate condition at remote ends of control structures (if ... then, case)
22. Use one statement per line
23. Group related constructs
24. Group related port or signal declarations
25. Switch constructs should not be nested to more than 4 levels
26. Remove unnecessary code fragments
27. Order of items should be the same in package header and body
28. Use predefined attributes to make code generic and more re-usable
29. Do not have code that have been commented out in checked-in versions