End of test criteria

In reply to mseyunni:

Hi Madhu,
There are multiple cases. I am trying to describe the situation where you can drop objections…

  Best Case : No drop of packets   
     - At scoreboard, try predicting the number of output packets for the injected
       packets. Once all have been received , you may drop the objection. 

     - If say, number of packet prediction is non-deterministic, 
           Try to reconstruct the payload from the received set of packets. 
           On periodic limits, you can match the received payload vs injected 
           payload. Once all have been matched, you may drop the objection.
          
     - You may probe DUT's internal signals to know if packets are still residing in DUT.

     - Certain designs have pkt counters, which you can keep reading via host interface
       at regular intervals to know the status and then drop the objection. 

  Worst Case: Drop of packets occurs...
      - A simple global timeout can be kept in the top module.
        initial #(No_of_pkts*Worst_Case_Delay) $fatal_error  ... etc   

      - Null packets(Non-Payload) : some protocols may mandate to keep sending null 
        packets b/w payload packets to keep the connection/link active, in such cases, 
        have a limit on the number of maximum allowed Null packets. 

+Shri