VHDL Issue Number: 2096 Language_Version VHDL-2002 Classification LRM Terminology, Grammar and Typographical Errors Summary Error is ambiguous Relevant_LRM_Sections 0.2.2 Related_Issues Key_Words_and_Phrases Authors_Name Jim Lewis Authors_Phone_Number 503-590-4787 Authors_Fax_Number Authors_Email_Address jim@synthworks.com Authors_Affiliation SynthWorks Authors_Address1 Authors_Address2 Authors_Address3 Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 26 May 2006 Date Analyzed: 08-Sep-2006 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 23-May-2007 Description of Problem ---------------------- Section 0.2.2 defines error as: error: The condition described represents an ill-formed description; implementations are required to detect the condition and report an error to the user of the tool. This is does not tell us whether we will get an assertion style error or a stop the simulator error because the simulation cannot be continued. This issue seems to come from the liberal interpretation of error with respect to textio read that many implementations have gravitated to. Perhaps it is ok for the textio error to be an assertion error, but it is not ok for different implementations to do different things here. Proposed Resolution ------------------- Need to define a separate term for an assertion error and use it where appropriate. VASG-ISAC Analysis & Rationale ------------------------------ The LRM identifies errors that can be detected at various stages in processing a VHDL description, including analysis, elaboration and during execution. The paragraph quoted by the submitter specifies that an implementation is required to detect and report errors, but does not specify the precise form reports are to take. Where the error is detected during execution of a description, reporting the error in the form of an assertion violation appears admissible, since that fulfills the requirement that the error be detected and reported to the user. However, if the error is detected prior to execution, it cannot be reported as an assertion violation, since the semantics of assertion statements involve execution. The significant issue, as identified by the submitter, is whether implementations should be free to define the precise form of error reporting, or whether the LRM should specify the form. If it is implementation defined, as is currently the case, then scripts used to control processing of descriptions may not be portable. Were the LRM to specify that, for example, errors detected during execution be reported in the form of an assertion violation, then portability of scripting would be enhanced. However, such a change would give rise to backward compatibility problems for implementations that currently behave differently. Moreover, there would still remain other aspects of scripting that would remain non-portable, such as control of other aspects of the processing environment. The submitter's proposed resolution is to define terminology for an assertion error and to use it where appropriate. This is currently done in VHDL-2002 in 8.2: If the expression results in the value FALSE, then an *assertion violation* is said to occur. This term is used with reference to execution of assertion statements. Elsewhere, lexical, syntactic, and semantic errors in a VHDL descriptions are referred to as "errors", as described by 0.2.2. Terminology such as "it is an error if ..." and "and error occurs" refer to such errors. Given these considerations, the ISAC does not see strong motivation to change the LRM to mandate a form of error reporting, and considers the disadvantage of a change to outweigh the suggested advantage. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change in interpretation. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change. -------------END OF IR----------------