Running truly parallel sequences on same physical sequencer

OVM
,
1

Hi,
My agent has a sequencer connected to a driver of some HW interface (CIO), this protocol defines several layers of which I can run.

  1. single transaction, read/write transactions.
  2. burst of single transaction, burst is marked with start/end signals.

so our sequences are built in layers.

  1. A sequence that run single transaction
  2. A sequence that run a list of single transactions, wrapped with grab/ungrab of the sequencer.

my intention is to create a bunch of read bursts, in one sequence (using virtual seqr)
and another bunch of write bursts (again, using virtual seqr) and to fork them in parallel so I’ll be able to get on the bus a mix interleaved bursts of read and writes.

What I actually get is the writes and after that the reads, no interleaved bursts.

no wait for a response from driver in any of the sequences.

// sequence #1 body, single item handling, I've omitted sequence fields
task cio_txn_seq::body();
    `ovm_do(req);
endtask : body
    
// sequence #2 body, I've omitted sequence fields 
task cio_seq::body();
    cio_txn_seq txn;
    cio_txn_t   cio_txn_q[$];

   p_sequencer.grab(this);

    foreach( cio_txn_q[i] ) begin
        `ovm_do_with(txn);
    end

    p_sequencer.ungrab(this);

endtask : body

// read bursts (virtual sequencer) body
    task body();
        cio_seq     cio_seq;
        
        super.body();
        for (int i=0;i<m_length;i++) begin //{
            `ovm_do_on_with(cio_seq, p_sequencer.pick_sequencer(m_agent_name), {
                m_opcode == READ;
            });
// #1ps;// I've even added a artificial delay to move to next tick
        end//}
    endtask : body
endclass: btrs_cio_rand_seq

// write bursts (virtual sequencer) body
    task body();
        cio_pkg::cio_seq     cio_seq;
        
        super.body();
        for (int i=0;i<m_length;i++) begin //{
            `ovm_do_on_with(cio_seq, p_sequencer.pick_sequencer(m_agent_name), {
                m_opcode == WRITE;
            });
// #1ps;// I've even added a artificial delay to move to next tick
        end//}
    endtask : body
endclass: btrs_cio_rand_seq

these 2 are forked as I mentioned.

Help is very appreciated.
Thanks,
Uriel

2

Take a look at the article about Sequence Arbitration. This should give you some understanding why the order that you add sequences to a sequencer affects their execution and how you can change it.

3

Hi,

I’ve considered using prioeities in the sequencer, but one thing kept me from doing it, the second layer sequence is creating a bunch of basic sequence items that are linked to each other by their order, I cannot mix them, once I’m sending 2 bursts to the sequencer and re-prioritize them I’ll surely break this order link thus break the protocol, thats why I have the grab/ungrab from the first place, so 2 parallel bursts will not interleave their basic sequence items.

one thing I did test (code below), is using semaphore on the 2nd layer instead of greb/ungrab, and it actually worked, but I want to understand what is happening here.

// sequence #2 body, I've omitted sequence fields 
task cio_seq::body();
    cio_txn_seq txn;
    cio_txn_t   cio_txn_q[$];
 
seqr_semaphore.get();
   //p_sequencer.grab(this);
 
    foreach( cio_txn_q[i] ) begin
        `ovm_do_with(txn);
    end
 
    //p_sequencer.ungrab(this);
seqr_semaphore.put();
 
endtask : body

Thanks,
Uriel

4

Changing the priorities is not what you want to do. What you want to do is change the sequencer mode of arbitration. The default is SEQ_ARB_FIFO which means the sequences will be completed in the order that they are added to the sequencer. Change it to SEQ_ARB_RANDOM and the sequences will be randomly selected.

5

In reply to cgales:

Hi, thanks for your reply.

I agree, my comment was referring arbitration not priority, sorry.
Still, I dont think arbitration will help me here , again , that’s because it will shuffle the FIFO content going to the driver, this will create an illegal sequence of items that will violate the protocol i.e. illegal bursts.

What I wanted to assure is that the arbitration will work on the second level sequence the one with the grab/ungrab code.

Thanks,
Uriel