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…/
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.
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
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.
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.
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 …
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.