Richard Lin

That sounds reasonable. Not sure if there was a reason it's not currently being prefixed with the class name, but I don't think so?

Yeah, that's an interesting question. I'm not sure I want to have expectDequeuePartial because of the potential to proliferate into all kinds of special-case expectDequeue* which could get really confusing....

That's amazing... and also simultaneously kind of terrifying. One problem I see with making partial bundles a top-level option is that it's not an obvious option, and library builders might...

I'm curious about the use case for needing an absolute maximum cycles: are you encountering livelock, or is it some artifact of your test structure? Getting cycle counts is something...

So I would generally treat a test that overran its maximum cycles as a failed test (assume it failed from livelock), that's a reasonable addition (though I don't think it...

Sorry, there isn't yet. I think this could be a relatively simple change to implement, but there's a train of major refactor PRs undergoing review, so it might be some...

To expand on that answer a bit more: - Testbenches written in testers2 are nonsynthesizable, you're essentially writing a Scala program that interfaces with a simulator through peek and poke...

That makes sense. Architecture-wise, it should be possible to create a backend that dumps poke and delays, and it was a theoretical consideration during the design phase. I don't have...

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

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