We have a stimuli that is generating a “real” type of signal (like temperature) and our system is sampling the stimuli and producing a result which is sent to the output over a protocol X. We want to check whether the temperature transmitted over the protocol X is matching (maybe with tolerances) the temperature of the stimuli. The stimuli transaction though is generated at a much higher rate than the one transmitted to the output.
While we typically use fifos to cope with out-of-sync transactions, I’m not entirely sure how to proceed in this situation. I’ve been trying to search “uvm scoreboard multirates”, “uvm scoreboard different transaction rates” but none of these searches have produced the result I wanted.
In reply to abs:
What you are describing is the common scoreboard scenario. The UVM Library provides you the uvm_analysis_fifo to solve this issue.
Maybe my initial question was not clear enough, so I’ll elaborate. Let’s call the fifo on the output transactions the “output_fifo” and the fifo on the stimuli transactions the “input_fifo”.
For every transaction on the output_fifo of the DUT I have N transactions on the input_fifo. So now I will have one fifo full of N transactions and the other fifo with one transaction only.
In the scoreboard run_phase I pop the first transaction out of the “output_fifo” and how would I go about comparing with the transactions in the input_fifo? Do I pop one by one until I find one that matches? Since the matching is approximate, there might be more than one transaction matching, how do I proceed in telling which one is the match?
Difficult to answer without knowing how your matching algorithm works. You could put your stimulus transactions into a simple queue instead of a fifo. Then you can scan the queue however you need, and pop stimulus transactions off the queue when you are sure they are no longer needed.
For the matching algorithm it all depends on the situation, but in general our do_compare are performing a difference between the predicted and monitored data and whenever they are below a certain threshold then we mark it as valid.
This works with stimuli that are monotonic otherwise there will be more than one predicted value to match the monitored one, in that case we do not have yet found a robust matching algorithm. Probably we should be look up more “signal processing” techniques to match the two time series and maybe with some upsampling and interpolation as well.
The queue proposal is quite interesting, if we start from the hypothesis that predicted values are always at a higher rate than monitored ones, we can have the predicted write to fill the queue and the monitored write to trigger the matching algorithm.
Th eUVM will not be able to answer your question which sample you should use when you have mor than one tarsnaction matching. This should be defined by your application algorithm. The compare with a certain tolerance should not be a real problem.
In reply to abs:
Th eUVM will not be able to answer your question which sample you should use when you have mor than one tarsnaction matching. This should be defined by your application algorithm. The compare with a certain tolerance should not be a real problem.
I agree with you, indeed, but it took me a while to realize that what I thought was a common problem is indeed very specific and needs to be addressed specifically, not generally.