HDL Coding Guidelines - Part 7

Hints
  1. Avoid more package references than needed
  2. Keep all objects and subprograms in the nearest possible scope
  3. Keep local objects invisible outside a package
  4. Transfer stable component declarations into components packages
  5. Re-use functionality of standard packages as much as possible
  6. Size of VHDL Units should be reasonable for synthesis
  7. A VHDL unit should not exceed 500 lines of code
  8. A process or subprogram should not exceed 100 lines of code
  9. Component instantiations should not exceed 4 levels of hierarchy
  10. An architecture should not contain more than 10 processes
  11. Structural and behavioral code should not be mixed
  12. Define project packages early in the project
  13. Hide old VHDL files
  14. Follow Naming conventions for VHDL units
  15. Follow Naming conventions for VHDL files
  16. Follow Naming conventions for VHDL objects
  17. Choose short instance names
  18. Keyword casing should be uniform in all VHDL code
  19. Use an intermediate signal for reading from an output port
  20. Self-defined conversion functions must assert un-mappable input values
  21. Use complex data types inside architectures
  22. Use a small number of self-defined global data types
  23. Insert test-enable for scan-test
  24. Use vector operations instead of loops
  25. Avoid unnecessary repetition of function calls
  26. Use efficient description for the wrap around of counters
  27. Build interface consistency checks into the model
  28. For soft-core development use generics, do not use constants
  29. A testbench has neither ports nor generics
  30. Variables of access types should be modified only in procedures defined in packages
  31. Use abstract, compact coding style in testbench and simulation models
  32. In case of accelerated simulation or emulation, the testbench must be synthesizable
  33. Stop the simulation from within the testbench
  34. Use assertion messages extensively
  35. Check the success of a read operation
  36. Use std.textio only, where really necessary
  37. Store file data to a VHDL variable, if read multiple times
  38. In association lists of subprogram calls use named association
  39. Indentation should be consistent in all VHDL code
  40. Align comments vertically
  41. Align declaration lists vertically
  42. Align association lists vertically
  43. Use closing labels for entity, architecture, process, loop, generate, etc.
  44. Indicate condition at remote ends of control structures (if ... then, case)
  45. Use one statement per line
  46. Group related constructs
  47. Group related port or signal declarations
  48. Switch constructs should not be nested to more than 4 levels
  49. Remove unnecessary code fragments
  50. Order of items should be the same in package header and body
  51. Use predefined attributes to make code generic and more re-usable
  52. Do not have code that have been commented out in checked-in versions
  53. Carefully use real values with PN-generators
  54. Be aware of operating-system-specific features
  55. Take care of array widths for std_logic_arith operators
  56. Use conversion functions around arithmetic operators
  57. Requirements for resource sharing
  58. EMC and transmission line effects need not be modeled
  59. Minimize the number of processes, signals, and signal assignments
  60. Replace signals by variables whenever possible
  61. Inhibit execution of statements where not necessary
  62. Divide large memories into blocks
  63. Avoid declaring constants within subprograms
  64. Always use deallocate(access_obj) to dereference allocated memory
  65. Use only well tested functions for object-initialization purposes
  66. Be aware of the use of the attributes DELAYED, STABLE, QUIET, and TRANSACTION

0/Post a Comment/Comments

Your comments will be moderated before it can appear here.

Previous Post Next Post
ads1
Ads2