Note: The variable “i” used in for loop is globally declared), Dis comment the line and explain the behavior of for loop.
module check();
int i;
initial
fork
begin
for(i=0;i<2;i++) begin
#0 $display("OOO",i);
//#0;
end
end
begin
for(i=0;i<2;i++) begin
#0 $display("KKK",i);
//#0;
end
end
join
endmodule
In reply to Sriram Yalavatti:
Elaborate your doubt, that what do you want to ask?
In reply to rohit1501:
My doubt is for the above code i am getting displays as below,
And if i uncomment the commented #0 delays, i am getting displays as below,
Doubt 1)Finally i couldn’t able to analyse how fork_join is giving priority for the given threads and how stratified event queue is applied for that #0 delays.
Doubt 2)How i am getting value 2 in both the displays if at all the for loop termination condition is i<2 though the display is inside the for loop.
Note:1>In all the simulators i am getting the same kind of result.
2># KERNAL is just about an KERNAL information.
In reply to Sriram Yalavatti:
Hi,
Doubt 1.
Nobody predict the order of threads which are scheduled in same time slot.
This is because SystemVerilog/VHDL are for Hardware design, not software.
In Hardware world, nobody knows the order of simultaneous events.
You should keep it in your mind.
Doubt 2.
These behaviors are correct.
The key to understand these behavior is - in which timeslot (when) is “i++” executed.
In reply to kitanisi:
In reply to Sriram Yalavatti:
Hi,
Doubt 1.
Nobody predict the order of threads which are scheduled in same time slot.
This is because SystemVerilog/VHDL are for Hardware design, not software.
In Hardware world, nobody knows the order of simultaneous events.
You should keep it in your mind.
Doubt 2.
These behaviours are correct.
The key to understand these behaviour is - in which timeslot (when) is “i++” executed.
Hello kitanisi,
Thank you for the response,
1)Your assumption is wrong about prediction of threads which are schedules in same time slot,
Why because if we do not have any control over the forks then the threads present in the
fork-join, fork-join_any and fork-join_none will execute sequentially.
example code:
module semaphore_example;
class driver;
task send(input string message);
begin
fork
begin
sem.get(2);
$display("=======%s",message);
sem.put(1);
end
begin
sem.get(1);
$display("---------%s",message);
sem.put(2);
end
begin
sem.get(2);
$display("+++++++++%s",message);
sem.put(1);
end
join
end
endtask
end
endclass
driver dr[3];
semaphore sem;
initial begin
foreach(dr[i])
dr[i]= new();
sem = new(2);
fork
dr[1].send("driver12");
dr[0].send("driver1");
dr[2].send("driver13");
dr[1].send("driver2");
join_none
end
endmodule
Try to analyse the above code with semaphore concept to control the threads. At the same time change the thread positions which are inside the send task then you will come to know how the thread is giving priorities to the threads.
2)If the behaviour is correct can you just elaborate the process in words, I couldn’t able to understand your points.
In reply to Sriram Yalavatti:
In short, latest example uses semaphore to align events.
First example is w/o semaphore.
what if no semaphore in latest one ?
In reply to kitanisi:
In reply to Sriram Yalavatti:
In short, latest example uses semaphore to align events.
First example is w/o semaphore.
what if no semaphore in latest one ?
If there is no semaphore, then as i told the threads will execute based on the call in sequential order. For better analysis kindly work on the code at least once in the simulator.
In reply to Sriram Yalavatti:
This is not correct. The order of statement execution in a fork/join cannot be guaranteed by the LRM. This is not to say you can observe a tools behavior and determine that it executes in sequential order. You cannot rely on that ordering. Different tools and even different versions of the same tool can change the ordering.
In reply to dave_59:
Fine but as of now according to my knowledge and the experiment which I have gone through by using different tools which are present in Eda playground I got the above solution as threds without control were executed sequentially.
Hi Dave,
Apart from the semaphore concept can you kindly help me how the code is executing which is in the first chat of this conversation.
Thanks and Regards,
Sriram
In reply to kitanisi:
In reply to Sriram Yalavatti:
Hi,
Doubt 1.
Nobody predict the order of threads which are scheduled in same time slot.
This is because SystemVerilog/VHDL are for Hardware design, not software.
In Hardware world, nobody knows the order of simultaneous events.
You should keep it in your mind.
Doubt 2.
These behaviors are correct.
The key to understand these behavior is - in which timeslot (when) is “i++” executed.
- one time slot later (because of #0) from $display.
“#0” shouldn’t advance into the next time slot, correct?
Isn’t it more of scheduling the event to be processed in the in-active region (same time slot)?
I’m guessing the reason for print “2” is because “i” has a global scope, and both processes seem to be updating it. Am I interpreting it incorrectly?
In reply to amandepanda:
I think there has been some incorrect use of the term time-slot. By the LRM definition, a time-slot is the exception of all event regions from Preponed to Postponed where $time is a constant value. A #0 event delay causes an iteration of active and inactive event regions. In other HDLs, this is formally defined as a delta cycle.
Sriram, I can only give you the same answer to the same question. Whether the two loops appear to execute sequentially top to bottom or bottom to top, or in parallel is not defined by the LRM, it is a race condition.
In reply to dave_59:
In reply to amandepanda:
I think there has been some incorrect use of the term time-slot. By the LRM definition, a time-slot is the exception of all event regions from Preponed to Postponed where $time is a constant value. A #0 event delay causes an iteration of active and inactive event regions. In other HDLs, this is formally defined as a delta cycle.
Sriram, I can only give you the same answer to the same question. Whether the two loops appear to execute sequentially top to bottom or bottom to top, or in parallel is not defined by the LRM, it is a race condition.
Hello Dave,
Greeting for the day;
Actually when i started to analyse the simulation for the above code, i also understood like a #0 event delay causes an iteration of active and inactive event regions. In other HDLs, this is formally defined as a delta cycle. I waited for the response like, may be because of some other reasons this kind of simulation result came out.
I guess final conclusion is because of some delta cycle race between two processes(two #0 delays) i was getting an unpredictable simulation result.
@Dave:If i am wrong about the above conclusion kindly reply to this message.
Thanks and regards: Sriram Y.