Here is some more general advice for simulation of HDL code. No respect is paid to verification methodologies like UVM or OSVVM. Most of it is obvious, but it helps my memory when I write these things down.

  • Use one big record type to define what is part of a test case.
    Then define multiple constants of the test case record type, one for each test case.
    Scheduling of and switching between test cases becomes a matter of a single signal/variable assignment.
  • Read test cases from a file. Switching between test cases becomes a matter of reading from an different file. Test cases can be run in sequence by reading several files in sequence. It’s now possible to add test cases into a version control system separately. A disadvantage is that additional coding and maintenance for the test case files is required.
  • Write reusable procedures and functions to generate the stimuli for the DUT. This is a kind of primitive BFM.