IEEE 200X Fast Track Change Proposal ID: FT-13 Proposer: Name email: email Status: Open Proposed: Date Analyzed: Date Resolved: Date Enhancement Summary: Define stop(), finish() and reset() procedures within a standard package located in the IEEE library Related issues: Relevant LRM section: Enhancement Detail: ---------------------------- Purpose: To allow designers to control: a. Finishing simulation, typically from the testbench after all stimulus has been exhausted and all responses have been detected. Or when an unrecoverable error condition has been detected. b. Allow designers to insert calls to break the simulation. Typically, this would occur in testbenches when the testbench detects a mismatch between expected and actual results. However, it could also be used anywhere within the design to detect erroneous situations and break the simulator as close to the cause of the error as possible. c. Allow a testbench to restart simulation. Presumably to run a different set of tests through the same design. However, there may be other uses as well. Detailed Proposal: The VHPI addition to 1076 defines the routine vhpi_control(). This routine allows the implementation of these two standard routine in terms of the standard VHPI. Specifically, these routines would be defined by their C language (foreign) implementations. These C implementations would then contain calls to vhpi_control() passing in the vhpiControlT enumeration values: In library IEEE, I assume some type of Utils package containing (among other declarations): procedure STOP; procedure FINISH; procedure RESET; procedure STOP is -- Vendor-specific 'Foreign attribute mapping this procedure -- to the vhpiStop function attribute FOREIGN of STOP:procedure is "implementation-specific"; begin report "STOP is not supported by this simulator"; end procedure STOP; procedure FINISH is -- Vendor-specific 'Foreign attribute mapping this procedure -- to the vhpiFinish function attribute FOREIGN of FINISH:procedure is "implementation-specific"; begin report "FINISH is not supported by this simulator"; end procedure FINISH; procedure RESET is -- Vendor-specific 'Foreign attribute mapping this procedure -- to the vhpiReset function attribute FOREIGN of RESET:procedure is "implementation-specific"; begin report "RESET is not supported by this simulator"; end procedure RESET; Of course, implementations will be free to optimize the implementation of these routines, but it is convenient that it is possible to implement them in terms of foreign subprograms that make calls to the standard VHPI function using standard VHPI enumeration literals. Analysis: ---------------------------- Peter Ashenden Last revised: 11-Dec-04 The proposal is to provide a VHDL description with a mechanism to control progress of a simulation. A model for such a mechanism is provided by the proposed VHPI specification, which defines three simulation control actions: - vhpiStop: the tool stops simulation then accepts further directives from an interactive user or a command source - vhpiFinish: the tool enters the termination phase - vhpiReset: the tool enters the reset phase, in which time is reset to zero and the model reinitializes The VHPI includes a function vhpi_control with the prototype PLI_INT32 vhpi_control (vhpiSimControlT command, ...); The type vhpiSimControlT is defined as typedef enum { vhpiStop, vhpiFinish, vhpiReset } vhpiSimControlT; A VHPI program can call vhpi_control with one of these values to invoke the corresponding control action. For each, a tool may accept further arguments with implementation-defined semantics. A tool may also accept other values for the command argument, again with implementation-defined semantics. The FT committee considered whether the name "reset" for a control action would conflict with common use of that name for reset signals in designs. The committee asked whether it would be appropriate to rename the control action to "restart," and to rename the action currently called "restart" to "restore." The response from the VHPI tech team was that the current nomenclature is based on prior art, both in EDA and in other areas of computing such as operating systems and fault-tolerant systems. Furthermore, a number of existing simulators for VHDL and other languages use the current terminology. Hence, a renaming as suggested would cause more confusion and incompatibility. An approach to meeting the requirements of this proposal, proposed by the VHPI tech team, is to simply provide a VHDL binding to the vhpi_control function. This could be done by defining a package in library STD as follows: package VHPI is constant VHPISTOP : INTEGER := 0; constant VHPIFINISH : INTEGER := 1; constant VHPIRESET : INTEGER := 2; constant VHPISUCCESS : INTEGER := 0; constant VHPIFAILURE : INTEGER := 1; function VHPI_CONTROL ( COMMAND : INTEGER ) RETURN INTEGER; attribute FOREIGN of VHPI_CONTROL[INTEGER return INTEGER]: FUNCTION is "VHPIDIRECT null vhpi_control"; end package VHPI; package body VHPI is function VHPI_CONTROL ( COMMAND : INTEGER ) RETURN INTEGER is begin report "VHPI_CONTROL is not supported by this simulator"; return VHPIFAILURE; end function VHPI_CONTROL; end package body VHPI; The specification of the vhpi_control function for the three defined control actions is that, if no further arguments are provided beyond the command argument, an implementation-defined default action occurs. The advantages of providing a binding in this way are that - The semantics are defined by the VHPI specification. - The names do not conflict with common names used in models. - The mechanism allows for a VHDL model to invoke further control actions that might be defined by an implementation, provided those actions do not require further arguments or define default actions in the case of no further arguments being provided. - The package may be extended with futher bindings to other VHPI functions and capabilities where appropriate. The disadvantages are that - A tool is not required to provide VHPI functionality, but may wish to provide the simulation control features required in this proposal. - The vhpi_control function uses C varargs as the means of providing further arguments for specific control actions, such as message strings for stop and finish actions. VHDL does not provide a corresponding parameter passing mechanism that can be used in a binding. An alternative approach to meeting the requirements of the proposal is to provide procedures for specific control actions in a separate package. This package ultimately could be extended to provided further interfaces to the host environment, for example, access to command-line arguements and environment variables. The proposal includes a reset action that could be invoked by a VHDL description. When execution returns to time zero, it would execute again just as it had before. In the context of a VHPI program, where callbacks can affect the external environment of a VHDL description, a reset action is useful. However, is is not likely that a reset action would be useful when invoked by a VHDL description that cannot affect its external environment. Hence, it will not be considered further in this analysis. An environment package declaration defining operations for stop and finish actions, defined in library IEEE, is package ENV is procedure STOP ( STATUS: INTEGER ); procedure FINISH ( STATUS: INTEGER ); end package ENV; The STOP procedure would cause the host simulator to temporarily stop execution in such a way that it can be resumed from the point at which it stopped. The FINISH procedure would cause the host simulator to terminate simulation. It would be an error for execution to return to the VHDL description after a call to the FINISH procedure. For both procedures, the value of the STATUS parameter can be used in an implementation defined manner by the host simulator. For example, it may be provided to a simulation control script for use in determining what external control actions to perform. Resolution: ---------------------------- Specify inclusion of package ENV in library IEEE as described in the analysis.