Minutes of ISAC meeting held via telecom on 01 July 2004. Present: Peter Ashenden, Jim Lewis, Deepak Pant, Chuck Swart, Ajay Varikat TOPIC: Web based database for ISAC issues: After some discussion it was agreed that two appropriate tools for this were Bugzilla and Mantis. An example of similar Bugzilla use for the Rosetta standard can be found at: bugzilla.ittc.ku.edu/index.cgi A Mantis version for system verilog is at eda.org/svdb ACTION: Peter and Chuck will examine these tools (others are welcome to look at them also.) Potential repository websites are eda.org and Peter's website. ACTION: Chuck will look into viability of eda.org. TOPIC: Fast Track issues Since we are all already involved in studying fast track issues, it was agreed that these would not take first priority in the ISAC meeting. TOPIC: IR2027 When loop index is static, drivers are created for each element of array. This is the well-known problem: for I in 1 to 3 loop sig(i) <= ... end loop Drivers are created for all of sig rather than for the "obvious" values of sig(1 to 3). It was noted that the example could be rewritten using slices to avoid the issue. It was suggested that the VHDL FAQ be updated to deal with cases like this. It was also suggested that some form of knowledge base be developed to help users find solutions to problems like this. Although the example might not be the best, there may well be similar problems which don't have an easy way to. It was suggested that Jim use his presence on c.l.vhdl to query the newsgroup about this, but... it was decided that this is an issue for the Modeling and Productivity Group and not an ISAC issue. ACTION: Chuck communicates this issue to M&P chair (Jim Lewis) TOPIC: IR2028 Clarify Simulation Cycle The example has mistakes. It should read: "The problem can be illustrated by considering an in mode port S1, which is associated with S2'Stable. S1(an explicit signal) cannot be updated until S2'Stable is updated, which in turn cannot be updated until S2 is updated." ACTION: Chuck will edit the IR to reflect this. The author suggests using the concept of nets to combine and simplify some steps in the simulation cycle. It was pointed out that this issue might be related to a fast track issue (FT11 Signal expressions in port maps.) Discussion of this relationship pointed out that the semantics of FT11 will be cleaner if there is a delta delay between the evaluating the signal expression and propagating value to the corresponding port in the map. Comment by chairmen: These are the kinds of fat track issues the ISAC needs to look into. Peter pointed out the the simulation cycle will be complicated by ongoing VHPI work. ACTION: Peter to reexamine this issue after VHPI work in this area becomes stable. TOPIC: IR 2029 Non-relevant words and paragraph. The IR points out that the LRM often redundantly forbids certain forms of composites, when they are already illegal. The author also indicates a second issue where the LRM refers to the name of a physical type (all physical types are anonymous) ACTION: Ajay will write up the analysis of the IR. ACTION: Chuck will issue a new IR as a repository for "low-level" semantic issues such as incorrect references to types, subtypes, base types, etc. as described by the second issue in the IR. TOPIC: IR 2030 What signature does a method have? The author asks if the signature of a protected method contains the method type as a parameter. (A common form of implementing methods is to pass and object reference as a hidden parameter.) Peter responds that method attributes are consistent without this parameter. ACTION: Peter will write this up. TOPIC: IR 2031 "mod" function needed for TIME There was general agreement that this is a good idea. Issues: (a) The type of the second argument needs to be INTEGER instead of TIME for unit consistency. (b) A quick analysis indicates that the resolution limit for time does not cause any problems. ACTION: Deepak will write this up. TOPIC: IR 2032 Function "now" is not pure The author claims that the VHDL2000 decision to make NOW a pure function breaks staticness, prevents optimizations, and is no longer needed to support VITAL. There is general agreement on this issue, but some concern about possible problems with user code written under the assumption that NOW is pure. It was pointed out that several vendor have not yet made NOW pure and they have not had problems with customer code. It is not known if any implementations have made NOW pure. The general issue of getting user feedback was raised. One possible source for getting information is comp.lang.vhdl, which Jim is active in. The decision was made to proceed without seeking more user feedback. ACTION: Ajay to write up. TOPIC: IR 2033 Incremental operator and auto subtype boundery(sic) wrap The author would like the VHDL tools to perform actions like modular arithmetic in certain cases. There could also be a need for a form of saturating arithmetic. One possible solution is for the user to define his own integer type and overload the desired arithmetic operations. In any event this problem is not an ISAC issue. It either belongs to the Data Types and Abstraction group or to the Modeling and Productivity group (depending on whether or not changes to the type system are needed to achieve this goal.) ACTION: Chuck to contact Steve Bailey (VASG chair) to assign to appropriate group. TOPIC: Peter Ashenden paper on Generics on Packages and Subprograms. This paper can be found at: http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/dta_type_genericity.pdf This functionality is critical for VHDL200X fast track success: ACTION: All are to review this. TOPIC: FT22 Composite expressions being locally static. Consider the following code fragment, where G is an integer generic: subtype s1 is integer range G to G+3; constant c1:s1 := 2; According to the LRM c1 is locally static: Its value is known at analysis time although whether or not this value lies within the subtype range can't be checked until elaboration. John Ries has been looking into LRM changes for making composite expressions locally static. It is pretty clear that, given an array arr, if arr(1 to 3) is going to be locally static, then the index subtype of arr must be locally static, and the element subtype must also be locally static if it is itself a composite. The element subtype should probably be locally static in all cases, scalar and composite. A clean way to specify this is to require that all locally static expressions have locally static subtypes (where appropriate). From a pragmatic point of view the suggested difference is that now for a locally static expression you know the value at analysis, but you don't necessarily know other information. Under the proposal, if an expression is locally static, everything about the expression is locally static. ACTION: All think about whether or not this is a good idea.