Rich
Rich

Reputation: 1185

What is the minimum length of time/cycles a System Verilog wait() statement will wait?

I have a SystemVerilog task I am trying to port to SystemC. The body of the task simply waits on a boolean expression and then pushes onto a queue. The SystemC wait mechanism doesn't work quite the same way though, it will only wait on time or events.

So I'm wondering what is the minimum length of cycles/time that SystemVerilog wait() will wait before re-testing the boolean expression. In other words, how often or what drives re-testing of boolean expressions in SV wait()?

If the answer is simply once every cycle, which I hope and expect but can not confirm, then the solution is easy.

Here is the code, with some things renamed and simplified to make more sense out of context:

    virtual task put(input cls_item item);
        wait (queuecount < queuemax);
        push_back(item);
    endtask

Upvotes: 2

Views: 2307

Answers (2)

jclin
jclin

Reputation: 2559

I do agree you can think of wait(expression) as always checking the condition expression continuously. That's thought for the designer, but a computer program can not be designed at that way or it wastes CPU time in the condition checking loop.

In SystemVerilog, its compiler might model the boolean expression as an event. When the execution runs to wait() and condition is false, the simulation kernel suspend the current thread and execute others. In the simulation, every time queuecount or queuemax has been changed, the condition is re-computed using < operator. Once the condition is satisfied, the event is triggered and then the waiting thread is re-schedule and prepared to resume its execution.

In SystemC, because it's C/C++ world plus an event driven hardware modeling library, that's the natural of C/C++ you write a function like function(<condition expression>). However, after C/C++ compilation like GCC, actually the program will first evaluate the <condition expression> then pass as the argument to the function. It is the software way. Such that, in wait() function, it can only see true or false or 0/1, it does know about what you are waiting for. It does not make any sense for the real intent of wait() in hardware modeling. Therefore, the wait() can only accepts event argument in SystemC. For example,

wait (event);       // waiting for the event
wait (a_signal);    // signal interface has value_changed_event, posedge_event, negedge_event
wait (10, SC_NS);   // simulation time is also an event in SC kernel

If you would like to model the same condition for wait() like SystemVerilog, you have to manually write the detail of events. Following is a proof of concept pseudo code, you can find examples from SystemC or sc_fifo class.

    sc_event           waiting_event;

    void put( ... ) {
        while (!(queuecount < queuemax))
            wait( waiting_event);
        push_back(...);
    }

    void get( ... ) {
        ...
        notify_queue_available();
    }

    void notify_queue_available() {
        if (queuecount < queuemax)
            waiting_event.notify();
    }

Upvotes: 1

dwikle
dwikle

Reputation: 6978

From the LRM:

9.4.3 Level-sensitive event control

The execution of a procedural statement can also be delayed until a condition becomes true. This is accomplished using the wait statement, which is a special form of event control. The nature of the wait statement is level-sensitive, as opposed to basic event control (specified by the @ character), which is edge-sensitive.

The wait statement shall evaluate a condition; and, if it is false, the procedural statements following the wait statement shall remain blocked until that condition becomes true before continuing.

Basically, you can think of wait(<boolean expression>) as checking the expression continuously. Once the expression is true the wait will unblock and the execution of the sequential code will continue.

If the expression is true when the wait() is first encountered, it will not wait at all.

Upvotes: 3

Related Questions