Proposed semantics
The fork process is designed to be similar to Loop:
process_1 = tester.fork()
process_2 = tester.fork()
process_1.poke(circ.I0, 1)
process_2.poke(circ.I1, 2)
process_1.expect(circ.O0, 3)
process_2.expect(circ.O1, 4)
tester.join(process_1, process_2)
Join semantics
We should support these three join semantics via function calls:
join -> tester.join(*args)join_none -> tester.join_none(*args)join_any -> tester.join_any(*args)
Implementation details
We need to take care of two major backends, namely, SystemVerilog and Verilator. SystemVerilog is much easier to implement without any doubt, but Verilator is straightforward as well.
SystemVerilog
Upon join functions are called, we extract actions from each process and codegen them inside a begin end block, then emit proper keyword.
Verilator
Although Verilator does not have any fork/join construct, we have pthread and std::thread. The tricky part is how to synchronize the local timing control, should we support it. One way to solve this is block the local timing control by default and use a scheduler thread to unblock fork thread. join_none, join_any, and join can be easily implemented through pthread or std::thread.
Questions
- It is very common for a fork process to have local timing controls. For instance, if default clock is set, we can do
##1 to wait until next clock cycle, or simply #1 to delay one time unit. Are we going to support timing controls in fault? That might requires some changes on the implementation of steps and clocks in fault.
- The concept of fork/join inevitably introduces race conditions. Are we going to support
mutex or semaphore semantics? semaphore is a native construct in SystemVerilog, and it is almost identical to that in pthread. From implementation perspective it is straightforward to add.
Please let me know if you have any suggestions or comments.
Proposed semantics
The fork process is designed to be similar to
Loop:Join semantics
We should support these three join semantics via function calls:
join->tester.join(*args)join_none->tester.join_none(*args)join_any->tester.join_any(*args)Implementation details
We need to take care of two major backends, namely, SystemVerilog and Verilator. SystemVerilog is much easier to implement without any doubt, but Verilator is straightforward as well.
SystemVerilog
Upon
joinfunctions are called, we extract actions from each process and codegen them inside abegin endblock, then emit proper keyword.Verilator
Although Verilator does not have any fork/join construct, we have
pthreadandstd::thread. The tricky part is how to synchronize the local timing control, should we support it. One way to solve this is block the local timing control by default and use a scheduler thread to unblock fork thread.join_none,join_any, andjoincan be easily implemented throughpthreadorstd::thread.Questions
##1to wait until next clock cycle, or simply#1to delay one time unit. Are we going to support timing controls in fault? That might requires some changes on the implementation of steps and clocks in fault.mutexorsemaphoresemantics?semaphoreis a native construct in SystemVerilog, and it is almost identical to that inpthread. From implementation perspective it is straightforward to add.Please let me know if you have any suggestions or comments.