I have general question on how to end the test (gracefully) and also how to implement a watchdog timer that detects hangs in the RTL. I believe both these threads (that looks for graceful termination) and the watchdog time should run in parallel.
My environment has, 3 active (primary) interfaces that can inject any number of request packets and 2 reactive interfaces that can respond to DUT (w/wo delays) and 2 output interfaces.
Graceful termination:
Let us say the packets that I intend to inject into the RTL may/may not be equal to the number of output packets. Also, considering the delays in injecting the requesting packets and receiving the packets due to possible stalls/bubbles in the environment, how do I implement the end of test. As, I cant simply drop the objection after injecting all the request packets as they will take time to come out of the RTL based on various delay configurations.
Watchdog timer:
How to implement a watchdog timer that can also be configured ?
Can anyone give me an idea of how to implement these sort of things, possibly with a snippet of code ?
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.
Thank you for the ideas. I thought about the packet prediction, which is not that trivial in my case as it depends on some calculations based on the reactive response generators, basically modelling what the RTL does (effectively). Also, probing the DUT may not help in cases, where DUT had sent out all the packets, but are held in the response generators and if my configuration had large delays in processing the request packets, I do not want to drop the objection, so trying to understand what the best solution would be to consider all the cases of best & worst case delays.