[sv-bc] New guidelines for functions

From: Rich, Dave <Dave_Rich_at_.....>
Date: Sun Oct 08 2006 - 23:54:54 PDT
I had an action item to draft some guidelines for function rules in
light of new SystemVerilog constructs. In addition to listing specific
constructs allowed or disallowed, we should list fundamental guarantees
about functions so it will be easier to integrate other constructs as
they are introduced. 

 

We first need to consider the fact that functions should be allowed to
execute any statement that does not have the potential to block or
suspend the current process. That means allowing not just
fork/join_none, but NBAs and event triggers as well.

 

Next, we need clarifications about using the three different flavors of
fork statements in a function. Although none of these flavors block, all
of these require some blocking statement to be useful. Fork/join and
fork.join_any both split the current process into parallel threads, but
they will have no use unless they are allowed to block. The LRM should
note this and perhaps make them illegal inside a function like they were
in 1364-2001.

 

A fork/join_none requires a blocking statement in the parent process
before any spawned dynamic process can run. This means dynamic process
are scheduled as inactive (or re-inactive inside a program block)
events.  But there are many places where functions are called where
there is no parent thread, or before any events are scheduled.
Therefore, a fork/join_none may only be executed from a process started
by an initial or always block. Consequently, calling a function with an
embedded fork/join_none statement would be illegal if the function is
called from a static variable declaration initialization, constant
expression, continuous assignment, or a concurrent assertion.

 

And finally, unless we want to require some major control flow graph
analysis, the check for an illegal fork/join_none could be as late as
runtime. This is not as user unfriendly as it seems because most error
would be caught at or before time 0.

 

I originally entered mantis 1336 and Arturo later entered 1615. We
should combine the two.

 

Dave

 

 

 

 

David Rich
Verification Technologist
Design Verification & Test Division
Mentor Graphics Corporation
dave_rich@mentor.com
Office:   408 487-7206
Cell:     510 589-2625

 
Received on Sun Oct 8 23:55:06 2006

This archive was generated by hypermail 2.1.8 : Sun Oct 08 2006 - 23:55:31 PDT