On 10/01/2015, at 9:00 pm, Daniel Kho <daniel.kho@tauhop.com> wrote: > Jan Decaluwe explains this clearly in one of his suggestions, and which I also agree: > > -- JanDecaluwe - 2014-11-02 My suggestion is to implement this similar to vector types: allow unconstrained types (e.g. UNIVERSAL_INTEGER) in interfaces, but require finite constraints at elaboration time. This would provide the modeling advantages of arbitrary length integers while keeping the advantage of a compiled language: the elaborator/compiler could perform optimizations based on the constraints. This should address any performance concerns. > On 10 January 2015 at 15:27, Daniel Kho <daniel.kho@tauhop.com> wrote: > Tristan, > As from what I understand from the ArbitraryIntegers proposal, it is not suggesting to have infinite precision integers at simulation/elaboration time. It is merely suggesting to have unconstrained integers (yes, infinite precision if you may) prior to being constrained later at a higher-level hierarchy of the design, which makes the design synthesizable and finite. Performance concerns aren't paramount. VHDL has purposefully discarded infinite precision arithmetic. 9.5 Universal Expressions, paragraphs 5: For the evaluation of an operation of a universal expression, the following rules apply. If the result is of type universal_integer, then the values of the operands and the result shall lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself. If the result is of type universal_real, then the values of the operands and the result shall lie within the range of the floating-point type with the widest range provided by the implementation, excluding type universal_real itself. -- Understanding how this came about is a matter of history, reflecting a differences between VHDL87's Issue Report 0021 discarding support for globally static infinite precision as an interpretation and VHDL92's Language Change Specification 0020, no longer 'requiring' support for infinite precision at all. From IR0021: VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Adopt the issue author's recommendations. Specifically, Paragraphs 3 and 4 of Section 7.5 of the VHDL LRM should be read as follows: The accuracy of the evaluation of a universal expression of type universal_real is at least as good as that of the most accurate predefined floating point type supported by the implementation, apart from universal_real itself. Furthermore, if a universal expression is a locally static expression, then the evaluation must be exact. For the evaluation of an operation of a non-locally static universal expression, the following rules apply. If the result is of type universal_integer, then the values of the operands and the result must lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself. If the result is of type universal_real, then the values of the operands and the result must lie within the range of the floating point type with the widest range provided by the implementation, excluding type universal_real itself. This was VASG approved as an interpretation (IEEE 1076-CONC-1990, The Senses of VASG, Page 13). Note the difference from the original language: IEEE Std 1076-1987, 7.5 Universal Expressions, paragraphs 4 and 5: The accuracy of the evaluation of a universal expression of type universal_real is at least as good as that of the most accurate predefined floating point type supported by the implementation, apart from universal_real itself. Furthermore, if a universal expression is a static expression, then the evaluation must be exact. For the evaluation of an operation of a non-static universal expression, the following rules apply. If the result is of type universal_integer, then the values of the operands and the result must lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself. If the result is of type universal_real, then the values of the operands and the result must lie within the range of the floating point type with the widest range provided by the implementation, excluding type universal_real itself. -- So here we find that originally the standard's language supported the notion of both locally static and globally static exact universal expressions requiring infinite precision, and to reduce an unknown elaboration effort globally static universal expressions were thrown under the bus. The VHDL92 effort, eventually resulting in the -1993 version of the standard reflects on the issue further (LCS-0020(2), excerpted): !brief-overview-of-the-problem The VHDL LRM requires "exact" evaluation of static universal expressions. There are three problems with this requirement. First, its not clear whether "static" or "locally static" is meant in this context (this is the original motivation behind IR-0021). Second, it is not clear whether the gains provided by exact evaluation of certain universal expressions outweigh the corresponding implementation difficulty. Finally, there is a certain amount of confusion about what "exact" evaluation means, particularly for real universal expressions. !proposed-solution Drop the requirement for exact evaluation of static universal expressions. The precision/accuracy requirements of static (or locally static) universal arithmetic should be no more demanding than those for run-time universal arithmetic. !rationale VHDL got the idea of exact "compile-time" universal arithmetic from Ada. Much of the motivation for this requirement in Ada is clearly the initialization of "untyped" numeric quantities called "named numbers". VHDL of course has no such concept. Hence we see relatively little real need for exact universal arithmetic at compile time. We would be very surprised if there were any VHDL models in existence that relied an arbitrary precise compile-time universal arithmetic. Its also not clear to us that all VHDL implementations indeed provide exact evaluation of compile-time universal expressions. Since the idea of exact compile-time universal arithmetic seems to be of so little value, is so poorly defined and seems inadequately understood by so many we simply favor removing the requirement from the language. !lrm-sections-affected 7.5 !examples !upward-compatibility Theoretically this is not an upward-compatible language change. We doubt, however, whether there exist any real VHDL models whose results be negatively affected. !implementation-impact This change makes the language easier to implement. Those implementations that do indeed provide exact universal arithmetic at compile time can of course continue to do so. !other-alternatives-considered Our second preference for resolving this is as follows. First, change the language so that exact evaluation of universal expression is only required for locally static expressions. The reason for this is that (in our view) if an implementation has to support exact evaluation of universal expressions at elaboration time the language might as well require exact evaluation of these expressions at run time (i.e., in general). This strikes us as a significant implementation burden for very little gain. Second, change the definition of "exact" and the use of the term "accuracy" in LRM 7.5 to be more clear and specific (IR-0021 has a good discussion of this). !open-issues !reservations-about-the-requirements -- Noting the first proposal was adopted, Issue Report 0021 representing the alternative proposal and no one registered any reservations at the time. So essentially infinite precision in universal expressions as a requirement for VHDL has been discarded "as a significant implementation burden for very little gain" considering the lack of named numbers. You could note that in -2008, 5.2.3 Integer types, 5.2.3.1 General, paragraph 7 still requires exact equivalence between arithmetic operator results and mathematical result: The same arithmetic operators are predefined for all integer types (see 9.2). It is an error if the execution of such an operation (in particular, an implicit conversion) cannot deliver the correct result (that is, if the value corresponding to the mathematical result is not a value of the integer type). -- And this could be expected to have a performance impact, requiring a trap on rollover for arithmetic operators found under 9.2, also associated basic operations. 'correct' appears to depend on 'mathematical' as in "ordinary mathematical meaning". This requirement is unchanged from -1987. Together these impact the desire to expand the range of physical types. 9.5 in particular requires "... the values of the operands and the result shall lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself", which essentially tells us the bounds of a new integer or physical type must fall within the range of type INTEGER in the absence of a new wider integer type being added to package STANDARD. This also affects basic operations ("...the evaluation of an operation of a universal expression", the operations of a type defined in 5. Types, 5.1 General, Paragraphs 2 and 3). A solution to increasing the range of a user defined physical type might be to either increase the implementation defined range of type INTEGER which is likely fraught with difficulties for synthesis vendors or adding a new integer type to package STANDARD which they could politely ignore. The need for infinite precision arithmetic in hardware description may not have been adequately addressed by Patrick Lehmann's examples. An analogy might be doing carpentry with measurements in microns, the physical materials and tools don't support it. We tend not to use systemic descriptions to fix a particular described piece of hardware's position in the universe. Those details can be provided in comments, descriptive names, attributes and system description. Think of it as a collision between the language's intended use "...in all phases of the creation of electronic systems. Because it is both machine readable and human readable, it supports the development, verification, synthesis, and testing of hardware designs; the communication of hardware design data; and the maintenance, modification, and procurement of hardware." (From the current Introduction, non-normative). VHDL doesn't claim to be intended to communicate electronics systems design data, just hardware design data. And that would incidentally make a great segue for a SystemVHDL effort should someone feel the need to change the scope of the language. -------- VHDL87 Issue Report 0021: http://www.eda-twiki.org/isac/IRs-VHDL-87/IR0021.txt VHDL92 Language Change Specification 0020: http://www.eda-twiki.org/isac/vhdl-92-LCSs/LCS-0020 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Jan 26 13:37:59 2015
This archive was generated by hypermail 2.1.8 : Mon Jan 26 2015 - 13:38:31 PST