fork/join Proposal

[Kuree]

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

1. 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.
2. 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.

[leonardt]

We should support timing control and local timing controls, but for a vast majority of designs I'd imagine ##1 (default clock based timing) should be sufficient so maybe we should start there? Another issue is multiple clocks, in which case we might need fine grained, time unit based control? (sync up the clocks based on some fraction). I think mutex/semaphore semantics will be necessary for tests using concurrent data structures (e.g. multiple monitors pushing items onto a queue). Perhaps a simpler option to start with is to have race-free datastructures implemented in the target language and have tests use those data structures to avoid race conditions. However having support for these primitives in the front-end would definitely be the most flexible because I could imagine cases where the user just wants to use a mutex for a simple synchronization.