| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
![]() |
| Thread Tools |
|
afd
Guest
Posts: n/a
|
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? |
|
|
|
|
|||
|
|||
| afd |
|
|
|
| |
|
Colin Paul Gloster
Guest
Posts: n/a
|
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/sr...data+%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 |
|
|
|
|
|||
|
|||
| Colin Paul Gloster |
|
|
|
| |
![]() |
| Thread Tools | |
|
|
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc..
SEO by vBSEO ©2010, Crawlability, Inc. |



