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

{ 0 Reactions ... read them below or write one }

Post a Comment

Your comments will be moderated before it can appear here.