Killing sequence error: [SEQREQZMB] The task responsible for requesting a wait_for_grant on sequencer

UVM
, ,
1

Hi,

could somebody tells me how can I bypass the following uvm_error when I’m trying to kill a running sequence before getting ended normally, UVM reports the following error:

uvm_test_top.env.ahb_system_env.master[0].sequencer [SEQREQZMB] The task responsible for requesting a wait_for_grant on sequencer ‘uvm_test_top.env.ahb_system_env.master[0].sequencer’ for sequence ‘default_parent_seq’ has been killed, to avoid a deadlock the sequence will be removed from the arbitration queues

Many thanks,
Regards,

2

In reply to Mohamed_TN:

It really depends on why your are killing your sequences and what state they might be in when getting killing. You may need to call stop_sequences() on the sequencer. And you have to make sure your drives are in correct state as well.

See this discussion for other issues.

3

In reply to dave_59:

thanks Dave, I’m killing my sequence because something wrong is detected (functionally) and I need to stop it, I’ve used seq.kill() and sequencer.stop_sequences() with both I got the same error message (with sequencer.stop_sequences() the simulator stuck), for the driver state how can I identify it?

Thanks,

4

In reply to Mohamed_TN:

Without seeing any more code are a lot more details, it will be difficult to help you. I suggest finding where your simulation is stuck when adding stop_sequences.

5

In reply to Mohamed_TN:

In reply to dave_59:
thanks Dave, I’m killing my sequence because something wrong is detected (functionally) and I need to stop it, I’ve used seq.kill() and sequencer.stop_sequences() with both I got the same error message (with sequencer.stop_sequences() the simulator stuck), for the driver state how can I identify it?
Thanks,

I think it is always not a good idea to kill or stop a sequence. It looks like you are in the phase of developing sequences. If something goes wrong you should reduce the number of cyles you are running and then debugging the issue. Killing a sequence will never point you to the cause of the problem.

6

In reply to dave_59:

I will try soon giving an example simplifying the case of issue

7

In reply to chr_sue:

Thanks chr_sue,

In fact what I mean by something wrong is a something described in the specification when the normal sequence is running and an event is occured the sequence must be stopped, then the issue has to be managed and sequence must be restarted I did not find other solution than stopping tbe sequence,

8

In reply to Mohamed_TN:

Yourr sequence body task has a loop running. Have a break statement inside this loop leaving the break when the event occurs. This is just simple.

9

In reply to chr_sue:

I tried fork with disable fork I got the same error, disable fork and kill have the same effect.

10

In reply to Mohamed_TN:

With disable for you are stopping the process running in the fork/join. It is a different mechanism but the the same result.

11

This is an example of code similar to my case just to simplify the issue:

the following is the main virtual sequence implementing a normal behavior:



class seq1_vseq extends uvm_sequence;

  uvm_reg_seq seq1;
  vip_seq seq2;

  `uvm_object_utils(seq1_vseq )
  
  function new(string name="seq1_vseq ");
    super.new(name);
  endfunction : new

  virtual task body();
    uvm_status_e status;
    uvm_reg_data_t value;
    int k_idx;
     
    seq1 = uvm_reg_seq ::type_id::create("seq1 ");
    seq2 = vip1_seq ::type_id::create("seq2");

    fork
      forever
        seq2.start(p_sequencer.vip1_seqr, this);
      seq1.start(p_sequencer.ahb_seqr, this);
    join_any
  endtask : body
endclass: seq1_vseq

the following one is a special sequence that will call for the above sequence to implement a special behavior which is the normal behavior of above virtual sequence that will be interrupted by a special event:



class seq1_with_abort_event_vseq extends uvm_sequence;
  seq1_vseq vseq1;

 `uvm_object_utils(seq1_with_abort_event_vseq )
  
  function new(string name="seq1_with_abort_event_vseq ");
    super.new(name);
  endfunction : new
    
  virtual task body();

    vseq1 = seq1_vseq::type_id::create("vseq1");

    fork
      vseq1.start(p_sequencer, this;
    begin
      wait (abort == 1);
      vseq1.kill();
      //some code to handle the abort event
      //we restart the vseq1 again after treating the abort event
      vseq1.start(p_sequencer, this));
    end 
  join
endtask: body
endclass: seq1_with_abort_event_vseq

the uvm_error issued by seq1 (called in seq1_vseq) sequencer.

To answer chr_sue about why I did not use a break statement when the abort event occurred inside the sequence (seq1_vseq)) that I will stop or kill, in fact the two processes are separated I wanted to do something clean and reusable since seq1_vseq just one example I have many like it in my case, so I implemented all normal behaviors in each sequence then for the abort event I called a sequence each time with the abort event in a new sequence (seq1_with_abort_event_vseq ), it may not be the perfect approach but I found it more clean and simple to understand and debug.

12

In reply to Mohamed_TN:

2 questions:
(1) where d9oes the abort variable does come from?
(2) your vip1_seq is running forever togetzerr with your reg_seq in a fork/join_any. Is this your intention?

13

In reply to chr_sue:

  1. I just put it to simplify but it can be anything come from virtual interface or anywhere in the environment

  2. yes

14

In reply to Mohamed_TN:

Your sequence should never have a connection to the virtual interface.
which tydata type is the avort variable? Is it an event or what is it?

15

In reply to Mohamed_TN:
Perhaps these articles on On-the-Fly reset could help. They’re old, but may be still might be relevant.