How does OOO handled in all the cases?

I went through OOO scoreboard implementation options. Associative arrays or LUTs are used to store the transactions using an unique field of the transaction as index_id(mostly address) for before queue. I believe this undex_id is a must to handle out of order transactions.

In some cases, there may not be such unique fields in transactions(seq_item). In that case, do we add an index_id field to the transaction(seq_item) just for testbench reference? Do we generate it internally in sequence/driver?

I came across an example wherein, set_transaction_id, get_transaction_id are used to identify the sequences to the sequencer and route the responses back to the sequencer. is this OOO applicable only on driver-sequencer side? This is not useful to use in case of OOO scoreboard, right? Scoreboard requires a field of transaction to be unique to store in before queue, right?

I am just trying to get the difference between OOO handling in both the cases. I would appreciate any clarity given or any link to understand it further.

Thanks in advance!

In reply to uvmsd:
I think you may be confusing two different things. The transaction_id is used to send a response back to the sequence that sent the sequence_item. It doesn’t matter if the responses are in-order or out-of-order. If the response are out of order, then you’ll have to use the same technique you used in the scoreboard to match the responses from the driver, like the unique field value.

I agree with Dave. I think you are getting confused between these two

  1. out of order transactions verification in a scoreboard
  2. sequence item arbitration by the sequencer

For 1 like you mentioned we use associative arrays and queues and all transactions generally have an id field.

For 2 as far I understand sequencer will handle the id. You don’t have to worry about it.

In reply to dave_59:

In reply to uvmsd:
I think you may be confusing two different things. The transaction_id is used to send a response back to the sequence that sent the sequence_item. It doesn’t matter if the responses are in-order or out-of-order. If the response are out of order, then you’ll have to use the same technique you used in the scoreboard to match the responses from the driver, like the unique field value.

ok, thanks Dave.
I was bit confused since when I searched for out of order handling, out of order driver was also listed.
BTW, in case of out of order responses, the unique field value is from the transaction field ?

In reply to yasaswi93:

I agree with Dave. I think you are getting confused between these two

  1. out of order transactions verification in a scoreboard
  2. sequence item arbitration by the sequencer
    For 1 like you mentioned we use associative arrays and queues and all transactions generally have an id field.
    For 2 as far I understand sequencer will handle the id. You don’t have to worry about it.

Thank you! For 1, the transactions will generally have an id field. But I believe there must be some protocols that won’t have unique id field. How is that handled? One such could be packet processors etc.

In reply to uvmsd:

You’ll have to look at the your design requirements. If the design can’t can’t figure it out, what can you verify?

In reply to dave_59:

In reply to uvmsd:
You’ll have to look at the your design requirements. If the design can’t can’t figure it out, what can you verify?

Sorry, I haven’t come across such a design so far. But I was just trying to understand the possibilities and options.

Thanks Dave.

In reply to uvmsd:

If there is no id field how does the design handle OOO transactions? How does it know which transaction’s data it is receving? I have never come across an implementation where there is no id field and the transactions are allowed OOO. Not sure sorry.