Fast-Track Meeting 6-28-2004 Attendance Steve Bailey Jim Lewis Deepak Pant Ajay Varikat John Ries Chuck Swart Eric Marschner Dave Bishop Peter Ashenden Purpose of meeting was to review fast track proposes. Determine if they are done. If they are not done what needs to be done to complete the proposal. FT3 Array/Scalar logic operations Eric initialed a discussion on the completeness of change proposals. Each LCS needs to do a section by section review to ensure completeness in determining a features impact. This is what previous revisions used as a standard for LCS proposals. Current LCS proposal are not at this level of detail. It is expected the the LRM editor will to a section-by-section review against all change proposals to develop complete LCS. Status of proposal: DONE FT4 Min, Max There is an issue on visibility of min with physical type of time. Long term we may want to look at allowing overloading of physical type units but not for fast track. Some discussion on what name to use instead of min. Conclusion was to use minimum and maximum. There was a proposal to relax identifier rules to allow for identifiers with trailing _ and some non-alpha numeric characters like !. This may be needed for PSL but not for this proposal.Action Item was to change proposal to use minimum and maximum, Dave Bishop. Status of proposal: DONE after name change. FT13 STOP/FINISH/RESET Dave has functions currently as an addition to the standard package. Previous meetings suggested having a separate package for these functions and any addition VHPI functions made available to the language like PSL access function. The proposed package is VHPI in std. There was significant discussion on the conflicts caused by having a function name RESET with signals named RESET. There was discussion if RESET is the correct function name and if RESTART would be better name. Use of RESET causes conflicts with VHPI itself. RESTART is used in the VHPI to handle loading of a previous save simulation checkpoint. Action item for Peter is to investigate if the VHPI can change this functions names so RESTART set the simulator to time 0. RESUME or RESTORE for loading a checkpoint. Eric brought up a previous proposal for the 93 revision to have an explicit method to reset a process back to it's initial state. It is not clear if this functionality is needed. Because of conflict on RESET function. The proposal is to remove the RESET function pending what Peter finds out. Status of proposal: DONE after specify function are in package std.VHPI and removal RESET from package FT22 Changes to locally static expressions. Chuck pointed out there maybe an issue with subtypes. Current rules may not require that expression subtype be locally static for the expression to be locally static. For scalar values this isn't a big deal but for arrays it is. Eric pointed out we need to check LRM for places that locally static expression are need to insure that there is no assumption that the expression is a scalar value. Action item John R. to investigate the locally static subtype issue. Status of proposal: NOT DONE, update proposal and review FT23 IEEE package functions locally static. Discussion how to specify which function can be used in locally static expressions. Eric felt we should have a consistent rule like all functions in library IEEE packages that are pure should be allowed. The LRM would then have a section most likely in section 14 that details what packages are in library IEEE. This would make the real functions in MATH_REAL locally static. Since the bodies are non-normative this would lead to different analyzer results. The group could not see any pressing need for complicated real expressions to be locally static. Therefore the package MATH_REAL's functions need not be consider for functions to be used as locally static. For fast track is was determined that only the pure functions in the packages std_logic_1164, numeric_std, numeric_bit and numeric_unsigned, would allowed in locally static expressions. Action item, update the list of packages and add the restriction that the functions must be pure. John Ries. Action Item for Dave Bishop is determine if we need a numeric_bit_unsigned package. Status of proposal: NOT DONE, update proposal and review. Side comment: David is looking for the 1164 test vectors. Anyone have them? FT26 Action Item: Chuck to research if there is an impact of the LCS on type conversions and resolution functions. Note 2 in clause 8.12 needs to be removed or rewritten. Status of proposal: DONE , assuming Chuck's action item results in nothing. Other business Eric brought up an issue of visibility of type enumeration if only a the type is made visible. Is this being address? No current proposal addresses this issue.. Steve says this doesn't appear to be an issue with current users. Agreement that this is not really needed for FT but if Eric wants to write it up and the proposal is non-controversial it could go into FT. But most likely this will not happen. We didn't finish the issue list for this meeting. We may have to schedule more meetings.