TWiki
>
P1076 Web
>
VHDL2017
>
LCS2016_059a
(revision 7) (raw view)
Edit
Attach
---+ Language Change Specification for Ordering of any scalar array type ---++ | <sticky><b>LCS Number:</b></sticky> | LCS-2016-059a | | <sticky><b>Version:</b> </sticky> | 1 {25-Jan-2017} %BR% 2 {14-Feb-2017} | | <sticky><b>Date:</b> </sticky> | 14-Feb-2017 | | <sticky><b>Status:</b> </sticky> | Voting | | <sticky><b>Author:</b> </sticky> | Patrick Lehmann %BR% Martin Zabel | | <sticky><b>Email:</b> </sticky> | [[Main.PatrickLehmann]] %BR% [[Main.MartinZabel]] | | <sticky><b>Source Doc:</b></sticky> | - - - - | | <sticky><b>Summary:</b> </sticky> | Remove the limit that only discrete array types can be ordered. | ---+++ Voting Results: Cast your votes here Yes: 1 %USERSIG{PatrickLehmann - 2017-01-25}% - ver 1 1 %USERSIG{LievenLemiengre - 2017-01-27}% - ver 1 1 %USERSIG{JimLewis- 2017-02-06}% - ver 1 1 %USERSIG{ThomasPreusser- 2017-02-10}% - ver 1 1 %USERSIG{MartinZabel - 2017-02-14}% - ver 2 1 %USERSIG{MartinThompson- 2017-02-17}% Version 2 No: 1 Abstain: 1 %USERSIG{BrentHahoe - 2017-02-16}% Version 2 - Abstain due to lack of personal time for review. ---++ Style Notes <noautolink> <sticky> Changes are shown in %RED%red font%ENDCOLOR%.%BR% Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR% Restructuring is shown in crossed out %GRAY%<del>gray font%ENDCOLOR% somewhere else in %GRAY%gray font%ENDCOLOR%.%BR% Editing or reviewing notes in %GREEN%green font%ENDCOLOR%. ---++ Reviewing Notes There should be no reason to restrict ordering on 1-dimensional arrays to discrete types, especially if all scalar types can be ordered. *Version 2* Fixed formatting regarding ordering of discrete / scalar array types, including a slight rewording. ---++ Details of Language Change ---+++ 5.3.2.4 Predefined operations on array types Given a type declaration that declares a %RED%<del>discrete</del>scalar%ENDCOLOR% array type T (see 9.2.3), the following operations are implicitly declared %BR% immediately following the type declaration: <pre> function MINIMUM (L, R: T) return T; function MAXIMUM (L, R: T) return T; </pre> ---+++ 9.2.3 Relational operators | *Operator* | *Operation* | *Operand type* | *Result type* | | = | Equality | Any type, other than a %BR% \ file type or a protected type | BOOLEAN | | /= | Inequality | Any type, other than a %BR% \ file type or a protected type | BOOLEAN | | < | Ordering | Any scalar type or | BOOLEAN | | <= | | %RED%<del>discrete</del> scalar%ENDCOLOR% | | | > | | array type | | | >= | | | | | %GREEN%[...]%ENDCOLOR% | | | | %GREEN%[...]%ENDCOLOR% The ordinary ordering operators are defined for any scalar type and for any %RED%<del>discrete</del>scalar%ENDCOLOR% array type. A scalar array is a %BR% one-dimensional array whose elements are of a scalar type. %RED%Likewise, a discrete array is a one-dimensional array whose elements are of a discrete %BR% type.%ENDCOLOR% Each operator returns TRUE if the corresponding relation is satisfied; otherwise, the operator returns FALSE. %GREEN%[Reviewer Note: The definition of the relation < (less than) for discrete array types is broken since VHDL-2002 due to a formatting error, see comments.%BR% The second edit in gray/red re-establishes the definition from VHDL-1993 by restructuring it (in gray), including a slight rewording (in red).]%ENDCOLOR% For scalar types, ordering is defined in terms of the relative values. For %RED%<del>discrete</del>scalar%ENDCOLOR% array types, the relation < (less than) %BR% is defined such that the left operand is less than the right operand if and only if %GRAY%<del>the left operand is a null array and the right operand is a non-null array.</del>%ENDCOLOR% %GRAY%<del>Otherwise, both operands are non-null arrays, and one of the following conditions is satisfied:</del>%ENDCOLOR% a. %GRAY%<del>The leftmost element of the left operand is less than that of the right, or</del>%ENDCOLOR% a. %GRAY%<del>The leftmost element of the left operand is equal to that of the right, and the tail of the left operand is less than that of the right (the %BR% tail consists of the remaining elements to the right of the leftmost element and can be null).</del>%ENDCOLOR% %GREEN%[Editor note: The above striken text must be restructed as a list with two levels (gray color) and edited (red color) as follows.]%ENDCOLOR% a. %RED%either,%ENDCOLOR%%GRAY% the left operand is a null array and the right operand is a non-null array,%ENDCOLOR% a. %RED%or, <del>Otherwise,</del>%ENDCOLOR%%GRAY% both operands are non-null arrays, and one of the following conditions is satisfied:%ENDCOLOR% * %GRAY%The leftmost element of the left operand is less than that of the right, or%ENDCOLOR% * %GRAY%The leftmost element of the left operand is equal to that of the right, and the tail of the left operand is less than that of the right (the %BR% tail consists of the remaining elements to the right of the leftmost element and can be null).%ENDCOLOR% The relation <= (less than or equal) for %RED%<del>discrete</del>scalar%ENDCOLOR% array types is defined to be the inclusive disjunction of the results of the < and = operators for the same %BR% two operands. The relations > (greater than) and >= (greater than or equal) are defined to be the complements of the <= and < operators, respectively, for the %BR% same two operands. %GREEN%[...]%ENDCOLOR% ---++ Comments ---+++ Version 1 It may be instructive to know why in 1987 the decision was reached that the relational operators for 1-dimensional arrays were only only defined for discrete arrays. Maybe Erich Marschner could provide some insight. Regarding the proposed changes, I believe that in the paragraph after the table, the wrong sentence is marked as new. The LCS number in the table does not correspond to the number used in the document page. -- %BUBBLESIG{ErnstChristen - 2017-01-25}% There could be some issues with ordering real numbers, for instance, what do you do with NaN & infinity values. But real in vhdl already has a defined ordering so I can't see why this operation isn't allowed, I guess it's an oversight. -- %BUBBLESIG{LievenLemiengre - 2017-01-27}% The ordering rules on arrays are based on the scalar value ordering. So I think if a scalar can be ordered in any case, the array should have the same ability. This also adds ordering for physical types, which are internally integers. -- %BUBBLESIG{PatrickLehmann - 2017-01-27}% Isn't there a bug in the current LRM? The 2nd paragraph on page 122 reads: "[...] For discrete array types, the relation < (less than) is defined such that the left operand is less than the right operand if and only if the left operand is a null array and the right operand is a non-null array." Thus, the relation < is true if the left operand is a null-array and the right operand is a non-null array. But, the sentence also states that the relation is only true in this case which actually means that it is false in the other cases, which includes the case where both arrays are non-null, right? If you agree with me, then how it is possible that the following paragraph (the 3rd paragraph on page 122) starting with "Otherwise, both operands are non-null arrays, [..."] can handle the case when both are non-null arrays? -- %BUBBLESIG{MartinZabel - 2017-01-27}% Regarding Lieven's observation with NaN and Inf, these are, in VHDL, not in the range of the predefined type REAL so any such value should cause a range violation. On Martin's question, up to, and including, 1076-1993, the text reads: For discrete array types, the relation < (less than) is defined such that the left operand is less than the right operand if and only if * The left operand is a null array and the right operand is a nonnull array; otherwise, * Both operands are nonnull arrays, and one of the following conditions is satisfied: * The leftmost element of the left operand is less than that of the right; or * The leftmost element of the left operand is equal to that of the right, and the tail of the left operand is less than that of the right (the tail consists of the remaining elements to the right of the leftmost element and can be null). The text was changed in 1076-2002 for reasons unknown to me, but it sure looks like a formatting error. -- %BUBBLESIG{ErnstChristen - 2017-02-10}% ---+++ Version 2 @Ernst: Thanks for looking it up. I have re-established the old formatting, including a slight re-wording. -- %BUBBLESIG{MartinZabel - 2017-02-14}% %COMMENT%</sticky> </noautolink>
Edit
|
Attach
|
P
rint version
|
H
istory
:
r14
|
r9
<
r8
<
r7
<
r6
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r1 - 2017-04-02 - 15:47:59 -
TWikiGuest
P1076
Log In
or
Register
P1076 Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
P1076
Ballots
LCS2016_080
P10761
P1647
P16661
P1685
P1734
P1735
P1778
P1800
P1801
Sandbox
TWiki
VIP
VerilogAMS
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback