Reply To: Writing a Test Plan, Identifying Transactions, and Documenting BFMs/MIT

[Jim Lewis]

Why Randomize
Our goal is to thoroughly test a design. For some designs, directed testing will get the job done.

For some designs, there are too many variations to be able to test every variation in the system. Variations can be a multiplying factor in testing a design. If the design can limit the variations in the system, the system can be tested more thoroughly – however this may sacrifice capability (flexibility) or performance of the system.

The depth of state information in the design also impacts verification. Is it sufficient to test relationships between the current and next transaction (such as read followed by a write), or do we need to test deeper relationships than that (read, read, write).

When we need to explore a larger space, randomization does a good job. Such as varying packet types, sizes, and cycle delays work well with randomization.

Exploring interactions of different interfaces interacting with the same resource. Simple example of this is where the DUT is an AxiStreamFifo and we randomize the data and delays in writing to and reading from the Fifo.

A more interesting example would be creating traffic to a network switch. Our first thing we might try is doing balanced traffic between all nodes in the switch. A more interesting test might be to designate a node as a file server and another as the WAN. Then randomize to have each node send most of its traffic to either the file server or the WAN and very little (or none) from node to node.

With randomization, we need to confirm we did something useful. This is where functional coverage comes into play. With functional coverage we look to correlate events (or values) on one or more independent objects generally happening at the same time that confirm something useful happened.