IEEE 1394b Working Group General Meeting, Holiday Inn, Monterey Bay, Santa Cruz, CA, Tuesday, February 10, 1998 Chairman: David Wooten, david.wooten@compaq.com, (281)518-2731 Vice Chairman: Michael D. Johas-Teener, mike@zayante.com, (408)461-4901 Editor: Eric Hannah, ehannah@mipos2.sc.intel.com, (408)765-4441 Secretary: Richard Churchill, richard.churchill@compaq.com, (281)514-6984 Reflector: p1394b@zayante.com Home Page: http://www.zayante.com/p1394b/ FTP Site: MS IE address -- ftp://ftp.zayante.com/p1394b/ Netscape workaround -- ftp://ftp.zayante.com/FTP/pub/p1394b/ 1. Introductions 2. Review of agenda 3. Minutes of previous meeting 4. PAR Status 5. Procedures 5.1 Voting 5.2 Price/Pricing 5.3 Call for Patents 6. Task Group Reports 7. Extra Items 7.1 Multi-port and slow link speed mapping -- Peng Zhang 7.2 8. Future Meeting Dates 8.1 March 17 & 18, Tempe, Arizona; Intel (Steve Bard) 8.2 April 27 & 28, Newport Beach, California; Rockwell (Brad Saunders) 8.3 At Risk! June 9 & 10, St. Petersburg, Florida; AMP (Chuck Brill) 8.4 July 13 & 14, Bath, UK; ST/HP/Xyratex (Whitby-Strevens/Coles/Instone) 8.5 August 18 & 19, Portland, Oregon; SSI (Steve Finch) 8.6 At Risk! September 14 & 15, St. Petersburg, Florida; AMP (Chuck Brill) 8.7 October 19 & 20, Maui, Hawaii; Lucent (Farrukh Latif) 8.8 December ?? & ??, TBD 9. Adjournment Meeting came to order at 8:05 AM ============================================================================= 1. Introductions Introductions were made around the room. 2. Review of agenda The agenda was presented and accepted without objection 3. Minutes of previous meeting The minutes of the previous meeting were approved without objection 4. PAR Status We still have an approved PAR. 5. Procedures 5.1 Voting Voting rights are reserved for those who are recorded as present at the current meeting, and who attended at least one of the immediate past formal meetings. 5.2 Price/Pricing The pricing of anything may not be discussed except in the most general terms, such as "A will likely cost more then B." The current prices of things may be discussed, but not in the context of future pricing. Any discussion of pricing, particularly of future pricing, may violate U.S. anti-trust law. 5.3 Call for Patents All parties holding any intellectual property rights to matters discussed here, or proposed for inclusion in the p1394b draft standard are herewith called upon to give proper notice of those intelletual property rights to this group and to the appropriate IEEE office. Failure to so notify this committee and the IEEE may result in loss of some or all property rights, or in removal of such material from the draft standard. 6. Task Group Reports 6.1 S100 Task Group Report - Shuntaro Yamazaki Report of 1394b S100 meeting on Feb. 9, 1998 - Connector selection for POF and HPCF PMD - 10 minutes presentation for each candidate - Number of eligible voters: 70 (Voting right was given to those who attended either January 6th meeting in Houston, or November 26th meeting in Tokyo.) - Voting method: - the same as S800 connector selection process - eliminate those who get the least votes with each round - four rounds of Voting Voting Results R1 R2 R3 R4 PN 16 16 25 40 FJ 10 10 -- -- SMI 17 22 22 25 LC 4 -- -- -- OMJ 20 19 20 -- Abstained 3 2 2 2 MOTION (in S100 group) S100 sub TG recommended the PN connector to the parent p1394b committee as our selection of a POF/HPCF connector to be drawn in the section 8.1 of 1394b draft document. - Moved by: Richard Churchill - seconded by: Don Chambers As there were no objections and significant support, the motion carried. The S100 committee now passes from service, having completed its task. 6.2 Copperheads - Max Bassler Agenda was REview and approve .. ... January Minutes Need for more system makers to attend Scope of work approved Request for cable detect pin in 6 ckt I/O added to scope Keying for Beta, Bi-lingual, etc. issue for 1394b WG Chair/secretary to create physical layer chart - informational Al Kelly and bob Gannon to propose test methodology for bulk cable test [Do we need cable keying? Wooten - You can't exclude cables until you know what is at the other end, so keying of the connector is problematic. Is this logical or physical? Physical. Who advocated these? Moved that both keying and detect pins be removed from the copperhead effort. Moved by ??? seconded by Bill Northey. Moved to divide by ???, seconded by ???. [Chairman pointed out that this is out of order, since this is a problem for the task group. We don't know what we would be solving. Task group needs to look at this, then come back. Colin - We had an input from a mobile PC vendor, in order to avoid doing our toning/detection, in order to conserve power. There might be an AC coupled component that can't be detected by the standard mechanism. Opinions varied. Eric - if you tone down a cable that is not connected at the other end, you may be radiating. Also, keying is ugly, but we need positive control of what we are radiating. Wooten - Upstarts need to clarify what they are after here. Opticals may need something to detect presence of a cable. If you move the problem to opticals, and key there, you may simplify the problem. Still need to figure out how to detect the fact that the cable is adequate to the connection. How do we determine the cable is adequate before we start high-speed Beta signaling? Keying is harder than detect. May be best to use a high-speed cable detect pin to differentiate. Would Colin like to take a Action Item to clarify this? Max - How about taking the problem back to the Copperheads. How do we deal with cable- speed mismatch?] [Group will develop a chart of all connectors (fiber and copper) for the broader group.] January minutes (cont.) Chuck Brill to propose an EMI/RFI test for review Proposal to have off-cycle meeting passed with the presence ... Jan. Minutes (cont.) Presentations - Al Kelly - Bill Northey Agenda for Feb. Presentations planned - Dave Brunker - Cable assembly testing for 1394a, Annex B - Al Kelly and bob Gannon - bulk cable testing methodology (reflector discussion expected) - Bill Northey - Proposed changes to 1394-1995 connector 6.3 P1394b UTP5 task group - Colin Whitby-Strevens UTP5 agenda 1. Welcome, intros, approval of agenda 2. Presentations - simulation meolleing - Eric Hannah - 50m looks OK with fixed equalizer, but not 100m - more modelling promised - fixed equaliser measurements - Alistair Coles - 50m looks OK with fixed equalizer 3. Review of new draft (31 Jan, 1998) 4. Open Issues - Jitter budget - Receiver sensitivity (may help reach by reducing it) - Launch power (may help EMI by reducing it) - How to spec the receiver at the bulkhead connector when the equalizer comes after it - Is an eye diagram helpful? 5. Future Work 6. Any other business [Wooten - Is anyone thinking of a passive device at the UTP5 rj-45, mated to a six-pin, and thence to the device at the other end of the 1394 cable? How does the phy know to operate at only s100 in this case? Wooten - Eric wants you to work on that ... May end up with active lump, and not a passive one.] 6.4 Upstarts - Colin Whitby-Strevens Upstarts - Feb 98 - Report 1. Homework Assignments 1. for the optical transceiver folks to provide input as to a. the passband cut-off frequency b. the signal detect latency - on the assumption that the transceiver operates fully powered all the time - not yet done - but will now evaluate the Tone Proposal (see below) 2. for the PHY designers to provide input as to the power and imple- mentation costs of sloppy and reasonably accurately controlled tones - conclusion - use a crystal oscillator 3. for the system designers to provide input as to the minimum dis- connect/reconnect cycle time which must be detected - human relative real-time 2. Introduction to and review of V3 (based on p1394a D1.4) - modifications are cleaner than previous version - startup now takes note of a new "plug_present" bit - problems identified with current algorithm, but solutions believed to exist - Modified version to be placed on web site, and incorporated into next draft 3. Tone proposal - Accepted in principle (see homework #1 above) - requires "signal detect" to be incorporated into electical spec 4. Speed negotiation - nothing yet done, but will base this on the tone mechanism [Suggested that we use some "morse code" embedded in the toning scheme. Wooten - Are the optical connectors going to be able to handle this? Well, what is the system requirement? We can deal with it, if you pro- vide the usage models ... Do we have a version of an optical connector that generates a tone, and one that's not? Do we need to be able to turn off a fiber signal if we have nothing connected at the other end? If you need a 4- or 6-pin cable, you don't have presence detect, but for a fiber, we don't have an EMI problem. Optical transceivers will be powered all the time ... May wish to have a detect-pin for the optical stuff to prevent the ~ 1 sec. powerup period. Are we trying to solve a problem that isn't really a problem? If you have a portable device with an optical port, ... Wooten - I can solve that! Don't put an op- tical connector on it! How about just saying that portable devices don't tone unless THEY want to use the connection? This creates a user problem, since, if the user is trying to control the portable device remotely, the portable device will not be able to detect that it is supposed to be listening ... How about just shorting through the plug to detect a plug present? Resume causes some problems. How to detect a resume if you have powered down the optical transceiver? Care must be taken in the style of the solution, as you may force some unpleasant requirements into the standard and devices ... We have added a flag to the start-up algorithm, without specifying how that flag got set ... You still don't necessarily know that there is anything at the other end of the cable ... We prefer that we be able to use the standard plug and receptacle. For special applications, we need the connector folks to show us what might be done for detection ... Need to come to some conclusion to decide whether to retain this in the state machines. Micro-switch should work just fine, since we already have things that use these ... We may restrict this to the receptacle, with nothing in the plug ...] P1394b upstarts - V3 overview - Connectivity Management now based on P1394a D1.4 - PJ generously provided the port state machine and C code sources - new version (V3) dated Feb 8th, 1998 - Essence of the mechanism is unchanged (eager-Beta, etc.) - One consistent change in port state machine and code - replace use of bias[i] by receive_ok[i] - In DS_mode, means bias[i] - In Beta_mode, means seen a continuous incoming signal (not just the occasional connect tone) - in essence, means that we can expect to receive full signaling - keep the term bias to mean p1394a TpBias - No other change to the port state machine - most of the "actions" C code is unchanged as well - Needed to find a home in our model for the p1394a continuously running PHY level (i.e. across all ports) machine - really deals with the PMD, but has to be placed "above" the port - most changes take place in this code - deals with determination of Beta mode operation - maintains the connected[i] flag in Beta mode p1394b upstarts - V3 notes and issues - New flag "disconnected[i]" - says that an external mechanism has determined that there is no physical connection - so don't even think about toning, etc. - Unholy mix of shared variables and service calls - no attempt so far to clean this up - New code in 'resume actions' get the Beta Synchronization going - toning when and only when p1394a says connect_detect_valid[i] - i.e. not during normal signaling - Relies on "signal detect" - suggest starting with the Gigabit Ethernet spec for this - does NOT imply signal quality, reception of 8B/10B, etc. - Disabled port issue - toning (AC coupling) cannot be used to track connection status - Timing constants TBD - Probably contains lots of bugs - Details of speed capability notification not done P1394b upstarts - tone proposal - 1 - Toning should be very low power, - the main time that toning is required is during the time that a port is suspended. - Other requirements are:- - Must be capable of transmission through an optical transceiver (assumed cut-off frequency of 100 MHz, full swing PECL inputs); - Must be capable of transmission over POF and UTP (maximum frequencies of the order of 100-200 MHz). - Must be capable of overcoming the start-up latencies of an optical transceiver (of the order of 500 microseconds); - Must be capable of detecting the transition from physical connection to physical disconnection or vice-versa in human-scale real-time (typically 50 milliseconds); Tone Proposal - 2 - open-loop transmission/reception of a regular tone. - reception indicates a connection, lack of a tone indicates no connection. - Transmit a "tone" every 34.133 milliseconds (122.8/2**23), - i.e. approx 30 tones a second. - tone comprises a signal of frequency 122.88 MHz - (S800 transmission rate / 4) - tone duration of 533.333 microseconds - (2**17 clocks of a 122.88 MHz clock). - for EMC reasons on UTP, it may be necessary to use a signal of half this frequency - it needs to be verified that this can pass through an optical transceiver sufficiently well to provide a signal detect at the far end. - previous proposals based on a "loose" clock are not considered further, - no significant power savings y using such a clock in place of a crystal oscillator. - transmitters are active for 1/256 of the time, - will not be consuming power otherwise - Signal detect circuit is used to detect that a valid signal is received - latched, and the latch sampled at appropriate intervals. The latch is reset after each sampling - indicates that a valid tone has been received since the last time a sample was taken. Tone proposal - signal detect - Based on Gigabit Ethernet Receive conditions SIGNAL_DETECT -----------------------------------+------------------------------------- Vinput Receiver < 200 mV pk-pk |FAIL -----------------------------------+------------------------------------- Other conditions |UNSPECIFIED Examples | 1) Receiving neither a tone nor a | non-8B/10B encoded data stream | 2) Other end of the link undergoing| power-on-reset (POR) transients | 3) 200 mV (p-p) < V input Receiver | < Minimum differential sensi- | tivity | 4) One of the differential lines is| open | -----------------------------------+------------------------------------- Receiving a tone or encoded 8B/10B |OK characters, AND Minimum differen- | tial sensitivity < Vinput Receiver | < Maximum differential input | -----------------------------------+------------------------------------- 6.5 B-port - Alistair Coles 1394b Port Task Group Agenda, Feb 9, 1998 ... first slide ... [Meeting started late, and will be continued later today] PHY detected end of packet error: bPHY - aLINK - 1394b PHY is capable of detecting some errors at teh end of packets that will not necessarily be detected by the LINK - This is due to the 8B/10B disparity rules - We do not have an agreement on a proposal for forwarding this infor- mation to a DS port (or to a 1394a PHY) - If we are satisfied that the probability of such an error is low enough, then we can ignore the information when forwarding the packet to a 1394a DS port for 1394a LINK 6.6 Standard Electrical - Eric Hannah Task Group Activities - Determine Beta mode biasing schemes and parameters - Develop specs. for connect/suspend/resume beta toning - Self-test modes - simple sanity check - exhaustive stress test - Develop system level modeling of signaling (Mike Teener has suggested using Copperhead reflector.) Beta DC biasing std Elec TG Feb 9, 1998 Block Level Diagram of Two PHYs connected by a 1394 cable *** diagram *** (problem: p1394b interfaces may be 1) DC coupled, 2) AC coupled, or 3) interfaced to some other circuit with unusual biasing features (e.g., electro-optics)) P1394a/b Interface circuit *** diagram *** (- push-pull curent source. Transmitter knows nothing of Voltage! - Should not move the common mode voltage!!! - Spec states 172mV-265mV differential output (w/load) - Presence of Speed Signal and VG currents set common mode range to 0.523V-2.525V. - TPB Transmitter specifies the port's minimum supply voltage.) [That's backwards ... Yes, but ...] Differential Driver Operation Operation of differential TX_Data and TX_Strobe drivers *** diagrams *** Common Mode Specification *** diagram *** *** table *** - TPA is the source of the common mode voltage. Due to differences in ground potential, TPB must be designed to function under an expanded common mode range. P1394a/b Interface Circuit *** diagram *** Beta DC Bias Assumptions - TpBias is disabled in beta mode and in startup mode - TPB (beta Transmitter) sets the common mode voltage - simpifies transmitter circuit design - most analog designers are more compfortable with large common mode variations on receivers than on transmitters - implication: - The receiver must tolerate a large common mode voltage input range due to ground shifts for DC coupling - The transmitter is a current steering device and needs at least 0.5 Volt on the output terminals to be in saturation - For AC coupled situation, the receiver must provide its own biasing - Optionally include a high impedance network to allow DC coupled systems to overdrive the receiver's self bias 3.3 Volt CMOS Proposal - Transmitter bias - transmitter provides bias - Vhigh = 2.1 V - Vcm = 1.4 - 1.7 V - Vlow = 1.0 V - Receiver bias - Receiver only provides bias for AC coupling - Vhigh = 2.6 V - Vcm = 0.9 - 2.1 V - Vlow = 0.5 V These numbers are necessary for bilingual operation 2.5 Volt CMOS Proposal - transmitter bias - transmitter provides bias - Vhigh - 1.6 V - Vcm = 0.9 1 1.2 V - Vlow = 0.5 V - Receiver bias - Receiver only provides bias for AC coupling - Vhigh = 2.1 V - Vcm = 0.4 1.7 V - Vlow = 0 V - These numbers assume eta mode only operation Task Group Input - TpBias may be turned on TPA while TPB is toning. Need for a corner case in the Upstarts state machine. - Make sure that the high impedance receiver bias network won't screw up speed code signaling. 6.7 p1394b Accelerations - Dave LaFollette Example Step 1 *** diagram *** - bus owner/supervisor/selector (BOSS) node 1 is sinding packet a to Node 3 - All upstream paths contain requests to the BOSS Example Step 2 *** diagram *** - BOSS node 1 completes packet A - packet A requires an ACK - No grant is sent ... Example Step 3 *** diagram *** - node 3 becomes BOSS by sending ACK ... ... Example Step 4 *** diagram *** - node 3 BOSS grants highest priority request - sends requests on all ports Example Step 5 *** diagram *** - Node 4 opts to calim grant - becomes BOSS - Sends Packet B - Other nodes forward requests toward BOSS Example step 4 alternate *** diagram *** - node 3 boss grants highest priority request - if no requrests, grants parent - if no requrests for this interfal, sends arb reset on all ports - sends requests on all ports Benefits - minimum elasticity buffer - space is not needed to insert tokens within the data stream - request size can increase - use request token followed by 8 bit request/arb reset data? - requests can contain priorities - cycle_start>current_isoch>next_isoch>current_asynch>next_asynch - arbitration phase eliminated (concurrent with data) - subaction gap eliminated - arb reset gap eliminated - ... ... More benefits - continuous stream of requests - requests are generally available at teh node issuing the grant when the node is ready to send the grant - continuously updated priority can be included in requests - Error handling - lost request - requests are sent conintually - lost grant - grant is passed to parent port if no requests pending - root always receives a packet on a grant - timeout occurs when the root receives neither a packet nor a grant - root becomes the boss after bus reset or upon timeout [We will need some thing to allow nodes to recognize when they are in an environment that is b-only, or mixed, etc., so that we can decide on how to accelerate.] 6.8 Simulation - Kanhere Prashant No report at this time. 6.9 PHY-Link - Martin Sodos PHY-Link Taskforce, Santa Cruz, February 10, 1998 HY-LINK TF - Recap - initial draft of PHY-link spec presented in FL, and added to draft 0.071 ... ... PHY-link TF - Brief review of the initial Draft: The intical PHY-link interface draft: - retained capability for isolation - largely ... ... PHY-Link TF - Initial draft (continued) - maintain or increased existing timing margins - increase width to 16-bits at S800 ... ... PHY-Link TF New Draft - The new draft is a refinement of the original ... ... PHY-LINK TF Issues resolved since the original draft 1. Do we need SClkRtn at S800? - No. New draft changed to presence of ... ... PHY-Link TF Elimination of sClk Rtn at S800 essentially creates 16-bit alpha interface at s800 ... PHY-link TF 2. Is Lreq fast enough at 50 MHz? resolved: No. Lreq needs to clock at teh same rate as SCLKRtn (or just SClk at S800). PHY-Link TF 3. Does this have an effect on repeaters? No. PHY-Link TF 4. Should Clk recovery be used instead of sclkrtn" No. ... PHY-Link TF 5. At the ad hoc meeting held in FL, a request for reconsideration was made to revisit the groups standing recommendation for a 16-bit/50 MHz interface in favor of an 8-bit 100 MHz one. In FL, the limited number of ... ... PHY-Link TF 6. Is a change to an LVTTL interface really necessary? - Yes. Timing analysis contributed on the reflector showed that: a. Adequate timing margins require the use of LV technology. b. ... PHY-Link TF Clarification: An S3200 interface operates at 200 MHz. In order for this interface to support S100, a single bit only ... ... PHY-link TF *** table *** PHY-Link TF As of today: The initial draft has been posted for 8 weeks, and ample opportunity discussion hs been given. ... PHY-Link TF We think we are done, and any remaining issues are easily handled within the committee proper. [Did you treat the case of dealing with an 8-bit ACK over a 16-bit I/F? Sodos - I feel that this is an on-going discussion. This is not a unique problem to this I/F. ... Wooten - how do you tell the PHY that the item you wish to send is only 8-bits, when you on a 16-bit I/F? How does the Link know not to sent the extra 8 bits? ... We might induce a half-cycle latency to allow the PHY to recognize the fact that no more data is coming, and so the item must be an ACK ... So, do you say in the spec. tat the PHY has to hold on to the first 16 bits until you know what may or may not be sent? Not yet. The discussion only arose a few days ago. ... What I envision is that after some delay, all comments would be rolled into the draft, which would then be forwarded to Eric into the full document ... Regarding the LV interface, this still allows isolation doesn't it? Yes. What about the swing for the signals in association with Schmidt trigger thresholds? Schmidt trigger designers need to build much smarter triggers. Have you thought about what these threshholds should be? No. You should ... This probably needs to be handed over to some real experts on this ...] 7. Extra Items 7.1 Multi-port and slow link speed mapping, *** first slide *** Introduction - multi-speed port: If a PHY has multi-speed ports, (eg. DS port, Beta port), 1) The per port speed need to be stored ... ... - Slow Link ... ... ... PHY REGISTER MAP *** register map diagram *** Port Register Map *** register map diagram *** [What is this "other" information telling us. If the PHY is connected to a slow link ... I understand, what does this have to do with this? We have two places to get link speed ... Negotiated speed is the speed we need to run at, So what is the per-port speed telling us? ... We operate at the minimum of link, phy and port speeds ... Port speed could be programmable ... There is inherently a max signaling speed for a port, and here you are trying to reduce that for operation. What you have here looks like it is what is implemented in hardware, rather than that it is the connection constraint. ...] Modified Self-ID Packet *** three packet diagrams *** - ... ... The modified self_ID packet and BM's speed Map (recommended solution) sp = real_speed and rsv = 10. for the old bm ... The modified self_ID packet & BM's speed map (alternate solutions) 1. sp = real_speed and rsv = 00. For the old BM S/W, the sp will be used to build up the speed map. For the new BM S/W, it will always read PHY reg3 to check the M_speed and the Link_speed. If M_speed = 1, the new BM S/W will read the port register to get the per port speed in- formation and build up the speed map. If the Link_speed is slower than PHY, the Link_speed will be used to build up the speed map. 2. sp = real_speed or 11, rsv = 00. (If Link_speed is not equal to PHY_ speed, or multiple speed ports, sp = 11). The new BM S/W will sort it out whether the link_speed is slower or the multiple speed ports when sp = 11 by reading the PHY reg3. The Old BM S/W might have problem when sp = 11, because of the slower Link_speed. 7.2 1394 Queue-Based Modeling - Robert Liu Why? - Functional Verification - various arbitration enhancements - PHY to PHY interactions - PHY to LINK interactions - Hardware requirements - ... ... Event-based simulation tools - tools evaluated - BONeS by Cadence - SES Workbench - Extended by Imagine That! - Extend - Customm blocks allowed - C code based - Source code available for ALL library blocks - Code Profiling Event-based simulation Tools - Extend (cont.) - PC and Mac based - Good visual display - Inexpensive [Mike Teener used this to model the original protocols ...] 1394a Arbitration Modeling - Custom blocks - 1394a PHY - Simplified Link - Cable - Simplifications - ... ... 1394a Arbitration Modeling - Types of packets - arbitration signals, such as TX_Request, RX_Grant, etc. - data - ack - Transaction protocol - SBP-2 Task Group? - Task group for queue-based modeling - existing modeling group - Share code on the custom blocks - contact info 8. Future Meeting Dates 8.1 March 17 & 18, Tempe, Arizona; Intel (Steve Bard) P1394b and .1 will meet together, which has lead to some scheduling problems with regard to the rates for the rooms. This entails a rate difference of $20 between the first block and the latter block, so RESERVE REAL SOON! Use program number 73728 to reserve your room. If you are an over-seas attendee, there is an additional form to be filled out, which may be obtained from the 1394 TA Upcoming Events web page. You must tell the reservation folks SPECIFICALLY that you intend to be there for the .1 dates, else they will reserve only for the first nights. 8.2 April 27 & 28, Newport Beach, California; Rockwell (Brad Saunders) Again, this is with .1, and perhaps with 1212r. See the web site and (in a few days) the 1394 TA Upcoming Events web page. There is a scheduling problem for Alistair, so there may be some flipping of days with 1394.1 and 1212r. Watch for information. The meeting rooms are at Rockwell, which is across the street from the hotel. The hotel room rate is a Rockwell rate 8.3 At Risk! June 9 & 10, St. Petersburg, Florida; AMP (Chuck Brill) There have been scheduling problems, so watch the reflector and elsewhere for the final schedule 8.4 July 13 & 14, Bath, UK; ST/HP/Xyratex (Whitby-Strevens/Coles/Instone) These dates are still solid ... 8.5 August 18 & 19, Portland, Oregon; SSI (Steve Finch) This is in process. There might be some change, but probably not. 8.6 September 14 & 15, St. Petersburg, Florida; AMP (Chuck Brill) - or - September 14 & 15, Chicago, Illinois; Molex (Max Bassler) This needs a decision ... 8.7 October 19 & 20, Maui, Hawaii; Lucent (Farrukh Latif) In its infinite wisdom, the TA moved the Fall meeting dates to conflict with our ('b', .1 and 1212r) meeting dates. This is being worked ... 8.8 December ?? & ??, TBD 9. Adjournment The meeting was adjourned, to reconvene on Wednesday, March 18, 1998, at the Embassy Suites Hotel, 4400 Rural Road, Tempe, Arizona. ============================================================================= Attendance List Bill Anderson w.anderson@worldnet.att.net 408-980-8033 Jon Ando jon_ando@compuserve.com 847-473-1373 Takeshi Aoki aokit@alles.or.jp +81 45 945 2537 Tatsuya Arai tatsuyaa@hiroseusa.com 805-522-7958 Akira Aso aaso@molex.com +81 462 65 2328 Steve Bard steve_bard@mail.intel.com 503-264-2923 Max Bassler mbassler@molex.com 630-527-4490 Charles Brill cebrill@amp.com 717-592-6198 Dave Brown dave_brown@3com.com 408-764-6334 Mike Brown mike_brown@ccm.sh.intel.com 602-554-3713 Dave Brunker dbrunker@molex.com 630-527-2622 Joe Byouk jrbyouk@amp.com 704-824-6343 Don Chambers chanmbersd@jae.com 714-753-2600 Dao-Long Chen dao-long.chen@symbios.com 970-223-5100 x9461 Richard Churchill richard.churchill@compaq.com 281-514-6984 Alistair Coles anc@hplb.hpl.hp.com +44 117 922 8750 Kazunobu Endo ldv06630@niftyserve.or.jp +81 285 82 4958 Firooz Farhoomand firoozf@ix.netcom.com 408-653-4059 Takayuki Fujii u019252@jae.co.jp +81 3 3780 2782 Dave Gampell dave_gampell@hp.com 408-435-6680 Bob Gannon rgannon@cm-corp.com 860-779-4249 Eric Hannah ehannah@mipos2.sc.intel.com 408-765-4441 Jerry Hauck jerry_hauck@ccm.sc.intel.com 408-765-5528 John Hill jhill@amp.com 717-592-6175 Hideki Hiyuki miyukih@erg.shinjo.co.jp +81 745 65 1161 Jack Hollins jack_hollins@eng.adaptec.com 408-957-2309 Kazunari Hyakutake kazu_hyakutake@amp.com +81 44 844 8077 Yoshio Inagaki inagaki@cns.hino.toshiba.co.jp +81 42 586 3295 Tatsuo Inoue inoue@ba2.so-mel.or.jp +81 3 5545 7813 Tom Jones thomas_c_jones@ccm.ch.intel.com 602-554-3569 Prashant Kanhere prashant@macrodesigns.com 510-668-1773 Marcus Kellerman marcus.c.kellerman@wdc.com 714-932-5000 Shingeri Kobayashi skobayas@amp.com +81 44 813 9793 Dave LaFollette dlafolle@mipos2.sc.intel.com 408-765-2587 Farrukh Latif flatif@lucent.com 610-712-7546 Chong Lee chlee@lucent.com 610-712-3002 Francesco Liburdi liburdif@hollingsworth.com 607-748-0025 Robert Liu rober_liu@ccm.intel.com 408-765-6549 Hirokazu Mamezaki mamezaki@ffm.fujifilm.co.jp +81 22 347 1128 Gerald Marazas marazas@vnet.ibm.com 919-543-6892 Masahito Matsuo matsuom@jae.com 714-753-2621 David McCallum dmccallum@molex.com 630-512-8525 Daniel Meirsman daniel.meirsman@leu.ce.philips.com +32 16 390 733 Jack Merrow jmerrow@leviton-telcom.com 425-486-2222 Michitoshi Mitani mititosi@alles.or.jp +81 45 945 3947 Akihiro Miyachi amiyachi@molex.com +81 462 65 2329 Reza Moattar reza.moattar@tsc.tdk.com 714-508-8731 Palanisamy Mohanraj palanisamy_moharaj@ccm.ch.intel.com 602-554-4243 Yoshimasa Morishita jst00505@niftyserve.or.jp +81 45 541 2181 Peter Munguia pmunguia@sedona.intel.com 602-554-9406 Kazunobu Murata ex_batam@indosat.net.id +62 778 611397 Kazuki Nakamura kazuki-n@dtinet.or.jp +81 8275 3 5320 Richard Nesin nesin@lucent.com 610-712-6785 Bill Northey northewa@bergelect.com 717-938-2119 Takayuki Nyu new@optsys.cl.nec.co.jp +81 44 856 2082 Shoji Oda wakooda@po.infosphere.or.jp +81 3 3500 5116 Larry Phillips lphillip@us.ibm.com 303-773-7782 James Piccione james.piccione@smi.siemens.com 408-895 5136 Bill Prouty bprouty@hp.com 916-785-4631 Kyozo Saito kyozo_s@gw3.alps.co.jp +81 229 23 5111 Shoichiro Saito saitosho@gw3.alps.co.jp +81 229 23 5111 Tomoki Saito saito@ccm.cl.nec.co.jp +81 44 856 2082 Brad Saunders bradley.saunders@rss.rockwell.com 714-221-6513 Masashi Seto mseto@molex.com +81 462 61 4500 Masood Shariff mshariff@lucent.com 732-957-5479 Kazuo Shirai irslab@ppp.star-net.or.jp +81 44 811 6311 John Smolka jsmolka@ti.com 972-480-1049 Ron Soderstrom rows@vnet.ibm.com 507-253-6290 Martin Sodos msodos@issiusa.com 408-969-4683 Kazui Sogabe dw750134@jnet.sei.co.jp Robert Stuart stuart@sharpsec.com 360-834-8948 John Ta john.ta@tus.ssil.com 714-573-6957 Shinichi Takagi stakagi@amp.com +81 44 900 5102 Ju-Ching Tang jctang@corp.cirrus.com 510-623-8300 x5189 Ken Taylor foken@aol.com 508-836-2700 Michael Johas Teener mike@zayante.com 408-461-4901 Susumu Tosaka tosaka@sslab.sony.co.jp +81 3 5448 3537 Toru Ueda ueda@slab.thr.sharp.co.jp +81 743 65 4529 Yoshihisa Wada ex_batam@indosat.net.id +62 778 611397 Hirosha Wakai wakai@slab.sharp.co.jp +81 743 65 4529 Kenji Watanabe nabeken@sslab.sony.co.jp +81 3 5448 3537 Colin Whitby-Strevens colinws@bristol.st.com +44 1454 611500 David Wooten david.wooten@compaq.com 281-518-7231 Hiro Yamada yamada@tam.toray.com 212-697-8150 Shuntaro Yamazaki yamazaki@ccm.cl.nec.co.jp +81 44 856 2082 Takeshi Yuasa yuasa@ecs.tel.co.jp +81 3 5561 7217