Implement expectHold about chiseltest HOT 2 OPEN

Results of today's discussion:

• Proposed syntax is an expansion of the expect syntax: wire.expect(val).hold, which performs the immediate instantaneous expect and holds until the end of the timescope. Semantics are inclusive at start and exclusive at end (so it does not perform the check on the cycle the timescope ends, this allows waiting on a precondition for the expect.
• One consideration is that this has to work with Regions. The proposed syntax is a delayed expect: wire.expect.hold.onRegion(region).do(val).
  • Note: ideally we would have wire.expect(val).hold.onRegion(region), but the expect(val) will evaluate instantaneously and cause problems. The above is kind of a least-worst solution, but ideas are welcome.
• Order checking is unclear, but the simplest is that the expect executes every timeslot after the thread (or where it would be scheduled to execute, if it is blocked), and cross-thread-dependency checks happen accordingly. Unless anyone has better ideas, this is what will be implemented, though as Testers2 remains in alpha we can always change it.

from chiseltest.

Putting down some more thoughts.

One question is whether expect-hold should be only level-sensitive or also driver-sensitive (as is the case with instantaneous expect - it checks the driver must be the same thread or a parent thread before the immediate child spawned). Note that driver sensitivity only matters for combinational paths within the testdriver code.

Driver sensitive

• Implementation would largely be as described above, the expect would evaluate immediately, and at the end of the thread's execution slot for each timeslot the timescope is active.
• This should indirectly ensure the value holds through all threads executing. The point is moot for threads executing before, and only parent threads execute after. Parent threads can't override-poke wires that child threads are expecting after the child thread spawns.
• Main arguments for would be this providing consistent semantics as the regular expect while maintaining the level sensitivity property through the end of the timeslot. Might also disallow potentially unsafe interactions, which can be explicitly overridden with the use of regions.
• On the other hand, this might also disallow potentially useful interactions. While the same thread can poke a wire that is expectHeld, a child thread cannot. But given that this is a disallowed interaction with regular expect, perhaps expectHold shouldn't allow this either.

Driver insensitive

• Implementation would be slightly different, the expect would evaluate immediately, and at the end of each timeslot (after all threads have run).
• Aside from the initial expect (which can be skipped), this can't throw a thread order exception. Also directly ensures the value holds right before a clock edge.
• Main argument for would be that it's currently unclear what antipatterns the driver-sensitive path would prevent. But as the driver-sensitive path is more restrictive, I'm probably going to implement that first.

Other

• For multiclock designs, consistent use of expectHold (instead of the instantaneous expect) with a timescope lasting one clock cycle can ensure that a signal lasts to the end of the specified clock, even if another thread clobbers the signal in a timeslot before the relevant clock edge. This may be more a library style thing, to encourage the use of expectHold where an instantaneous expect might not be robust to multiclock and extra timeslots between clock edges.

from chiseltest.