RE: [sv-ec] fork...join_none in functions, and final blocks

Jonathan,

 

The discussion on whether fork...join_none is legal has been settled;
that is Mantis item 1615.

 

With regards to final blocks, I don't believe allowing fork..join_none
in functions adds anything new.

Functions have always been able to trigger additional activity - that
is, modify signals to which other processes are sensitive and perhaps
fork new processes.

Evidently, processes triggered (or indirectly spawned) from within a
final block are not executed, and the same will be true of processes
spawned from within a final block by executing a fork...join_none. For
example, consider the following:

 

always @foo $display("foo");

 

final begin

   foo = ~foo;

   $display("done");

end

 

It is clear that the message "foo" will not be displayed, which is not
fundamentally different from using a fork...join_none, as in: 

 

final begin

   fork $display("foo"); join_none

   $display("done");

end

Or, calling a function that contains the fork...join_none.

 

            Arturo

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Friday, November 24, 2006 2:20 PM
To: sv-ec@eda-stds.org
Subject: [sv-ec] fork...join_none in functions, and final blocks

 

Apologies if this has been discussed already.

 

I know that there is ongoing discussion about 

whether fork...join_none should be legal in

a function, since it clearly doesn't block

but it does impact the scheduler by creating

one or more new process.  If such process 

spawning in a function gets to be legitimized,

it creates a difficulty with the definition

of "final" blocks which at present are defined

to contain code that executes in zero time

and could appear in a function.  It is obviously

inappropriate for "final" to spawn a thread that

might try to consume time.

 

This is clearly a soluble problem - it's only

a matter of definition - but I wondered if

it had been considered...

-- 

Jonathan Bromley, Consultant

 

DOULOS - Developing Design Know-how

VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

 

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK

Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com

Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

 

The contents of this message may contain personal views which 

are not the views of Doulos Ltd., unless specifically stated.