Conditional waiting on events : API discussion

Based on https://github.com/cocotb/cocotb/pull/1250 (by @Fatsie) proposals and discussion in https://github.com/cocotb/cocotb/issues/1682

We have discussed a bit internally on https://github.com/cocotb/cocotb/pull/1250 and concluded is a that it is a good idea but:

• function names have to be clear
• we can gain performance if we implement this in a slightly different way

For performance reasons the function should include as input:

• synchronization trigger (clock and edge)
• sensitivity list (signals to observe)
• condition for trigger

We would like to make API to replace such example:

    while True:
        await RisingEdge(clk)
        if condition():
            do_something()

with something like:

await OnCondition(clk, signals, condition)

Implementation of the waiting part could be initially somewhere along the lines (from @eric-wieser ) :

async def OnCondition(clk, signals, condition)
    while True:
        await RisingEdge(clk)
        if condition():
            break
        await First(*[Edge(hdl) for hdl in signals])

• We should support signals, vectors and buses?
• Should we use ReadOnly()?
• FallingEdge of clk

This way we minimize the number of triggers/callbacks that will improve performance and may become the recommended way to wait for the signal. In the future, such a trigger can be moved to GPI/C++.

Considering those points we should agree on API before implementation. Proposals are welcome. https://github.com/cocotb/cocotb/pull/1250 can be a starting point.

[themperek]

@chiraag It is interesting but can you move your findings to new issues? It does not look to me it belongs here. Also would be good to say what simulator and version you are using.

[cmarqu]

Related: Cadence’s Specman/e language and tool have something they call an event_port: https://community.cadence.com/cadence_blogs_8/b/fv/posts/usage-of-event-ports-with-edge-attribute-to-define-simulator-sensitive-events-rather-than-simple-ports