Subject: RE: [sv-ec] Issues with Sections 7,8 & 10
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Jan 10 2003 - 17:06:58 PST
> From david.smith@synopsys.com Fri Jan 10 16:03:10 2003
>
> Hi Kevin,
> A couple of procedural points.
>
> 1. Section 7.6 has not been modified from 3.0. If there is an issue with it
> I would appreciate it if you would bring it to the attention of the SV-BC.
>
> 2. Section 9.7 has been removed in the draft (as a suggestion). Likewise
> section 8.7 should also have been removed. This was actually based on this
> discussion on REV-15. If there are no objections then both sections are
> gone.
>
> This leaves your comments on Section 7.3 and 10.5.2 for discussion by the
> committee.
>
> Regards
> David
Maybe should've cc'd the BC :-)
Since chapter 9 is up next anyway, here are some of my thoughts on process/fork-join:
"any" & "none" are unnecessary if you just have an optional expression for the number
of process to join (0 == none, 1 == any, no expression == all). Additionally, if the
expression is negative the excess process are killed, e.g.:
fork p1();
p2();
p3();
join -1;
If p1() completes first, p2() and p3() are killed.
Since fork cannot return an identifier for the processes it creates, fork/join with
an expression on the join should be limited to static scopes so that the name of
the fork can be used for process control. The exception being that the expression can
be constant negative value, since that doesn't leave dangling processes.
The process statement should return a process identifier which can be stored globally
or returned from dynamic scopes (like function calls) for process control.
Process control tasks should be methods on the process group name (fork) or id, e.g:
grp1: fork
p1();
p2();
p3();
join 0;
process my_proc = p4(); // process <id> = <statement>
fork // wait for all
grp1.join();
my_proc.join();
join
I suggest using "join" as the method rather than "wait" so that it mirrors the "join"
in fork/join - it would take the same optional argument of the number of processes to
wait for. You could then do:
grp2: fork
p1();
p2();
p3();
join 0;
do
grp2.join(1); // wait for one process
$display("one down %d to go\n",grp2.processes());
while (grp2.processes()); // .processes gives the number in the group
always @(reset) grp2.terminate();
The methods could be applied to any named block to control processes that are children
of that block. Similarly process ids are valid until all children of the process as well
as the process itself are dead.
Other methods would be "suspend" and "restart".
Regards,
Kev.
This archive was generated by hypermail 2b28 : Fri Jan 10 2003 - 17:08:02 PST