Clock event put, get, and wait

I found that my simulation was hanging when I called queue.put on a queue with maxlen=1. I also hung awaiting Event.wait()

I’ve fixed the problem by creating versions of the queue and event that loop on a clock-based event so that control goes back to the simulator. Now you pass uvm_root().run_test() the clock as well as the test name. This gets stored in ConfigDB() and can be used anywhere in the testbench.

Clock-based blocking

Here is the event:

class UVMEvent(Event):

    def __init__(self, name, clock):
        super().__init__(name=name)
        self.trigger = Timer(10, units="step")
    
    async def wait(self):
        while True:
            await self.trigger
            if self.is_set:
                return self.fired
            else:
                continue

And here are the put and get:

    async def put(self, item):
        while True:
            await self.trigger
            try:
                self.put_nowait(item)
                break
            except QueueFull:
                continue        

    async def get(self):
        while True:
            await self.trigger
            try:
                item =  self.get_nowait()
                print("GOT:", item)
                return item
            except QueueEmpty:
                continue

Do you think this a generalizable feature in cocotb?

[marlonjames]

There is no inherit problem with a task calling await q.put() on a Queue with maxlen = 1. The calling task will suspend until there is room in q, which can only happen if another task calls await q.get() or q.get_nowait().

I don’t see value in adding extra Timer triggers or waiting on clock edges inside these coroutines, as they are already waiting on some Event to be triggered. If your simulation is not progressing, there is some other underlying issue.

[eric-wieser]

I think there’s a misunderstanding here. Control is returned to the simulator simply when there are no coroutines left to run, right? The scheduler loop is roughly:

• Simulator triggers a “real” event and wakes up some coroutines
• Those coroutines set events and may wake up other coroutines
• Coroutines go to sleep again by awaiting
• Eventually the last coroutine awaits and control returns to the simulator

The only thing that makes “real” triggers special is that they start the chain of events. Any type of trigger can end a chain of events.

If you end up in a situation where the only events waiting to fire are “virtual”, your testbench has a deadlock and is itself the problem; no change to your dut can ever wake it.

If you end up in a situation where your coroutines wake each other up forever, then your testbench has an infinite loop in which no time passes and is itself the problem; no simulator events will ever be able to fire.