Testing should normally be done in a bottom-up fashion, which means that blocks will be simulated in separate testbenches before they are integrated. This has the advantage that simulating smaller blocks requires less computing resources, which means the simulation runs faster and it's easier to find errors. Also since there is less code it's easier to identify the problem area. Of course there are limits to splitting the testing effort into sub-blocks. The designer needs choose the right level of hierarchies by comparing the effort to write additional testbenches against the effort to locate bugs in a more complex testbench. Usually if several designers are involved there should be at least one testbench for each designer's module and a testbench for the complete device.
There should be a testplan for the device which makes sure that every part of the design is exercised. Each test should have a unique identifier (ideally the directory name in which the test files are kept) and a description of the test.
If several designers work on the same device it's useful to have a bug log, a file that is kept in a central location and has an entry for every bug which is found. Here is a possible format:
| Bug No | Status | Found by / Date | Test Case | Description | Fixed by / Date |
| open | Stefan / 3/16/99 | mp_test_1 | back to back cycles fail on MP interface | ||
| closed | Bryan / 3/17/99 | sdr_1 | CRC values inverted | ||
There are also tools which help to maintain these logs and (among other things) prevent that entries are accidentally deleted.
Any small change in a minor file of the design could potentially cause the design to fail. It's therefore important that all tests are run after the last change has been made to the design code (and before the design is manufactured). To make this task feasible all tests should be automated and self-checking, so that they can be run from a script instead of having to run every test manually and having to check every log file line by line.
