On 11 Nov 2014, at 9:26 am, Andreas Bombe <[email protected]> wrote: > On Fri, Nov 07, 2014 at 10:48:29AM +0100, Joris van Rantwijk wrote: >> On 2014-11-07, Tristan Gingold wrote: >>>> At this point I wonder if it's not just simpler to just go and >>>> implement a free alternative implementation instead of discussing >>>> at length how to handle that IEEE license. I see that it would be >>>> some work, but the payoff of not having to worry about the licenses >>>> would be worth it I think. >>> >>> Feel free to start the effort. That would be helpful. >> >> I have my own implementation of std_logic_1164 (at VHDL-1993 level). >> >> While working on that, I found that it was impossible to get it right >> without constantly looking at the reference code. There are many places >> where you appearantly have a choice, and there is no intuitive way to >> know what the right answer is. > > That's a bit special since the bodies of the multivalue logic packages > are normative unlike the bodies of other standard packages.
IEEE Std 1076-2008 Annex A (informative) Description of accompanying files, A2. Package bodies, A.2.1 General: VHDL source files for the packages residing in library IEEE described in this standard are in the ieee directory of the archive file. The bodies of the standard mathematical packages are not normative. They are provided as a guideline to implementers, to suggest ways in which implementers may implement the packages. The bodies of the standard multivalue package and the standard synthesis packages, on the other hand, are normative specifications of the semantics of the packages. A.2.2 Standard mathematical packages (body not normative) (math_real, math_complex) A.2.3 Standard multivalue logic package (body normative) (std_logic_1164, std_logic_text_io) A.2.4 Standard synthesis packages (body not normative) (numeric_bit, numeric_std, numeric_bit_unsigned, numeric_std_unsigned) A.2.5 Fixed-point and floating-point packages (not specified) (fixed_float_types, fixed_generic_pkg, fixed_pkg, float_generic_pkg, float_pkg) And what being normative means: (From the header of of one of the normative body packages) -- Note : This package may be modified to include additional data -- : required by tools, but it must in no way change the -- : external interfaces or simulation behavior of the -- : description. It is permissible to add comments and/or -- : attributes to the package declarations, but not to change -- : or delete any original lines of the package declaration. -- : The package body may be changed only in accordance with -- : the terms of Clause 16 of this standard. -- : 16.7 Standard multivalue logic package b) The STD_LOGIC_1164 package body ... Implementers of this package body may choose to simply compile the package body as it is; or they may choose to implement the package body in the most efficient form available to the user. Implementers shall not implement a semantic that differs from the formal semantic provided herein. So, there is leeway. And while the same holds true for standard synthesis packages (they have the same Note in the body), There are additional semantic restrictions found in Clause 16 and Clause 9 (Expressions, covering operators). 16.8.5 Packages for arithmetic using bit and standard logic values 16.8.5.2 Allowable modifications Vendors of tools conforming to this standard shall not modify the package declarations. However, a vendor may provide package bodies for any of the packages in which subprograms are rewritten for more efficient simulation or synthesis, provided that the behavior of the rewritten subprograms remains the same under simulation. The behavior of the original and rewritten subprograms are the same if, for any combination of input values, they return the same return values. The text of messages associated with assertions may differ in the rewritten subprogram. The package bodies for the NUMERIC_BIT and NUMERIC_STD packages declare a constant named NO_WARNING that has the value FALSE. A user may set NO_WARNING to TRUE and reanalyze the package body to suppress warning messages generated by calls to the functions in these packages. For this reason: — A tool vendor who rewrites the package body shall preserve the declaration of the NO_WARNING constant to allow a user to suppress warnings by editing and reanalyzing the package body. — A simulation tool vendor who provides a preanalyzed version of the package body should also provide a mechanism for suppressing warning messages generated by the package functions. --------- And you could note that without this 'permissiveness' there could be no competitive distinctiveness distinguishing one vendor's offerings for another, leaving tool implementations to vary in performance by how they have optimizations applied to elaborated models and internal representations of types (objects in general) or LRM feature compliance (the set of who is fully compliant is the imaginary sound of one cricket chirping). Also the implementor already has similar leeway and various semantic restrictions on package standard 'declared' operators. In any event there's a license to do what Tristan has described. And yes package bodies can be semantically normative, but don't need to be literal copies. (Also noting A.2.1 is informative and not normative, where package bodies are described as normative ;-), while Clause 16 which is normative gives license).
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
