ISAC: proposed agenda for ISAC meeting July 07 2005

Next Meeting: Thursday July 7 2005, 8 pm Pacific Daylight Time
              (Friday July 8 2005, 3 am GMT)

telecom info (same as always)
US 888.742.8686
Other 303.928.2600
Conference ID 3331797

1. Review Status of Web Based IR system.

2. Review Response document for difficult ISAC-Approved Issues.
I am attaching this document. It is the same document I sent
several weeks ago. So far, only one person has commented.
Please read this before the meeting if you can.

3. Open ISAC Issues
2068    ISAC-Approved       Peter           Entity instantiation with space 
                                            before the entity name
2068 is approved subject to review/response from Deepak and Ajay.

2043    Analyzed        Deepak          Numeric VALUE attribute 
                                        parameter can't have sign
2054    Submitted       Larry           Individ. assoc. rules for array 
                                        formal are not valid
2062    Analyzed        Ajay            Range staticness
2064    Analyzed        Larry           Type conversion of unconstrained 
                                        output in a port map
2065    Submitted       Chuck           OTHERS in aggregates too restrictive
Please review my attached analysis of some OTHERS issues.

2038    Submitted                       Minor semantic errors

4. Process for analyzing old IRs.







This is the response document to the ballots for the Difficult
ISAC-Approved Issue Reports.

The following IRs were submitted for ballot:

2004, 2013, 2032, 2042, 2045

All IRs were approved.

IRs Approved Without Comments:

2013, 2032

IRs which received comments:

2004 Definition of SLA doesn't make sense

In an informative affirmative ballot, a reviewer strongly supports the
decision that no change is necessary in the definition of SLA

CONCLUSION: IR2004 is VASG-approved.

2042 Architecture as a block causes problems

In an affirmative ballot, a reviewer asks if it is necessary add a new
annex or clause in the 2002 LRM to inform users of these issues.

RESPONSE: The ISAC will mention this possibility to the VASG. However,
the effort involved in making any official change to the 2002 LRM is
virtually the same as re-balloting the LRM. Also, the ISAC knows of no
implementation which has treated the architecture as a separate block,
so in practice, this should not be a problem.

In a negative ballot, a reviewer states two issues (quoted in full): 

"1. The analysis does not seem to take into consideration the use of path
names from the point of view of pre-elaboration tools.  The standard should
provide one set of rules for path interpretation that can be used within the
language and within VHDL tools.  Since the entity/architecture relationship
is one to many, it is necessary to be able to distinguish between
declarations of one architecture from another of the same entity.  Thus,
support for E.A1.C and E.A2.C (entity E, architectures A1 and A2, constant C
in each architecture) should also be a requirement for a proper solution."

RESPONSE: 

The names discussed in the analysis are expanded names (see LRM clause 6.3),
not path names.  Specifically, the names Work.E.C, E.C, and A.C can only be
used within the declarative region where C is declared.  This form of name
is distinct from path names (either pre- or post-elaboration), which address
an item from an external view, that is, from a root name space external to
the enclosing construct.

Formation of paths names is a separate issue from that addressed in IR2042.
Path names are addressed elsewhere, including:

- VHPI: A pre-elaboration path name for the constant C in the example would
  be Work.E:A.C

- Cross-Module Reference (XMR) proposal described in VHDL-200x-FT proposal
FT07

- PSL

There is an ongoing discussion to unify the form of path names among these
specifications, the 'path_name and 'instance_name specifications, and
expanded names.  See
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname.pdf and
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname_issue_roll
up.html.


"2. If E.C is allowed, it must be restricted to use only within the
architecture body, or there must be some rules introduced to require that
every architecture of E have compatible declarations of C."

RESPONSE:

Since C is declared within the architecture body, it cannot be referenced
within the entity declaration.  The scope and visibility rules (LRM clauses
10.2 and 10.3) specify that the scope of the declaration of C starts at the
declaration and extends to the end of the architecture body.  In this case,
C is only visible within its scope, which does not extend to the entity
declaration.  So the existing rules already address the commenter's
requirement.

CONCLUSION: IR2042 is VASG-approved.

2045 Add the ability to comment an entire block of code

In one affirmative ballot and one informative negative ballot, two
reviewers state that nested block comments should be allowed.

In an informative affirmative ballot, a reviewer supports the prohibition on
nested block comments.

RESPONSE: Some nesting of comments is allowed, since -- comments can
be present within a block comment. Since the affirmative vote was for a
construct in which nested block comments are not allowed, there is no
change to the existing issue solution. Notice however, that if it is
later determined that nested block comments should be allowed, this
capability can be added without affecting backward compatibility.

In a negative ballot, a reviewer supports the solution but states that the
ISAC should not be adding language constructs.

RESPONSE: The ISAC is technically not adding language constructs. The ISAC
has made a recommendation to the VASG, which can accept, reject, or modify
the recommendation. Also, historically, the ISAC has made proposals for
language changes, particularly in areas which require careful language
analysis. For this particular issue it was decided that the fastest way to
resolve it was to make a specific recommendation.

CONCLUSION: IR2045 is VASG-approved.




The paper addresses the semantic issues with expanding allowable cases for
OTHERS in array aggregates.

The current rules allow OTHERS in array aggregates if the "subtype" of
the array aggregate can be determinable from context. In general,
this means that the aggregate must be associated with a constrained
array subtype for the OTHERS to be legal. In most cases, this constrained
array subtype must also be locally static. A modest exception to the
locally static rule allows OTHERS for dynamic constraints if the aggregate
has only the OTHERS and no additional associations.

An additional rule states that if there is no OTHERS association, but
an OTHERS would be legal, the the direction, but not the bounds come
from context.

We examine the possibility of extending the use of OTHERS to more
cases.

1. There are some situations in which an OTHERS makes no sense.
In particular when an aggregate is used as a parameter to a subprogram
where the formal is unconstrained. In this case there is no reasonable
way to determine the size of the aggregate.

variable v1: bit_vector(1 to 3);
...
   if( v1 = (OTHERS => '1')) ...

2. Suppose we extended the rules to allow OTHERS for
unconstrained arrays as in the first example of CASE1 from the IR.

    procedure (b,c :
    out signed) 
    begin 
       b := (OTHERS => '0'); -- not legal because b is unconstrained 
       c :=('1',OTHERS => '0'); -- not legal because b is unconstrained 
    end; 

If we allow this we introduce a subtle incompatibility.

Consider a similar procedure:

  procedure proc1 (
    var1 : inout bit_vector) is
    begin
      var1 := (1=>'1',0=>'0');
--      var1 := (0=>'0',others => '1');
--      var1 := (1=>'1',others => '0');
    end;

Under current rules, only the first assignment is legal.
It creates an aggregate with bounds and direction 0 to 1.
If proc1 is called with a parameter whose bounds and direction
are 1 downto 0, then the net affect is a reversal of bits.
Note also, that it would be legal to call this with any
bit_vector of size 2.


label1 : process
  variable v1 : bit_vector(1 downto 0):= "10";
begin  -- process label1 
  proc1(v1);     --v1 is reversed
  b1 := (v1=('1','1'));
  wait;
end process label1 ;

If we allow the two OTHERS cases which are commented out in
proc1, then it seems reasonable that all three cases should
produce the same result, i.e. the bounds and direction should
be picked up from the formal.

3. Interplay with proposed FT changes?