David, These sort of objections you cite sound like reps from the EDA industry complaining that they don't want to be forced to do "hard" things or make improvements to their legacy code due to the expense. It wasn't that long ago that a certain major vendor barely supported any more than the subset of VHDL that mapped 1-to-1 with Verilog. Should the language have been frozen then? Typical computers are at least two orders of magnitude faster than those available in 1992. Concerns about resource limitations that were valid then don't apply today. Consider that synthesizers of the era didn't support any use of real typed values, even in constant expressions that statically evaluate to a synthesizable type. That doesn't mean that use of real in synthesis is not valid or useful today. Likewise, limited support for universal integers has its place as originally intended in the specification of Ada and VHDL-87. There is no reason why it shouldn't be possible to express a constant value using universal integers provided the result fits into the range of the integer type (or time when defining physical types). Many programming languages today have built-in support for bignum integers, some of which are completely transparent to the user. Suitable libraries exist for every conceivable language one might want to implement a VHDL tool in. There are no practical barriers to making this work. VHDL shouldn't be left stuck in the past because of concerns that don't apply any more. It should not be necessary to increase the size of integer just to gain access to the range of values expressible by time in other physical types. It is clear that many vendors aren't going to budge on the size of integer even though the language is designed to make such a transition as seamless as possible. The current state of inequality between time and other physical types doesn't need to persist when a simple solution is available to fix it. The proposal doesn't even require generalized support for universal integers if the option to have a new type named "physical" is implemented. VHDL should not be fragmented into a separate "advanced" version. Verilog was fundamentally plagued with limitations that couldn't be easily patched over with incremental upgrades. VHDL doesn't need to be subjected to the same fate. Market realities make it impossible for that to succeed even if someone was daring enough to try. This proposal isn't about a change of scope. It is trying to make the language more rational and orthogonal. -- Kevin Thibedeau On Mon, Jan 26, 2015 at 4:36 PM, David Koontz <diogratia@gmail.com> wrote: > > 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 <http://www.eda-twiki.org/cgi-bin/view.cgi/Main/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* <http://www.mailscanner.info/>, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 27 14:38:22 2015
This archive was generated by hypermail 2.1.8 : Tue Jan 27 2015 - 14:39:53 PST