InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ieee / p1394 / min_mail / mn920624.txt < prev next >

Wrap

Text File | 1992-07-19 | 41.2 KB | 951 lines

P1394 High Performance Serial Bus Minutes 6/24/92 Page 1 Printed 7/20/92 Thursday, July 16, 1992 To: P1394 High Speed Serial Bus Interested Parties, Subject: Minutes for June 24, 1992 Sofitel Hotel Minneapolis, MN USA Secretary's Report: Ken Stewart, NCR Minutes of the IEEE P1394 working group, held on June 24, 1992 at the Sofitel in Minneapolis, MN, colocated with the X3T9.2 meetings. The meeting was called to order at 9:08 AM with the following attendees: Peter Bartlett Charles Brill Ed Cady Mike Chastain Lee Cleveland Forrest Crowell Tom Debiec Ronald DeRemer John Disbrow Frank Duffy Greg Floryance Giles Frazier Richard Fryer Edward A. Gardner Charles Grant David B. Gustavson Emil Hahn Bill Ham Norm Harris David Hatch Mike Holt Phil Hughes Dr. David V. James Skip Jones Sam Karunanithi Lawrence J. Lamers Michael Lazar John Lohmeyer Don May Gene Milligan Rich Mizia Charles Monia Richard Mourn Vit Novak Scott Petler Thomas J. Potyraj Curt Ridgeway John Scheible Robbie Shergill Robert N. Snively Jeff Stai Ken Stewart Ken Terlep Pete Tobias Bob Whiteman Raymond Yule Agenda: - Revision 5.1 Document Status - Connector Status Report - Backplane Status - JTAG - Prototype Status - 8b/10b and Coding issues - Link Layer Changes - 8b/10 Patent Policy - Retry Mechanism - Clock Recovery PLL Synchronization Time - Bandwidth Sharing - Isochronous Timing - DS Link Coding - DC signaling Connector Working Group Report: Dave Hatch (Stewart Connector) Two meetings have been held this month; one in Harrisburg last week and another meeting here at the hotel [hotel Sofitel in Minneapolis] yesterday. We discussed the problem of gold flaking off the pins onto the plastic IBM has volunteered to test this. Our goal is to create a connector that will withstand 5,000 insertion cycles. The contact surface was 5 mils, which should give a good connector. To permit hot plugging, the ground should make contact first. Dave needs direction from this group; is hot plugging important? Ed Gardner said, "This interacts with DC signaling, we need ground contact first." An IBM representative had queried their AS400 people, who say that ground should mate first. Q: How much extra will this cost? A: Dave doubts that this feature will cost as much 5 cents, probably more like 1 cent extra per connector. After brief discussion, the group decided that this is important enough to require it. Resolved: The connector should make ground contact first and break ground contact last. Dave's group also looked at Radio Frequency leakage from the male to female mating shells. There will be significant RFI concerns, especially with 200-400 Mb/s transfer rates, so we must design the shield to work well. Dave asked: Is the FCC guideline adequate or should we use something else? A: Yes, FCC is adequate. Dave says we will need to add more detents to the connector shell to give satisfactory shielding. Someone asked: should we follow the IEC standard. Mike Teener said that it is useful to point to these kinds of standards rather than invent one yourself. Dave will consider this and report back. The complete name of the standard is: International Electrotechnical Commission standard 512-23a, Shielding Effectiveness at 100MHz to 19GHz. Dave continued by saying that if many surface mount pads are mounted in a plane, it might be better to have a through-hole connector. Sun would vote for through-hole. DEC opposes that. NCR favored surface mount. Perhaps we should specify the footprint for both. A quick vote showed that 12 people (not companies) want surface mount; 3 want through-hole. Seagate wants straddle mount surface mount. Ed Gardner (DEC) wants a bulkhead straddle mount connector. The current vertical mount connector is through-hole only. Five people are interested vertical mounting; 4 want through-hole, none want surface mount. Dave gave a brief update on the cable. It is just under 0.2 inches outside diameter. The interior is very tight, with an impedance of 75-95 ohms. We can get up to 110 ohms by increasing the diameter. AR; Dave Hatch: tell us the attenuation in dB per meter. Continuing, Dave said that we need to reach a settlement on the gauge of the power pair. It would be nice to have a single connector. The problem is that 25 meter cable requires 19 gauge wire, while 5 meter cables require the much smaller 24 gauge wire. The small size of the overall connector implies small pins that will not easily support the heavy 19 gauge wire. Florin Oprescu selected 19 gauge from engineering requirements and standard wire gauge charts several months ago. Today, somebody declared that 19 gauge is not readily available; we will probably pay extra for it. It might be better to use 18 gauge wire, which is widely available. However, 18 gauge wire will be even more difficult to fasten to the small connector pins. This heavy gauge is necessary only for the proposed 25 meter cable. At 10 meters, 22 gauge is satisfactory. At five meters, 24 gauge wire is all that is necessary. The important thing is to maintain a maximum voltage drop of 0.5 volt drop per hop. Q: What is ground in this? A: Negative power supply. Everything about the cable is specified "per hop." Apple reports that less than about 2% of interested Apple parties want 25 meter cables. Given the requirement for 19 gauge wire for 25 meter cable, is anyone interested in 25 meter cables? Silence. (Editor╒s note: after doing more homework, the actual power supply wire requirements are 26 gauge for 2m, 24 gauge for 3m, 22 gauge for 5m, 19 gauge for 10m, and 15 gauge for 25m.) Greg Floryance tried to prototype a 1394 device. He found that there is no standard for internal connectors. His interest is in connecting internal disk drives, say 1.8, 2.5 and 3.25 inch form factors. His box has its own power, separate from the cable power. He has a problem with the PHY chip needing power from the cable. Greg thinks it will be useful to have other signals, beyond what 1394 specifies. Greg also wants hot plugging. Concurrent maintenance is a different issue than plugging into a hot bus. It is one thing to merely add or remove a device from a live bus. Concurrent maintenance, on the other hand, means replacing a dead device while the rest of the system carries on. If the dead device is in the middle of a chain, and you unplug the cables, then one end of the chain looses contact with the other. It is not even possible to connect the cables to each other because they will both be the same sex. Greg kept referring to a dual ported device, but after a little discussion, it was decided that Greg's use of the word "Dual-Port" is not correct. The fact that 'dual-port' means something else only confused people. We did not come with a good phrase that means simultaneous connection to two ports via connectors. Greg proposes a new internal connector having 25 pins. Four pins would supply signals to the right-side device; four for the left; the center pins would carry power and ground. However, we still don't have concurrent maintenance. The chairman declared that we don't have time to discuss this today, but he (Mike Teener) encourages interested parties to get together and bring back recommendations. Notice: The connector system issue's meeting will be on Wednesday evening July 22 in Rochester, Minnesota, collocated with the SCSI working group meeting. Dave Gustavson pointed out that other things might have to come into a device besides the P1394 signals. He suggested that Dave Hatch investigate mounting the PHY chip in the connector. Hatch replied that he would be happy to read a paper on it (chip in connector) but won't carry the torch for it. Greg supported Dave Hatch by saying, "the connector people will do exactly what we tell them to do. It is up to the committee to decide these kind of architectural issues." Dave was very happy to hear this. The question came up, "Does anyone have ideas on what the worst case number of mating cycles should be?" Some people bring home their laptops every day, giving 2 to 4 mating cycles per day. Dave Hatch asserts that you have to ask "What does 5000 cycles mean?" What happens after 5001 cycles? Can you expect 6000 cycles on a connector rated at 5000? Experience has shown that whenever there is a rider and a flat spot, the flat wears first. In the current proposal, the bulkhead connector has the flat. Therefore, the current proposal assumes you will throw the computer away and save the cables. Hmmm. Backplane Report: Kim Clohessy (DY 4 Systems) Many things have changed in the cable spec--8b/10b for example. First we looked at gap times. Different technologies give different clock speeds in a backplane. You can expect BTL to deliver 49 Mbit/s; TTL gives 12Mbit/s and optimized TTL 24Mbit/sec. Some people proosed extra ID bits and Rate Monotonic scheduling, but after it was pointed out that this would slow down all arbitration just for this one rarely used feature, the proposal was dropped. The detailed minutes of the backplane task group are attached to this note. The next meeting will be in July colocated with the Futurebus meetings. Prototype Status: Mike Teener (Apple Computer) The transceiver chip was taped-out two weeks ago. (Tape-out refers to sending a magnetic tape to shop that makes photo-lithographic masks for integrated circuits.) The Link chip simulations should have been finished Monday or Tuesday, unless Jim collapsed. Bill Duckwall's arbitration IC is progressing; simulations look good, performance is up, gate count is up (not good). This version has the clocked NRZ signaling method. It runs at 98.304 Mb/s. Felix (the link chip) has 46,000 gates, of which 12,000 are required for 1394. The rest is for FIFO's and Apple's own massive DMA requirements. Link Layer Changes: Pete Bartlett (NCR) Mike Teener and Pete Bartlett have been working on the protocol state machines. Pete gave a brief report on some minor changes they have made to the specification. There was a redundant way of sending cycle start packet; Pete removed the link layer method. He also added a way of resetting the state machine. Pete also removed a redundant path in state machine having to do with the unified request response. Pete made a lot of cosmetic changes in the transaction layer. He added a way to handle a missing ACK. Mike Teener added the retry mechanism he discussed last time. Break 10:40 - 11:00 DS Links: Forrest Crowell (SGS Thomson) In this proposal, there are still two wires but one is for data and the other is a strobe. The clock is an XOR of the two. They like to use the word "autobaud" to describe this system because every bit *could* be transmitted at a different rate and the data would still be received properly. This is advantageous in battery powered applications. Also, a PLL is not required. (Chair╒s note, these are general characteristics of all explicitly clocked systems, including the present P1394 centered data scheme). Another advantage is that the clock internal to the chip is 1/2 the bit rate (Chair╒s note, this is not quite true ... the DS link uses a clock at 1X the bit rate, 1/2 the baud rate, while the current P1394 centered data scheme requres an internal clock at 1X the baud rate). The transmission method causes a potential smearing out the RF spectrum since the clock is not a constant frequency. In the worst case, however, the signal has the same frequency content as the current scheme. This occurs with a continuous stream of 1's or 0's. An alternating 1╨0 pattern causes the frequency in the cable to be 1/2 the bit rate. Signaling is based only on the order that edges are received. Therefore, there is less sensitivity to skew. It is possible to build a dynamic de-skew circuit using a variable delay line. To train the delay line it would be necessary to generate simultaneous edges, which is not normally allowed. Q: Does this need training pulses? A: We are currently looking at 2000 characters. The old 4b/5b method of signaling originally in P1394 used a similar delay line de- skew concept. It performed de-skew on both edges, and consequently needed only two edges to set the delay lines. The DS links signaling scheme is not currently DC balanced. However it may be possible to revise the coding to achieve DC balance. Pete Bartlett (NCR) said, "If we start with 8b/10b then run through this, we could reduce both the skew and the internal clock requirements and still have DC balance." "Currently we need twice the clock rate, which is hard to do at 400 MB/s and causes power consumption to go way up." Ken Stewart said, "I hope we are not proposing to license both 8b/10b and DS links." Inmos Test data: An experimental 10 meter, 138 Mb/s DS Link ran for 790 hours with no errors. That gives a bit error rate (BER) of 5x10**-15. It was also tested at 30 meters and 75 Mb/s with no errors. The test chip was driven with AT&T 41M series pseudo ECL chips. Inmos will obtain a P1394 cable from Dave Hatch and run the same test on our cable. Licensing: SGS Thomson would not force the entire DS Links protocol on us. They are willing to license just the signaling. AR: Peter More; bring back licensing information. AR: Forrest Crowell, Peter Moore; give us DC balance. In the discussion that followed, someone said that 8b/10 is attractive because it has DC balance and is used in Fibre Channel. Working circuitry already exists. Forrest countered by saying that this (change to DS signaling) would be an extremely simple change. There is no increase in complexity. Furthermore, it gives a more robust and flexible physical interface. Forrest asked, "How do we train now?" A: We don't because we have a clock. Mike Teener continued the theme, "Start of clock defines beginning of packet." "End of clock defines end of packet." "ACK's are eight bits long exactly." "Data is never 8 bits exactly." There was discussion over whether we should proceed and set the standard according to Apples production schedule (using 8b/10b) or look for the best solution. Steve Cornaby (Conner Peripherals) tried to talk about his three wire adaptation of DS links, which is free, but was quickly silenced by protests over adding a third shielded-twisted-pair into the cable. If we are going to do this, lets get the advantages of both: DC balance and lower skew and lower internal clock. Pete Bartlett will help. Contact Pete Moore moorep@inmos.co.uk Forrest Crowell crowellf@isnet.inmos.com 8b/10b Patent Issue: Ken Terlep (IBM) Ken can't declare exactly what the terms will be. That goes through IBM corporate headquarters. However the intent is to be same as Fibre Channel; the license would be a $5000 one agreement for each manufacturer. It would apply to IEEE 1394 only. IBM management will get a letter to the P1394 chairman within 30 days. Q: Can we get a policy statement from IBM to use 8b/10 for all IEEE and ANSI standards, rather than wait until IBM wanders into a committee and proposes it? A: No. It is case by case licensing. IBM needs a formal request from each standard. Q: Would it be better for some of the officials of the IEEE and ANSI committee to reach a position on licensing issues? Dal Allen replied, "Currently there is a proposal to the ANSI officers to do just that." Dal Allen "The use of this interface crosses more boundaries than any other interface, so I'm concerned that this is going to make it difficult for plug compatibility." "I am looking at setting a standard for plug compatibility." "We may set up a trade association." "Anybody who is interested in being on an email distribution, please sign the list." Lunch 12:11 - 1:45 PM Shameless Advertising: Ken Stewart (NCR) Ken Stewart (NCR) invited everybody to view a joint demonstration of NCR's new Media Interface Controller (MIC) chip and AT&T's optical transceivers at 5:00 PM that evening. MIC is a 266 Mb/s transmitter and receiver in one CMOS chip, intended for Fibre Channel. Combined with AT&T's 1300 nanometer LED transceivers, the system was working reliably on 3 kilometers of fiber optic cable, which is three times the Fibre Channel distance limit for this configuration. Latest Draft Mike distributed revision 5.1 of the P1394 specification. He noted that this is a ╥working group only╙ version. A more complete version would be available later. Clock Recovery: Ken Terlep (IBM) Ken commented that he was playing virtual Jerry Marazas today, referring to the fact that Jerry had volunteered to make this presentation. They (at IBM) took a look at the size of the preamble required to sync up to the bit stream. Using only the K28.5 character (one of the control characters in IBM's 8b\10b code--K28.5 is also the idle character in Fibre Channel). it takes between 2 and 5 characters. Five is the upper limit. They are working to narrow that number down, but today, they can report that the number of characters required to synchronize a clock recovery circuit would not be more than 5. They had assumed positive disparity on the first character for these tests. A Proposed AC Signalling Scheme: Ron DeRemer (IBM) The 8b/10b code gives DC balance to P1394 data. This would permit AC coupling except that the P1394 arbitration uses DC signaling. This is a quick look at one possible way to replace DC signaling during arbitration. One of the main goals here is to eliminate the separation between PHY and LINK chips currently required for DC isolation so they can be combined into one single chip. Ron tried to minimize changes to P1394. DC power carried in the cable will also need isolation, and that is slightly more complex, however it is certainly do- able. Transmit and receive are half-duplex while arbitration is full duplex. Ron proposes an encocing with the ╥1╙ signal = clock /2; a ╥0╙ would be clock/4; and the ╥Z╙ signal would be indicated by clock/8. Signal amplitude will stay the same. We will need some hysteresis on the receiver, maybe 120 mV. There is no need to change hysteresis for different speeds. When idling, the transmitter outputs could be at high z and the chip clocks gated off. For arbitration, we'd detect transitions on tpA, then turn on the chip clock to the arbitration logic. To transmit or receive, we'd turn all chip clocks on. This frequency modulation scheme permits an all digital CMOS chip as opposed to current proposal with analog components requiring high precision resistors. Pulse transformers cost about 15 cents. Q: How can we detect detected or unconnected ports? A: No answer yet. The committee then articulated this list of requirements and desires for any improved signaling scheme: - Tolerate 10 volts ground offset. - approximate DC balance - 3 volt to 5 volt compatibility - allow DC coupling - detect addition of a node in 0.5 seconds - detect deletion of a node in 5 seconds - power dissipation no higher than current Desires - highest breakdown voltage as long as it's free - no difficult transistors (precision analog) - 2 volt operation - desire .005 second detection of addition of a node and .5 second detection of deletion - eliminate high precision resistors - off-shelf transceiver - separate PHY and LINK chips (long discussion of backplane versus cable) AR: Mike will distribute the requirement/desires list and invite proposals via the reflector. AR: Mike will ask Roger and Florin to do a comparative analysis of AC-coupled and DC-coupled systems. Priority Arbitration: Dave James (Apple) In the early days of serial bus, everybody had an ID so it would work on the backplane. However, these bits are not needed on a cable. Currently it is permissible to send only one packet between any two arbitration reset gaps. Dave's new proposal: A fair node does exactly the same. An unfair node sends one packet fairly and some number of packets unfairly. We could assign bits in the packet to determine how unfair a node can be: 00 = fair 01 = sends 2 times as many packets as a fair node 10 = sends 4 times as many packets as a fair node 11 = sends 8 times as many packets as a fair node There was some discussion that maybe we should architect the spec such that it is impossible to arbitrate unfairly. The general feeling was that you couldn't do that because you can always find a way to break the rules, unless we cripple the spec to the point of uselessness. Another point was that four levels of fairness seems excessive. Perhaps it is better to only use one bit, with two states of fairness. Either have high priority or low. Consensus As we began to wrap up the meeting for the day, the IBM people requested a vote as to whether 8b/10b should be included in the spec. Mike explained that the way he has been handling issues as this is look for consensus on all issues: to make changes if there is no objection, and then double check at the next meeting. If there is still no objection then it stays. Nevertheless, the dozen-or-so IBM folks wanted a vote Here are the results: Issue: in favor opposed DC balanced code 16 00 DC balanced arbitration 10 00 8b/10b encoding 10 00 self clocking code 03 12 clocked 8b/10b code 16 00 current DS links (no DC balance) 00 11 (Chair╒s note: there was a lot of abstention on the DC balanced arbitration and the 8b10b code. This is a sure indication that these subjects are not as well understood as they should be. Roger and Florin will be coming back with some analysis of the costs and benefits of AC-coupled arbitration, and the new 5.2 spec has the first drafts of the 8b10b text, so we should get better information soon.) Meeting adjourned at 4:45 PM Chair's Report: Mike Teener Working Group Document Access Bob Snively of Sun is the manager of the P1394 Internet email reflector. To send a note to the entire P1394 community with Internet access, send a message to "p1394@sun.com." If you want to be added to the reflector, please send a note to Bob at "Bob.Snively@eng.Sun.com" and copy me at "teener@apple.com." I strongly suggest that you join the reflector if you want to follow what is going on. If you absolutely cannot get access to the Internet, and you will be making contributions to the ongoing conversations, then I can FAX the proceedings to you once a week or so ... but any of your contributions must be put on a Mac or PC-format 3.5" floppy in plain-text format and shipped to me. Note to all AppleLink users: you can get access to the reflector via "p1394@sun.com@internet#", and the address you send to Bob Snively is: "(your alink ID here)@applelink.apple.com." All p1394 documents given to me in electronic form will be made accessible on Apple's ftp server "ftp.apple.com" in the "pub/standards/p1394" directory. The draft standard is kept there in both MS Word for Mac and PostScript format. Subsciptions to the working papers (drafts and meeting contributions) can be obtained from the IEEE Computer Society office in Washington, DC, at +1-202- 371-0101. Ask for Brenda Williams and mention account code 070-4351-0222. There are two task groups associated with P1394, and an interest group: Cable and Connector Task Group: David Hatch Stewart Connector Systems R.D. 2, Box 2020 Glen Rock, PA 17327 Voice: 717-235-7512 Fax: 717-235-7954 Backplane PMD (physical media dependent) Task Group: Kim Clohessy DY4 Systems 1 Fitzgerald Rd. Nepean, Ontario K2H 9J4 Canada Voice: 613-596-9911 Fax: 613-596-0574 JTAG Interest Group: Lee Whetsel Texas Instruments 6500 Chase Oaks Blvd Plano, TX 75086 Voice: 214-575-2601 Fax: 214-575-6198 (Lee has been busy with other work lately, so I am searching for a replacement.) Action Items 1) (Teener) Put in ╥actions╙ for the state machines (continuing). 2) (Teener/James/O╒Connor/Gardner) Flesh out the management sections (continuing). 3) (James) Module/node configuration CSR wording (continuing). 4) (VanBrunt) Cable physical layer electrical interface update (continuing). 5) (Hatch) Connector and cable specification update (continuing). 6) (Backplane task group) Priority arbitration number uniqueness. (continuing) 7) (Clohessy) Bus backplane implementations. (continuing) 8) (Mike Teener) What happens to arbitration protocol if cable is too long or has too many nodes? (continuing - part of error analysis) 9) (Oprescu/Hatch) Estimates of cable cost versus cable length and transmission speed for 5 and 10 meters and 100 and 400 MB/s. (continuing) 10) (Everybody) Should we code the data? (closed, yes we do) 11) (Teener/Bartlett) Link layer updates (continuing). 12) (Marazas) IBM patent policy for 8B10B (continuing, partially complete). 13) (James/Gustavson) Improved/optional retry mechanism -- model to show why this is important. 14) (Marazas) Requirements for IBM clock recovery startup: number of edges needed (closed, but additional information may be coming). 15) (James) Bandwidth sharing protocol improvements (continuing, partially complete). 16) (Teener) Isochronous timing for IMA rate signals. 17) (Hatch) Attenuation in dB per meter. 18) (Moore) DS link icensing information. 19) (Crowell/Moore) DC balance on the DC link. 20) (Teener) Convert draft to FrameMaker format. 21) (Oprescu/Hatch) Cable spec for higher speeds. 22) (VanBrunt/Oprescu) Comparative analysis of AC-coupled and DC-coupled systems 23) (Mike Teener) Draft 5.3 (to be distributed at August meeting). Meeting Schedule The next meeting will take place on: August 19, 1992. BOEING Computer Services, Seattle, WA (jointly with X3T9.2 ╤ SCSI). Host: Everett O. Rigsbee (+1-206-865-7364). See attached note for details. The schedule for the next few months is ... September 15, 1992. NCR , Colorado Springs, CO. Host: Ken Stewart (+1-719-596- 5795, kstewart@ncr-mpd.FtCollins.NCR.COM). See attached note for details. Week of October 5 (probably the 6th, 7th or 8th), 1992. Boston, MA. Host: Ed Gardner (+1-719-548-2247, gardner@ssag.enet.dec.com). The schedule will be finalized at the August meeting. Agenda for the next meeting 1) (Teener) Draft status. 2) (Hatch) Connector task group report (including cable cost estimates). 3) (Clohessy) Backplane task group report 4) (all) JTAG interest group leader recruiting. 5) (Teener) Prototyping status. 6) (VanBrunt) Cable Physical Layer update. 7) (Oprescu) Cable PMD tests and update. 8) (Teener/Bartlett) Link Layer doumentation update. 9) (James) Improved/optional retry mechanism -- model to show why this is important. 10) (Marazas) Requirements for self-clocked systems: preamble, end-of- packet. 11) (James) Bandwidth sharing protocol improvements. 12) (Teener) Isochronous timing for IMA rate signals. See you in next month ... Sincerely, Michael Teener Attachments: August meeting details Clohessy - backplane task group reports (many more attachments to printed minutes) ======================================= To: ASC X3T9 Committee Members, Liaisons & Attendees From: Everett O. Rigsbee, Boeing Computer Services Subject: Meeting Announcement: Bellevue, WA, August 17-21, 1992 The August 1992 meeting for the ASC X3T9 Committee will be held at the: Hyatt Regency Bellevue 900 Bellevue Way NE Bellevue, WA 98004 Phone: (206) 462-1234 or (800) 233-1234, FAX: (206) 451-3017 Hosted by: BOEING Computer Services during the week of August 17-21, 1992. For this meeting a block of 250 rooms has been reserved which will be available only to X3T9 attendees. Please be sure to identify yourself as an X3T9 attendee when making your reservation by phone or use the reservation mailer provided to insure that you get a room from our block at the discount conference rates. The Conference rates are as follows: Single: $97.00, Double/Twin: $107.00 per night plus a 13.6% room tax. The Hyatt Regency Bellvue has provided a pre-printed reservation form for making your reservations in advance, or you may call the numbers above any time prior to the deadline. Please note: RESERVATION DEADLINE is July 27, 1992 !!! Reservation requests received after this date will be accepted on a space available basis only, so don't be late! You don't want to look for a place short term in August. The Hyatt Regency Bellevue is conveniently located at the center of Bellevue just across the street from the Bellevue Square Mall. There are many shops and restaurants located within easy walking distance. There are shuttle services which will bring you to/from the airport and the hotel for a nominal fee, so I recommend not using a rental car because the hotel parking will cost you about $10 a night. If you want to go sightseeing you can rent a bicycle. To reach the hotel by car, take I-405 North as you exit the airport and go about 15 miles North until you pass the exit for I-90 East & West and go through a tunnel. The first exit after the tunnel is for "8th Ave SE"; DO NOT take this exit. The next exit is for 4th Ave NE and 8th Ave NE; take this exit keeping to the right, then left and then right to 8th Ave NE Westbound exit. Go 5 blocks West on 8th Ave NE to Bellevue Way, turn right and the 1st driveway on your right is the entry to the Hyatt Regency Bellevue. They will direct you to their underground parking. I am looking forward to seeing all of you in Bellevue, Washington! Sincerely, Everett O. Rigsbee, Boeing Computer Services, (206) 865-7364 ======================================= MINUTES OF THE JUNE 23RD BACKPLANE TASK GROUP MEETING Minneapolis MN Attendees Kim Clohessy DY 4 Systems 613 596 9911 Thom Potyraj JHU APL 301 953 6598 Frank Duffy NRaD 619 553 3404 Mike Dorsett NAWC 317 351 4809 Mike Teener Apple 408 974 3521 Dave Gustavson SLAC 415 961 3539 Fred Sauer Paramax 612 456 2244 Bruce Dunlop CDI 612 921 6811 Emil Hahn Motorola 602 962 3133 Patty Smith NAWC 317 351 4104 Matt Drobnik NAWC 317 543 2863 Tom Porter Raytheon 508 490 3618 Agenda Introductions Approval of the Agenda General Comments Kim Clohessy Clock Speeds for Different Bus Types Thom Potyraj e.g. VME, NUbus, FB+ Arbitration Thom Potyraj Priority Bits Bridging Discussions Document schedule Kim Clohessy Encoding NRZ vs 8B/10B Polarity of Timing Diagrams Next Meeting(s) The meeting was called to order at 1:30 PM General Comments The following comments where made by Kim Clohessy The mission of the Backplane Task Group is "Provide the input for the paragraphs set aside for the backplane version of Serial Bus in the current P1394 document." This is mainly clock speed and signal characteristics. The mission has expanded to include a review of the arbitration mechanisms and timing to be used by the backplane version of Serial Bus. The backplane group should provide input from a backplane perspective into the overall operation of Serial Bus The following backplanes are being considered FB+ BTL VMEbus TTL NuBus TTL Fastbus ECL Other busses can be considered in the future. The following general procedure will be followed by the task group: Identify the paragraphsor sections that affect the backplane implementation of Serial Bus. Develop the appropriate wordingfor these sections. Determine what additional specification material is required. Submit to the P1394 editor for inclusion into the P1394 document. Arbitration Times Thom Potyraj walked through an analysis of the timing requirements for arbitration on the backplane version of Serial Bus. This included a discussion of gap timing. The following points were made during the general discussion that followed. 1. Because the cable version has adopted a totally new approach to arbitration based on line states, the backplane group effectively was free to develop its own arbitration method optimized for backplane environments. 2. It was suggested that we no longer use an "arb-high" for each arbitration bit. It was agreed that we should look into replacing this with a synch bit (a "1") at the beginning of the arbitration cycle. This will reduce the overall time for arbitration by a small amount, and may reduce the complexity of the interface. 3. It was stated that the sampling ambiguity between cards is in the order of 40 nS, made up of 20 nS for transmission line effects and 20 nS for sampling and decision making. (Note: if we assume a 50 MHz clock for on-board state machines and we decide double sampling is required to harden against metastability, we may need to extend this by another 20 nS - more analysis is required). 4. The acknowledge gap is set at 10 bit times. This is the time from the last data bit until the time the responder asserts the data line to "busy" the bus. 5. The sub action gap will be set at 10 bit times plus 1 generous backplane round trip delay (Suggestion set this at 2 bit times i.e. total of sub action gap = 12 bit times) 6. The fairness arbitration gap will be set at 10 bit times plus 2 generous backplane delays. (suggest we set the fairness arbitration gap to 14 bit times). 7. It was recommended that we use nanoseconds in the timing specification but include in Appendix B the analysis backing up the derivation of the value. 8. There are two cases for arbitration, the first is arbitration directly following an a bus transaction, and the second is arbitration when the bus is idle. It was decided that solving the second case can handle the first. Basically modules wishing access the bus wait until there is no activity on the bus before asserting their first arbitration bit (the synch bit). Modules must however distinguish acknowledge gaps from sub action gaps etc. Clock Rates 1. The clock rates for the several different backplane buses were proposed Clock Rate Data Rate MHz MHz FB+ BTL 24.576 49.152 VMEbus TTL 12.288 24.576 if SSBLT works out 6.144 12.288 if standard VME is used NuBus TTL 6.144 12.288 FastBus ECL 24.576 49.152 For TTL backplanes it is necessary to operate the drivers in open collector mode during arbitration and totem pole during data transfer. 2. Silicon implementers should set up dividers to accommodate the multiple data rates. Priority Bits There has been some discussion about increasing the number of priority bits. The current spec has 1 bit, Dave James has suggested adding two more bits into the packet. There have been some discussions about allowing for 8 or even 16 bits. Serial bus basically provides bandwidth allocation during the fairness interval. Using the urgent mode and two addition bits suggested by Dave James will increase the bandwidth available to each module. It will not however address latency concerns. At this time the backplane group will leave further discussion of priority to the general 1394 working group. Bridging It appears that a bridge between the backplane version and the cable version of Serial Bus is both required and desirable At this point it is assumed that one of the cards in the backplane would hold the bridge.Bridging is an area of general discussion, not just a backplane issue. Items to consider are different clock rates, isochronous operation, the concept of a "half bridge"and address management. Document Schedules Michael Teener made available a copy of 5.1v1 for review and comment. He indicated that he would plan a working group ballot for the September time frame and Sponsor ballot before the end of the year (Michael admitted that this was optimistic.) The sub task group will target getting the majority of its input in by September. 5.1v1 will be reviewed and sections identified before the next meeting. It should also be possible to document the driver and receiver characteristics before the next meeting. (Heavy use of EMAIL). Data Encoding The cable community is considering 8B/10B as a data encoding method. The backplane group felt that this was not required for the backplane version and will stick with NRZ. Polarity The polarity of waveforms shown in the document is confusing, especially to the TTL and BTL backplane communities. It was agreed that waveforms should be show as would been seen using an oscilloscope on a real backplane and that logical diagrams should use register representations. Next Meeting The next meeting will be held in Del Mar, Thursday July 16th 92 in conjunction with the FB+ meeting. Call VITA (602) 951 8866 for details about the hotels etc. Please send comments or questions about the minutes to me Kim Clohessy at 70720.2071@compuserve.com ====================================================================== Update of Backplane Sub Task Group Activities Since the Last Meeting Since the last meeting we (Thom Potyraj and myself) having been looking at the details of arbitration and gap timing for BTL (FB+) and TTL (VMEbus) backplanes. At this point our approach has been the following: 1. Assumes that the implementation will have a base clock of 49.152MHz. The silicon designers I have discussed this with feel comfortable with this number. Much higher and the design gets tricky especially over full military temperature ranges. We assume that state machines will be clocked at this rate. (20.34nS) (i.e. on only one edge) This period is referred to as the Base Rate Bit Time 2. We are working with the assumption that BTL and ECL implementation will transmit data at a rate of 49.152 Mbits/sec. TTL-VMEbus implementations are looking at a rate of 24.576 Mbits/sec. At this point TTL for NuBus is 12.288 MBits/sec. 3. We have reviewed various options and will make the following recommendations at the next backplane meeting. a) The SBUS_A be renamed to SBUS_DATA and SBUS_B be renamed to SBUS_CLK. b) The removal of the "arb-high" part of an arbitration bit in the arbitration sequence. c) The SBUS_CLK be used to (in addition to clocking data) i) signal the start of an arbitration sequence rather than using a the arb high or a sync bit ii) hold the bus between winning arbitration and transmitting data iii) by the responder to hold the bus until it can transmit an acknowledge packet iv) signal the end of a data packet d) A recommended arbitration sequence will be presented for discussion. The suggested arbitration bit time will be 6 base rate bit times (122nS). The arbitration bit sample delay is 4 BRBT (81.68nS). These numbers are based on the following assumptions. i) the assertion of SBUS_CLK is used to signify the start of the arbitration sequence ii) transmission of high to low signals are incident wave. This should be true for BTL, ECL and the TTL implementations using the new driver and receiver specifications be developed for REV D of VMEbus. iii) The one way transmission propagation delay is less than 20nS for all technologies and allowable bus length iv) The sampling clock is 20.34nS max v) The maximum delay from sampling an idle bus state to asserting the SBUS_CLK line is in the order of 35nS. This is to ensure the maximum skew between arbitrating modules meets the sample and hold requirements. A detailed waveform will be presented at the meeting for discussion. e) To allow for precise timing of gaps it will be recommended that the first data bit be sent with a rising edge of SBUS_CLK. This means the last bit will be on the falling edge of SBUS_CLK. Further that the "sender" hold the SBUS_CLK line for several addition clock times before releasing the line. This will allow more precise detection of the end of the packet and hence the start of the gap. f) Based on e) the ACK_GAPs are gaps at the end of data packets that are "expected" by the responder. To distinguish Sub_Action Gaps from ACK_GAPs, the Sub_Action Gaps will have a minimum length of 6 bits (122nS). To distinguish Sub_Action gaps from Arbitration Reset gaps the Arbitration Reset gap will have a minimum length of 10 bits (203nS). Any time greater than 203nS can be interpreted as a Arbitration Reset Gap or an idle bus. g) Modules that come "on-line" will not drive the bus (generate glitches) and must wait for a Arbitration Reset Gap before arbitrating for the bus for the first time. This will ensure that the PMD state machines are "synchronised" to the bus activity. I assume the implementation of PHY state machines will track the bus activity even if the module is not actively participating in the transaction and especially when it waiting to get access to the bus. h) Recommended details for the TTL drivers will be presented. It is assumed that standard BTL drivers will used for FB+ applications. Currently the TTL transceivers have the following specifications: The transceivers shall meet the following specifications: Low-state sink current IOL 3 64 mA Low-state voltage VOL 2 0.6V at IOL = 64 mA High-state source current IOH 3 15 mA High-state voltage VOH 3 2.4V at IOH = 15 mA Minimum source current with IOS 3 50 mA at 0 V board pin grounded Maximum source current with IOS 2 225 mA at 0 V board pin grounded Maximum rise time in totem 2 nS pole mode Maximum fall time 2 nS When transceivers are turned off shall limit their loading to the following values: Current sourced by board at 0.6 V, IOZL+IIL 2 450 5A including leakage current Current sunk by board at 2.4 V, IOZH+IIH 2 100 5A including leakage current Total capacitive load on the signal, including transceiver, signal trace and connector shall be less than 16 pF. All of the above is presented as a baseline for discussion at the next meeting. Agenda for July 16th meeting 1:30pm (Del Mar) Introductions Approval of the agenda Approval of minutes of last meetings Arbitration Sequence discussion Gap Discussion Electrical Characteristics discussion Review of Document Sections Other items Adjourn Suggestions for other items should be forwarded to me as soon as possible. Kim Clohessy, Chair Backplane Task Group of P1394