Waiting for clock is blocking the execution

UVM
1

I am trying to generate a clock inside the interface

 interface dut_if();
//importing uvm & package files
	bit clk;
	initial begin 
	clk =1'b0;
	end
	always 
	begin
		#10 clk = ~clk;
	end
endinterface : dut_if

However the following call inside driver blocks


	task run_phase(uvm_phase phase);
		`uvm_info("info3", "checking clock begins", UVM_LOW)
		@(posedge vif.clk) `uvm_info("info3", "vif clock works",UVM_LOW) 
	endtask : run_phase

The following is the transcript output

UVM_INFO m_driver.sv(25) @ 0: uvm_test_top.tb.env.agent.driver [info3] checking clock begins

UVM_INFO m_driver.sv(82) @ 0: uvm_test_top.tb.env.agent.driver [m_driver] Report: driver sent 0 packets

I tried to sync the clock within a driver task but it was blocking because of which I put in the run phase directly. I am able to “get” the virtual interface vif in the connect phase and the test runs if I remove any clock check (but since the DUT is tied to the interface, it does not respond without the clock). Is there something I am doing wrong?

2

In reply to Giri3839:

It would really help to show a complete example showing the behavior you are seeing.

Without seeing all of the code, there could be a variety of potential issues.

It is recommended to create the clocks at the testbench level and use them as inputs to your interfaces/modules. Also, you should use a forever block to generate a clock, not an always block.

3

In reply to cgales:
Thank you for the reply. I had tried changing the code to look like this in top file


	bit clk;
	man_if dut_if(clk);
	//initialization
	initial begin
		clk = 1'b1;
	end
	//Clock generation
	always
	begin
	 #10 clk= ~clk;
	end

this is the interface code

interface man_if(input clk);
task check_clk();
`uvm_info("info2","starting check...",UVM_LOW)
`@(posedge clk) `uvm_info("info2","not blocking...",UVM_LOW)
endtask : check_clk
endinterface : man_if

and the display is showing only the first line.
This really is the complete record of clock appearing in the files. I do not own the module I am trying to verify so I am not sure how much I can share
I have another task in the driver run_phase which is executing correctly with @(posedge clk) removed. Is there anything specific you’d like to know?

4

In reply to Giri3839:

Change your clock generation:


bit clk;

initial begin
  clk = 0;
  forever #10 clk = ~clk;
end
5

In reply to Giri3839:

You have a potential race condition with the 1st posedge of clk happening at time 0. Since the initial value of a bit is 0, you are assigning it to 1 at time 0. That will be a race condition with any code waiting on @(posedge clk) also at time 0.

You can avoid that race by making sure the first assignment to clk does not happen at time 0 (As I see Chuck just suggested).

If you want clk to start out with the value 1 instead of its default value 0, the declare it as

bit clk=1;

This initialization is guaranteed to occur before any initial or always block starts executing.

6

In reply to cgales:

Thank you for the suggestion but the blocking seems to continue. I want to add that
1.the waveform shows the clock toggling but the statement is blocking
2.the task is in the same scope as the clock signal and I am able to update other signals through another task defined in the interface(clock becomes blocking in that too)
3. the interface itself is accessible since I can call the tasks through a virtual interface

I feel as if this is a silly mistake somewhere but I am out of ideas on where to look, because as I have said earlier, this is the only place where clock signal is referred to

EDIT: I have found that it is a delay problem and it gets solved by defining a default sequence instead of the seq.start() method. Do you know why it is happening?

7

In reply to dave_59:
Thank you. I do not have any requirement for the initial value. I have changed it to 0 but the issue still persists. The problem is that clock is blocking rather than not toggling itself. But I will keep this point in mind for the future…

Also, just noting my thanks for the explanations on backdoor access method in the DVCon paper. It was helpful

Can you please tell me why seq.start(sequencer) would lead to intolerance of delay in run task

8

In reply to Giri3839:

You should never use a default sequence. The seq.start() method is the recommended method to start sequences. You would have to show your environment if you want more insight on why things aren’t working as expected.

9

In reply to cgales:
Okay, I have found the issue and it really is a silly one. I started out with a default sequence and changed it to seq.start later without incorporating the raise/drop objection. This meant that my initial code was running correctly but any delays would not be allowed to run. But since I didn’t put any delay and directly asked to wait for clock,I assumed it was a problem with the clock signal and tried to solve that.
Thank you for your time and responses.