Textio Boolean Write
Proposal Information
- Who Updates: JimLewis, YourName>, ...
- Date Proposed: 2013-11-13
- Date Last Updated: 2013-11-13
- Priority:
- Complexity:
- Focus: Testbench
Requirement Summary
VHDL-2008 LRM requires that identifier based literals, including boolean, are printed as lower case. Prior to this they were printed as upper case.
Related and/or Competing Issues: NONE
Issue Summary: Bugzilla 285
Bugzilla 285 VHDL-2002 LRM describes the semantics of textio read and write procedures in clause 14.3 with: "The definition of the string representation of the value for each data type are as follows: ... The representation of a BOOLEAN value is formed by an identifier, either FALSE or TRUE."
However, in VHDL-2008 the expanded semantics of string representations in clause 5.7 state: "When forming the string representation for a WRITE procedure in STD.TEXTIO (see Clause 16) or for an implicitly defined TO_STRING operation, except where otherwise specified for an overloaded TO_STRING operation: ... Letters in a basic identifier are in lowercase."
Together, these statements imply that the write procedure will produce "TRUE" and "FALSE" for earlier language versions and "true" and "false" for the same procedure called from VHDL-2008 code.
Because of the vast amount of legacy code in existence, if the semantics of WRITE for VHDL-2008 are not changed I suspect that vendors will be forced to add a switch/mode/etc to allow the older behavior.
There are several ways to solve this problem, non of them ideal. Until this issue is resolved we will keep the older implementation of WRITE, but use the newer interpretation of to_string.
Possible Solutions
Solution 1: Follow VHDL-2008 Rules
VHDL-2008 specifies lower case, so use lower case.
Solution 2: Support case sensitive identifiers
Write identifiers in the same case they are specified in.
Solution 3: Make Boolean a Special Case
Rewrite the rules so that writing boolean is consistent with language revisions prior to 2008 and is always upper case for both write and to_string.
Recommendations
This is not the only inconsistency between language revisions. If someone needs consistency with an older version, they can use the switches provided by tool vendors. Going forward, consistency between vendors is important. The easiest way to do this is for vendors to implement the standard as written.
General Comments
Supporters
Add your signature here to indicate your support for the proposal