Directed-Test Methodology
Building a directed verification environment with a comprehensive set of directed tests is very time-consuming and difficult. As directed tests only cover conditions which have been anticipated by verification team, they do a poor job of covering corner cases. This can result in costly re-spins or, worse still, missed market windows. conventionally verification IP works in a directed-test environment by acting on specific testbench.
Commands like read, write or burst to generate transactions for whichever protocol is being tested. This directed traffic is used to verify that an interface acts as expected in response to valid transactions and error conditions. Drawback is that, in this directed methodology, task of writing the command code and checking responses across the full breadth of a protocol is an overwhelming task. Verification team frequently runs out of time before a mandated tape-out date, resulting in poorly tested interfaces. Though, the bigger issue is that directed tests only test for predicted behaviour and it is essentially the unforeseen which trips up design teams and leads to extremely costly bugs found in silicon.