[vhdl-200x-ft] Updated FT19 for process types

The following document is update to the idea of making processes that cause
specific sythesis results to occur. Based feedback in a meeting in November,
instead of having specific process for latch, flip-flop, and combinational
processes we went with an attribute.  We also added the use of ALL in a
sensitivity list of a process to indicate all signals read by that process.

Regards,
    John


-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--


IEEE 200X Fast Track Change Proposal

ID:	  FT-19

Proposed by:     Jim Lewis Jim@SynthWorks.com
Analyzed by:     Jim Lewis Jim@SynthWorks.com

Status:       Done
Proposed:     Dec/03
Analyzed:     June/O4
Resolved:     Date

Enhancement Summary:     process_comb, process_latch, process_ff

Revisions:
  Rev3:  4/15/05         Reworked to use attributes and ALL
  Rev2:  9/16/04         Added restriction on calls to subprograms 
                         that access global signals
  Rev1:  Initial release

Related issues:          
Relevant LRM section:    

Enhancement Detail:
----------------------------
process_comb, process_latch, process_ff are intended to give
RTL coders the ability to replace the sensitivity list of the 
process with one that is generated appropriately for the process
type.   

In hardware design, sensitivity lists are often a source of 
simulation errors.  These forms of process remove the necessity
for the user to specify the sensitivity lists.  

The hardest part of this is getting a correct sensitivity list 
for process_ff:

  From 1076.6:
    The process sensitivity list includes the clock and any 
    signal controlling an <async_assignment>.
    <async_assignment> = An assignment to a signal or variable which 
    is not controlled by <clock_edge> in any execution path.

  Based on 1076.6, the sensitivity list should contain:
    any signal specifying a clock edge and 
    any signal that either controls or is on the right hand 
    side of an assignment that is made when all 
    clock edge conditions are false.  


Analysis:
----------------------------
Consensus was that making special processes types that matched
synthesis results put an extreme burden on other tools to insure
program correctness.  An alternative proposal of two part was put
forth to solve the problem where results don't match intent.  The
first part is to allow the keyword ALL to appear in the sensitivity
list of a process.  This is to reduce the miss matches when a signal
is incorrectly left off the sensitivity list for combinational processes.
The second part is to and three attributes COMB, LATCH, AND FlipFlop,
which can be used to indicate intent. Additionally, a simplified attribute
specification is created and allowed in the concurrent code sections.
This is to allow attribute to placed near the process.

For example

 L1'COMB IS TRUE;

 L1: PROCESS (ALL)
  BEGIN
   O <= A AND B;
  END PROCESS;

The process statement is changed to

process_statement ::=
  [process_label :]
    [postponed] process [ process_sensitivity_list] [is]
      process_declarative_part
    begin
      process_statement_part
    end [postponed] process [process_label];

process_sensitivity_list ::=
    ALL
  | ( ALL )
  | ( sensitivity_list )

The use of ALL in the sensitivity list of a process indicates that the
process is sensitive on any signal that is read within that process.
This includes signals read indirectly through subprograms.

For example:

ARCHITECTURE a OF e IS

SIGNAL s1, s2, s3: BIT;

PROCEDURE assign ( SIGNAL s : out BIT ) IS
BEGIN
  s <= s3;
END;

BEGIN

p1: PROCESS ALL  -- would include S3;
BEGIN
  assign(s1);
END PROCESS;

END;

What signals ALL refers to is computed as follows.

Declarations within the process are ignored.  For every statement of a
process, a subset of expressions in each statement are examine using
the rules in 8.1 to extract the signals that the process reads and are
added to the sensitivity list.  For assertions, report, next, exit,
and return statements all expressions are examined.  For
signal_assignement, variable_assignements, all expressions to the right
of the <= and := respectively are examined. For if_statements, the
condition expressions are examined. For case, the expression is
examined. Any expressions in the iteration scheme of the loop
statement are examined. Additional the enclosed sequential statements
of the loop, if, and case statements are also examined using these rules.
For procedure calls, the expressions for in and inout parameters are
examined.  For any subprogram found in examined expressions, their
statements are also examined using the above rules but only signals
which are not part of the parameter list are added.  These rules do
require to complete call chain of a process to be determined but it does
not require propagation of constants, loop unrolling, dead code removed,
or similar analysises.  As a result the sensitivity list will be close
to what sysnthesis uses but will not match in all cases.  For example
n

SIGNAL out, data : std_logic_vector( 15 downto 0);
signal mask : std_logic;

P1: PROCESS ALL
BEGIN
 FOR  i IN 0 to 14 LOOP
   out (i) <= mask AND data(i);
 END LOOP;
END PROCESS;

The sensitivity list of P1 is data, mask.  For a synthesis, the
sensitivity list is really data(14 downto 0) and mask.

Three new attributes will be declared in package standard.

ATTRIBUTE   comb : BOOLEAN;
ATTRIBUTE   latch: BOOLEAN;
ATTRIBUTE   flipflop : BOOLEAN;


When one of these attributes is TRUE on a label of a concurrent
statement, then the user intends a specific results of synthesis from
this process.  At most one of the three attributes is true for a given
concurrent label.  If the attribute COMB is true, then the output(s)
of this process do not contain any feedback, latch, or flip-flop after
synthesis.  If the attribute LATCH is true then the output(s) are
implemented with a hardware latch.  Similarly if the attribute
FLIPFLOP is TRUE then the output(s) are implemented with a hardware
flip-flop device.  There is no requirement for the compiler to check
that this is actually satisfied by the process.

The concept of a simple attribute specification is added to the language.
A simple attribute specification provide a easy way to attribute an object
near the place of the object's occurance or use.

attribute_specification ::=
    attribute   attribute_designator of entity_specifition is expreesion;
  | simple_attribute_specification

simple_attribute_specification ::=
    attribute_name  IS expession;

concurrent_statement ::=
    block_statement
  | process_statement
  | concurrent_procedure_call_statement
  | concurrent_assertion_statement;
  | component_instantiation_statement
  | generate_statement
  | simple_attribute_specification


Open questions:
Should simple_attribute_specification be allowed in sequential
statements?  Do signals that appear on the left of the <= and := but
are not the target also appear in the sensitivity lists?  For example
  data ( idx) <= value;
Should idx be in the sensitivity list, currently it would not be
included.  Is it legal for the compiler to check correctness of the
attributes, at least in simple cases.

For example

p1'comb IS TRUE;

p1: PROCESS ALL
BEGIN
 IF ( select ) THEN
   Q <= D;
 END IF;
END PROCESS;

It is legal for this to be flagged?

Should we exclude signals that are written by a process be excluded
from the sensitivity list?



Resolution:
----------------------------
[To be performed by the 200X Fast Track Working Group]