-------------BEGINNING OF IR----------------
VHDL Issue Number: 2082
Language_Version VHDL-2002
Classification Language Definition Problem
Summary Elaboration of unconstrained interface objects
Relevant_LRM_Sections 4.3.2.2 Association lists
12.2 Elaboration of a block header
12.5 Dynamic elaboration
Related_Issues Accellera VHDL-TC VTC-7, LCS-2006-118, IR 2085
Key_Words_and_Phrases elaboration, formal interface objects, association elements
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: 27 January 2006
Date Analyzed: 19 April 2006
Author of Analysis: Chuck Swart
Revision Number: 1
Date Last Revised: 20 April 2006
Description of Problem
----------------------
The order of elaboration of interface objects and the corresponding
associations is problematic when the type of an interface object is
unconstrained. For such interface objects, the index ranges are taken
from the association elements.
12.2 and 12.5 specify that elaboration proceeds by first
elaborating the formal objects (generics, ports or parameters),
followed by elaboration of the association lists. Elaborating
the formal objects involves elaborating the subtype indications
and creating the objects. However, for objects of unconstrained
types, the objects cannot be created until the index ranges are
known, and that isn't until the corresponding association
elements are elaborated.
Proposed Resolution
-------------------
Elaboration needs to be defined in such a way that association
elements are elaborated before formal objects are created. A possible
sequence may be
(1) elaborate the subtype indications of the formals
(2) elaborate the association elements (including any implicit
association elements)
(3) determine index ranges for formals from association elements,
if required
(4) create formals
VASG-ISAC Analysis & Rationale
------------------------------
The submitter is correct. There are defects in the elaboration rules
for unconstrained interface objects.
LCS-2006-118 deals with this issue for generics. The proposed Recommendation
for Future Revisions contains wording to correct the problem for ports and
for subprogram parameters.
Some comments on the proposed changes:
In the existing LRM it is not clear whether or not clause 12.3.1.4,
Object declarations, applies to interface objects which are not
generics or ports. We have clarified this by explicitly stating that
they are not covered by this clause and by adding appropriate wording
to clause 12.5.
It is also unclear in the current LRM whether or not parameters of
mode OUT are initialized. Clause 12.5 has been modified to specify
this initialization.
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
---------------------------------------------
LCS-2006-118 changes clauses 12.2, 12.2.1, and 12.2.2 (among others).
These changes correct the problem for generics. The following similar
changes apply to ports and subprogram parameters:
12.2.3
Change:
The elaboration of a port declaration consists of elaborating
the subtype indication and then creating a port of that
subtype.
To:
The elaboration of a port declaration establishes that the
port can subsequently be referenced.
Change:
Elaboration of a port association list consists of the
elaboration of each port association element in the
association list whose actual is not the reserved word
open.Elaboration of a port association element consists of the
elaboration of the formal part; the port or subelement or
slice thereof designated by the formal part is then associated
with the signal or expression designated by the actual
part. This association involves a check that the r4restrictions
on port associations (see 1.1.1.2) are met. It is an error if
this check fails.
To:
Elaboration of a port association list consists of the
elaboration of the port association element or elements in the
association list associated with each port
declaration. Elaboration of the port association elements
associated with a port declaration proceeds as follows:
a) The subtype indication of the corresponding port
declaration is elaborated.
b) The formal part or parts of the port association elements
corresponding to the port declaration are elaborated.
c) If the type of the port is an array type or contains a
subelement that is of an array type, the rules of 3.2.1.1 are
applied to determine the index ranges.
d) If the actual is not the reserved word open, the port (or
each subelement or slice thereof) designated by the formal part
or parts is then associated with the signals or expressions
designated by the actual part. This association involves a
check that the restriction on port associations (see 1.1.1.2)
are met. It is an error if this check fails.
12.3.1.4 Object declarations
Add as a first paragraph:
The rules of this clause apply to explicitly declared object
declarations. Generic declarations, port declarations and
other interface declarations are elaborated as outlined in
12.2.1 through 12.2.4 and 12.5.
Remove note 1 which starts
"These rules apply to all object declarations other than ..."
12.5
Change:
b) Execution of a subprogram call involves the elaboration of
the parameter interface list of the corresponding subprogram
declaration; this involves the elaboration of each interface
declaration to create the corresponding formal
parameters. Actual parameters are then associated with formal
parameters...
To:
b) Execution of a subprogram call involves the elaboration of
the parameter association list. This involves the elaboration
of the parameter association element or elements in the
association list associated with each interface
declaration. Elaboration of the parameter association elements
associated with an interface declaration proceeds as follows:
i) The subtype indication of the corresponding interface
declaration is elaborated.
ii) The formal part or parts of the parameter association
elements corresponding to the interface declaration are
elaborated.
iii) If the type of the interface object is an array type or
contains a subelement that is of an array type, the rules of
3.2.1.1 are applied to determine the index ranges.
iv) The interface object designated by the formal part or
parts is then associated with the actual parts.
v) If the interface object is a variable of mode OUT then the
implicit initial value for the object is determined.
-------------END OF IR----------------
-------------BEGINNING OF IR----------------
VHDL Issue Number: 2085
Language_Version VHDL-2002
Classification Language Modeling Enhancement or Deficiency
Summary What happens when a parameter of mode out is not assigned in a procedure?
Relevant_LRM_Sections 2.1.1.1
Related_Issues
Key_Words_and_Phrases procedures, out
Authors_Name Larry Soule
Authors_Phone_Number 650-584-1919
Authors_Fax_Number
Authors_Email_Address larrys@synopsys.com
Authors_Affiliation Synopsys
Authors_Address1
Authors_Address2
Authors_Address3
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 8 February 2006
Date Analyzed: 09 March 2006
Author of Analysis: Chuck Swart
Revision Number: 2
Date Last Revised: 20 April 2006
Description of Problem
----------------------
Here is an example of a procedure with an out-mode
parameter that is conditionally assigned.
architecture a of e is
subtype t is bit_vector(1 to 4);
constant c : t := (others => '1');
procedure p(i : in integer; o : out t) is
begin
if i > 0 then
o := c;
end if;
end procedure;
Section 2.1.1.1 says that only for in and inout parameters is the
value copied in (when using pass by copy). When exiting the
procedure, inout and out parameters are copied back in. If the
out mode formal is not assigned in the procedure, this has the
effect of writing t'left back into the actual which seem
counter-intuitive.
At least 2 VHDL implementations known to me handle this
differently.
Proposed Resolution
-------------------
Specify that only parameters of mode out that have been assigned
inside the procedure get copied out.
VASG-ISAC Analysis & Rationale
------------------------------
One way to view this problem is to ask the question: Do OUT mode
parameters get initialized (presumably to the appropriate 'left
value)? Because of the copy-in semantics for objects of mode in or
mode inout, this question is moot for other modes. Also, The rules for
signal parameters make this question meaningless for signals. That
leaves the question for out mode variables.
The LRM is not completely clear on this issue. Section 12.5 states:
"Execution of a subprogram call involves the elaboration of the
parameter interface list of the corresponding subprogram declaration;
this involves the elaboration of each interface declaration to create
the corresponding formal parameters."
Elaboration of interface declarations is not defined explicitly.
However, section 12.3.1.4 Deals with Object declarations:
"Elaboration of an object declaration that declares an object other
than a file object or an object of a protected type proceeds as
follows:
...
b) If the object declaration includes an explicit initialization
expression, the the initial value of the object is obtained by
evaluating the expression....Otherwise, any implicit initial value for
the object is determined.
c) the object is created.
d) Any initial value is assigned to the object."
Its not clear whether or not this clause refers to interface
declarations.
Clause 4.3.1 Object declarations, states:
object_declaration ::=
constant_declaration
|signal_declaration
|variable_declaration
|file_declaration
These are syntactic constructs which are not interface declarations.
This seems to imply that object declarations are not intended to
include interface declarations.
Also, in the above clause, the meaning of section b) is unclear. Out
mode parameters must not contain an explicit initialization expression
(such expressions are interpreted as the value for the parameter if
left unassociated.) So its not clear whether or not an implicit
initial value for the object applies.
There are (at least) two possible solutions to the problem.
1. Extend copy-in semantics to include out mode parameters. This has
the advantage that values which are not updated within the subprogram
are unchanged. This solution also works well with pass by reference
implementations. (There might be a problem with access types?)
2. Change clause 12.3.1.4 to specifically refer to interface
declarations (or add a new clause). This solution seems to meet the
VHDL principle that all variables are initialized, and the
initialization of interface declaration would be virtually the same as
that for local variables in the subprogram. There is a potential
performance problem, in that arrays which are passed by reference
would have to be initialized each time a subprogram was called.
Its not clear whether either of these solutions would affect backward
compatibility. It does seem that different implementations have
treated this problem in different ways, so some sort of backward
incompatibility may be inevitable.
The opinion of the ISAC is that OUT mode parameters should be
initialized to the default value. If the initialization is not
wanted, then the mode should be INOUT, which will imply copy-in
copy-out semantics.
IR 2082 involves extensive rewording of clause 12.5. This
rewording includes initialization of OUT mode parameters.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change. It is not clear whether or not OUT mode parameters are to
be initialized in the current standard.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Adopt the proposed wording used in IR 2082.
-------------END OF IR----------------
-------------BEGINNING OF IR----------------
VHDL Issue Number: 2091
Language_Version VHDL-2002
Classification Language Definition Problem
Summary Translation between std_logic_vector based types and std_ulogic_vector
Relevant_LRM_Sections In std_logic_1164 there is a function called:
to_stdlogicvector (std_ulogic_vector) which
is used to convert from the base type
"std_ulogic" to the base type "std_logic"
because the base type for these types are
the same, some simulators say they the are
interchangeable. Others do not.
Related_Issues There were some other issues recently on closely
related subtypes.
Key_Words_and_Phrases to_stdlogicvector, to_stdulogicvector
Authors_Name David Bishop
Authors_Phone_Number 585-726-6788
Authors_Fax_Number
Authors_Email_Address dbishop@vhdl.org
Authors_Affiliation Eastman Kodak
Authors_Address1 2400 mt read Blvd
Authors_Address2 Rochester NY 14650-3006
Authors_Address3
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 19 April 2006
Date Analyzed: 20 April 2006
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 20 April 2006
Description of Problem
----------------------
Please look at the following code:
library ieee:
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
......
variable UUU :
unsigned (5 downto 0);
variable SSS : std_logic_vector (5 downto 0);
variable SUSU : std_ulogic_vector (5 downto 0);
begin
SUSU :: std_ulogic_vector (SSS); -- works but shouldn't (use to_stdulogicvector(SSS))
SSS := std_logic_vector (SUSU); -- works but shouldn't (use to_stdlogicvector(SUSU))
UUU := unsigned (sss); -- works
SSS := std_logic_vector(UUU); -- works
UUU := unsigned(SUSU); -- works but shouldn't (use unsigned(to_stdlogicvector(SUSU)))
SUSU := std_ulogic_vector(UUU); -- works but shouldn't (use to_stdulogicvector(std_logic_vector(UUU)))
Added: the relevant types in package numeric_std are:
type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
type SIGNED is array (NATURAL range <>) of STD_LOGIC;
The relevant types in package std_logic_1164 are:
TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;
FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic;
SUBTYPE std_logic IS resolved std_ulogic;
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;
Proposed Resolution
-------------------
Two as I see it.
If this is legal VHDL, then a note about closely related subtypes
should be in the LRM.
If this is not legal VHDL, then I will notify the group which says
this code is legal.
So far 1 simulator says this is legal and 3 say it isn't.
VASG-ISAC Analysis & Rationale
------------------------------
The submitter raises the question of what type conversions are
permitted among the type std_ulogic_vector, std_logic_vector (defined
in std_logic_1164) and unsigned (defined in numeric_std.
Type conversions are described in clause 7.3.5. A type conversion is
legal if the base type of the type mark (the target type) is closely
related to the type of the operand. The types in question are all
closely related, for the following reasons:
- They are all array types.
- They all have the same dimensionality (namely, 1).
- For each index position, they index types are all the same (namely,
natural).
- The element types are all the same (namely, std_ulogic).
Note that, regarding this last point, it is the type of the elements
that is relevant, not the subtype. While std_logic_vector and unsigned
have std_logic as their element subtype, both have std_ulogic (the
base type of std_logic) as the element type.
Since all three array types are closely related, conversion between
any two is legal.
One might then ask why std_logic_1164 includes the to_stdlogicvector
and to_stdulogicvector functions, if their effect can be achieved with
a simple type conversion. One possible rationale is that the package
also contains overloaded functions of these names that convert a
bit_vector operand to the target type. Those functions cannot use the
target type name as the function name, so a different name was
chosen. The package designers may then have added the functions
converting between std_ulogic_vector and std_logic_vector to mirror
the naming of the bit_vector conversion functions.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change in interpretation.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No change.
-------------END OF IR----------------
Received on Thu Apr 20 09:27:02 2006
This archive was generated by hypermail 2.1.8 : Thu Apr 20 2006 - 09:27:02 PDT