Subject: Re: [sv-ec] Comments on updated event proposal
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Mar 13 2003 - 14:06:07 PST
Neil,
I hope you saw my earlier response to Jay so I won't
repeat those comments here.
My comments are interspersed in blue.
Attached is a new version with all your edit's applied.
Arturo
----- Original Message -----
From: "Neil Korpusik" <Neil.Korpusik@eng.sun.com>
To: <sv-ec@eda.org>
Sent: Thursday, March 13, 2003 11:28 AM
Subject: Re: [sv-ec] Comments on updated event proposal
Jay has raised some good points on the latest event proposal. I agree with
the suggestions that he has made.
The latest proposal is definitely a step in the right direction over what
we had been considering in the last face-to-face meeting.
I would like to add the following comments to the discussion:
1. Section 12.6, first paragraph, last sentence
"Also, System Verilog events act as handles to synchronization queues,
thus, they can be passed as arguments to tasks, and they can be
dynamically allocated and reclaimed."
The part about being "dynamically allocated and reclaimed" is a bit unclear.
The user doesn't use the 'new' method to allocate an event. It appears that
there are a couple of places where this dynamic behavior is exhibited.
True. Uers do not call new on events, but they can call new on a class that
contains event declarations, and that would create new events:
class foo;
event e; // this creates a new event
event b = null; // this does not.
function new( event _b ); b = _b; endfunction
endclass;
a. Event declarations in a subroutine
These could be declared to be automatic. This causes the events to
be dynamically allocated when the subroutine is called.
Yes, and deallocated when the subroutine returns.
b. Assigning one event to another
It appears that this would cause the "underlying synchronization
object" to be reclaimed.
Yes, provided that no other references to the underlying synchronization
object remain.
Is this what you intended or is there more to it?
This is what I intended.
2. Example on page 2
event done;
event done_too = done;
fork
@done_too;
trigger(done);
join
The @done_too may or may not see the event trigger in this example since
the order of thread execution within a fork/join pair isn't defined.
Good point. The example should be changed to:
#1 trigger(done);
3. Section 12.8.1 Disabling Events
event E1 = null;
@E1;
@E1 will now either no longer block (or always block - depending upon
whether Jay's suggestion is adopted or not).
What if we subsequently assign E1 to another event variable that isn't
set to null? (e.g. E1 = E2;)
Will E1 now take on the behavior of event E2 or is it permanently
stuck in a particular state because it had previously been assigned null?
Subsequent operations on E1 will take on the behavior of E2, but
the process that was executing @E1 prior to the assignment is
not affected by the assignment (blocks forever or doesn't block).
4. Typos and possible wording changes
There are some typos and possible text changes;
a. Should 'wait' always be bold within the text?
Yes.
b. Section 12.6.3, page 2, 3rd paragraph, 2nd sentence
"The trigger property..." could be re-written to be
"The triggered event property..."
OK.
c. There are a few places where the font is messed up, especially for
the word 'while' in that last example and the word 'null' throughout
the text.
OK.
d. Section 12.8.2, page 3, last sentence
"If a process is blocked waiting for event1 when another event is
assigned to event1, the wait will never unblock".
Could be re-worded as follows:
"If a process is blocked waiting for event1 when another event is
assigned to event1, the currently pending wait will never unblock".
What about:
If a process is blocked waiting for event1 when another event is
assigned to event1, the currently waiting process will never unblock".
Neil
> X-Unix-From: lawrence@cadence.com Thu Mar 13 05:51:47 2003
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Subject: [sv-ec] Comments on updated event proposal
> Date: Thu, 13 Mar 2003 08:51:19 -0500
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: Comments on updated event proposal
> Thread-Index: AcLpZ57nXeN5M9QESFCZK8K/vvhMcg==
> From: "Jay Lawrence" <lawrence@cadence.com>
> To: "sv-ec" <sv-ec@eda.org>
> X-Received: By mailgate.Cadence.COM as FAA03519 at Thu Mar 13 05:51:20 2003
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id
h2DDpMsD011430
>
>
> A few comments, we are making progress on this.
>
> --------------------------
> Return value of wait_order
> --------------------------
>
> I think we should treat wait_order the same way we treated $cast. It is
> either a function or a task depending on how it is called. If used as a
> task then it prints an error. If used as a function it returns a status.
> So rather than inventing a new use for => you could just say.
>
> success = wait_order(a, b, c);
> Or
> success <= wait_order(a, b, c);
>
> Using existing assignment operators.
>
>
> -------------------------------
> Clarify multiple triggers issue
> -------------------------------
>
> The paragraph beginning with "Events are not limited to occur only once
> ..." is unclear. Given:
>
> event a, b, c;
> wait_order(a, b, c);
>
> Which is legal
>
> a, a, a, b, b, c
>
> Or
>
> a, a, b, b, a, c
>
> Given our discussions I believe only the first sequence is legal, but
> this is unclear from the text.
>
> ----------------
> Disabling events
> ----------------
>
> I don't like introducing a case where @ does not block. @ always blocks.
>
> I would say that
>
> event E;
>
> E = null;
> @(E);
>
> Blocks forever because the event will never trigger. We could define.
>
> E = null;
> wait(E);
>
> To not block and continue (i.e. a null event always has E.triggered ==
> TRUE).
>
> This implies that if you are using persistent events you should use
> 'wait' and 'wait.triggered' to get what you want and we just don't
> change '@'.
>
>
>
> ===================================
> Jay Lawrence
> Architect - Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 14:07:28 PST