Subject: Re: [sv-ec] Re: Clarification for Section 15.8
From: Stefen Boyd (stefen@boyd.com)
Date: Mon Mar 17 2003 - 22:48:45 PST
At 11:45 AM 3/17/2003 -0800, Arturo Salz wrote:
>Stefen,
>
>BTW, the tool ensures the synchronization happens.
Arturo,
Thanks. Sounds like my example needs to be
noted to reflect this.
>A short example is fine. What you have below seems too long.
A short example would be fine once it's
clear what is going on. I have given the
smallest example I could write that covers
the cases of timing control in tasks that are
executed back to back and with statements
between. The only reason it is long is because
t1, t2, and t3 are identical copies (more or
less) but have been broken out so we can label
the statements as to when they would be scheduled.
>In general, there's a misconception regarding the region execution.
I don't think I have any misconceptions about
the regions of execution. I am probably imprecise
with my language.
>Once ANY region is to be executed then that region becomes the
>active region. The difference is not where things execute, but into
>which region different statements are scheduled to execute:
>
Agreed. My comments in the code were meant
to indicate where the statement would *first*
be scheduled.
> blocking assignments are scheduled into the Active region
> #0's are scheduled into the Inactive region
> NBA's are scheduled into the NBA region
> 0-skew clocking sampling are scheduled into the Observe region
> program-block statements are scheduled into the Reactive region
>
>Therefore, labeling different statements with region names is very
>misleading and confusing. We need to find a better way to describe
>these conditions. Perhaps this should go in the scheduling semantics
>section?
>
I don't really care where it goes, but if it
isn't clear where these statements get scheduled,
then we need to clarify the document somewhere.
The effect of running the program block in the
reactive region adds new behavior that has never
been documented before. It's clear where statements
in the program get scheduled, but it's not clear
what happens when we call blocking tasks.
You may not find it desirable to have this example
in the lrm, but at least for my benefit, can you
correct the labels to indicate which region they
are *first* scheduled. Of course, blocking assignments
always are evaluated in the active queue, but some
of these will be evaluated after we have made it
to the reactive region, whereas some of them will
get executed the first time through the active queue
(for that timestep).
Stefen
> Arturo
>----- Original Message -----
>From: <mailto:stefen@boyd.com>Stefen Boyd
>To: <mailto:Arturo.Salz@synopsys.COM>Arturo Salz
>Cc: <mailto:sv-ec@eda.org>sv-ec@eda.org
>Sent: Monday, March 17, 2003 4:26 AM
>Subject: Clarification for Section 15.8
>
>Arturo,
>
>Since I don't think I'm going to be able to write
>unambiguous sentences and those that exist in this
>section don't seem to completely clarify what happens
>when calling blocking tasks, I'll write up an example
>for this section. Everyone can make sure I haven't
>made any silly syntax errors, and you can make sure
>the comments correctly reflect the region of the
>event queue when these statements are evaluated.
>
>This should clarify the meaning of
> "requires explicit synchronization upon return from the task"
>which doesn't make it clear to me if it's the tool
>that ensures the synchronization happens, or the user.
>
>Thanks,
> Stefen
>
>===================================================
>This examples demonstrates which statements
>will be evaluated in the active region vs
>the reactive region when calling module tasks
>from the program:
>
>module top;
> reg clk = 0;
> always #10 clk = ~clk;
> prog p1(clk);
> mod m1(clk);
>
>endmodule
>
>module mod(input clk);
> reg a,b,c,d;
> task t1;
> begin
> a = 1'b1; // REactive
> @(posedge clk);
> b <= 1'b1; // active
> end
> endtask
> task t2;
> begin
> c = 1'b1; // active
> @(posedge clk);
> d <= 1'b1; // active
> end
> endtask
> task t3;
> begin
> c = 1'b1; // active
> @(posedge clk);
> d = 1'b1; // active
> end
> endtask
>endmodule
>
>program prog(input clk);
> reg w,x,y;
> initial begin
> @(posedge clk);
> w = 1'b1; // REactive
> m1.t1;
> m1.t2;
> x = 1'b1; // active
> m1.t3;
> @(posedge clk);
> y = 1'b1; // REactive
> end
>endprogram
This archive was generated by hypermail 2b28 : Mon Mar 17 2003 - 22:49:42 PST