P1394b Working Group Meeting, May 5&6, 1997, Santa Clara, CA, Embassy Suites Hotel Michael Teener, Chair, absent at start Eric Hannah, Editor, absent at start Richard Churchill, secretary Colin Whitby-Strevens, Long-haul task group chair <<<<<<<<<<<< PART A (Long-haul) OF MEETING >>>>>> (The spelling of "fibre" is in deference to Colin.) I. Administrivia Meeting called to order by Colin Whitby-Strevens Note made of traffic over Santa Cruz Mountains, delaying Mike Colin reported addition of long-haul duties at Eindhoven, as agreed by Mike Teener. Questions regarding the addition of task were raised, and were answered by Colin, stating that 1394b now has this additional work with the expectation that it might later be spun off into a seperate effort. Agenda 1. Introductions 2. Approval of Agenda 3. Background 4. Review of objectives and guidelines 5. Proposed model 6. Review requirements 7. Contributions David Smith (Honeywell) - VCSEL technology for optical fibre Patrick Yu (NEC) - POF 8. Discussion - timescales, etc. 9. Action items 10. AOB 1. Introductions around .... 2. Agenda was agreed. 3. Background Mike Teener explained reason for a two-day meeting, rather than the traditional one-day: Expansion of task to long-haul/gigabit operation. Task group will assume responsibility for bit-push, remainder of group with worry about SW, silicon, etc. ... Future problem getting and keeping meetings coordinated. Issue regarding appropriateness of addressing the 100 Mb/s UTP5 problem -- would require changes to PAR, etc. "PMD for Long Distance 1394 Kick-off meeting" by Colin follows VESA HN Committee selected 1394 as cluster interconnect VESA HN selected 1394 as basis of home backbone needs an appropirate physical layer needs protocols for IP, etc. PHY working group within VESA HN to develop technology demo as first step towards spec part of ... ..... 4. Review of objectives and guidelines -- continuation of presentation by Colin Objectives Evaluate and refine the requirements Consider the use of Optical Fibre and UTP transmission media Consider the long distance transmission at all 1394 cable environment speeds, ... Prioritise the determination of a medium recommendation for new domestic installations [*** Considerable discussion seeking to clarify issues, such as the requirement for UTP. Mike made the point that this arguement for UTP is spurious, since the requirements will be different in 3 years, and fiber is easier to install than coax ... Dick Scheel pointed out the "fear" factor associated with fiber, and that this is an education problem as much as ahything ... ***] Guidelines 5. Proposed Model(s) -- continuation of presentation by Colin Model 1 [drawing ...] A new reference point is defined, called PMII (Physical Media Independent Interface). The current P1394b work defines everything towards the PHY from this interface, the new PMD subgroup defines everything towards the medium from this interface. Model 2 - There is one specification for PMII, but a range of specifications for 1394b-n (n is used to distinguish one from another) - The PMD-n transceivers are unintelligent and non-configurable. The role of a transceiver is to convert between the signals provided by the PMII and a suitable format for long-distance transmission. - The PMII electrical specificaiton is the specification currently being defined within 1394b for S800 and upwards short copper links. In this casel, the PMD transceiver is null, and the PMII = 1394b-N, (where N is the value of n which identifies this interface. - The PMII may or may not be connectorised. When connectorised, it uses the standard 1394 connector. [*** Discussion of assorted implementation issues, including cost. Point raised that competing technologies have had no initial discussion of or concern for cost -- which is opposite of "traditional" 1394 approach. ***] Model 3 The following packagin options are permitted (non-exhaustive list):- - The external interface of the device is the current 1394 connector. A short 1394 copper cable leads to a dongle, which converts to an appropriate optical interface, and a short optical cable is termin- ated in an optical connector. - As above, with the optical cable replaced by a long-haul copper cable (e.g. UTP-5). - The external interface of the device is the current 1394 connector. a 1394 copper cable leads to an active wall plate with another 1394 connector, the transceiver, and connections to installed fibre (or long-haul copper). - The external interface of the device is an appropriate optical or long-haul copper connector. The long reach transceiver is internal to the device, the PMII is not connectorised, and may be subsumed within an integrated implementation. The speed capabilities of the PHY may exceed the speed capabilities of the PMD transceiver. The PHY needs to discover the bandwidth capabil- ities of the channel with no user involvement. The start-up procedure is therefore defined across the PMII. [*** Discussion of assorted issues ... Mention made of problems involved in creating any standard with active wall-plates, which approaches the impossible. Assorted discussion of implementations, costs, etc. .... ***] 6. Review requirements -- Continuation of presentation by Colin PMD Proposed Requirements - 50m reach (100m preferred) per hop - determine worst-case delay - UTP-5 and Optical Fibres - minimise the differences between these two media - low complexity implementation - Facilitate FCC Class B emissions compliance - P1394b above the PMD layers - same tree-ID algorithms, self-ID algorithms - fully interoperable with current 1394 - no bus bridging required - Amateur installable - Installation guidelines, installation test, ... [*** VESA had a considerable discussion of requirements -- the round-about paths of high-end installations cna easily reach substantial one-hop reaches. Surveys indicated 50m was rather short for the US market, while 100m covers the vast majority of the US housing market. Every meter over 50m adds a percentage of the US home market. 50m was only acceptable if necessary, but leaves out a significant portion of the market (comment by Dick Scheel) Discussion of point by others regard- ing requirements and trade-offs. POF bandwidth and reach issues were discussed. 100m requirement suggested, but 70 to 100m offered as a good compromise. Discussion of the UTP-5 and Optical Fibre delta minimization discussed, with point made that the minimal delta was with respect to the i/f. Opinion expressed regarding low-priority for UTP support, with support in fact permitted as incidental, but not as an objective. Colin: "Cost is King!" -- "... Must decide what priorities are ..." Added P1394a at start of bullet 4 before "P1394b ..." Question raised regarding bridging ... Is it a priority that no bridging be required? (Yes!) Lasers must be class 1 EYE-SAFE (IEC 825-1 and CDRM (r-DA)) for regu- latory purposes in order to be amateur installable. David Wooten raised issue of the incompatibility of the requirements, stating that the simple, low-cost objective is not compatible with the requirement to support "all known media at all known data rates." -- LEDs can get us to about 300 Mbaud (some to 600) -- POF gets us to about 150 Mbaud -- laser from 300/600 Mbaud to 1+Gbaud Question/Comment that we need to be aware that we should consider the availability of technologies --- 300 Mbaud may be possible with LEDs, but is anyone actually selling such a solution? Might we practically be limited to 155 Mbaud by the vendors when using LEDs? "It has not been demonstrated that POF is necessarily cheaper than glass fibres ...." Additional discussion about how to approach the problem ... "encap- sulated" within the cable, or within the wall seems the simplest ... We should look at the state of research, and see how we can interplay to our mutual benefit to reach a better cost-point ... Strike the distinction between MMF and SMF, which gets us to seven options for prioritization ... Questions regarding model ... Model must support incremental upgrade. ***] Votes for priority ... (Each person present was permitted a single vote in each of the two priority levels.) I II Speed & Technology -- -- --------------------------------------------------- 0 2 S100/UTP 0 5 S100/Fibre 1 1 S200/Fibre 1 2 S400/Fibre 11 0 S800/Fibre 7 0 S1600/Fibre 0 8 S3200/Fibre (This vote implies at least two more abstentions in the "second priority" vote than in the "first priority" vote.) (1) lowest cost, and (2) S800 and upwards (???) Should we support the same layers "above" the PMD? (Shall the encoding schemes, etc., used be identical for both low-speed and high-speed solutions?) Motion moved by Richard Churchill, and seconded by Colin Whitby-Strevens. The vote was 20 yeas versus 2 nays, and the motion carried. 7. Contributions David Smith (Honeywell) - Vcsel (vertical cavity surface emitting laser) technology for optical fibre Run on much lower current ... Testable on wafer ... significantly lower cost than edge emitting lasers ... Central active region between p- and n-mirror stacks ... Made with multiple quantum wells ... AlGaAs, AlAs, GaAs, etc., used Comparison of properties ... Sub milliamp thresholds are now being displayed ... Encapsulated, Class IIIb can be used in a Class I manner ... Modulation current 3-10 mA, CD lasers >10 mA Spectral Width 0.5nm, vs CD laser 9 nm, and LED 50-200 nm ... Patrick Yu (NEC) - POF - Reiteration of parts of his Eindhoven presentation ... Goal of 200 Mb/s this Fall ... 1394 POF requires "fixes" for (1) Arbitration, (2) Self_ID, and (3) encoding (to use 4B5B). One 70m hop over POF roughly equivalent to 3 hops in "traditional" 1394 -- roughly 350 ns -- exclusive of the implied outer- edge repeaters [*** Is the attenuation of the POF (10's of dB/100m) acceptable, given con- sequences regarding laser power vs. cost and eye-safety? Will the POF, GI, Gb capable, be acceptable to the high-speed 1394 folks? Indications are that this is not presently available, and there is no reliable knowledge regarding when it will be. Vendors must be checked ... Possible Action Item? Who? ***] 8. Discussion - timescales, etc. [*** Does the model presented imply that we will see VCRs, PCs, etc., with optical connectors? Quoth Mike, "Let's not worry about that now. If we work on the technologies, and make sure we can all do them, maybe the connector problem will go away. ... Discussion of cost of media vs. cost of installation vs. cost of "finishing" (termination, photonics, etc.). ***] 9. Action items < Colin is "nominated" to be chair of high-speed long-haul, and Taka Fujimori to be chair of the "lowest cost" effort. Colin passed sign-up sheets for both groups 10. AOB <<<<<<<<<<<< END OF PART A (Long-haul) OF MEETING >>>>>> <<<<<<<<<<<< START OF GENERAL P139B SESSION >>>>>> Presentation by Bill Northey (Berg) updating work done on improvements the existing six-pin connector and socket. Data rate improvements by geometry changes indicates 3 Gb/s data rate is achievable. see previous meetings presentation ... Offered to share simulation package data with any who are interested. Initial samples in July, with production in October. Summer Schedule Discussion Early June meeting in Seattle proposed, with a skip for July ... Suggestion by East Coast folks that meeting NOT be on Monday, so that they will not be forced to travel on the weekend. General agreement on week of June 9, possibly in Seattle. Proposal for a meeting in middle of September, with Colin W-Strevens suggesting Bristol, with a two-day meeting, plus suggestion that Peter be contacted regarding holding a P1394a meeting there at an adjoining time. October meeting in conjunction with TA in Phoenix. IBM presentation on 8B/10B. IBM's 8B/10B coding scheme is available for licensing for 1394b, with contact information, etc., as follows ... Al Torressen, (914)742-6275, TORRESS@US.IBM.COM, for a $5,000.00 license of the 8B/10B code. (This constitutes a completed Action Item from the previous meeting!) <<<<<<<<<<<< Recess for night at 4:40 PM, resuming Tuesday, at 9:00 AM. >>>>>> <<<<<<<<<<<< Meeting resumed at 9:35 AM, Tuesday May 6. >>>>>> Mike Teener was again delayed by traffic. AGENDA 1. Approval of Agenda 2. Introductions 3. IBM License 4. Presentations a. Start-up b. Codings Keith Heilman Taka Fujimori Jerry Hauck Alistair c. Electricals Karl Nakamura 1. Approval of (provisional) Agenda Done. 2. Introductions 3. IBM License Done. Same as previous day. 4. Presentations a. Start-up, Colin Whitby-Strevens (SGS-Thomson Micro.) (Six page document, titled "P1394b Start-up," distributed, with authors listed as "Colin Whitby-Strevens and friends.") Introduction - Start-up procedure for Beta-capable links - Independent of the coding shceme used - some requirements on such coding schemes - Goal is to start up in Beta mode if both ends of a connected link are Beta capable, otherwise start-up in DS-Link mode. - Normal bus reset, Tree_ID, Self_ID, and operation will follow AFTER this start-up procedure. - The techniques aims to be as sympathetic with the current 1394 philosophy as possible. Requirements - To start-up as an ordinary DS link if either end is not Beta capable - To start up in Beta mode if both ends are Beta capable - To start up in Geta mode at the maximum baud rate which is acceptable to both ends (this assumes a single operating speed in terms of baud, but with some form of padding to support lower speed packets.) - To support the higher speed copper links being defined with P1394b including speed determinations .... - - - - Sleep mode [Mike Teener arrives] [Physical Medium Dependent -- PMD] Model 1 diagram from previous day's presentation re-presented. Models 1-3 from previous day's presentation re-presented. Procedure - use of TPA and TPB - 1394-1995 uses both the TPA and TPB pair for transmission and reception of data, as well as for digital DC arbitration signalling - Common mode signalling is performed with respect to a bias volt. generated on TPA. This voltage is sensed on TPB as connection indication - current is also drawn at TPB which is sensed as a voltage drop at TPA for signalling. - It is required tht the PMII supports these facilities unchanged when the PHY is operating as a DS Link - In Beta mode, data is transmitted on TPB and received on TPA - the potential use for optical transmission implies either (i) there is no DC signalling across the PMII (ii) ... Start-up procedure, main states - The power-on start-up procedure for a Beta-capable PHY proceeds through the following states 1. Connection status: 2. Speed determination 3. Tree_ID, et. - After state 2, normal operation of the link is continuous - A procedure is defined for recovery from loss of synchronization - A procedure is defined to maintain a conection in a low-power mode where transmission is not continuous - Connection status - 1 - This state determines whether - - - - The use of TpBias is restricted to its use as specified for 1394-1995 DS Link signalling. A beta ... Connection status - 2 - On power on, a Beta capable PHY should wait for the TpBias debounce time, and then check for TpBias (on TPB) on each of its ports. - If TpBias is sensed, this implies that the port at the "other" end is a DS Link only device, and is enabled. The PHY generates TpBias on TPA, and the port starts up in DS mode as per P1394a (reset, Tree_ID, Self_ID, ...) - If TpBias is not sensed, then a sensing tone is transmitted (e.g. 125 MHz (62.5 MHz?)), and listened for. - If, at any time, TpBias is sensed, then this procedure is abandoned (this will occur if a DS-only device is switched on and its port enabled just after the Beta-capable device is turned on). - The tone is transmitted for a defined period of time - long enough to overcome the time constands in the PMD. 5.0 usec is proposed, but needs to be balidated by the PMD group as being sufficient to overcome the time constants in all anticipated PMDs. Connection status - 3 - If a tone is received, then this confirms that the "other" end is Beta capable. The PHYs at both ends enter speed determination state. - Care must be taken when specifying the frequency of the tone that will be low enough in frequency to pass through the slowest PMD, but .... Speed determination - 1 - This is largely still open, and requires further study. - The pHYs can exchange information giving their maximum operating speed, but this does not deal with the problem of a slower transceiver. - A possible method which inclues a crude transceiver test is described below - Three symbol sequences are defined -S1, S2, and S3 - For ease of understanding, consider each sequence as 2/4 10- bit symbols. - The choice of symbols depends on the coding scheme to be adopted. Each sequence has the property that the PHY can per- form .... - .... Speed determination - 2 - The sequence S! is transmitted repeatedly at the S100 equivalent rate (122.88 MBaud) - Simultaneously, the sequence is listened for. - The receiver performans syumbol alignment until it can receive the sequence successfully - The exchange of S1 continues for long enough .... - ... Speed determination - 3 - If the PHY is capable of a higher speed, it then transmits S3 repeatedly, otherwise it continues to transmit S2. - If it is capable of a higher speed, and it receives the S3 sequence, then it starts transmit the S1 sequence at the S200 equivalent rate, and attempts to lock reception at this rate. - Upon successful receptoin for a defined period of time, the PHY confirms receipt by changing the transmitted pattern to S2. The process repeats to the next higher speed. - In the event that transmission is not successfully received, then the PHY reverts to the lower speed. - Care needs to be taken to deal with the case when the trans- mission is OK in one direction, but not the other. - The result of this procedure is bi-directional transmission at the maximum rate acceptable to the PHYs, the transceivers and the medium. Bit alignment and symbol alignment is achieved - Upon completion of the procedure, the PHY commences to transmit. - The PHY also sets the Bias bit (simulating TpBias for the PHY-LINK interface), with the consequent implications for the Con bit. [Colin extended an apology for confusing the terms "link" and "port" in this presentation. Reader should take care to observe the usage in interpreting the presentation.] [*** Extended discussion of speed determination and reporting occurred here, with various questions raised, and in turn answered by assorted other attendees. ***] Choice of Sequences - The properties required of a sequence are - Each sequence should be DC balanced - Each sequence must provide suitable patterns for symbol alignment - IBM 8B/10B - Fibre Channel OLS (for S1), LR (for S2) and LRR (for S3) - similar to the fibre channel start-up procedure (but Fibre Channel des not have to provide a speed determination function) - Coles 8B/10B code (SC1 .... - ... - ... - ... - ... Await Connection - The beta capable PHY has received neither TpBias, nor a tone - It transmits a tone for a period of n usecs (n = 5?) - This is repeated at intervals of 60n usecs until either a tone is detected or TpBias is detected on TPB - If a tone is heard, then the speed determination procedure is entered - If TpBias is detected, then TpBias is generated on TPA, and start-up is as per 1394-1995 - This scheme avoids excessive energy being transmitted into an unterminated cable. - This would be necessary for a UTP 1394 link, but conuld also be a sensible move for any 1394b copper link. - Also consider use of "sleep" modes, and the need to be able to detect a wake-up signal without requiring the PHY to be powered all the time. - This may be achievable either by - a "signal detect" signal from the transceiver (communicated to the PHY by using some form of TpBias-type signal. - By having a low level active circuit which can respond to the reception of the tone and wake up the rest of the PHY - The second option is preferable. ???? - This is a topic for further study - However, a good starting point is the Fibre Channel state machine - provides hysteresis on the detection of an error (e.g. an invalid symbol, or excessive running disparity) - Synch is maintained unless a rapid sequence of errors is detected. - The PHY transmits an indication of loss of synch. - IBM 8B/10B code: this could be the NOS primitive sequence - Coles 8B/10B code: this could be the S1 sequence - The PHY enters the speed determination state on loss of synch. and on receipt of the loss of synch indication - the need to consider the seret behaviour on loss of synch. Summary - Start-up takes place BEFORE reset, Tree_ID, Self_ID, etc., - arbitration state machine is unchanged from 1394-1995 - Beta capable PHYs adapt _ _ [*** Extend discussion on numerous topics ... Suggestion of creating an "Open Issues" list as a "living document." ***] b. Coding -- Serial Bus Packet Format, Keith Heilman presentation (material has been on reflector) foil 1, diagrams, 1394-1995 start-stop to 1394b continuous 1394B Transmission Speed table ... 1394B Data Format table & brief comments ... 1394B Arbitration Format 2 Byte ordered sets for Arbitration signals ... (Encoding remapped) [ R | SPD |B1 |B0 |A1 |A0 ] [ | | | | | | | ] foil 5, table, 1394-1995 Arbitration encoding for IBM 8B/10B [*** Mike Teener accepts homework of developing method of using the now full-duplex connections to remove all gaps by performing arbitration in parallel with data transmission .... ***] <<<<<<<<<<<< RECESS FOR LUNCH AT 12:06 PM >>>>>> <<<<<<<<<<<< RESUME AT 1:20 PM >>>>>> -- "POF/UTP 1394 Long (100m), Based on 4B/5B Code" by Taka Fujimori Room-to-room connection via POF/UTP 1394 diagram Characteristics of POF/UTP 1394 PHY 1. One hop length of POF 70m @ 100/200 Mbps UTP Cat 5 100m @ 100 Mbps 2. Coding is the same as 100Base-T - 4B/5B Code Tech. is already proven - O/E, E/O Link accepts 10% unbalance with absolutely no additional cost 3. Passes FCC Class B 4. Cost is minimal 5. Low cost 650nm LD for POF 6. ATM Forum has passed SI (Step Index) POF 155 Mbps 50m with 2 splicing points UTP/POF 1394 Repeater Block Diagram diagram Valid 4B/5B Code table 4B/5B Code Mapping to 1394 table .... How Packets Look Like S200 Long PHY. .... ... S400 Long PHY. .... ... Conclusion 1. Mapping 1394 control onto 4B/5B is Complete Max Speed Signalling is unlimited: S800, S1600 ... 2. Sony & Hyundai submitted a Joint Proposal to DAVIC Hyundai submits IP (4B/5B) Statement 3. Proven by 100Base-T Ethernet, Minimal Cost Pass FCC Class B 4. Verilog Code will be available. -- HP 8B/10B Block Code, by Alistair Coles (Similar to previous HP presentation on HP/Coles 8B/10B) Spectrum of HP 8B/10B Block Code graph of spectral character of unencoded, MLT3 and HP 8B/10B codes. 8B/10B Block Code: Operation - Data: - Data codetable has 256 codewords: 111 have zero disparity (i.e. equal number of 1s and 0s - Encoder updates the running digital sum (rds) at the end of transmitted ... - - - - Control (Arbitration) - Control codetable has 8 codewords: all have zero disparity, and are never inverted. - These 8 codewords are Hamming distance 2 from ... - ... Block Diagram: Data/Control Paths diagram - 8B/10B coder uses separate code tables for data and control: 256 data codeowrds, 8 control codewords. - ... - ... ..... Synchronization - two codewords (SC1 = 1010101010 and SC2 = 0101010101) areprovided for synchronization - Local End of a link begins training by repeating the pattern {SC1, SC1, SC2, SC2}. Far end will always se an occurence of SC1 or SC2, even when not synchronized - Far end responds with the pattern {SC1, SC1, SC2, SC2}. - Far end uses transition between SC1 and SC2 to achieve codeword alignment. - Local end uses transition between SC1 and SC2 to achieve codeword alignment. - When codeword alignment has been achieved, repeating pattern is ... - ... [*** No present plans by HP to pursue a patent on this coding scheme. ***] 1394B: Control Signal Mapping - If 1394B PHY is to support PMD: At all cases consideration should be given to control signal timing at lower rates. e.g. At S100, two codewords (K28.5 ... [*** Discussion of Scrambling, Resynchronization, etc., ... Question regarding utility of Hamming distances of two between data and control characters, and between control characters. Proposal to be drafted by Mike Teener for arbitration w/o gap. 2 error conditions: GNT to device w/ no request and no GNT (fairness will take care of). MT will come up w/ simple codes and propose for next mtg. Gate count for 8B/10B IBM ~ 1K gates Coles (HP) 8B/10B coding for 100 Mbit PHY repeater in alterra 115K gates for total. For the coding, no numbers have been generted. AR: Get the verilog w/ and w/out the scambler. Look at publishing the verilog Alistair Cole The URL for the HP codes www.fireflyinc.com ***] -- Bit-ordering for IBM 8B/10B Coding, by Jerry Hauck This material was supposed to be distributed via the reflector, but had not been seen as of presentation. Presentation was informal, with intention of leading to reflector discussion. Burst errors caught by CRC up to 32-bits, but 8B/10B produces a 40-bit symbol set from 32-bit object, which may be a burst error, making for a 40-bit burst error that cannot be guaranteed to be caught by present CRC. Clarifying memo required to be consistent with present conclusion, Manner of bit-stuffing will need to be considered ... c. Electricals Changes in Gigabit Ethernet, by Karl Nakamura Brief comments on changes to Gigabit Ethernet, and finalization thereof. [*** Invitation to all from Mike Teener -- What signal levels should we be using for IBM 8B/10B coding, given our known characteristics (present cable and present or presume improved connectors ...), and what should the input sensitivities be? What are the eye- opening requirements? Karl has some information on this ... ***] Action Items .... Teener -- background arbitration ... Taka Fujimori -- Finding a common speed between connected PHYs Jerry Hauck -- clarification of legendary CRC, transmission ordering, etc. document on the reflector Eric Hannah and Karl Nakamura -- signalling requirements, etc., for 1394b All -- Comments and proposals based upon Colin's Start-up presentation/ proposal ... ============================================================================= Attendees: 1 Colin Whitby-Strevens SGS-Thomson +441454611500 colinws@bristol.st.com 2 Richard L. Churchill Compaq 281-514-6984 richardc@bangate.compaq.com 3 David R. Wooten Compaq 281-518-7231 davidw@bangate.compaq.com 4 Jerry Hauck Intel 408-765-5528 jerry_hauck@ccm.sc.intel.com 5 Steve Midford Intel 408-765-8370 steve_midford@ccm.sc.intel.com 6 Karl Nakamura LSI Logic 408-433-4516 karln@lsil.com 7 Taka Fujimori Sony +81-3-5488-6353 fujimori@arch.sony.co.jp 8 Bill Prouty HP 916-786-4631 billp@hprnd.rose.hp.com 9 Sumihiro Okawa Sony +81-466-30-4050 okawa@sm.sony.co.jp 10 Hiroshi Takizuka Sony +81-466-30-4050 takizuka@sm.sony.co.jp 11 David Smith Honeywell 972-470-4402 dsmith@micro.honeywell.com 12 Dick Scheel Sony 408-955-4295 dicks@lsi.sel.sony.com 13 Joel Urban Harting 847-741-1500 [email address not given] 14 D. Desourteaux Harting [no phone number given] d.desourteaux.harting@w????.fr [correction requested] 15 Kazuyuki Abe NEC System Lab 415-528-5904 kabe@sj-pceg.ccgw.nec.com 16 Peter Teng S3, Inc. 408-588-8111 pteng@mail.com 17 Ming Qu National Semiconductor 408-721-8922 mqu@rockie.nsc.com 18 Raghunath Cherukuri Texas Instruments 972-480-3384 crn@msg.ti.com 19 Claude Huss Matsushita E.W. 408-433-3386 claude@mew.com 20 Sunny Lam IBM 512-838-6276 sunnyl@us.ibm.com 21 Shinichiro Matsui NEC [no phone number given] s-matsui@nims.nec.co.jp 22 Robbie Shergill National Semiconductor 408-721-7959 rss@berlioz.nsc.com 23 Dao-long Chen Symbios Logic 970-223-5100 x9461 dao-long.chen@symbios.com 24 Bradley N. Saunders Rockwell 714-221-6513 bradley.saunders@nb.rockwell.com 25 Magami Tsugita NEC [no phone number given] tsugita@lsi.ting.nec.co.jp 26 Hiroaki Kobayashi NEC [no phone number given] kobaya@nims.nec.co.jp 27 Hideki Negishi NEC [no phone number given] negishi@kansai.nims.nec.co.jp 28 Keith Heilmann IBM 914-892-2413 heilmann@vnet.ibm.com 29 Michael Johas Teener Firefly 408-461-4901 mike@fireflyinc.com 30 Cyrus Momeni Cirrus Logic 510-624-7061 cyrus@corp.cirrus.com 31 Charles Brill Amp 717-592-6198 cebrill@amp.com 32 Bijit Patel Lucent 610-712-2188 patelb@lucent.com 33 Eric Bergles CEL 408-588-2216 ebergles@cel.com 34 Steve Bard Intel 503-264-2923 steve.bard@ccm.jf.intel.com 35 Bill Northey Berg 717-938-2119 northewa@bergelect.com 36 Patrick Yu NEC Electronics 408-588-5436 patrick_yu@el.nec.com 37 Jonathan Buck Amp Inc. 408-725-4923 jon.buck@amp.com 38 Mike Gardner Molex, Inc. 408-946-4700 mgardner@molex.com 39 Ketan Patel Molex, Inc. 630-527-4047 kpatel@molex.com 40 Max Bassler Molex 630-527-4490 mbassler@molex.com 41 Rajiv Choudhary Intel 503-264-8480 rajiv_choudhary@ccm.jf.intel.com 42 Jack Merrow Leviton Telcom 206-486-2222 jmerrow@leviton-telcom.com 43 Michael Nguyen Fujitsu 408-894-3542 michael.nguyen@fcpa.fujitsu.com 44 Firooz Farhoomand Matsushita/Panasonic 408-945-5625 firoozf@netcom.com 45 Alistair Coles HP Labs +44-117-922-8750 anc@hplb.hpl.hp.com 46 Mike Brown Intel 602-554-3713 mike_brown@ccm.fm.intel.com 47 Heather Lane SRTI 415-988-4812 heather@srti.com 48 Gene Matter Intel 916-356-4597 gene_p_matter@ccm.fm.intel.com 49 Nobuo Furuya NEC Electronics 408-588-5414 nobuo_furuya@el.nec.com 50 Benjamin Pan S3 Inc. 408-588-8379 bpan@s3.com 51 Kugao Ohuchi NEC Electronics 408-588-5503 Kugao_Ohuchi@el.nec.com 52 Khorvash Sefidvash Symbios Logic 714-474-7095 khorvash.sefidvash@symbios.com 53 Mike Winchell Symbios Logic 970-225-4807 mike_winchell@symbios.com ----------------------------------------------------------------------------- S100 Long Haul Signees: 1 Colin Whitby-Strevens SGS-Thomson +441454611500 colinws@bristol.st.com 2 Charles Brill AMP 717-592-6198 cebrill@amp.com 3 Bijit Patel Lucent 610-712-2188 patelb@lucent.com 4 Eric Bergles CEL 408-588-2216 ebergles@cel.com 5 Mike Brown Intel 602-554-3713 mike_brown@ccm.ch.intel.com 6 Max Bassler Molex 630-527-4490 mbassler@molex.com 7 Gene Matter Intel 916-356-4547 gene_p_matter@ccm.fm.intel.com 8 David James Express Associates 415-494-0926 dvj@ibm.net 9 Patrick Yu NEC 408-588-5436 pyu@el.nec.com 10 Raghunath Cherukuri Texas Instruments 972-480-3384 crn@msg.ti.com 11 Rajiv Choudhary Intel 503-264-8480 rajiv_choudhary@ccm.jf.intel.com 12 Sunny Lam IBM 512-838-6276 sunnyl@us.ibm.com 13 Shinichiro Matsui NEC [no phone number given] s-matsui@nims.nec.co.jp 14 Dao-long Chen Symbios Logic 970-223-5100 x9461 dao-long.chen@symbios.com 15 Hiroaki Kobayashi NEC [no phone number given] kobaya@nims.nec.co.jp 16 Hideki Negishi NEC [no phone number given] negishi@kansai.nims.nec.co.jp 17 Magami Tsugita NEC [no phone number given] tsugita@lsi.ting.nec.co.jp 18 Mike Winchell Symbios Logic 970-225-4807 mike_winchell@symbios.com 19 Dick Scheel Sony 408-955-4295 dicks@lsi.sel.sony.com 20 Taka Fujimori Sony +81-3-5488-6353 fujimori@arch.sony.co.jp 21 Sumihiro Okawa Sony +81-466-30-4050 okawa@sm.sony.co.jp 22 Hiroshi Takizuka Sony +81-466-30-4050 takizuka@sm.sony.co.jp 23 Alistair Coles HP Labs +44-117-922-8750 anc@hplb.hpl.hp.com 24 Eric Hannah Intel 408-765-4441 eric_hannah@ccm.sc.intel.com +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S800 Long Haul Signees: 1 Colin Whitby-Strevens SGS-Thomson +441454611500 colinws@bristol.st.com 2 Charles Brill Amp 717-592-6198 cebrill@amp.com 3 Bijit Patel Lucent 610-712-2188 patelb@lucent.com 4 Mike Brown Intel 602-554-3713 mike_brown@ccm.ch.intel.com 5 Gene Matter Intel 916-356-4547 gene_p_matter@ccm.fm.intel.com 6 David James Express Associates 415-494-0926 dvj@ibm.net 7 Patrick Yu NEC 408-588-5436 pyu@el.nec.com 8 Raghunath Cherukuri Texas Instruments 972-480-3384 crn@msg.ti.com 9 Rajiv Choudhary Intel 503-264-8480 rajiv_choudhary@ccm.jf.intel.com 10 Sunny Lam IBM 512-838-6276 sunnyl@us.ibm.com 11 Shinichiro Matsui NEC [no phone number given] s-matsui@nims.nec.co.jp 12 Dao-long Chen Symbios Logic 970-223-5100 x9461 dao-long.chen@symbios.com 13 Bradley N. Saunders Rockwell 714-221-6513 bradley.saunders@nb.rockwell.com 14 Hiroaki Kobayashi NEC [no phone number given] kobaya@nims.nec.co.jp 15 Hideki Negishi NEC [no phone number given] negishi@kansai.nims.nec.co.jp 16 Eric Hannah Intel 408-765-4441 eric_hannah@ccm.sc.intel.com 17 Jerry Hauck Intel 408-765-5528 jerry_hauck@ccm.sc.intel.com 18 Richard L. Churchill Compaq 281-514-6984 richardc@bangate.compaq.com 19 Mike Winchell Symbios Logic 970-225-4807 mike_winchell@symbios.com 20 David R. Wooten Compaq 281-518-7231 davidw@bangate.compaq.com 21 Steve Midford Intel 408-765-8370 steve_midford@ccm.sc.intel.com 22 Taka Fujimori Sony +81-3-5488-6353 fujimori@arch.sony.co.jp 23 Sumihiro Okawa Sony +81-466-30-4050 okawa@sm.sony.co.jp 24 Hiroshi Takizuka Sony +81-466-30-4050 takizuka@sm.sony.co.jp 25 Alistair Coles HP Labs +44-117-922-8750 anc@hplb.hpl.hp.com 26 Kazuyuki Abe NEC System Lab 415-528-5904 kabe@sj-pceg.ccgw.nec.com