Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Michael McNamara (mac@verisity.com)
Date: Thu May 22 2003 - 21:12:20 PDT
Randy Misustin writes:
> Hi Mac,
>
> Michael McNamara wrote:
>
> >Don't get me wrong, I do feel that the fork..join_any is a useful
> >shorthand for:
> >
> > fork : f
> > begin
> > task_a;
> > disable f;
> > end
> >
> > begin
> > task_b;
> > disable f;
> > end
> >
> > ...
> >
> > begin
> > task_z;
> > disable f;
> > end
> > join
> >
> >to
> >
> > fork
> > task_a;
> > task_b;
> > ...
> > task_z;
> > join_any
> >
> >and think it is a good addition, even though it uses up a keyword.
> >
> 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;
> >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
This archive was generated by hypermail 2b28 : Thu May 22 2003 - 09:56:07 PDT