The ballot comments are included below. > Malcolm Airst (Affirmative) > ------------ > 1. References should be made to the approved ANSI VME64 specification > The document should be changed to add the 64-bit option. It would not be a good idea to expand the scope of 1275.3 to embrace VME64: the 32-bit VME Bus specification and the 64-bit VME64 specification are sufficiently different that their Open Firmware specifications should be treated separately. Recent changes, concerning the matter of which standards organization has ownership of the VME Bus specification, further militate in favor of making the VME64/Open-Firmware specification the focus of another work. The last three sentences in the Overview, page 1 lines 6-10, are intended to be an adequate disclaimer to the effect that the 64-bit version of the VME specification is not addressed in this document. Nonetheless, the "Overview" section and reference [2] have been changed, to reflect the current situation, as follows: Last two sentences in the Overview: Extensions to the 32-bit IEEE standard introduced in the newer VME64 bus standard, ANSI/VITA-1 1995, which specifies a maximum address space of 64 bits, are outside the scope of this standard. All references to VME or to VMEbus within this standard refer specifically to the older ANSI/IEEE 1014-1987 VME Standard specification. Reference [2], add: This specification has been withdrawn as an IEEE standard, but can still be obtained from VITA, 10229 N. Scottsdale Road, Suite B, Scottsdale, AZ 85253-1437, USA; Telephone: (602) 951-8866. > Greg Buzzard (Negative) > ------------ > > 1. Define the significance of "*" on the line 64 of page 1. > > 2. The sentence beginning on the line 46 of page 2 should be moved > to the following paragraph, or should be expanded to apply to both > phys.lo and phys.hi. (1) The heading for Section 3 is changed from "Terms", to "Terms and Conventions" and Section 3.7 is added, to read as follows: 3.7. Bus Line names and abbreviations, when given, follow the conventions of Reference [2]. An asterisk (*) at the end of a Bus Line name indicates that the line is "active low". (2) The reference to "phys.lo" in the sentence beginning on line 46 of page 2 is a typographical error and should read "phys.hi". This will render the sentence in question correct and in the proper place. This was caught by other respondents, as well, and has been corrected in the new revision. > Kim Clohessy (Affirmative) > ----------- > > 1. Section 3 Terms > > These terms are very confusing and in my opinion defy > understanding. Can we have more hints copied over from the parent > document? > > 2. Page 2 of 10; line 31 should refer to section 2, not 3. > > 3. Page 2 line 23 use the standard names for these signals BBSY and > BCLR and maybe BR[0..3]. > > 4. Page 2 line 41. Is "reg" well defined (before usage)? > > 5. Page 2 line 46. Should this refer to phys.hi instead of phys.lo ? > > 6. Page 3 line 20. Is "interrupt" well defined (before usage)? > > 7. Page 4 line 62. What is the (--okay?) signifying? > > 8. Page 7 para starting at line 20. This section implies that the > vectors or status/IDs are fixed for each level. Many I/O boards > provide a vector based on the current state or results of an > operation, or even a priority of a response. Does this mean this > methods are not permitted? (1) Since the Supplements to 1275 lose most of their meaning outside of the context of the Core specification, it is a reasonably safe assumption that the reader of any of them will also have access to the Core. For this reason, none of the Supplements does more than make reference to the Core terminology to describe terms already defined therein. The same applies to this Supplement. (2) Please recheck your edition of the VME Standard. I believe you might have been looking at the newer 64-bit VME specification, which is a superset of older ANSI/IEEE 1014-1987 VME Standard specification, to which this standard specifically refers. (3) The standard _names_ for these signals are spelled out in full in the VME Standard, on page 125, and are copied correctly in P1275.3 Draft 8. The abbreviations, as shown in the VME Standard, are: BBSY* BCLR* and BR0* BR1* BR2* and BR3* (the * indicates "active-low"). These abbreviations have been added, parenthetically, to the line in question. (4) The "reg" property is well defined in the 1275 Core Standard. However, the word "format" in that line was a typographical error and has been removed. (5) Yes this should. This will be corrected in the next revision. (6) The standard interrupts property is well defined in the 1275 Core. (7) The function returns a boolean flag, for which the TRUE value indicates that the operation proceded successfully (i.e., "went okay"). This notation is described near the beginning of Annex A in the 1275 Core Standard. (8) If you are asking about boards that are capable of returning several different vectors or status/IDs for a given interrupt level, this is not a problem, nor does it conflict with any assumptions. As is al- ready stated in the specification, the device node corresponding to such a board would simply include, in its interrupts property, an entry for each level and vector combination the board might generate. To extend the example given, suppose a device generates VMEbus Inter- rupt Request level 3 and under some circumstances asserts the vector c0 during the Interrupt Acknowledge cycle, and under other circumstan- ces asserts the vector f3. The interrupts property would include the pair 3,c0 and the pair 3,f3 in its list. If, on the other hand, you are asking about boards whose VMEbus Inter- rupt Request levels and vectors or status/IDs are programmable by the O/S, then this, too, is not a problem. The device node firmware, at boot time, would list the level and vector combinations that apply to the board's state at the time the O/S is first started up, and the O/S would bear the responsibility of keeping track of the subsequent state of the programmable functions of the device. > Michael Roby (Abstain) > ------------- > I abstain because I do not have a copy of the base standard. However, > I have read what is contained in the supplement and do not find any > areas of concern. Therefore, if my abstention poses any balloting > problems I could easily be swayed to the affirmative. Thank you. It appears that balloting for the VME Supplement will need to go into recirculation. Your support at that time will be appreciated. > David Paktor (Affirmative) > ------------ > > Typo: Page 2, line 46: "phys.lo" should be "phys.hi". > > Clarification: Page 2, line 63: Prepend the words "For input," at the > beginning of the sentence. > > Typo: Page 9, line 60: "The an" should be "an". You're absolutely right. I couldn't agree more. The above changes are incorporated into the new revision of the document.