Fork-join clarification

[mrfirmware]

I'm using fork-joins in my testbench and I just want to be sure that
the more succinct version is functionally identical to the long
version (shown below).

// Succinct
fork
run_test(instance_1);
run_test(instance_2);
join

// Long
fork
begin
run_test(instance_1);
end

begin
run_test(instance_2);
end
join

I'm using SystemVerilog but I don't think this would be different in
Verilog.

Thanks,

- Mark

 

[Jonathan Bromley]

On Wed, 3 Sep 2008 07:17:41 -0700 (PDT), mrfirmware
<mrfirmware@gmail.com> wrote:

I'm using fork-joins in my testbench and I just want to be sure that
the more succinct version is functionally identical to the long
version (shown below).

// Succinct
fork
run_test(instance_1);
run_test(instance_2);
join

// Long
fork
begin
run_test(instance_1);
end

begin
run_test(instance_2);
end
join

I'm using SystemVerilog but I don't think this would be different in
Verilog.

You're fine. It's the same. A fork...join block wraps a bunch of
procedural statements (such as your run_test() calls) which are
executed in parallel; a begin...end wraps a bunch of procedural
statements which are then executed sequentially. A complete
fork...join, or a complete begin...end, has precisely the same
(syntactic) status as a single procedural statement and can be
used as one of the statements in another fork...join or
begin...end.

SystemVerilog changes the rules in two ways,
neither of which affects your issue:

1) Subprogram bodies:
In standard Verilog the body of a task or function
must be a single procedural statement. Of course,
almost any practical task or function needs multiple
statements, and therefore needs a begin...end to
enclose them. You could instead have a fork...join
as the body of your subprogram, but that's unusual.
In SystemVerilog, the usual begin...end is optional
so that you can now have multiple sequential statements
as the body of your subprogram.

2) Dynamic processes:
fork...join_none and fork...join_any. These have the
same "bracketing" effect as fork...join, but launch
their sub-threads in a rather different way.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[mrfirmware]

On Sep 3, 10:49 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Wed, 3 Sep 2008 07:17:41 -0700 (PDT), mrfirmware



mrfirmw...@gmail.com> wrote:
I'm using fork-joins in my testbench and I just want to be sure that
the more succinct version is functionally identical to the long
version (shown below).

// Succinct
fork
   run_test(instance_1);
   run_test(instance_2);
join

// Long
fork
   begin
       run_test(instance_1);
   end

   begin
       run_test(instance_2);
   end
join

I'm using SystemVerilog but I don't think this would be different in
Verilog.

You're fine.  It's the same.  A fork...join block wraps a bunch of
procedural statements (such as your run_test() calls) which are
executed in parallel; a begin...end wraps a bunch of procedural
statements which are then executed sequentially.  A complete
fork...join, or a complete begin...end, has precisely the same
(syntactic) status as a single procedural statement and can be
used as one of the statements in another fork...join or
begin...end.

Thanks. That's the confirmation I was hoping for.

Regards,

- Mark