@schoeberl So, if I understood your proposal, we should then have the following syntax for timed assertions:

eventually { a == b } delay by 3
always { a > b } delay by 5 
exactly { a < b } delay by 7

Is it something like that you are looking for?

@schoeberl For the operators, I can't use any syntax that potentially collides with chisel syntax, so I chose to have them preceded by the ? character:

eventually { a ?== b } delay by 2
always { a ?< b } delay by 5
exactly { a ?> b } delay by 7
never { a ?>= b } delay by 1

It does look a bit odd, so I'm always open to any other proposal in this regard.

The idea behind the operators is to add the possibility to compare two different ports at different cycles, which isn't really as easy to do using the regular conditions. For example:

eventually(5) { dut.io.a ?== dut.io.b }

Would have to be done in a much more verbose way otherwise:

eventually(5) { () => { 
    val a = dut.io.a.peek().litValue()
    dut.clock.step(5)
    a == dut.io.b.peek().litValue()
}}

I personally find that the timed operators remove a lot of headache and simplify the overall syntax.

Yes that works if you just want to evaluate your function at multiple different cycles, but not if you want to do something like compare two ports at different cycles (i.e. port a from cycle 0 compared to port b from cycle 7). To do this you need some sort of separation between the two ports, which is offered by the operators. Such a separation isn't possible to get by just using a function literal.

Otherwise the stepping and asserting is already done internally, but the assertion simply evaluates the given function: assert(func()).

Yes, I think this is what I would want for eventually. Same as in ScalaTest. Comparing values from different points in time is a very special case. And you can do it like this:

val a = dut.io.a.peek().litValue()
eventually(5) {
  dut.io.b.peek().litValue() == a
}