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