On 02/07/18 16:18, Evan Lavelle wrote:
> On 02/07/2018 13:14, Martin Whitaker wrote:
>
>> Using 1364-2005 as a reference, section 11.6.3 states:
>>
>> "A blocking assignment statement (see 9.2.1) with a delay computes the
>> right-hand side value using the current values, then causes the
>> executing process to be suspended and scheduled as a future event. If
>> the delay is 0, the process is scheduled as an inactive event for the
>> current time.
>>
>> When the process is returned (or if it returns immediately if no delay
>> is specified), the process performs the assignment to the left-hand side
>> and enables any events based upon the update of the left-hand side. The
>> values at the time the process resumes are used to determine the
>> target(s). Execution may then continue with the next sequential
>> statement or with other active events."
>
> So your reading of 11.6.3 is that everything is statement-based, and the blocking assignment must be
> executed before the next statement, which is the event control (@(...)). Since the event control
> hasn't been executed yet, the process isn't sensitive to the update, so clk stops toggling. That
> makes sense, of course.
Not everything, no. But statements in the same sequential block must be executed in order - that's
11.4.1(a). And I think it is reasonable to assume that includes the case of looping from the end to
the beginning of the block.
> But, at the same time, the actual algorithm in 11.4 isn't statement-based, and the algorithm
> couldn't run after every statement, or the scheduler wouldn't work - it can only run after suspend
> points such as delay or event controls (as is the case with VHDL and SystemC). I remember Steven
> Sharp confirming this in c.l.v, but I don't have a record. In this sense, it seems to me that 11.4
> conflicts with 11.6.3.
Look at 11.4.2. It states that "statements without time-control constructs in behavioral
blocks do not have to be executed as one event". That implies the converse, that statements with
time-control constructs (# and @) do have to be executed as one event. But in general, the scheduler
is free to switch between processes at any time - not just at statement boundaries or at event controls.
> So, if you only ran the algorithm at the next event control, at the *same* simulation time, you'd
> discover an update event on clk at the *current* sim time, and you might be tempted to re-enable the
> process (in this case, 'clk' would start toggling), but no simulators I've tried actually do this.
> Maybe the fix is that processes are only sensitive to future events, and not events in the current
> time slot?
No, the update event for a blocking assignment is part of that statement and must be executed before
that statement is considered complete. Evaluation events for any sensitive processes are added to
the active queue immediately after performing the update (as per the pseudo-code in 11.4). So if the
process is still executing the last statement, it can't have reached the time control for the next
statement, so can't be sensitive.
> I think my basic confusion is that 11.4 must be wrong. Some of the algorithm must run between
> statements, or blocking assignments wouldn't work. Some of it can't run between statements, such as
> enabling other processes which are sensitive to blocking assignments - this has to wait until a
> suspend point.
No, I think this is where you are going wrong. The sensitive processes are enabled (by adding them
to the active queue) at the time the update event is executed. At a suspend point, the scheduler
just picks an event that's already in the active queue.
|
