Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Thu May 22 2003 - 11:35:01 PDT
Michael McNamara wrote:
>Randy Misustin writes:
> > Actually, I believe the correct transformaion is:
> >
> > fork
> > task_a;
> > task_b;
> > ...
> > task_z;
> > join_any
> > disable fork;
> >
> > assuming no other forked process are active. I agree that this is
> > useful.
>
> As I drove home I realized that the single disable after the
> join_any would be necessary.... Where is that unsend button?
>
> However, you have to name the fork in order disable it, and you can
> not use a keyword for the name, so correctly the code would be
> something like:
>
> fork : the_fork
> task_a;
> task_b;
> ...
> task_z;
> join_any
> disable the_fork;
>
Interestingly enough, the disable command has been enhanced to accept
the keyword 'fork' in addition to a block identifier.
>> >However, in my opinion the join_none adds no value. I believe it is
> > >only there due to a misguided sense of completion; one has a join
> > >which waits for all; one has a join that waits for the first; why not
> > >add a join that waits for no one?
> > >
> > >I ask, why add such a thing?
> > >
> > >It uses up name space (breaking backwards compatibility), adds no
> > >modeling value (breaking requirement to add value), and is difficult
> > >to understand (provides surprise).
> > >
> > >-mac
> > >
> >
> > This is probably where someone more familiar with the original
> > proposal should jump in. Other than I share a disdain for newly
> > introduced keywords, I don't have a particular problem with this
> > feature. If you accept that it was useful to extend Verilog with
> > non-blocking assignments (delayed, event-controlled, and then
> > repeat-counted-with-event-control), then acknowledging the desire
> > for more programatic control over what activity happens in the
> > future from the current causal event isn't so much of a leap. I'm
> > sure someone can come up with a cool example of a behavioral
> > implementation of a pipeline using fork-join_none and some of the
> > mailbox and concurrency constructs.
> >
> > Cheers,
> >
> > -randy.
>
>
> I look forward to see the value demonstrated. Peter & Simon couldn't
> show me a value four years ago; although this really wasn't a major
> issue back then.
>
> If one wishes to start up a number of threads from a particular bit
> of behavioral code, the classic way to do this is:
>
> event start_your_engines;
>
> always @(t) begin
> // do stuff
> ->start_your_engines;
> // do other stuff
> end
>
> always @( start_your_engines ) task_a;
> always @( start_your_engines ) task_b;
>
> It is very clear what this does, and rather succinct; and synthesizable.
>
> If one wants control over the children, again
>
> always @(t) begin
> // do stuff
> ->start_your_engines;
> // do other stuff
> @ ( race_is_over) begin
> disable a;
> disable b;
> end
> end
>
> always @( start_your_engines ) begin : a
> task_a;
> end
>
> always @( start_your_engines ) begin : b
> task_b;
> end
>
>-mac
>
>
There are limitations to doing it as you suggest, beyond which transforming
event start_your_engines;
always @(t) begin
// do stuff
->start_your_engines;
// do other stuff
end
always @( start_your_engines ) task_a;
always @( start_your_engines ) task_b;
into:
always @(t) begin
// do stuff
fork
begin
task_a;
@(t) task_b;
end
join_none
// do other stuff
end
certainly offers better encapsulation. Beyond which, if we can get these
automatic variables to play out well, task_a and task_b can accept
parameters from the controlling loop.
-randy.
This archive was generated by hypermail 2b28 : Thu May 22 2003 - 11:40:24 PDT