VHDL-2002 vs VHDL-93 vs VHDL-87?

A

afd

Guest
I've looked up google, but I can't seem to find a concise
summary about the differences between VHDL 87/93/2002.

What are they?

And what's the next version of VHDL?
 
Someone wrote:

"I've looked up google, but I can't seem to find a concise
summary about the differences between VHDL 87/93/2002.

What are they?"

VHDL93 has many differences from VHDL87, these are mostly additions
amongst which are shared variables and directly instantiating a component
by using the entity name; and at least one change to filehandling
which is not backwards compatible. You may find Andrew Guyler, "VHDL
1076-1992 Languages Changes", EURO-DAC1992 enlightening which can be
found from HTTP://Portal.ACM.org

VHDL2002 is almost identical to VHDL93, except for the addition of
protected types. A somewhat similar summary is given on page iii of
the definition of VHDL2002. Actually come to think of it, page iii of
the definition of VHDL93 also provides an overview of changes.

"And what's the next version of VHDL?

Next in relation to what? Accellera VHDL2006 is expected to be
replaced with very minor differences by IEEE VHDL2007. The latest
draft of this from WWW.Accellera.org (for which one stupidly must
create an account to log in for) is P1076-2006-D3.2.pdf though you can
see from httpS://bugzilla.mentor.com that some more changes have been
made after version Draft 3.2. (VHDL2006 is version Draft 3.0.)

You may also wish to read IEEE Std 1076.6 "IEEE Standard for VHDL
Register Transfer Level (RTL) Synthesis", 2004 from
http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=1342563&isnumber=29580&punumber=9308&k2dockey=1342563@ieeestds&query=%28+1076.6%3Cin%3Emetadata+%29&pos=0

Possible changes to VHDL in the Accellera or the imminent IEEE
standard may include: support for something inspired by the "[..] the
simple subset of the Property Specification Language (PSL) as an
embedded language for formal specification of the behavior of a VHDL
description. PSL is defined by IEEE 1850-2005 [..]";
alternative_label (which is conditional and different from the extant
IF facility with GENERATE) with GENERATE; I have noticed the addition of
subprogram and package generics but VHDL never had (and still does not
have) generic instantiations in which the parameter is a type (Ada83
had all of these kinds of generics); forced parameters; "a reference
to the formal signal parameter within an expression is equivalent to a
reference to the actual signal" might also apply to a parameter of
mode BUFFER; perhaps it is no longer officially "an error if" "the
subtype of the actual is not compatible with the subtype of the
formal" and similarly "if the subtype of the formal is not
compatible with the subtype of the actual" (that the change in syntax
VHDL2006 may be more restrictive on how exposed a SHARED VARIABLE may
be; and Rising_edge has been overloaded to accept a parameter of type
Boolean.

Where an "unconstrained" array used to be relevant, the newer, broader
concept of an "unbounded" array may apply. The terminology
"array_constraint" has been added.

A resolution "indication" may replace a resolution function.

What used to be "unconstrained" may now be termed to be "partially
constrained".

A record_constraint production has been added, but it seems to hardly
be progress towards a variant record of Ada83.

In VHDL2006, linkage mode has still not been removed.

The operators ?= etc.

N.B. the ?? operator can be treated as being automatically present
even if
lexically absent as in this example:
"
use IEEE.STD_LOGIC_1164.all;
signal S: STD_ULOGIC;
assert S; -- implicit conversion applied
".

The FORCE and RELEASE keywords seem for SIGNAL assignments.

"Simple force assignments and simple release assignments [..]
do not involve drivers."

A selected_signal_assignment can have a token consisting of strictly
only one question mark, but I do not know what this "question mark
delimiter" is for but it would seem to be related to the use of a
"question mark delimiter" in a CASE statement to impose involvement of
any of BIT; BOOLEAN; or STD_ULOGIC in the expression (not to be
confused with the condition).

An attempt seems to have been made to simplify the chore of writing
the sensitivity list of a PROCESS by the introduction of the keyword ALL
into the syntax here, but it seems to be forbidden sometimes and I do not
know whether it really works when allowed.

Ambiguous homographs are now legal due to generic subprograms.

Tool directives are recognized as well as comments have been mentioned as
parts of source not in the main VHDL description.

The character ` is now legal. It is for a tool directive, which used to be
implemented as a special -- comment.

Classical unnestable (bad) multiline (good) C comments are legal.

Things which I noted which were written in version D3.2 after version
D2.11 (D2.11 was never a standard, it came after VHDL2002) of the VHDL
Language Reference Manual: the word "must" is replaced by the word
"shall"; Bugzilla issue number 13; LCS-2006-012.pdf: "static discrete
range" instead of merely "discrete range" in a particular context; and
it was made clearer that recursion is allowed in an uninstantiated
generic subprogram.

The phrase "an impure function is never conformant to a subprogram
specification of a pure function" is replaced with "an impure function is
never lexically conformant to a subprogram specification of a pure
function":
HTTPS://Bugzilla.Mentor.com/show_bug.cgi?id=60

A list of ways that a composite subtype can be fully constrained is
unchanged, but is now accompanied by a list of ways that a composite
subtype can be unconstrained.

The "implicitly" declared function TO_STRING has been moved to another
part of the package STD.STANDARD.

The index range for each index of an array object for a constant declared
by an object declaration or for an attribute whose value is specified by
an attribute specification always involves an implicit conversion to the
subtype of the constant or of the attribute and the index ranges are
always defined by the result of the implicit conversion.

Some phrases were added without actually changing the standard, e.g. "A
record constraint may be used to constrain a record type or subtype (see
4.2)".

"For an interface constant declaration (other than a formal parameter of
the predefined = or /= operator for an access type) or an interface
signal declaration, the subtype indication must define a subtype that is
neither a file type, an access type, nor a protected type. Moreover, the
subtype indication must not denote a composite type with a subelement
that is of an access type"
has been replaced by
"For an interface constant declaration or an interface signal
declaration, the subtype indication shall define a subtype that is
neither a file type, an access type, nor a protected type. Moreover, the
subtype indication shall not denote a composite type with a subelement
that is a file type, an access type, or a protected type".

What had been called "The ordering operators" are now called "The
ordinary ordering operators".

A change is also mentioned in
HTTPS://Bugzilla.Mentor.com/show_bug.cgi?id=50
Also, two long sentences concerning leftmost and rightmost bounds have
been added.

A locally static expression can use operators for NUMERIC_BIT_UNSIGNED and
NUMERIC_STD_UNSIGNED; or can be an unconstrained or partially constrained
composite subtype for which the applicable constraints are locally static.
The clauses:
"i) A qualified expression whose operand is a locally static expression
j) A type conversion whose expression is a locally static expression"
have been replaced with
"i) A qualified expression whose type mark denotes a locally static
subtype and211 whose operand is a locally static expression
j) A type conversion whose type mark denotes a locally static subtype
and whose expression is a locally static expression".

Not all attributes of an interface object whose mode is buffer may be read
in version Draft 3.2, unlike version Draft 2.11, so mode out may be
identical to mode buffer (unlike every IEEE version of VHDL so far).

"[..]
An expression is said to be globally static if [..]
[..]
e) A constant (including a deferred constant)
[..]
j) A predefined attribute that is a value and whose prefix is either a
globally static subtype or is an object or function call that is of a
globally static subtype
[..] 'DRIVING_VALUE, whose prefix is either a globally static subtype or [..]
[..]
[..] A qualified expression whose operand is a globally static expression
[..] A type conversion whose expression is a globally static expression
[..]

A globally static range is either a range of the second form (see 3.1)
whose bounds are globally static expressions, or
a range of the first form whose prefix denotes either a globally static
subtype or an object that is of a globally static
subtype[..]

[..]"
has been replaced by
"[..]
An expression is said to be globally static if [..]
[..]
e) A constant (including a deferred constant) explicitly declared by a
constant declaration with a globally static subtype or with an
unconstrained or partially constrained composite subtype for which the
applicable constraints are globally static
[..]
j) A predefined attribute that is one of 'SIMPLE_NAME, 'INSTANCE_NAME,
or 'PATH_NAME
k) A predefined attribute that is a value and, other than the predefined
attributes 'SIMPLE_NAME, 'INSTANCE_NAME, and 'PATH_NAME, whose prefix is
either a globally static subtype appropriate for a globally static
attribute or is an object or function call that is of a globally static
subtype
[..]
[..] 'DRIVING_VALUE, whose prefix is either a globally static subtype
appropriate for a globally static attribute or [..]
[..]
[..] A qualified expression whose type mark denotes a globally static
subtype and whose operand is a globally static expression
[..] A type conversion whose type mark denotes a globally static subtype
and whose expression is a globally static expression
[..]

A prefix is appropriate for a globally static attribute if it denotes a
signal, a constant, a type or subtype, a globally static function call, a
variable that is not of an access type, or a variable of an access type
whose designated subtype is fully constrained.

A globally static range is either a range of the second form (see
3.1) whose bounds are globally static expressions, or
a range of the first form whose prefix is appropriate for a
globally static attribute[..]
[..]".

"[..] The rules for locally and globally static expressions imply that a
declared constant or a generic may be initialized with an
expression that is neither globally nor locally static; for example, with
a call to an impure function. The resulting constant value may
be globally or locally static, even though its subtype or its initial
value expression is neither. [..]
[..]"
has been replaced by
"[..] The rules for globally static expressions
imply that a declared constant or a generic may be initialized with an
expression that is not globally static, for example, with a call
to an impure function. The resulting constant value may be globally
static, even though its initial value expression is not. [..]
[..]"

"[..]
If the target of a variable assignment statement is in the form of an
aggregate, and if the locally static name in an
element association of that aggregate denotes a given variable or denotes
another variable of which the given variable
is a subelement or slice, then the element association is said to identify
the given variable as a target of the assignment
statement. It is an error if a given variable is identified as a target by
more than one element association in such an
aggregate.

[..]"
was replaced with
"[..]

If the target of a variable assignment statement is in the form of an
aggregate, and if the locally static name in an
element association of that aggregate denotes a given variable or denotes
another variable of which the given variable
is a subelement or slice, then the element association is said to identify
the given variable as a target of the assignment
statement. It is an error if a given variable is identified as a target by
more than one element association in such an
aggregate. Furthermore, it is an error if an element association in such
an aggregate contains an others choice, or if the
element association contains a choice that is a discrete range and an
expression of a type other than the aggregate
type.

[..]"

The following was added to Draft version 3.2 of the upcoming IEEE VHDL
standard:

"For a matching case statement in which the expression is of type
STD_ULOGIC, or an array type whose element type
is STD_ULOGIC, it is an error if the value of the expression is the
scalar value '-' or an array value containing '-' as
an element.

NOTES

[..]

4 - An others choice is generally required in a matching case statement
in which the expression is of type STD_ULOGIC, or an
array type whose element type is STD_ULOGIC, since explicit choice values
cannot be written to represent metalogical values of
the expression. (Application of the predefined matching equality operator
with a metalogical operand value gives the result 'X'.)
Such expression values, which shall nonetheless be represented by a
choice, are represented by the others choice."

Much of Section 12.5 Dynamic elaboration has been changed.

"[..]

14.1 Predefined attributes

Predefined attributes denote values, functions, types, and ranges
associated with various kinds of named entities[..]"
has been replaced by
"[..]
14.1 Predefined attributes

Predefined attributes denote values, functions, types, subtypes,
signals, and ranges associated with various kinds of named entities".

Regards,
Colin Paul Gloster
 

Welcome to EDABoard.com

Sponsor

Back
Top