the ISAC is serving in the role of LRM review committee for the current LRM balloting effort. In the review process for version D4.2 of the LRM the following issue was discovered. It is identified as Bugzilla number 234 and you can read it (no login required for reading) at https://bugzilla.mentor.com. Below is the issue and proposed solution as described in that Bugzilla report. It seems like a good solution, but requires changes to package std_logic_texio (aliases must be added). Note that a similar problem involving moving functions rising_edge and falling_edge from one package to another was solved the same way. Please let us know ASAP if you have any issues with this proposed solution. Chuck Swart Chair ISAC At the ISAC telecon on 19 June, it was pointed out that the way the std_logic_textio package is defined introduces an incompatibility with the prior version defined by the donor. The procedures defined in the prior version are now defined in std_logic_1164, and std_logic_textio is empty. The premise is that users will have a use class that uses all of both packages, viz use ieee.std_logic_1164.all, ieee.std_logic_textio.all; Under this scenario, the placement of the declarations does not matter, as they will become directly visible regardless. However, if a users writes selected names for the procedures that were in std_logic_textio, the difference in placement is exposed. The models will no longer work. A remedy was suggested, taking advantage of the revised semantics of aliases and homographs. The procedure declarations in the prior version of std_logic_textio can be replaced by aliases designating the corresponding declarations in the new version of std_logic_1164. That way, selected names for std_logic_textio procedures will still work. In the more usual scenario of a use clause referring to all of both packages, each alias and its designated declaration both become directly visible, but there is no ambiguity as they both denote the same named entity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jun 24 18:40:26 2008
This archive was generated by hypermail 2.1.8 : Tue Jun 24 2008 - 18:41:44 PDT