[sv-ec] Comments on event changes CH17.html

Subject: [sv-ec] Comments on event changes CH17.html
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Jan 06 2003 - 03:47:02 PST

I assume we are going to begin today where we left off on the event
debate. I believe the debate now focuses more around the contents of
http://www.eda.org/sv-ec/CH17.html than what is in the Draft 1 LRM so my
comments refer to that document.

Syntax nits
----------

- It currently says:

> The syntax to declare a non-persistent event is:
> event event_dentifier;

I believe this should be 'event_identifier' this occurs a bunch of times
in the changes document.

- last example is:

> fork
> T1: while(1) @ E2;
> T2: while(1) @ E1;
> T3: begin
> E2 = E1;
> while(1) -> E2);
> end
>join

The line "while(1) -> E2);" has a syntax error, the last ')' is not
needed.
This would also send NC into an infinite loop forever triggering E2. It
think the entire line should just be '-> E2;' and remove the while
altogether (maybe it needs a begin/end).

Persistent Event Clarification Needed
-------------------------------------

If we are going to accept this concept of an event that "persists
throughout the time-step, that is, until simulation time advances". We
are going to need to propose a change in the simulation cycle (1364 -
Chapter 5) to add a portion of the stratified event queue where these
things change state back to "off" after the monitor events have
executed.

Alternative Proposal for "Persistent Event" - "Non-blocking Event
Trigger"
------------------------------------------------------------------------ 

--

Note: this is different than what Adam K. previously proposed (and was
rejected)in IEEE 1364, that was events with transport delays, but had
the same title.

The big value added by the persistent event is the reduced
non-determinism created by allowing the event to remain triggered in
order to avoid race conditions which occur from 0-delay simulation
semantics. This is exactly like the race-conditions that are created by
using blocking assignments.

I propose the we introduce a new operator ->> which we will call the
non-blocking trigger operator. The operator takes a single event as an
argument:
	event E;

	->> E;

The effect of this operator is that the event E will be triggered in the
non-blocking assignment phase of the simulation cycle. In 1364, this
would be defined as adding a "non-blocking assign update event" to the
current simulation time. The effect of this update event would be to
trigger the referenced event.

The procedural code context in which the non-blocking trigger occurs
continues to execute sequentially (does not block). This is also true of
the regular trigger '->' operator, so the name non-blocking event
trigger refers to when the event is scheduled rather than what happens
in the sequential context.

This delaying of the event trigger until NBA-time disambiguates the
triggering of events in exactly the same way that non-blocking
assignments disambiguated assignment many years ago, and requires no
changes to the simulation cycle. 

It also has the advantage that events do not have to take on the
characteristic of having a persistent value over time. They are still
just instantaneously triggered (like the (posedge clk) in the CH17
proposal), so a new declaration for events (event bit) is not necessary.
All events could be triggered in this way. Note, I actually like the
promotion of events to first class objects that can be assigned to one
another and passed to tasks. I would even allow them to occur in
'struct' and 'union' objects to embed an event with data.

The following example is ambiguous.

	event E1;
	fork
		T1: begin @ E1 $display("T1"); end;
		T2: -> E1
		T3: begin @ E1 $display("T3"); end;
      join

Depending on the simulator (or even simulation cycle) Either T1 or T3,
or both will display and the fork/join may or may not ever unblock. If
you replace the trigger with a non-blocking trigger.

	event E1;
	fork
		T1: begin @ E1 $display("T1"); end;
		T2: ->> E1
		T3: begin @ E1 $display("T3"); end;
      join

The order of execution becomes unimportant. T1 and T3 would both block
and the trigger would be scheduled for NBA-time. When NBA-time arrives,
both processes would always see the event.

There of course remain multiple NBA times possible in a given simulation
cycle, but that very, very rarely causes issues with blocking vs.
non-blocking assignment ambiguity. This solves the race condition
problem triggering events with no more and no less ambiguity than
non-block assignments did without introducing a new class of object or
changing the simulation cycle.

Note, a logical extension of this proposal would also be to allow a
delay control after the operator:
	->> #5 E1;
I bring it up here just because someone will. I think it makes sense but
wouldn't protest too hard if only the immediate case was allowed. This
is closer to Adam's proposal on adding transport delays to event
triggering.

Jay

This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 03:47:37 PST