Out of order in driver and scoreboard

Hi ,

I have few doubts in uvm driver and scoreboard. How to handle the out of order in driver and scoreboard ?

In reply to maaroop:

You should not have doubts. Each seq_item Can be identified by its ID. In the scoreboard you have to perform the compares with the correct IDs.

In reply to chr_sue:

Hi Ben,

There are two ids , one is seq_id and transaction id. These id’s are generated by sequencer.

In scoreboard , should we compare transaction_id of each seq_item ?
or

should we add extra logic in seq_item , like id_count which increments when the task is called

And my last question is :when data from dut , i.e through virtual interface ,how to identify id from dut signals to compare with seq_item id ?

I would really appreciate if there is any code example for this?

In reply to maaroop:

Refer to this thread here.

In reply to maaroop:

In reply to chr_sue:
Hi Ben,
There are two ids , one is seq_id and transaction id. These id’s are generated by sequencer.
In scoreboard , should we compare transaction_id of each seq_item ?
or
should we add extra logic in seq_item , like id_count which increments when the task is called
And my last question is :when data from dut , i.e through virtual interface ,how to identify id from dut signals to compare with seq_item id ?
I would really appreciate if there is any code example for this?

If you are following the UVM Guidelines both IDs are generated automatically, i.e. you can identify any seq_item as a unique item. The method set_id_info(req) is doing this for you. This is the behavior you need to implement the correct functionality in your scoreboard

In reply to chr_sue:

In reply to maaroop:
If you are following the UVM Guidelines both IDs are generated automatically, i.e. you can identify any seq_item as a unique item. The method set_id_info(req) is doing this for you. This is the behavior you need to implement the correct functionality in your scoreboard

Two follow-up questions :
1)
Can we use the same seq id/transaction id method for even in-order transactions between more than one I/O ports on a router, if the port_id is not known?
2)
Is the idea to use the set_id_info in the response from the driver and write to rsp port? If so, could you show an example of how the scoreboard might use this info from the rsp port?

Thanks

In reply to UVM_beginner:

WRT to 1) I do not really understand what you mean. On the driving side there is always a one-to-one connection, 1 sequencer connected to 1 driver.
WRT to 2): here is a piece of codewith the fundamentals:

forever
begin
  seq_item_port.get(requ[i++]);

  @(posedge dut_vi.clock);
  dut_vi.cmd <= requ[i].cmd;
  ...
  fork
    begin
      my_tx resp;
      resp = my_tx::type_id::create("resp");
      resp.data = dut_vi.data;
      resp.set_id_info(requ[j++]);

      repeat(2) @(posedge dut_vi.clock);

      seq_item_port.put(resp);
    end
  join_none
end

In reply to chr_sue:

[quote]In reply to UVM_beginner:

WRT to 1) I do not really understand what you mean. On the driving side there is always a one-to-one connection, 1 sequencer connected to 1 driver.

If there is a router with 2 input ports and 2 output ports, each input port can send transactions to either of the 2 output ports. But the transaction is received in-order, without a port-id. So at the o/p port, we cannot know if the transaction that was received is from the “expected” input port. In the scoreboard, can we use sequence id/transaction id concept for comparing transactions in this scenario?

Thanks for your answer on 2)

In reply to UVM_beginner:

What you have to know is where a transaction comes from. This is not related to the seq/transaction_id. You could use a transaction data memeber which is indicating this.

In reply to UVM_learner6:

[quote]In reply to chr_sue:

Hi chr_sue, will every single seq_item from the same port also have a unique transaction/seq_id? Example same input_port sends 2 transactions on the stream, will they have unique transaction/seq id?

And if these 2 transactions have not arrived from the DUT side, we use a queue/associative array to store these transactions. When the transaction arrives on DUT side, we can search the queue for the trans/seq_id and do a comparison.

If so, there is not much trouble implementing in-order or OOO comparison, is that correct? Please correct me if I am missing something, because then there would not be so much discussion on OOO?

Thanks.

In reply to UVM_learner6:
seq_items comming from the same sequence have always the sam sequence_id, but the transaction_id’s are unique… Storing the transactions which cannot processed immediately in an associative array is a good solution. We can use the transaction_id as index. Then we do not have to search a whole queue, but looking for an existing index.

1 Like

In reply to chr_sue:

In reply to UVM_learner6:
seq_items comming from the same sequence have always the sam sequence_id, but the transaction_id’s are unique… Storing the transactions which cannot processed immediately in an associative array is a good solution. We can use the transaction_id as index. Then we do not have to search a whole queue, but looking for an existing index.

Thanks chr_sue.

1 Like