Subject: [sv-ec] Ext-16 comments
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Nov 21 2003 - 10:13:17 PST
As defined I think this proposal would cause more confusion than help
due to the non-determinism of when waiters on this event would wakeup vs
the triggering task entry/exit.
Taking the example for the donation:
task send_receive(inout byte b);
bus <= b;
# 5
b = bus;
endtask
task check_sr();
@( begin send_receive ) $display( "sent some data" );
@( end send_receive ) $display( "received some data" );
endtask
I'll rewrite the check_sr task slightly (by adding %d to the $display)
as:
task check_sr();
@( begin send_receive ) $display( "sent some data = %d",
bus );
@( end send_receive ) $display( "received some data =
%d", bus );
endtask
When send_receive is executed the event (begin send_receive) is
triggered. The task send_recieve might continue executing or maybe the
task check_sr would immediately be executed. In this particular example
the $display in both cases would print the "old" value of bus because a
non-blocking assignment of bus <= b was used in the example. This is
probably not what the user would expect,he would expect the data being
sent.
If the send_recieve task was re-written with a blocking assign (bus =
b), then there would be non-deterministic results. To get determinism
the user would have to code something like:
task send_recieve(
task send_receive(inout byte b);
#0
bus = b;
# 5
b = bus;
endtask
This would be a real pain in every single task (and a performance hit in
simulation).
To get this kind of coverage a coding convention of triggering events in
the task and waiting in a deterministic fashion is probably preferred.
Although I have sympathy for the intent of this proposal, I'll be voting
NO because I believe the increased non-determinism will give users
unexpected results in both simulation results and coverage usages.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Fri Nov 21 2003 - 10:13:59 PST