IEEE P1164 Working Group - Change Proposal

ID:	  CP-005

Proposer: Peter Ashenden <peter@ashenden.com.au>
	  (From requirements gathering)

Status:	  Proposed (1-Jun-2001)
	  Analyzed (17-Nov-2002)
	  Resolved (17-Feb-2003)

Summary:  Make vector result subtypes same as 1076 operators

Detail:

(From slides presented at VIUF-1999)

Range of return value of overloaded logical operators on
std_logic_vector differ from IEEE1076 definitions for one dimensional
vectors of bit and boolean as e. g. bit_vector

  function "and" ( l, r : std_logic_vector) return std_logic_vector is
    alias lv : std_logic_vector ( 1 to l'length ) is l;
    alias rv : std_logic_vector ( 1 to r'length ) is r; 
   variable result : std_logic_vector( 1 to l'length );
  begin
    if (l'length /= r'length) then
      -- ERROR
    else
      for i in 1 to l'length loop
        ...

Similarly are the other operators NAND, NOR, OR, NOT declared

Definition according to VHDL-LRM 7.2.1 would request, that the result
is an array with the same index range as the left operand.

  function "and" ( l, r : std_logic_vector) return std_logic_vector is
    variable result : std_logic_vector( l'range ); 
    alias rv : std_logic_vector( l'range ) is r;
  begin
    if (l'length /= r'length) then
      -- ERROR
    else
      for i in l'range loop
        ...

Pro and Cons

  - Compatibility with VHDL vs. Upward compatibility of the package
  - Some tools already implement IEEE 1164 functions in this way


Workshop summary

  - Needs study/ justification
  - Several no's in group because of implementation issues


Analysis:

	By Peter Ashenden <peter@ashenden.com.au>, 17-Nov-2002

	As a matter of good style, a model should avoid dependence on
	the index range of the result of an array operation.  It
	should use array attributes instead.  Models that use array
	attributes would not be affected by the proposed change.

	However, the fact that the change is requested suggests that
	users do, in fact, code models that depend on the result index
	range.  Such models would be broken by the proposed change.

	Thus, in the interests of backward compatibility with existing
	models, the proposed change is rejected.


Resolution:

  Analysis accepted

  Member votes: Accept 12 (92%)   Reject 1 (8%)    Abstain 0 (0%)
  All votes:    Accept 12 (86%)   Reject 2 (14%)   Abstain 1 (7%)

  From Steve Bailey

  refers to comments for CP-003, viz:

    In general, the analysis/recommendation is fine.  However, I prefer
    that the range of the result be consistent with 1076.  My reason
    being that if the design/designer typically uses N downto 0 ranges,
    then the result would be consistent with what is typical of the
    design/designer (assuming that the vector operand is typical).
    Also, I believe some tools already do it this way (even though it
    isn't standard).

    But, I think this is a relatively minor detail since the result is
    usually assigned to something else and then has the range of the
    target.  (Which means that failing to persuade the WG to change, I
    wouldn't vote No on the ballot because of this.)

  From David Bishop

  I find that l'range make much more sense here.