In reply to dave_59:
Thank you
In reply to dave_59:
I too had the same doubt that answer should be 5 & 7. But is it that since add is a static task, so when fork-join will end, latest value will overlap(/erase any previous value) & hence 7 is displayed twice.
Please correct me if Iām wrong.
Thanks
In reply to GoAyushi:
Hope this makes things clearer
Since the add is a static task by default, the local variables are allotted only one memory location for all calls to that task.
@t=0 ā a=3 , b=2
@t=1 ā a=3 , b=4; (second call overwrites the first call values, as no separate memory is allocated for local variables in different calls to the task); The first call hasnāt reached the display statement because of #2 delay.
@t=2 ā The first call display statement is executed and the sum is a(3)+b(4)=7
@t=3 ā The second callās display statement is executed and the sum is again a(3)+b(4)=7.
In reply to dave_59:
SystemVerilog added a lifetime qualifier for modules and interfaces so that all routines defined in that module would be considered automatic by default so you didnāt have to add the automatic keyword after each function or task declaration.
Hi Dave,
From the quotes is it implied that all the functions in my scoreboard class are automatic by default? And during run_phase all calls made to any task or functions will have an automatic behavior?
Thanks,
DJ
In reply to danajewely:
First question, yes. See the second paragraph of my previous reply.
Second question, not exactly. The calling of a task or function does not determine its lifetime, only its declaration. All of the tasks/function in your UVM code will be automatic, but letās say your driver calls a task/function via a virtual interface, the lifetime of those are static by default unless you declare them otherwise.
SystemVerilog added a lifetime qualifier for modules and interfaces so that all routines defined in that module would be considered automatic by default so you didnāt have to add the automatic keyword after each function or task declaration.
Does that mean, by Default all functions and tasks are Automatic ?
I tried the example
module test();
task add(int a, int b);
#2;
$display("the sum is %0d", a+b);
endtask
initial
fork
begin
add(2,3);
end
begin
#1;
add(3,4);
end
join
endmodule
whose o/p is 7 ,7 which means by default lifetime is static ā¦
In reply to abajaj:
The default lifetime for everything is static, except for class methods, which can only have automatic lifetimes.
SystemVerilog added a lifetime qualifier for modules and interfaces so that all routines defined in that module would be considered automatic by default so you didnāt have to add the automatic keyword after each function or task declaration.
what does this mean ?
In reply to abajaj:
module automatic test();
task add(int a, int b); // the lifetime of this task is now implicitly automatic
#2;
$display("the sum is %0d", a+b);
endtask
initial
fork
begin
add(2,3);
end
begin
#1;
add(3,4);
end
join
endmodule
In reply to dave_59:
Hi Dave, thank you for your explanation. I am wondering more about the synthesis consequences of automatic vs static and what later enabled automatic? Specifically, it is my understanding that each call of a module, task, or function in a verilog program will synth into a hardware element or collection of for each.
Letās say I have a fibonacci program with 20 rounds. For example, letās say each round synthesizes to a single CLB such that I now have 20 CLBs utilized on the fpga to execute the entirety of the program. this would mean that each round is static in terms of itās hardware implementation right? Automatic would be if I only had 1 or a few CLBs that could be reused over and over as many rounds as it takes to execute a program? I hope you can see my confusion. It hovers around how static and automatic are thought about in terms of synthesis, not programming.
Thanks Again!
In reply to dave_59:
In reply to srikanthen:
With no delays, you have a race condition. There are many possible outcomes, although you are only likely to see 5,7, or 7,5. That is because most event driven simulators only exec one thread at a time and do not switch to another thread until there is a potential blocking event.
I still donāt get how the static task produces the correct result without the #2 delay and otherwise with the #2 delay.