RE: [sv-ec] Program Block / Reactive Region Use Cases & Requirements

>From: Ryan.S.Warner@seagate.com

>With the discussion of the region a task runs in being ruled by where the
>thread was started, let me propose an alternative to the possibility for
>the program block.  It should just define a reactive process.

>This always
>seemed the most natural representation of a program to me anyway.  It is a
>thread (or set of threads), not a physical piece of hierarchy.

Yes, this makes sense.  When there was a distinction between program
variables and design variables, there was some reason for having a
program block that was broad enough to include variable declarations
also.  (This is also presumably an artifact of the feature being
grafted on from another language, which had to be in a separate unit,
rather than being developed as a natural extension within Verilog.)

If the distinction is just a different kind of process, then it does
make more sense to distinguish just the process.  The requirement to
instantiate a program as a sub-instance seems awkward.  Making a
program block like an initial block instead of like a module makes
sense.

Another alternative would be to use an ordinary initial block, with
a procedural construct that can delay execution to the reactive region.
I have already suggested that the rules for scheduling should be based
on which region the scheduling process is running in, not what kind of
process it is.  So once the initial block delayed to the reactive region,
further delays would continue to wake up in the reactive region.  This
would allow finer control, such as the ability to fork off two processes
from the same parent, one of which runs in the active region, and the
other of which delays to run in the reactive region.

Steven Sharp
sharp@cadence.com