IEEE 200X Fast Track Change Proposal ID: FT-12 Proposer: Stephen Bailey email: sbailey@model.com Status: Proposed Proposed: 08/03 Analyzed: 02/16/04 Resolved: 02/16/04 Related issues: Relevant LRM sections: 1.1.1.2 Ports 4.3.2 Interface declarations 12.6.2 Propagation of signal values B.182 Enhancement/Requirements Summary: -------------------------------------------------------- Read output ports. The value read shall be the local driving value after the resolution of local drivers and contributing values. Enhancement/Requirements Detail: -------------------------------------------------------- There are circumstances in which it is necessary to read the driving value of an OUT mode port. VHDL currently does not permit an OUT mode port to be read directly. Within a process, it is possible to determine the value that the process is driving a signal using the 'Driving_Value attribute. However, additional circumstances exist when it is necessary to read the driving value of the port and not the driving value of a specific process. The primary circumstance is in assertion-based verification where a property needs to ensure that a design entity is driving the output to the correct value or otherwise must take into consideration the driving value of the entity. Implementation Summary: ---------------------------- Two general approaches exist for satisfying this request: 1. A new attribute could be defined that is analogous to the existing 'Driving_Value but applies to the driving value of the port and not a specific process. The pros to this approach is that it requires explicit referencing of the attribute and provides a superficial holding of the existing language restriction against reading of an OUT mode port. The cons are that the obvious attribute name has been used. A new attribute name will be needed to avoid limit confusion. However, some potential for confusion for users would remain. Also, this approach is not the most concise as any attribute name (no matter how short) will be longer than simply referencing the port name. 2. The language restrictions against reading OUT mode ports are removed. The driving value of the port is read normally. While this approach is more concise, it also has potential for confusion. When an INOUT port is read, it is the effective value that is read. Also, this would make BUFFER and OUT mode ports identical in semantics. In both cases, the question arises as to whether the ability to read an OUT mode interface objects should apply only to signal class objects or if they should also apply to variable class objects as well. Simplicity would argue that it should apply to all classes of interface object. Also, for language simplicity and to complete the work started in earlier revisions with relaxing the restrictions on BUFFER mode ports, it is proposed that OUT and BUFFER mode interface objects be treated identically. Implementation Details: ---------------------------- Section 1.1.1.2 Ports a) shall be replaced with: a) For a formal port of mode *in*, the associated actual must be a port of mode *in*, *inout*, *out* or *buffer*. Section 2.1.1.1 Constant and variable parameters Add a 2nd note at the end of this section: 2--The value of an actual associated to an *out* mode variable parameter is never passed into or used by the subprogram. The *out* mode parameter is initialized based on its declaration. When an *out* mode variable parameter is read, the value that is read is the value that would be copied out to the actual if the current statement reading the parameter's value were replaced by a return statement. Section 2.1.1.2 Signal parameter Change the first paragraph to For a formal parameter of class signal, a reference to the signal is passed into the subprogram call. Moreover, if the parameter is of mode out or inout, a reference to the driver of the signal is also passed into the subprogram call. In the second paragraph, change the text For a signal parameter of mode in or inout, with For a given signal parameter, Add a 2nd note at the end of this section: 2--If an *out* mode signal parameter is read, the value that is read is the effective value of the signal associated as the actual parameter in the call to the subprogram. Section 4.3.2 Interface declarations The 2002 OUT mode description in the section starting "An interface object has one of the following modes:" will be deleted. The 2002 BUFFER mode description in the same section will be modified to include OUT mode as in: -- *out* or *buffer*. Reading and updating the value of the interface object is allowed. Reading the attributes of the interface object is also permitted. A 5th note shall be added at the end of this section that states: 5--Although *out* and *buffer* mode ports are semantically identical, there is an important design documentation differentiation between the two. It is intended that the reading of an *out* mode port should be done only for passive activities (that is, functionality used for verification purposes) such as within monitors or property/assertion checkers. If the value of an *out* direction port needs to be read to implement the algorithmic behavior of the architecture, then a *buffer* mode port should be used. Due to the complexity that monitors/ checkers can reach, it is impossible to semantically impose these restrictions of use within the language without compromising the ability to write complex monitors/checkers. Section 12.6.2 Propagation of signal values In the paragraph describing how the *effective value* is determined, the first bullet shall be modified to include OUT mode ports as follows: -- If S is a signal declared by a signal declaration, a port of mode *out* or *buffer*, or an unconnected port of mode *inout*, then the effective value of S is the same as the driving value of S. Annex B, B182: Replace the existing definition of *out*: B.182 *out*: One possible of a port or subprogram parameter. A port of mode *out* contributes its driving value to the netowrk containing the port; the design entity containing the port is also allowed to read its driving value. A subprogram parameter of mode *out* can be modified and its value read by the containing subprogram. If the *out* parameter is signal class, the the value read is the effective value of the signal associated as the actual in the call to the subprogram (or the subprogram's parent, recursively). If the *out* parameter is variable class, the value read is the current output value of the parameter. Discussion: ---------------------------- The resolution taken is the simplest and most consistent application of existing language semantics to cover the desired capability. Analysis/LRM Changes ---------------------------- See above. Note: This change is backward compatible. Resolution: ---------------------------- [To be performed by the 200X Fast Track Working Group]