VHDL MATH PACKAGE WORKING GROUP, P1076.2 Minutes of meeting in San Jose, 16 June 1995 Present: Jose Torres (Chair), jose@vhdl.org Charles Swart Chuck Swart John Hines Greg Peterson Joanne DeGroat Next meeting: most probably at VIUF in October at Boston, MA, USA. SUMMARY OF MEETING J. Torres presented an overview of deliverables for this group, status of the standardization process for this standard, expected schedule, and open issues. C. Swart presented an overview on the test bench for 1076.2, as well as issues regarding accuracy to compare results and compare with zero. Open issues were discussed and proposals for resolution were presented 1. DELIVERABLES for P1076.2 The VHDL math packages (P1076.2) will consist of basic functions and type conversions for real and complex types. It consists of two packages: MATH_REAL and MATH_COMPLEX. The packages will be installed in library IEEE. The deliverables will consist of the following: package declarations, package bodies, and documentation for the standard. A testbench will be prepared for each package as a guideline for implementors, but it will not formally be part of the standard and/or the documentation. The latest version of the packages is available through anonymous ftp from vhdl.org, in the directory /vi/math/package, file names are: math_head.6.13.95.vhd math_body.6.13.95.vhd or math.6.13.95.tar.Z -- for tar compressed version of the 2 files The packages can be retrieved as follows: ftp vhdl.org username: anonymous password: ftp> cd /vi/math/package ftp> get math_head.6.13.95.vhd ftp> get math_body.6.13.95.vhd ftp> bye If you do not have access to ftp, send an e-mail request to jose@vhdl.org 2. STATUS of P1076.2 All documentation for P1076.2 has been sent to IEEE for balloting. Based on the most up-to-date information, IEEE is planning to start sending ballots out by 6/15/95. Assuming that ballots are mailed around 6/15/95, the current tentative schedule is as follows: - balloting: 6/22 - 7/22 - address negative ballots: 7/22- 8/22 - submit standard to IEEE board: 9/15/95 - get IEEE approval: 12/95 (board gets together every quarter) For all of you who are part of the balloting group, please MAKE SURE TO RETURN YOUR MATERIALS ASAP so that we have time to address your answers and make the 9/15/95 date, which is critical. If we miss the September date, then we may need to wait until 3/96 to get IEEE approval. The following is an extract of the conformance rules discussed and mentioned in the documentation that apply and pertain to the use and implementation of this standard: a) No modifications shall be made to the package declarations whatsoever b) The standard mathematical definition and conventional meaning of the mathematical functions that are part of this standard, which are clarified by the Math_Real and Math_Complex package bodies, represent the formal semantics of the implementation of the Math_Real and Math_Complex package declarations. Implementers of these packages may choose to simply compile the package bodies as they are; or they may choose to implement the package bodies in the most efficient form available to the user. Users shall not implement a semantic that differs from the formal semantic specified herein. c) The Math_Real package shall be built on top of the standard data type and precision requirements for floating point operations defined in IEEE P1076-1993 (STD.STANDARD) d) The minimum precision required is that of the VHDL LRM (IEEE P1076): minimum of six decimal digits of precision in a range contained within the bounds -1E38 to 1E38 inclusive. Because of this reason and the fact that the functions are implemented on digital computers with only finite precision, the functions provided in this set of packages can, at best, only approximate the corresponding mathematically defined functions. An implementation is allowed to provide a higher precision. e) For some functions, the implementation must deliver "prescribed results" for certain special arguments, as defined in the comments for the functions both in the function declaration and the function body. The purpose is to strengthen the accuracy requirements at special argument values. Prescribed results take precedence over maximum relative error requirements. f) The semantics of the standard require that all the functions in the packages detect and report invalid parameters (out of range) through an assert statement. Domain of valid values is indicated in the Math_Real and Math_Complex package declarations. The default value of the severity level shall be Error. An implementation is allowed to provide a mechanism for the user to redefine the value of the severity level. g) The semantics of the standard do not require detection of overflow or underflow. Therefore, detection of underflow/overflow is optional and implementation dependent h) A definition of what comprises the capability of representing and distinguishing signed zeroes is beyond the scope of this standard. Implementations are allowed the freedom not to exploit the capability even when available. i) If an implementation chooses to provide any extensions beyond the minimum requirements of this standard (e.g., precision, overflow handling, ...), then it shall document its behavior accordingly. 3. ISSUES with P1076.2 Currently IEEE is in the process of reviewing the scope and text of copyright declarations, as well as whether or not the source code part of a standard will be available for free distribution or not. Therefore, the current copyright in the packages for P1076.2 is temporary and subject to change based on IEEE's resolution on this matter. This is a very controversial matter that is being reviewed by all the standardization groups that are in the process of submitting documentation for balloting. A proposal was presented to modify the documentation to document the standard without including the source code for the packages (POSIX like), and put the source code in a different place for free access. We will address this issue during the balloting period. 4. TESTBENCH: Status and Issues The testbench, which is not part of the standard, will be provided as a reference for implementors and will not be part of the documentation. The testbench is completely self-contained and fully written in VHDL. The test bench exercises data points for all the functions, compares the values generated by an implementation against a set of "golden" outputs, and produces a report with min accuracy found for each function. The goal of the test bench is to provide a clue on how close an implementation is to the expected results and accuracy, but not to be a validation tool. It is important to note that the math package results may be slightly different on different workstation combinations due to the workstations particular support for floating point arithmetic, which may not be immediately apparent to the average VHDL user. Also, there are issues regarding the comparison of values against zero (i.e., should e-25 be considered close or far from e-40?). The current status of the test bench is as follows: a template for all the functions is available, a reasonable/adequate set of data points is available for some functions but not all, further work/help is needed to complete the sets of data points, it has been run on 4 different commercial VHDL simulation tools. The current version of the test bench is only available upon request, since it is not complete. If you are interested on receiving a copy, please send e-mail to jose@vhdl.org or cswart@analogy.com. Once the test bench is complete, it will be placed in the /vi/math/package directory and eventually will be transferred to John Hines, so that it becomes part of the VHDL test suite his group is responsible for.