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.