Operations on Ranges
Proposal Editing Information
- Who Updates: <Add YourName >, ...
- Date Proposed:
- Date Last Updated:
- Priority:
- Complexity:
- Focus:
Requirement Summary
Allow static operations on "ranges".
-------------BEGINNING OF IR----------------
VHDL Issue Number: 2072
Language_Version VHDL-93
Classification Language Modeling Enhancement or Deficiency
Summary Allow static operations on "ranges"
Relevant_LRM_Sections <unknown>
Related_Issues <unknown>
Key_Words_and_Phrases range, operator
Authors_Name Stewart Cobb
Authors_Phone_Number 650-644-1418
Authors_Fax_Number
Authors_Email_Address stu@novariant.com
Authors_Affiliation Novariant Corporation
Authors_Address1 1350 Willow Road
Authors_Address2 Menlo Park, CA
Authors_Address3 94025
Current Status: Forwarded
Superseded By:
------------------------
Date Submitted: 18 August 2005
Date Analyzed: 02 December 2005
Author of Analysis: Chuck Swart
Revision Number: 1
Date Last Revised: 02 December 2005
Description of Problem
----------------------
This is a change proposal for the syntax of the VHDL language
regarding "ranges" of array types. It would have the effect of
allowing simple arithmetic to be used in array range references, so
that the following example would work as intended:
--> Types and signals for example:
type WORD is array (31 downto 0) of std_logic;
type HALFWORD is array (15 downto 0) of std_logic;
signal my_word :
WORD;
signal my_half_lo : HALFWORD;
signal my_half_hi : HALFWORD;
--> Proposed change would allow:
my_half_lo <: my_word(my_half_lo'range);
my_half_hi <= my_word(my_half_hi'range + my_half_lo'length);
--> Currently legal code is much less clear:
my_half_lo <= my_word(my_half_lo'range);
my_half_hi <= my_word(
(my_half_hi'high + my_half_lo'length) downto
(my_half_hi'low + my_half_lo'length) );
--> It is possible to write a "currently legal" example
--> that does not require knowledge of the range
--> directions, but that's even less clear:
my_half_lo <= my_word(my_half_lo'range);
if my_half_hi'ascending then
my_half_hi <= my_word(
(my_half_hi'low + my_half_lo'length) to
(my_half_hi'high + my_half_lo'length) );
else
my_half_hi <= my_word(
(my_half_hi'high + my_half_lo'length) downto
(my_half_hi'low + my_half_lo'length) );
end if;
--> This change should also allow expressions like this:
subtype SIGNED_BYTE
is integer range -128 to 127;
subtype UNSIGNED_BYTE
is integer range (SIGNED_BYTE'range - SIGNED_BYTE'low);
--> Expressions like the second one are useful inside
--> library functions which cannot assume the size, range,
--> or direction of their arguments.
Proposed Resolution
-------------------
If the endpoints of a range are a certain type, then operators which
can be applied to that type should be legal when applied to the
"range", and should be interpreted as applying to both endpoints of
the range simultaneously.
VASG-ISAC Analysis & Rationale
------------------------------
Some of the problems that the author mentions can be solved by using
aliases to normalize ranges and directions of array objects.However,
this proposal goes farther and permits some form of arithmetic on
ranges.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Consider this enhancement request.
-------------END OF IR----------------
Current Problems / Issues
Use Model / Code Examples
Questions
Proposal
General Comments
Supporters
_Add your signature here to indicate your support for the proposal
--
PatrickLehmann - 2016-02-19
Topic revision: r5 - 2020-02-17 - 15:34:37 -
JimLewis