ISAC: updates for Thursday's ISAC meeting

From: Chuck Swart <cswart_at_.....>
Date: Tue Apr 18 2006 - 16:48:56 PDT
IRs 2074 and 2086 have been updated.
LCS 113 supersedes IR 2054.
This LCS has deep consequences, so I would like
you to read it carefully. But if you don't have time
the area aroung page 6 deals most closely with IR 2054.

If you can't get access to LCS 2006-113, let me know and I'll
send you a copy (The isac mailing list won't accept it because
it places a Draconian limit on file sizes)

Also, in my notes for IR 2074 I have a statement:

"There was also confusion about wording regarding actuals. The 
visibility rules favoring select names are intended to
apply to local parameters used as actuals, not to all actuals."

Can anyone speak to the reason for this? I thought that clauses h) 
through m) were pretty clear about this.





VHDL Issue Number:      2074

Language_Version:       VHDL-2002
Classification:         Language Definition Problem
Summary:                Problem with direct/select visibility in formal part
Relevant_LRM_Sections:  4.3.2.2, 10.3
Related_Issues:         0006
Key_Words_and_Phrases:
Authors_Name:           Chuck Swart
Authors_Phone_Number:   503.685.0846
Authors_Fax_Number:     503.685.0921
Authors_Email_Address:  cswart@model.com
Authors_Affiliation:    Model Technology
Authors_Address1:       8005 SW Boeckman Road
Authors_Address2:       Wilsonville, OR 97070
Authors_Address3:

Current Status:         Analyzed

Superseded By:

------------------------
Date Submitted:         12 September 2005
Date Analyzed:          10 November 2005
Author of Analysis:     Chuck Swart and Ajayharsh Varikat
Revision Number:        3
Date Last Revised:      18 April 2006

Description of Problem
----------------------
Consider the following two VHDL code fragments:

A)

LIBRARY ieee;
USE ieee.std_logic_1164.ALL; -- X01 becomes visible as a subtype
ENTITY e1...
...
ARCHITECTURE a1 OF e1 IS
    COMPONENT c1 IS
       PORT(X01: IN std_logic);
BEGIN
    instance1: c1 PORT MAP ( X01(X01)=> s1);
END a1;

B)

PACKAGE p2 IS
        constant X01: integer := 1;
        subtype bv1 is bit_vector(1 TO 1);
END p2;

LIBRARY ieee;
USE work.p2.ALL; --X01 and bv1 become visible
ENTITY e2...
...
ARCHITECTURE a2 OF e2 IS
    COMPONENT c1 IS
       PORT(X01: IN bv1);
BEGIN
    instance1: c1 PORT MAP ( X01(X01)=> s2);
END a2;

Are either of these legal VHDL?

In example A) there are two possible interpretations:

1. The leftmost X01 is a type mark (with direct visibility) and the
X01 inside the parentheses is a formal designator. This expression is
legal.

2. The leftmost X01 is a port name (with visibility by selection)
indexed by a subtype, which in this case is illegal.

In example B) there are also two possible interpretations, with the
legal/illegal cases reversed from example A) with respect to direct
visibility and visibility by selection:

1. The leftmost X01 is a constant name (with direct visibility) and
the expression inside the parentheses is a port name. This construct
is clearly illegal.

2. The entire term is a formal designator, which reduces to an indexed
name.  The leftmost X01 is a port name (with visibility by selection)
and the X01 inside the parentheses is an index expression.

The grammar allows
    formal_part ::=
                formal_designator
               |<function>_name ( formal_designator)
               | type_mark ( formal_designator )

The name of the formal designator is visible by selection while the
name of the type_mark (and the index expression in example B) are
directly visible.

So the question reduces to what visibility rules are used to analyze:

   X01(X01)

which can be interpreted syntactically as either type_mark (
formal_designator) or simple formal_designator?

Given the visibility rules of 10.3, it is hard to tell if directly
visible names take priority over names visible by selection, or
vice-versa. If direct visibility has priority then interpretation 1
applies to both examples, making example A) legal and example B)
illegal.  If selected visibility has priority, then interpretation 2
applies, making example B) legal and example A) illegal.

If one were to argue that interpretation 1 applies to example A) and
interpretation 2 applies to example B) then the visibility rules would
be context dependent (or even more context dependent than current
rules).

The syntactic ambiguity in the formal_part rule is the major area (if
not the only area) in which the rules for direct visibility conflict
with those for visibility by selection.  The closest analogy is the
potential conflict between selected names and expanded names described
in IR0006. This conflict is resolved by adopting the expanded name
interpretation.

I believe that different simulators interpret the two test cases in
different ways, so this issue should be resolved to improve
portability of the language.

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

Adopt a rule stating that in formal parts selected names hide directly
visible names ( or vice-versa). This would make both examples illegal.
Other solutions are possible, but the important thing is to not make
the visibility rules context sensitive. In particular, interpretations
A 1 and B 2 should not both be legal.

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

The specific places at which such a conflict could occur are (from
clause 10.3 of the LRM)

"h) For a formal parameter declaration of a given subprogram
    declaration: at the place of the formal designator in a formal
    part (before the compound delimiter =>) of a named parameter
    association element of a corresponding subprogram call.

i) For a local generic declaration of a given component declaration:
   at the place of the formal designator in a formal part ( before the
   compound delimiter =>) of a named generic association element of a
   corresponding component instantiation statement: similarly, at the
   place of the actual designator in an actual part (after the
   compound delimiter =>, if any) of a generic association element of a
   corresponding binding indication.

j) For a local port declaration of a given component declaration: at
   the place of the formal designator in a formal part (before the
   compound delimiter =>) of a named port association element of a
   corresponding component instantiation statement; similarly, at the
   place of the actual designator in an actual part (after the
   compound delimiter =>, if any) of a port association element of a
   corresponding binding indication.

k) For a formal generic declaration of a given entity declaration: at
   the place of the formal designator in a formal part (before the
   compound delimiter =>) of a named generic association element of a
   corresponding binding indication; similarly at the place of the
   formal designator in a formal part (before the compound delimiter
   => of a generic association element of a corresponding component
   instantiation statement when the instantiated unit is a design
   entity or a configuration declaration.

l) For a formal port declaration of a given entity declaration: at the
   place of the formal designator in a formal part (before the
   compound delimiter =>) of a named port association element of a
   corresponding binding specification; similarly, at the place of the
   formal designator in a formal part (before the compound delimiter
   =>) of a port association element of a corresponding component
   instantiation statement when the instantiated unit is a design
   entity or a configuration declaration.

m) For a formal generic declaration or a formal port declaration of a
   given block statement: at the place of the formal designator in a
   formal part( before the compound delimiter =>) of a named
   association element of a corresponding generic or port map aspect."

The ISAC agrees that there should be a clear rule to determine
visibility when there is a potential conflict between direct
visibility and visibility by selection. It is preferable to choose
visibility by selection over direct visibility because a declaration
which is no longer directly visible can often be accessed by other
mechanisms.

In conclusion, the ISAC recommends that the syntactic ambiguity
indicated in the problem description be resolved in favor of
formal_designator, with a similar interpretation for actual_designator.

Note that the above LRM sections apply visibility by selection to
formal and actual designators, not to formal or actual parts.  If
visibility is to be used to distinguish the cases under discussion it
is beneficial to extend select visibility to the entire formal or
actual parts.

With this interpretation the leftmost X01 in example A) is interpreted
as a port name, so the example is illegal.

Example B) is also illegal: Both references to X01 refer to the port
name, so the example is semantically illegal.


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

Interpret the LRM as if the Recommendation for Future Revisions were
in effect.

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

In items h) through m) in clause 10.3 replace each occurrence of

"at the place of the formal designator in a formal part"

with

"at the place of the formal part"

and replace each occurrence of

"at the place of the actual designator in an actual part"

with

"at the place of the actual part".

Add wording similar to the following to clause 10.3 immediately
after the existing paragraph that begins with "A declaration is 
said to be hidden...":

"At a place in which a declaration is visible by selection every
declaration with the same designator which would otherwise be directly
visible is hidden."




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

VHDL Issue Number:        2086

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Incorrect description of type mark in disconnection specification
Relevant_LRM_Sections     5.3 Disconnection specification, page 85
Related_Issues            
Key_Words_and_Phrases     disconnection specification, type mark
Authors_Name              Peter Ashenden
Authors_Phone_Number      +61 414 709 106
Authors_Fax_Number        
Authors_Email_Address     peter@ashenden.com.au
Authors_Affiliation       Ashenden Designs
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Analyzed

Superseded By:

------------------------
Date Submitted:           8 February 2006
Date Analyzed:            13 March 2006
Author of Analysis:       Chuck Swart
Revision Number:          2
Date Last Revised:        18 April 2006

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

In the last paragraph of page 85, the first sentence reads:
    
      If the guarded signal is a declared signal or a slice thereof,
      the type mark must be the same as the type mark indicated in the
      guarded signal specification (see 4.3.1.2).
    
    Since the paragraph describes a guarded signal specification, it
appears that the first type mark referred to in the sentence is the
type mark in the guarded signal specification. Thus, the sentence
appears to state, tautologically, that the type mark must be the same
as itself.
    
    Subsequent sentences in the paragraph state that, for other forms
of signal name, the type mark must be the same as the type mark in a
declaration of the signal. Thus, it would appear that the first
sentence should say that the type mark be the same as the type mark in
the declaration of the signal, not the same as itself.
    
    A further problem is that the paragraph only deals with a declared
signal, a slice of a declared signal, an element of a declared array
signal, and an element of a declared record signal. It does not deal
with other members of a composite signal.

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

Amend the tautological description to refer to the type mark of the
subtype indication in the signal declaration.
    
    Revise the case analysis to cover the cases:
    
    - A declared signal or a slice of a declared signal: the type mark
    must be the same as that in the signal's declaration;
    
    - A slice of an array subelement of a composite signal: the type
      mark must denote the same subtype as the array element's
      subtype;
    
    - An element of an array subelement of a composite signal: the
      type mark must denote the same subtype as the element subtype
      indication in the declaration of the array type;
    
    - An element of a record subelement of a composite signal: the
      type mark must denote the same subtype as the element subtype
      indication in the declaration of the record type.

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

The submitter is essentially correct. However, the LRM seems to impose
a more stringent requirement involving type mark matching instead of
subtype matching. So the wording in the proposed solution should be
changed as indicated below.  In addition, for consistency, on page 86,
the first sentence should also be changed in a similar manner
(indicated below).

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

Interpret the LRM as if the Recommendation for Future Revisions were
in effect.

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

Clause 5.3 Disconnection specification

The paragraph beginning: 

   "If the guarded signal is a declared signal or a slice thereof..."

Should read:

    "If the guarded signal specification denotes a declared signal or
    a slice thereof then the type mark in the specification must be
    the same as the type mark in the subtype indication of the guarded
    signal declaration (see 4.3.1.2).

    If the guarded signal specification denotes an index value of a
    declared signal then the type mark in the specification must be
    the same as the type mark of the element subtype indication in the
    declaration of the array type of the guarded signal declaration.

    If the guarded signal specification denotes a slice of an array
    subelement of a composite signal then the type mark must be the
    same as the type mark in the subtype indication of the array
    subelement declaration.

    If the guarded signal specification denotes an element of an array
    subelement of a composite signal then the type mark must be the
    same as the type mark of the element subtype indication in the
    declaration of the array type.

    If the guarded signal specification denotes a record element of a
    composite signal then the type mark must be the same as the type
    mark of the element subtype indication in the declaration of the
    record type.

    Each signal must be declared in the declarative part enclosing the
    disconnection specification."

The paragraph beginning:

    "Subject to the aforementioned rules, a disconnection
    specification applies to the drivers of a guarded signal S of
    whose type mark denotes the type T..."

Should read:

    "Subject to the aforementioned rules, a disconnection
    specification applies to the drivers of a guarded signal S
    specified with type mark T..."




-------------END OF IR----------------
Received on Tue Apr 18 16:49:04 2006

This archive was generated by hypermail 2.1.8 : Tue Apr 18 2006 - 16:49:06 PDT