In IP, there is a block called “Input feeder” that when receives the GO field in it’s register it starts reading from a memory frames of video, based on DUT configuration registers.
These frames are being processed in various blocks in the IP, part of it are 3rd IPs.
The output of the IP is from a PHY (also 3rd IP).
Currently on the output there are no scoreboards, so cannot delay end of test using objections due to items in scoreboard.
Moreover, since the IP starts reading from memory by setting GO, there is no master driver + sequencer on the input of the IP. So cannot use objections. Am I wrong?
What would you suggest in order to end the test properly?
Currently, test ends using hard-coded # delay.
Was thinking adding watchdog on the output, which counts down from some value to zero and till expiration, and every time a transaction is monitored on the output is starting the count-down again.
If there is a register in the IP that tells it when to start, then is there a register that tells the user when it is finished? Perhaps a frame count register?
After writing all of the configuration registers and the start register, the testbench can poll the appropriate register to determine when the desired output has been achieved. After that, use a drain_time to allow sufficient time for the data processing to complete.
I will look to see if there is a register like that.
Problem is that in this IP(system), there are many blocks/IPs on data path until last output from the system.
First IP on the path is the algorithmic one which has this GO(start) register.
In the middle there are some more IPs of 3rd party and internal.
Last one on the path is a PHY VIP of 3rd party. This one does not have frame counter register, nor it has scoreboard (currently). So how should it work polling this register?
Some other thought,
if there is a bug in counting the frames and updating the frame counter register, or frame’s processing got stuck in the middle (RTL got stuck/deadlock) - polling of it might be problematic…
Using this mechanism will be good when it will be cleaned of bugs.
Anyway I guess we should use test timeout like UVM_TIMEOUT?
Added an image of high-level IP, not all is detailed though.
