Subject: Re: [sv-ec] Ext-16 comments
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Nov 24 2003 - 01:21:54 PST
Jay,
I fail to see why you seem to believe that this proposal somehow creates more
non-determinism in the language and hence more confusion.
To show you that, I'll rewrite the example using standard Verilog:
event ev_begin, ev_end;
task check_sr();
@ev_begin $display( "sent some data = %d", bus );
@ev_end $display( "received some data = %d", bus );
endtask
task send_receive(inout byte b);
-> ev_begin;
bus <= b;
# 5
b = bus;
-> ev_end;
endtask
The above example exhibits all the same non-deterministic properties as
your examples. In fact, I one can even write a synthesizable version:
bit call = 1'b0;
task check_sr();
@(posedge call) $display( "sent some data = %d", bus );
@(negegde call) $display( "received some data = %d", bus );
endtask
task send_receive(inout byte b);
call = 1'b1;
bus <= b;
# 5
b = bus;
call = 1'b0;
endtask
The bottom line is that this type of non-determinism is an inherent part of
the language. I also believe (and I'm certain you agree) that we should not
attempt to define the scheduling order of such constructs. That ordering
should not be part of the language, and users should never rely on such
ordering for their designs. This type of non-determinism is the natural effect
of Verilog's event-driven mechanism for modeling concurrency.
If we do not add this mechanism to the language, users that need this type
of functionality will have to do something much more painful that add a #0
at the start of a task: manually instrument every task or function call with the
equivalent of the code above. Perhaps even on top of the #0 statements that
you say would be a real pain. The proposal moves all this instrumentation
complexity into the compiler.
Conversely, modifying the semantics of the event control when used to define
a coverage group gives users the best of both worlds. It allows the hardware
modeling aspects of the language to execute in parallel (in an unspecified order),
and it allows the coverage gathering machinery to function deterministically.
Arturo
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: "sv-ec@server.eda.org" <sv-ec@eda.org>
Sent: Friday, November 21, 2003 10:13 AM
Subject: [sv-ec] Ext-16 comments
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 : Mon Nov 24 2003 - 01:23:08 PST