In ooo_comparator there is an implicit assumption that all elements in queue received_data[idx] are “in order” to compare.
https://verificationacademy.com/cookbook/scoreboards#Reporting_and_Recording
In reply to gs:
I had the same issue when analyzing this section of the Cookbook. The out of order comparator relies on the fact the the transactions received on the two analysis ports are tagged with the correct ID. Let’s say that the driver sends transactions with the in-order IDs of 1,2,3 and the DUT processes with different priorities and outputs them in 2,1,3 order.
On the driver transaction flow side, the IDs probably just a static integer for the transaction class that gets incremented each time a new transaction object is created. What I cannot figure out is how does the monitor know to assign the correct ID when it constructs its transaction object upon receiving a response from the DUT. I mean, the monitor receives the first output response and then it must decide what ID to assign to it: 1,2 or 3. How does it know that it should assign ID 2 to this first received response (considering the above example)?
In reply to LPO:
I don’t think so the monitor need to map the response from the DUT to the ID. You need to develop some kind of a hash-key where the unique key(ID in your example) is generated from the transaction itself(you could use multiple variables of a transaction to generate a unique ID). Once you receive the response transaction, you need to derive the unique ID through the same way as how you did earlier. This way you’ll guarantee that the IDs are unique and OOO comparisons could be done by matching the unique ID