ISAC: New IR 2109

This IR was just submitted. Let's discuss it at tonight's meeting.
The IR is also in the eda.org data base.

Chuck Swart



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------BEGINNING OF IR----------------

VHDL Issue Number:        2109

Language_Version          VHDL-2002
Classification            Language Modeling Enhancement or Deficiency
Summary                   Inter-process communication can hang unnecessarily
Relevant_LRM_Sections     
Related_Issues            
Key_Words_and_Phrases     protected type, process, wait
Authors_Name              Paul Butler
Authors_Phone_Number      (512) 683-8743
Authors_Fax_Number        
Authors_Email_Address     Paul.Butler@ni.com
Authors_Affiliation       National Instruments
Authors_Address1          11500 N. Mopac
Authors_Address2          Austin, TX 78759
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           1 February 2007
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:

Description of Problem
----------------------

    Two processes that each loop (without passing time or deltas)
    while waiting for progress in the other process might iterate
    forever if the simulator doesn't execute code in both processes.
    At least one popular simulator chooses one process and executes
    only the code in that process until it executes a statement that
    passes time (or a delta), causing the code below to never
    complete.
    
    If the LRM requires that simulator behavior, protected types seem
    unnecessary.  If the LRM required some form of preemption between
    simultaneous processes, VHDL users could rely on their
    inter-process communication to complete.  As it is, I can force a
    kind of cooperative preemption by passing time in both loops.
    Since protected type methods cannot pass time, I can't build that
    behavior into my semaphore type.
    
    Even if both processes execute, the looping wait looks
    inefficient. The ability to wait on something other than signals
    might help the situation.
    
    
    entity ThreadLock is
    end entity ThreadLock;
    
    architecture behave of ThreadLock is
    
      type Semaphore is
        protected
          impure function try_get return boolean;
          procedure put;
        end protected;
    
      type Semaphore is
        protected body
          variable available :
    boolean ::   true;
          
          impure function try_get return boolean is
            variable rval : boolean;
          begin
            rval := available;
            available := false;
            return rval;
          end function try_get;
    
          procedure put is
          begin
            available := true;
          end procedure put;
    
        end protected body;
    
      shared variable SemA, SemB : Semaphore;
    
    begin
    
      P1: process is
      begin
        assert SemA.try_get;
        wait for 0 ns;
        SemA.put;
        while not SemB.try_get loop
          report "P1 waiting for SemB";
          -- wait for 0 ns;
        end loop;
    
        report "P1 finished";
        wait;
      end process P1;
    
      P2: process is
      begin
        assert SemB.try_get;
        wait for 0 ns;
        SemB.put;
        while not SemA.try_get loop
          report "P2 waiting for SemA";
          -- wait for 0 ns;
        end loop;
    
        report "P2 finished";
        wait;
      end process P2;
    
    end behave;
    
    Execution works this way:

    P1 gets SemA and waits for 0 ns, P2 gets SemB and waits for 0 ns.
    In delta 1, execution resumes when both of the processes puts its
    semaphore and loops while waiting for the other process to put its
    semaphore.  If both processes execute in delta 1, both processes
    will finish.  If execution follows only one process until it
    passes time, neither process will finish.  Uncommenting the "wait
    for 0 ns" lines will allow the processes to finish.
    
    

Proposed Resolution
-------------------



VASG-ISAC Analysis & Rationale
------------------------------
TBD

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
TBD

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD


-------------END OF IR----------------