DynamicProcessInstance < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>DynamicProcessInstance (2020-02-17, JimLewis) (raw view)EditAttach
---+ Dynamic Process, Instances, Fork and Join

%TOC%

---++ Proposal Information
   * Current Owner: ...
   * Contributors: ...
   * Date Proposed: 2014-June-22
   * Date Last Updated: 2014-June-22
   * Priority:
   * Complexity:
   * Focus:
   * Related Issues: None
   * Competing Issues: None
---++ Requirement Summary

Dynamic Processes, Instances, Fork and Join

This is a place holder for a justification for the requirement and links to proposals.
---++ Application / Use Cases

TBD

---++ Dynamic Processes
   * 

---++ Dynamic Instances
   * configurable direct-entity instantiations.
   * synthesisable generics, store generic parameters ("settings") in a memory block. 
      * Need to define a maximum range for each generic to be synthesisable and finite.
      * Treat generics like ports, where a block changes behaviour when the value of the generic changes. Currently, one way of doing this is to convert generics to ports.
---++ Fork and Join
   * Prior work done in [[http://www.eda.org/vhdl-200x/vhdl-200x-tbv/vhdl-200x-tbv.pdf][TB3 in VHDL-200X TBV - Testbench and Verification Proposals]]
   * Original Verilog, simple fork and join - not used much. Hence, not much value in implementing a simple mechanism
   * SV - more complicated and have ability to kill later

From TBV3:
<verbatim>
[Fj_label:] Fork
   [ [label1 :] block  -- see also [[SequentialDeclare]]
     [ <declarations> ] ]
   begin
      { sequential statements }
   end [block] [label1] ;
   { [ [label2 :] block  -- see also [[SequentialDeclare]]
     [ <declarations> ] ]
   begin
      { sequential statements }
   end [block] [label2] ; }

join [all | none | first | [ condition_clause] [timeout_clause] ] [label_name];
</verbatim>

A forkjoin_stmt can contain 0 or more sequential blocks. A label is optional. A forkjoin_stmt causes all enclosing sequential blocks to be executed in parallel. The &ldquo;kind&rdquo; of join &ndash; &ldquo;all/none/first/condition_clause/timeout_clause&rdquo; - determines how execution continues subsequent to a forkjoin_stmt. The kind value of &ldquo;all&rdquo; indicates that all sequential blocks must complete execution before exiting the forkjoin_stmt. The value &ldquo;none&rdquo; indicates that execution continues immediately and that you do not wait for any sequential blocks to complete. The value &ldquo;first&rdquo; indicates that forkjoin_stmt can exit as soon as one sequential block completes execution. The default kind is &ldquo;all&rdquo;. The condition clause specifies the condition that must be true before execution continues following the join (the &lsquo;DONE attribute may be used in the condition clause). The timeout_clause specifies the amount of time to wait before execution continues beyond the join.

A forkjoin_stmt is not allowed in a function body.

statements. The label, keyword SBLOCK DECLARE and the declarations are optional. At a minimum, you need only the begin and end keywords. A sequential block may appear outside of a forkjoin as a independent sequential statement. A &lsquo;DONE attribute is defined for every sequential block and is applicable to a label of the sequential block. The attribute has the value false while the sequential block is being executed.

The outstanding sequential blocks do not terminate when the join clause is activated. Otherwise the value of "none" would be meaningless. (JR) Calling fork/join with none from within a subprogram has some tricky side effects. I would assume that standard vhdl visibility exists so what happens if you have code like
<verbatim>
process
  PROCEDURE P (...
    VARIABLE x : integer;
    PROCEDURE Q ....
    BEGIN
      FORK
        L1: BEGIN
          x := x +1;
         WAIT FOR 10 ns;
         x : = x +1;
         WAIT FOR 10 ns;
       END;
      BEGIN
        ...
      END;
      JOIN NONE;
    END;
  BEGIN
    Q(..);
  END;
BEGIN
  P;
  WAIT FOR 5 ns;
END PROCESS;
</verbatim>

The fact that Q and P exit before the sequential block L1 terminates implies that the stack for P and Q must remain around. I can see a number of implementation issues associated with that.

Recommend that forked blocks terminate when a procedure exits. Accessing global variables could cause problems such as which fork got executed first. Some options are not to allow global variables to be assigned within forked process (communication occurs only via signals), or allow global variables but make them as "shared" variables if more than one forked process intends to update its value (the later is recommended).

Variables cannot be waited upon in a condition clause.
---++ Comments

-- Main.ErnstChristen - 2015-01-27 - Fork/join: Semantically this seems to be supported by concurrent procedure calls.
---+++ Arguments Against

---++ Supporters
Topic revision: r3 - 2020-02-17 - 15:34:52 - JimLewis
P1076/Ballots