Coverage driven verification has a big advantage – you can write a single test, and let run it several times with random seeds. Each run will generate a slightly different scenario – depending on the nature of the constraints you provided. I’ve talked about the pros and cons of excessive use of coverage driven methods here and here. Anyway, sometimes you just want to take an existing test and quickly create a number of variants off of it to make a small regression suite (that you might even throw away later on). For example – you could have a basic test that does some CPU writes and then drives random frames. During configuration you write to a register that sets the FIFO level and you want to have 10 different tests, each writes a different value to this register.

Time to talk about module-to-system reuse, a very important topic. If you plan your verification environment properly (using one of the common methodologies in the market today or your own) you’ll be able to easily build a system level verification environment that reuses most of your module level environments (i.e. sub-environments). However, even if all your sub-environments are well suited for plug and play reuse at the top level, there are still considerations to be made regarding the overall topology. In other words, how do you go about connecting the sub-environments to each other to make an effective top level environment? Here are 3 methods that you can use.