[enhancement] Support barriers in testing/eval Procs

[hongted]

What's hard to do? (limit 100 words)

Currently procs can block for multiple reasons. For XLS's interpreters' purposes, a Tick() can return once procs are blocked and progress is made.

https://github.com/google/xls/blob/1578b44caac9cc63fc96924f09197d1d03dcd64c/xls/interpreter/proc_runtime.h#L119-L129

This issue is to enhance

1. XLS runtimes to support tick'ing until a set or procs are AtStartOfTick() and hold them.
2. DSLX language enhancements to support a barrier-like instruction so that a test proc can rely on #1000

Related: https://github.com/google/xls/issues/1538 https://github.com/google/xls/issues/1527

Current best alternative workaround (limit 100 words)

None

Your view of the "best case XLS enhancement" (limit 100 words)

DSLX should have a barrier or a WaitAndHoldProcsAtStart() built-in.

[ericastor]

~Sorry if I'm missing something, but what does issue #1000 have to do with this?~ (Fixed in original)

[mikex-oss]

That's just GFM messing things up. It's suppose to be Verilog delay control IIUC.

[grebe]

For the barrier to be useful for a test, I think you need the ability to have a group of test actions that happen atomically wrt the dut, e.g.

let tok = @startoftick(proc) {
  send(join(), ch1, ...);
  send(join(), ch2, ...);
};

...the idea being that the actions in the block happen atomically wrt to the proc after the prev tick ends but before the next begins. I think this is especially needed for latency-sensitive operations as otherwise you could wait for the start of the tick, immediately non-blocking-recv an empty channel, and then have the test put a value in that channel.