From mench@mercury.interpath.net Fri May 6 10:02:20 1994 To: isacsc@vhdl.org Cc: petera@cs.adelaide.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit IEEE DASC VASG ISAC Meeting Minutes 5 May 1994 Claremont Hotel, Oakland CA The ISAC wishes to express its thanks to Al Dewey for arranging the space for this meeting. Attendees --------- Clive Charlwood (Chair), Synopsys Peter Ashenden, University of Adelaide Daniel Barclay, Compass Design Automation Oz Levia, Synopsys Paul Menchini, Menchini & Associates Bill Paulsen, Viewlogic Jacques Rouillard, ESIM Chuck Swart, Mentor Graphics Alex Zamfirescu, Intergraph Electronics Reflector/Repository Status --------------------------- The repository is set up--thanks to Alex, Oz, and Randy Harr. The repository is in /vi/isac. The directory IRs contains the '87 IRs; the directory IRs1k contains the new IRs. Clive has not yet implemented the number allocation mechanism--that is coming. IR instructions and template are in the IRs1k directory. The RCS tools are in /usr/local/bin. The directory ~clive/man1 contains RCS man pages. (They may also be installed in the system man pages....) No on-line LRMs are there yet. The LRMs will go into /vi/isac/LRMs/*. A question was raised, "Should IRs should be publicly accessible? If so, which ones? The old ones? The approved ones? All of them?" After discussion it was decided to allow read access to all IRs by the world; that is, anyone with legal access to the VI machine. Finalize Next Meeting Details ----------------------------- Clive made a plea to do your work! The next meeting will be in Asheville, NC at the Grove Park Inn from 28-30 July 1994. A block of rooms has been reserved starting the evening of 27 July. Reservations must be made by 10 June. Team building will take place on 28 July--a river rafting trip will be scheduled. ISAC work will take place on 29-30 July. The ISAC will not meet in conjunction with the EuroDAC in Grenoble in September. Instead, a VASG meeting will take place that will include a plea for European membership. IR 1083 (Endfile pure function - Andy) IR 1080 (Operators and subprograms - Paul) IR 1079 (Concatenation Typos - Al) ------------------------------------------ None of these three has been done. These will be presented at the VASG meeting at DAC. So do the IRs, put it in the repository (see below), and bring slides so that you're prepared to present at the DAC. IR 1084 (Rebinding of Generics - Daniel) ---------------------------------------- This IR has not been analyzed. Current Issues -------------- 1008 - Std.Standard.Now not completely defined 1009 - Postponed processes may be executed twice during initialization 1028 - "work.E" vs. "E" in architectures and configurations 1033 - "type T is access T;" 1046 - Resolved signal definition 1053 - Intent of 'Last_Value 1067 - Recursive configuration 1078 - Returning null in TextIO 1088 - Logical-to-physical library mapping (new-Jacques) 1089 - Visibility of components when "used" (no IR yet written-Chuck) ???? - Assignment to an unconstrained subprogram parameter with "others". Most important: 1008, 1053, 1088, 1089, ???? (others) Of lesser importance: More information needed: 1089: Consider package P is component E1 is ... end component; component E2 is ... end package P; entity E1 is ...; architecture A of E1 is ... entity E2 is ...; architecture A of E2 is ... ... use Work.all; use P.all; entity Top is end; architecture Structure of Top is -- default binding doesn't work in here! end architecture Structure; There is a way around this. Don't "use P.all;" instead, instantiate P.. However, many users feel that the above case should work; moreover, many tools have "gone their own way" to make something similar to this example work. This discussion led to a discussion of whether this issue is within the ISAC charter. The LRM rules are clear, but may be insufficient. The problem is that various (some suggest at least 5!) implementations have extended the language in incompatible ways. The suggestion is that we take the general, charter issue to the VASG for clarification. We will then consider this specific issue if it is within our charter. Chuck will write this up as IR 1089. 1053 ---- The atomicity of 'Last_Value in VHDL'87 was at the scalar level. Consequently, 'Last_Value of a composite might never have been a value of the composite. Consequently, the definition of changed in VHDL'93. Hence, S'Last_Value(1) /= S(1)'Last_Value, as it was in VHDL'87. At the last meeting, it was postulated that the new definition was either unimplementable or posed an unacceptable implementation burden. That no longer appears to be the case. Daniel will write this up and present at the DAC. 1008 ---- The value of Std.Standard.Now is undefined during elaboration. There are three ways to handle this problem: 1. Now should return 0 fs during elaboration. 2. Now should return Time'Base'Low during elaboration. 3. Make it explicitly illegal to call Now during elaboration. It might then be useful to have a predicate that returns one Boolean value when it is called during elaboration and the other when it is called after elaboration. Daniel volunteered to analyze these possibilities and bring it to the next meeting. A vote on the above possibilities was taken: (4, 2, 1, 2 (absentions)). It was also noted that the definition of Now is rather weak. Perhaps this should be addressed in the next LRM update. 1088 ---- Consider: library L1, L2; : : (L1.P.S, L2.P.S) <= ...; The LRM says that the signals in the aggregate must be distinct. But is there a way to ensure that the libraries L1 and L2 are distinct? The language doesn't seem to speak to this problem. It was noted that at least one implementation does not allow multiple library logical names (other than Work) to refer to the same physical library. A subsidiary problem might be whether "architecture A of Foo.E is ...;" is legal. It appears to be, as long as Work and Foo denote the same library. There appear to be two issues: 1. Is it legal to have multiple library logical names denoting the same design library (other than work)? It appears to be implementation dependent. 2. If an implementation does support multiple library logical names denoting the same design library, then examples of the above code must be unambiguiously legal or illegal. For example, if L1 and L2 refer to the same design library, then the above example is illegal. It was noted that this implementation dependence reduces portability. The ISAC voted on these issues, as follows: 5 for, 2 against, 1 abstention. Consensus is in favor of these statements. There was some discussion as to whether implementations should be required to support multiple library logical names denoting the same design library. No conclusion was reached. Some members will work this issue off-line. It will be brought up at a future meeting. Respectfully submitted, Paul Menchini