IN driver if run_phase has called one more forver loop

Hi team,


task run_phase(uvm_phase phase);
	forever
	begin
	seq_item_port.get_next_item(req);
	//driving to the interface//
	calc_task(req);
	seq_item_port.item_done();
	end
endtask

task calc_task(clock_seq_item xtn);
	calc =0;
	clk_frequency = xtn.clk_frequency;
	clk_start  = xtn.clk_start;
	calc = (((1/clk_period)*1000)/2);
forever
begin
	if (xtn.clk_start)
		vif.clk = clk_local;
		#(calc)vif.clk = ~clk_local;
	else
		vif.clk = 0;
end
endtask

1)in the clac task there is forver loop so that the item done will not be passed ! so next seq i cannot get it through …
but i need to pass the clk continuously…

kindly advice to come out of this deadlock suitation…/

thanks,
Gowtham.

In reply to P.Gowtham Santosh:

You can use fork/join_none to set up a process to run in the background. Also be careful to avoid zero-delay loops that will hang your simulation. That is what would happen if xtn.clk_start is 0.

In reply to dave_59:

Hi Dave,
Goal:- clock driving logic continuously wr.t of clk_start is high were we get input from the
clk_frequency based upon that it will be calculated …
2)so intially default frequency will be calucated then by updated frwequency we get the
new clock sending/
3)the second sequence we set the clk_start will 0 then the clk_generation will stop.

task run_phase(uvm_phase phase);
	forever
	begin
	seq_item_port.get_next_item(req);//getting sequence
	//driving to the interface//
	calc_task(req);// calling the task 
	seq_item_port.item_done();//sending the seq has been processed.
	end
endtask
 
task calc_task(clock_seq_item xtn);
	calc =25;
        clk_start = 1;
       fork:label// this will be calculating contionsly when seq is given 
       begin
	clk_frequency = xtn.clk_frequency;
	clk_start  = xtn.clk_start;
	calc = (((1/clk_period)*1000)/2);
       end
        join_none
fork:label2
forever
begin
	if (xtn.clk_start)
		vif.clk = clk_local;
		#(calc)vif.clk = ~clk_local;
	else
		vif.clk = 0;
end
join_none
@(clk_start=0)disable label;//this will end the fork join and drop the objection.
endtask

whether this approcah is right so !!

thanks,
Gowtham.

In reply to P.Gowtham Santosh:

Hi Dave,

does my above code solve u above condition.

thanks in advance!

Regards,
Gowtham.

In reply to P.Gowtham Santosh:

I’m not sure if this is a good solution, doing 2 different things in your driver:
(1) processing your seq_item
(2) generating your clock signal.
I’d seperate these things creating a clock agent.

In reply to P.Gowtham Santosh:

What if you move the clock generation part into interface object.
so driver will just tell the interface object the clock frequency and start/stop. And all that stuff will do interface object.

In reply to haykp:

hi chr_sue,

1)it is not only for one module, for multiple modules we have drive different clocks …
multiple agents we will be creating and different frequency will be running through,
that why we need to drive in driver only …

2)could u give me some other suggestions ,

thanks,
Gowtham.

In reply to P.Gowtham Santosh:

In reply to haykp:
hi chr_sue,
1)it is not only for one module, for multiple modules we have drive different clocks …
multiple agents we will be creating and different frequency will be running through,
that why we need to drive in driver only …
2)could u give me some other suggestions ,

You need the clock signals in the driver AND the monitor.
If you have in each agent a diiferent clock you might have to redesign your clock frequency configuration and distribution. The best approach is to have the clock generation in the toplevel module. You could do the clock configuration in a configuration object you are randomizing at the beginning of your test, passing this to the config_db and retrieve these entries in the toplevel module.