VHDL Issue Number: 1115 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Should subtype and constraint checks really be made when the driver takes on the value of a signal? Related Issues: IR0034 Relevant LRM Sections: 1993 LRM 12.6.2, 8.4.1 Key Words and Phrases: signal assignment, subtype check, constraint check Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1995/06/21 Author of Submission: Shankha S. Mitra Author's Affiliation: Synopsys, Inc. Author's Post Address: 700 E. Middlefield Rd. Mountain View, CA 94043-4033. Author's Phone Number: 415.528.4795 Author's Fax Number: 415.694.4115 Author's Net Address: shankha@synopsys.com ----------------------- Date Analyzed: 1995/08/12 Author of Analysis: Clive R. Charlwood Revision Number: $Revision: 1.2 $ Date Last Revised: $Date: 1995/08/12 18:02:32 $ Description of Problem ---------------------- When is the appropriate time to perform subtype and constraint checks on a signal assignment at run-time? Both VHDL-1987 and VHDL-1993 state that such checks must be made when the signal is updated. Instead it seems more useful to perform such checks when a new transaction is added to the driver of the signal. Both VHDL-1987 and -1993 require subtype and constraint checks to be performed when the driving and effective values are computed (see 12.6.2 in either LRM). VHDL-1987 says nothing about making such checks at the time a transaction is added to the driver; VHDL-1993 specifically forbids checks at that time (see 1993 LRM 8.4.1 note 5). An update of the signal's value does not seem to be the appropriate time to perform subtype and constraint checks for various reasons (in no particular order): 1. Subtype and constraint violations may sometimes go undetected in the presence of conversion functions, type conversion functions, and resolution functions, thus resulting in erroneous designs, 2. Violations are not detected and reported as soon as possible, and 3. Better optimized code can be produced if such checks were made when a new transaction is added to the driver rather than when the signal's value is updated. For example, the space taken to store signal values in the driver can be optimized if one can guarantee that the checks are made early. The current rationale seems to evolve from the problem of doing subtype checks on signal parameters in procedures (see IR0034). Since the subtype of the actual signal is not known, range checks cannot be performed when assignments are made to the signal parameter. Thus such checks are postponed till the driver takes on the value. However this seems to be a weak reason to postpone subtype checks on all signals till the signal is updated. What is the intent of the LRM in this regard? Proposed Resolution ------------------- Change the LRM to perform subtype/constraint checks when transactions are added to the driver of a signal rather than performing them when the driver takes on the value. (Subtype/constraint checks would still need to be done on the effective value.) The problems pertaining to subtype/constraint checks on assignments to signal parameters should be resolved in some other fashion. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD