P139b general session, Aston Wailea Resort, Wailea, Maui, Hawaii, Thursday and Friday, October 23 and 24, 1997 Chair: David Wooten Secretary: Richard Churchill Agenda 1. Introductions 2. Meeting Fees 3. Procedures 4. Review of Minutes 5. PMD Liaison Report(s) 5.1 Discussion of user model 6. Task Group Reports 6.1 Cable/Connector - Max Bassler 6.2 PHY-LINK Interface - Martin Sodos 6.3 Upstarts - Colin Whitby-Strevens 6.3.1 Overall report - Colin Whitby-Strevens 6.3.2 Possible means of toning - Jim Doyle 6.4 Standard Protocol - Alistair Coles (by proxy) 6.5 Accelerations - Dave LaFollette 6.6 Network Simulations - Prashant Kanhere 6.7 Standard Electrical - Eric Hannah 7. Proposed new task group - data flow - How do bits bytes/symbols move trhough the PHY? - How do we compensate colck rate differences? - Symbol padding or bit padding? - Are PHY delays data rate dependent? Are they clock rate dependent? - What happens if/when an S800 capable PHY has to run an interface at S100 Beta mode? 8 Link Budget Analysis 8.1 ??? 8.2 ??? 9. Meeting Schedule 10. Review of Action items 11. Adjournment 1. Introductions Introductions were made. 2. Meeting Fees Chairman requested that all participants ensure that they are properly billed so as to pay the $20 meeting fee to the P1394b meeting account here at the hotel. 3. Procedures Comments were made regarding procedure, and the attendance sign-up sheet was passed. 4. Review of Minutes The minutes of the previous meeting were accepted without objection. 5. PMD Liaison Report(s) It was decided that a liaison report for a meeting the vast majority of us attended just this morning was redundant, and could be dispensed with. 5.1 Discussion of user model The chairman raised concerns regarding the patience of the VESA and DAVIC groups, and suggested that we should re-examine our users' model to assure a solution that satisfies the needs of users, and of the committees that intend to use 1394 for home networking solutions. Colin commented that it is desirable to have a unified standard -- one that is not confusing to the users. There appears to be a divergence between the low-cost, long-haul group, and the high-speed, long-haul groups. The fact that the DAVIC liaison letter mentioned specific data rates is of some concern. The low-speed group originally went off to determine whether a low-speed solution was viable, but Colin commented that he was not sure about where things now stand. David Wooten presented a draft letter to the DAVIC Physical Layer Techni- cal Committee regarding communication of timing of the completion of the p1394b effort, and its accommodation of DAVIC requirements. <<< insert the text of the letter >>> [Are we looking for a unified specifications which may contain alternative solutions? If that is what is required, that's what we'll do.] Dick Scheel reported generally as follows regarding VESA requirements: VESA wishes to specify to the exterior wall of a home, but not to be at all concerned about what happens outside the home. They envision clusters within the rooms, and an interconnect medium within the walls to support interconnect between the clusters. The long-haul backbone within the home is envisioned as long-haul 1394, with the clusters attached via some device (a bridge, or such) translating to the physical interconnect media of the clusters. They envision something on the order of 19 Mbps data rates betwixt the clusters, and the need to support a number of different such streams being communicated between the clusters. They believe that 100 m is a desirable goal for the reach of the backbone system. They have also looked at wireless schemes, but with low bandwidth achievable over very short distances, on the order of between neighboring rooms. [Is there a worst-case scenario? It's all pretty open ended scenario, with consideration of both the low-end and the "Uncle Bill's house" high- end being considered. 100 Mbps rates were considered the absolute mini- mums. Fore the near term, they envision the low-end speeds early, but the higher end coming on. Do they consider the effect of long-haul gap counts and other effects? Not really, but they just care about getting the TV programming through. Are they simply overlooking the problems? For a number of the committee members they had to work up to the 100 Mbps rate, rather than considering the real issues of future data rates. Did they consider the fact that S100 will not carry four 20 Mb/s video streams? Not really, but sort of growing awareness. Did they consider computer requirements? No, they regarded that as asynch, and viewed it as a different problem. They just want sufficient data rates for the AV content they need. If you need more performance for the asynch material, you buy a higher performance system/implementation. ... You can now get MPEG-1 compression devices for about a $150 price ... Davic's model is asymmetric, but the VESA model is much more symmetric.] [There's 80 to 160 Mbits for the DAVIC material, and then whatever else you might have? Pretty much. Comments on bridges, and the distinction between user models ... If the only thing you care about is the 40 Mbps, this may be fine, but this may not be all that is going on? Will a PC expose the bus its HDDs are sitting on to the universe, or will they wish to use a bridge, much less complex than a Pentium, perhaps on the order of an 8086, with a second chip for buffers. Say about $10? This is pretty bad for the PC market. The preferred solution may be to put the bridge at the periphery of the long-haul backbone, which keeps the local gap counts smaller. Discussion of requirements and desirable ways to hook things together, avoiding dongles and such by placing components within wall plates. There is still an issue regarding the TIA allowing "active" components within the wall. ... Further consideration regarding where to put such things as bridges ... There are good questions regarding the location of the appropriateness of putting an optical connector, or a bridge in some components, since you may end up forcing everything to have these in case they are placed in a configuration without a compo- nent with the needed bridge or optical connector. We really need to be both flexible and future proof ... What we may need to change is what lies in the wiring closet ... Need to avoid "distress purchases" such as additional bridges ... ] 5.2 Discussion of Model by S100 representative We will prepare a formal contribution for the next meeting ... The problem is very simple. FY 99 00 01 02 | | | | -------------------------------------------------------------- | Low-speed, low-cost | | ------------------------+------------------------------------- / / / high-speed, low-cost / / -------------------------------------------------------------- The user needs a solution today, and we will need to meet it. [So you have a solution that doesn't expose the user to anything to any other interface than the 6-pin connector. So, you are selling these in pairs, and what's between is proprietary? Yes. What are the licensing issues? Don't know, but think reasonable. Could be different connectors on each end of the fiber. Plan to use p1394b's 8B/10B code. This is for professional installation. Connector will never be on user equipment, and the intention is never to use this optical (or any optical) connector on any user equipment. I hope that at this point no-one will call this 1394, at least until it may be standardized. Why would you be unwilling to use GOF, as you have seemed to be in the past. You seem to be targetting this at the professional market ... Not really, though they are included. Hauck - I saw you present several different optical interfaces, which leaves me a bit confused, and I have doubts that 100 Mbps is adequate for the professional market. Why are you determined to go at this data rate? Who is demanding this? Will they be served by 100 Mbps? Plan is to get to S400 over POF. Colin - I see our job as to produce interoperable tech- niques. You seem to be solving problems without being concerned with the interoperability problem ... Wooten - If you don't standardize all the pieces along the path between 1394 connectors, what's in between is not 1394. You should be presenting a solution, then we the broader group decide whether this is what we need, and whether we can accept it. Comments that we really need to work together. There may be a miscon- ception of the task to be performed. If the group doing the low-speed work wishes to approach IEEE to standardize this, they may, but this task group should and will give the recommendation due consideration, and we may in the end accept and standardize it. This task group arose at the Eindhoven meeting of the TA, when the long-haul project was proposed, and the recommendation was to ask the p1394b group to parent it. We are at risk of serious interoperability problems when the 'b' group decides on a recommendation, and the S100 long-haul folks potentially decide to go their seperate way. We want the whole thing to be a single standard, not a set of conflicting products. Generically, what do we do with task group reports? We turn over the product of the task group to the group enditor, and then submit it to the review of the group as a whole. 5.3 Report of the S800 long-haul task group, by Colin Whitby-Strevens. The S800 long-haul group has not been well focused on the issues of user models, but upon, "How do we do high-speed, long-haul p1394b?" Connection Scenarioes - 1 1. Long-distance cable incorporating a dongle - Standardize the medium and the optical parameters *** diagram *** We have been working on transceiver component to transceiver component interoperability, regardless of the vendor of the separate ends of the cables. [The behaviours will be the same, as far as a 1394 device at either end is concerned? Yes. ...] 2. Long-distance cable incororating a dongle with passive wall-plate - standarize the medium, the optical parameters and the wall plate connector *** diagram *** Connection Scenarios - 3 5. Long-haul interface on the equipment - standarize the medium, optical parameters and the connector - much lower priority, but don't necessarily outlaw *** diagram *** What we are doing is try to specify the optical parameters, and the medium, with an eye to future proofing, and believe we have done that. We are now working on the selection of the optical connector. When that connector is selected, we can go out of existence or not as the group as a whole chooses. [Do you believe that there are any irreconcilable differences between you and the S100 group? Yes. I don't believe that they are trying to specify a single connector, etc., and the media are definitely different. ... For S800, we want to help people get to market more quickly by giving them a standard. There does not seem to be any point at which we would interface with each other. Does the S100 group plan to define means of interoperating with the 50 micron solutions of the S800 group? Yes (?), we will have a fiber-to-fiber interface/dongle specified. Has the S800 group plans to the level of a foot print of the transceiver, etc.? No. What about locating the transceiver behind the wall plate? There is much dispute on whether this is permissible under national electrical code, but the Smart House specification allows for power and other wiring domains to meet in accessible junction boxes in the wall, behind a wall plate. Having a 6-pin connector in the wall plate is much the preferrable solution, but as we are not certain of the legal issues involved, there is much confusion. We need to resolve this. I presume that the fiber in the wall should have a longer life than the transceiver in the wall plate? You have limits as to the power that you can inject into the wall. The limit is 24 VA. We can also put the circuitry into a lump on the wall. Perhaps the chair can ask the S100 long-haul group to present comparable user models. They need to resolve their own problems ... The reason we broke into two groups is that we had issues of implementation, and the cost of implementation. I don't think we can disregard POF. People we forget that POF can go 2 GBaud ... We don't know if we can get away with supporting both POF and a GOF media. The very clear mandate from the trade association was for a clear direction on the media to be installed inside the wall. There were several criteria. Another was taking the existing interface long-haul. We have serious problems in interoperability here. Our objective is and must be to make things completely transparent to the user. I can refresh my supply of the camcorders and PCs in my house faster than I can change houses. We must have a SINGLE solution that creates no problems for the user. ...] <<< adjournment until 8:30 AM Friday, October 23 >>> 6. Task Group Reports 6.1 Cable/Connector (Copperheads) - Max Bassler pIEEE 1394b Connector Task Group "Copperheads" Copper Interface for 800, 1600 and 3200 ... Task Group Ojbectives - Charter: To identify and document the copper interface (connector and cable) needed for ... - ... ... Task Group Ojectives (continued) Our guidelines are: - Meet ... ... Stated Plan - Develop selection criteria for copper interface and post on reflector 2 weeks before the 97/December meeting. review ... Requirements (?) User friendly model, latching option Cost is very important for boh computer and consumer interests The need for speed is a given - 800, 1600 and 3200 Mbs - Strong wish to have 1394-1995 interface operate at 800 Mbs (or higher?) Background ... ... Issues Feedback from Copper TG Meeting October 13, 1997 - Address speeds of 800 and 1600 as a priority, plan for 3200 Mbs. - Cost to be competitive with current 6 ckt system (relative). - Features: - Backward compatible shape - New form factor (smaller size) - Latching required? - ... ... Plug Compatible - pros - flat smt socket has the bandwidth - easy to identify - cons - upright DIP socket does not have the bandwidth - 800 and 1600 Mbs speeds possible, 3200 Mbs probably not - Cable coding for speeds - Adding cable detect pins - Dealing with current 1394-1995 pin layout-signals/.... New Interface - pros - small form factor - more applications including mobile and sonsumer - less pcb real estate - Higher speed by design, 800 to 3200 Mbs - extra margin of bandwidth - Include detect pins for cable speeds - cons - Not as easy to recognize - Hybrid cable needed - 1394-1995 to 1394b Action Items - Request WG to approve 7 day ftp posting rule for copper TG - Solicit cable manufacturers to show improved attentuation and crosstalk construction modeled on 6 ckt. - Declare patent policy - IEEE letter onfile for connector/cable proposals - License policy and terms for presentations - Charter 1394b electrical group for following: - rise-time by each speed (800-1600-3200 Mbs) - At a given rise-time min/max impedance - Power distribution with voltage drop expected. [What's this seven day rule you want? Want seven day posting before meetings, in place of the two week rule of the broader group. But we don't have a broader two week rule. That rule applies to .a, not to .b!] [Added hand-lettered line to previous foil --- - 1394 AV - 1394b hybrid cable] [Electrical group doesn't want artificial rise times (?) ... Need accurate cable and connector models for simulations, etc. ...] [Don't see why you have to design every component in the system ... if someone wants to build a rotten cable or connector, you can't stop them. You can't guarantee interoperability unless you build a quality product from end to end. We have to do things right. If the behavior at the interface is as defined, how can you tell what is done behind it? We already have a connector, and we need to define things around it. Other groups have tried to define around interfaces, and then have had problems. FC and others are pushing back away from the approach of defining only interfaces. ... ] [New line added to the last slide --- - Must maintain plug - could add an alternate later for S3200.] [We need to work together and avoid connector wars ... What about cable ID pins? Or side-bar communications for things like fiber optics?] *** hand drawn diagram *** 6 pin [Whatever we do here, it goes back to the PHY vendors. If we have signals, the PHYs have to be able to understand them. ... This connector will handle 800, and probably 1600, but not 3200. The 3200 cable would likely be double the cost or more, perhaps as much as five times as much as the existing cable. Would you like to explain the lumpy cable? A lumpy cable is a cable with a PHY in the end of the cable, with a medium within the cable ... Is that a possible solution for 3200? Not if the 6 pin can't handle it. The connector itself is the problem. This is legacy, and we have to figure it out. We need to go back to the connector vendors, and find out what can be done. What would the cable be like for an S3200 solution? The cable would be expensive. The cost would be in the cable, not in the connector. Could you make S3200 work at patch cord distances? I think it is the materials, not the distance that is the issue. CAT-6 and CAT-7 are being defined, but the cables are not more than about 30% higher than CAT-5. 430 MHz at 30 meters is possible with these new cable types. Speeds scale as the cable shortens. This would seem to indicate that better cables don't necessarily cost too much more. The problem may still be in the plug, though. Why can't you go beyond S1600 with the connector? Geometry. We can't really change this because of the compatability questions. We feel this 6 pin connector must change to go to higher speeds ... We welcome your material and hope to see it at a task group meeting ... Does shorter distance help? Yes, but there are still propagation issues ... You want to have a very inexpensive cable at S1600, and not suffer the costs inherent in S3200 until you get there. ... The charter is that we are working on a plug compatible interface, as fast as we can make it go. The work done indicates, so far, that we can't get to S3200 plug compatibly. We'll likely be able to do S800 and S1600 ... The higher speeds may become p1394c! ... Is it possible to go to copper only for a few inches to a PHY that drives fiber? The problem is the connector! We'll keep looking at this, but we don't think you will get a good system like this.] [We will look at the flat SMT connector for the future, since it is the best behaved, and the current 1394-1995 pinout. We will have a seven day posting rule for our group. We will bring in the calbe manufacturers for information and guidance. We will extablish a patent/licensing policy.] 6.2 PHY-LINK Interface - Martin Sodos 1394b PHY-Link Interface ... 1394b PHY-Link Taskforce - Status/Agenda - Sicne the last meeting: 1. Straw poll approved going to S800 first, providing overall progress is maintained. 2. Details worked out for proposed S800 solution. This meeting ... ... 1394b PHY-Link TF Details of S800 solution to be presented: - Timing/Roundtrip delay - generation of 50/50 duty cycle ... ... 1394b PHY-Link TF S800 - Generation of clock - Requirement: In order to maintain acceptable timing margins, a 50/50 duty cycle needs to be maintained. - Requirement: In order to maintain compatibility with the current architecture, the clock must remain at 50 MHz, and sourced from the PHY - Solution: This can be accomplised by using a 100 MHz source wich is divided by 2, then fed into the PHY clock distribution network. Duty cycle then is only sensitive to instantaneous speed chnages (should be very small). - Solution: ... 1394b PHY-Link TF Other Requirements: In order to have a cost effective solution through S800, ideally: 1. Thue databus width should remain at 8-bits, due to the PHY being pad-limited, and costs rising significantly with gatecount 2. The new protocol should retain compatibility with older PHYs/Links: b. No change from TTL pads should be made c. No clock frequency higher than 50 MHz 3. Due to the need for low trace capacitance, length and clean EMI characteristics, a matching pad layout on both the PHY nad link needs to be specified. [One of the fundamental assumptions of the task group is that people wish to maintain seperate PHYs and LINKs. There are high-frequency issues here ...] 1394b PHY-Link TF *** diagram *** 1394b PHY-Link TF *** table *** [We think we can obtain adequate margins on .35 micron features ...] 1394b PHY-Link TF S800 PC brd signal distribution. What about reflections? - A 2 cm trace length ... ... 1394b PHY-Link Taskforce Conclusions: Assuming: 1. A suitably fast technology 2. Fixed pinout on the PHY nad link 3. 2 cm PHY-LINK seperation S800 can be achieved using the dual-edge clocking approach. [Where is the 100 MHz clock divided? Before the PHY. Duckwall - I don't think there is a PHY on the market that doesn't have a 100 MHz clock in it, so there should be no added expense there.] 1394b PHY-Link TF S1600/S3200 outlin: Issues: 1. No technology appears adequate to allowing a PHY sourced clock faster than a ... 2. ... 1394b PHY-LINK TF Therefore: If wider separations are to be supported, a more sinusoidal and probably also differential electrical protocol will be required. A specific recommendation will be presented at the next meeting. In spite of PHY cost concerns due to pad limiting, a wider ... ... [Have you considered source clocking in both directions? ???] Straw poll: We can choose to have a seperate solution at S800 or not. We can develop solutions for s800, 1600 and up ... We could ONLY create the ultimate solution for S1600 and S3200, and deal with S800 seperately. So, what does the task group do? We need only to specify what makes the interface work with proper margins ... A. Do not proceed further but work on a comprehensive solution for all three frequencies. Will we still be pad limited at S800, with the bi-lingual PHYs? B. if (S800 seperate) then if (1600-3200 OK) then seperate s800, plus a comprehensive 800-3200 else comprehensive 800-1600 else comprehensive 800-1600-3200 solution [We are not voting on the means of solving the problem. What we vote on first is to have a seperate and distinct S800 solution, and seperate ones for the higher speeds. We think that we will need a seperate and distinct solution for the higher speeds. But there may not be a conflict in going for a comprehensive solution. All we are doing is trying to serve a market with that S800 specific interface, but we may not need to do that. The current best-guess is that we will not be able to maintain TTL beyond S800 ... One of the current strengths is that it allows people to be interoperable between different speed PHYs. Are any of the solutions being examined maintain such interoperability? Let's say we go for a comprehensive solution only. All that would be required is that we start ... If we have too many variations on the theme, we may have an unman- agable solution. I favor a comprehensive solution ... Colin - I don't want any of these. I don't want a solution that is not backward compat- ible with the lower speeds! Wooten - All roads lead to us having a comprehensive solution at some future time. Do we think they should spend their time working on other interfaces first or simultaneously? Backward compatibility is something they will work on if they can ... The backward compatible solution is an ever widening data path. This would allow a TTL interface off into the future, but the problem is that the PHY internals and drivers may not allow TTL levels elsewhere on the silicon/semiconductor ... What we are voting on is whether to do a seperate S800? Yes. Is isolation an option or not? I've heard rumors of an isolation that would be fast enough, but don't know for certain. I'd like to clarify what the motivation is for a seperate S800 solution ... Well, it is thought by some to be a low-hanging-fruit, but then it looks as if the comprehensive may be timely enough. I believe we should vote to reject the seperate S800 solution. Obviously I have not had the time to poll the group. I think we can do this in a timely fashion that will meet the industry's needs.] Moved by Mike Brown that the task group should develop an isolatable S800 solution that is compatible with S100 to S400 speeds, but not with S1600 and higher speeds. Seconded by Colin Whitby-Strevens. [The nature of the question has no impact on a comprehensive solution. I don't believe this speaks to whether this solution will appear in the final specification.] The question was called, and the vote was 14 yeas and 15 nays. 6.3 Upstarts - Colin Whitby-Strevens 6.3.1 Overall report Upstarts ad hoc meetings - 15/16 October, 1997 - Agenda - Scope and terms of reference - Docment outline - Discussion on the various phases of start-up - ... ... Scope of Work - Get a port into a state whether either 1. no connection 2. we've decided to operate in P1394a mode 3. or we've decided toperate in Beta mode - decided the line Baud Rate - go synchronised and exchanging IDLEs - Scope of work is the port and S/R state machines (as in S/R) and accompanying C code, circuit descriptions, signal tempates, etc., plus descriptive text - most of the states and transitions stay the same - the conditions are adjusted to reflect beta mode operation - will probably have to add a state or two between p6 ... ... Task Group Methodolgy - mainly email - new reflector - upstarts@zayante.com - subscribe by sending an email to requests@zayante.com with the one line message: subscribe upstarts your_real_name - Takes the email subscription address automatically - every opportunity ... ... *** document outline *** Introduction - Scope: start-up procedure for beta-capable links - when a port becomes connected, this precedure has to decide whether to start up in p1394a mode or Beta mode ... Port properties - 1 ... Port properties - 2 ... Sub-PHY long-haul port ... Port types and properties - S100* DS ... Interoperability table *** table *** P1394a Suspend/Resume State Machine (part, simplified) *** diagram *** *** table *** P1394b Eager Beta/Lazy a Algorithm for P2:Disconnected - Immediately start well-spaced (low power) pulse-toning on TPB, listen on TPA (details later) - if we hear the tone, then we know we're Beta mode - set Beta mode and go to P6:debounce - if we don't hear a tone, then if bi-lingual, look for con_status - if set, then set DS mode, and go to P6:debounce, otherwise repeat toning - following table gives the parameters that a bi-lingual or Beta mode only port will detect during P2:disconnected. *** table *** Eager Beta for P6:Connect debounce - if in beta mode, continue sending tones - power up the ort - wait connect_debounce - if no tomes then received, false connection, go back to P2:disconnect - ... ... Lazy-a for P6:Connect debounce - if in DS mode, power up the port, and apply a modified form of the P1394a algorithm - Lazy-a algorithm - Far end must be DS only, or else Eager Beta would have detected Beta mode - but not always ... ... P1394b Eager Beta/Lazy-a algorithm for P5:Resume - beta mode - if not already running (come from connect-debounce - exchange timed tones to determine operating speed - by this time, the port is powered up, so we can use the normal accurate timer ... ... Issues list - 1 - How to handle the extra error conditions (sync fail, etc.)? - Do the other state machines need to know whether we're in beta or not? - is there a need for a software override to force P1394a mode or to force beta mode? - .... - is there a need for a hardware configuuration(strap) option to force one or the other mode? - What level of software obserability is required? - line rate - beta mode or p1394a mode - in P7 or not, or state of state machine? - more detail (e.g. loss of synch flag)? - What higer level of control may be required, e.g. - try to resynch coz there's too many ... ... Issues list - 2 - What is the lowest signal frequency that can be sent via an optical transceiver simply to exercixe a connect/disconnect mechanism? - in discusion with Del Hanson (HP) and Ron Soderstrom (IBM) - Connect_Debounce state: don't understand exactly why connected can ... ... 6.3.2 Possible means for toning - Jim Doyle 1394b Startup Proposal - simple tone detector modulation (STPM) - Permits AC coupling - Low Power < 2 miliwatts using existing XTAL ... Purpose of this presentation - build ... ... Rules of Thumb for Tone Detection Technology - optimal sensitivity 0 dB SNR (paging) - Tone detectors ... ... Tone Detection technology - divide down from 24.576 MHz Oscillator - 1 MHz ... ... 1394b startup protocol *** circuit diagram *** *** four graphs *** Methods of tone detection - integrate ... ... Methods of tone detection (2) - zero Crossing/Bandpass Filter (... ... Bounded information theory - Shannon's Law Information Theory limits ... 1394b Startup Proposal *** three diagrams *** 1394b Startup Proposal *** diagram with signal diagrams *** *** LC Comb diagram *** Simplified Caluclations of Noise bandwidth for commutating filter ... 5x vs 7x Synchronous oversampled filter ... 1394b startup proposal *** diagram *** 1394b startup proposal *** signal waveforms *** similar similar ??? Falsing Probability Discussion - simple continuous sampling suggests MTBF ~ 2 years in noise - Assumptions ... ... Concerns and additional work - bandwidth of opticalnetwork and impact to tone frequency and power - driver compatibility (bilingual) - compatibility with suspend/resume? - ... ... Simulation ... ... Conclusions - Framework for analysis presented - ... ... [Pulse modulation may not get us the desired integration characteristics so ... Different schemes can be used, and we are trying to maintain com- patibility with CMOS. Is the 1 MHz a problem with AC coupled ... 6.4 Standard Protocol - Alistair Coles (by proxy, Colin Whitby-Strevens) Port Protocol Scope includes - define handling of arbitration and data signals through beta mode ports ... ... Scope does not include - Tree ID (root contention resolution), Self_ID, normal arbitration, arbitration enhancements - Start up ... ... Proposed Model *** diagram *** [This is not necessarily an implementation!] Issues - Speed signaling - proposal on web site - do we allow for revision of S200 to S400 - Error reporting - how do errors detected during decoding get passed to link layer for packet to be ignored? - how do errors detected during decoding get indicated on forwarded packet? - Error handling - when do we abort normal operation ... Contents page *** contents listed *** 6.5 Accelerations - Dave LaFollette Charter - Improve 1394b efficiency ... ... Overview - Take advantage of full duplex 1394b PHYs - send requests and grants against flow - Take advantage of 1394b port protocol - Embed requests and grants in data stream - Open Issues - Operation with legacy devices - Error handling - child or link request prioritization - details of encoding - expected performance gains - See Mike Teener's paper for more details ... Members - Group members are assumed to be the same as Port Protocol group - Logistics ... 6.6 Network Simulations - Prashant Kanhere Skipped 6.7 Standard Electrical - Eric Hannah Standard Electrical Task Group Report October 24, 1997 Members* Eric Hannah Bijit Patel Dave Brunker ... Charter - Define the electrical signaling parameters for 1394b PHY's - Primary focus is short-haul copper ... Electrical Issues - Specifications for transmitter and receivers - System jitter budget adn optimal allocations - Definitions for practical compliance measurements - eye diagrams - measurement points - jitter measurements - checklists for PHY vendors and OEM's - Creation of useful simulation models - Spice for cable adn connectors - spice for packages adn PC layouts - more general mathematical models for transmitters to receivers system modeling - Electrical interface reference design - Aid to the designer - at the level of the IEEE std. 1394-1995 electrical interface diagram and specification Proposed Workplan - process - private emails between taskgroup members - When issues become contentious or defined enough for discussion - telephone conference calls - Timeline - 0.5 rev. short-haul copper draft by December '97 meeting - Documentation - The current draft is a good beginning spec. (stolen from gigabit ethernet 7. Proposed 8. Link Budget Analysis 8.1 800 Mb/s Link Budget Analysis presented to P1394b October 23-24, 1997 .... 800 Mb/s BER Analysis - transmitter launch voltage = 600 mV - Cable and connector loss = 0.35 - loss due to impedance mismatch = 0.15 - Receiver input voltage = 178.5 mV - Noise and Crosstalk: - Connector and cable and PCB - Total RMS crosstalk = 14.4 mV - Thermal noise and reflection = 0.7 mV .... 800 Mb/s - Transmitter and Receiver Circuit noise - 1.06 mV - Receiver offset and overdrive = 70 mV - Signal-to-Noise Ratio = 14.5 dB - bit error rate (BER) = 3e-14 - Noise margin = 0.35 dB BER due to Sampler - Unit Interval (UI) @ 800 Mb/s = 1000 ps - Jitter components - recovered clock jitter = 10 ps - Input data jitter = 42.4 ps - Jitter due to rcv.input noise = 20.2 ps - Total alignment jitter = 48 ps - Static Phase offset = 10 ps ... BER due to Sampler - Sampling latch setup and hold = 80 ps - metastability period of latch = 5 ps - eye closure due to ISI = 200 ps - bit error rate (BER) of sampler - 3.8e-13 [Colin - These numbers you are quoting have no relationship with the fiber channel jitter budgets ... take the random number * 14 to get the peak to peak ... 620 ps peak-to-peak ... There seems to be something wrong with these numbers.] 8.2 1394long(S100) PHY Delay 4B/5B *** diagram *** 1394long(S100)PHY Delay 8B/10B *** diagram *** *** two hand-drawn diagrams *** Larger PHY delay means inefficient - additional PHY delay is approximately +176 ns, with 8B/10B. This eats up 3-4% of the bandwidth at every node *** diagram *** Bandwidth Wasted, assuming 256 byte-long async packet in average 176 ns * 6 ------------------ = 3.9% / node 26 us + 176 ns * 6 Bandwidth loss by 8B/10B is Significant - A typical house may have 4 hops of 1394 long PHY. With 8B/10B it suffers an unjustifiable 16 % bandwidth loss (3.9 % * 4) - ... ... Conclusion: REAL advantage of 4B/5B *** table *** 8B/10B Can't provide UTP 1394 (100m) - UTP cat-5(100m) is not possible with 8B/10B + MLT-3. Because 0 ... ... ["I am rather angry that these conclusions are at best grossly mis- leading, and at worst grossly irresponsible, especially presented to DAVIC." There were numerous comments on the accuracy or lack thereof of many of the assertions made, as well as the models presented.] Moved by Richard Churchill that the chairman send a liaison letter to DAVIC in response to Taka Fujimori's presentation to DAVIC, indicating disagreement with that presentation. Seconded by Jack Hollins. Motion carried unanimously. 9. Meeting Schedule 9.1 December (Fort Lauderdale, Florida) See TA Web page for details 9.2 January (Houston, Texas) See TA Web page for details 9.3 February (Monterey, California) TBD 9.4 March (Phoenix, Arizona) TBD 9.5 April TBD 9.6 May? June? (England?) TBD 9.7 Other future TBD 10. Review of Action items All task groups to proceed with their respective efforts. Chairman to write liaison letter to DAVIC regarding Taka Fujimori's presentation to that body. 11. Adjournment ======================================================================== ==== Attendance List Tatsuya Arai tatsuyaa@hiroseusa.com 805-522-7958 Nelson Arata nelson.arata@nsc.com 408-721-4979 Oleg Awsienko oleg_awsienko@ccm.ch.intel.com 602-554-9666 Steve Bard steve_bard@ccm.jf.intel.com 503-264-2923 Max Bassler mbassler@molex.com 630-527-4490 Karl Berstrom mpeg007@aol.com 800-888-0211 x4563 Mike Borgman mjbo@panduit.com 708-460-1800 Charles Brill cebrill@amp.com 717-592-6198 Mike Brown mike_brown@ccm.ch.intel.com 602-554-3713 Dave Brunker dbrunker@molex.com 630-527-2622 Jim Busse jimb@ccgate@sj.nec.com 415-528-3810 Ed Butler ebutler@sedona.intel.com 602-554-0751 Dao-Long Chen dao-long.chen@symbios.com 970-223-5100 x9461 Richard Churchill richard.churchill@compaq.com 281-514-6984 Dan Colegrove colegrov@us.ibm.com 408-256-1978 Jim Doyle jdoyle@sedona.intel.com 602-554-2051 Bill Duckwall duck@zayante.com 408-461-4902 Stephen Finch steve.finch@tus.ssil.com 714-573-6808 James Gay jimg@oakhill.sps.mot.com 512-891-2218 Eric Hannah ehannah@mipos2.sc.intel.com 408-765-4441 Yasumasa Hasegawa jasumasa@ffm.fujifilm.co.jp +81 22 347 1128 Jerry Hauck jerry_hauck@ccm.sc.intel.com 408-765-5528 John Hill [no email address given] 717-592-6175 Jack Hollins jack_hollins@eng.adaptec.com 408-957-2309 David Instone dinstone@uk.zyratex.com +44 1705 486 363 Weidong Jiang wjiang@fmi.fujitsu.com 408-922-9783 Prashant Kanhere prashant@macrodesigns.com 510-668-1773 Dave LaFollette dlafolle@mipos2.sc.intel.com 408-765-2587 Dan Landeck dlandeck@fmi.fujitsu.com 408-922-9522 Farrukh Latif flatif@lucent.com 610-712-7546 Takashi Matsui takashi_matsui@ibm.net +81 76 274 2440 Takatoshi Mizoguchi mizoguti@shijo.sharp.com +81 745 65 1161 Palanisamy Mohanraj palanisamy_mohanraj@ccm.ch.intel.com 602-554-4243 Bill Northey northewa@bergelect.com 717-938-2119 Takayuki Nyu new@optsys.cl.nec.co.jp +81 44 856 2082 Bill Prouty billp@hprnd.rose.hp.com 916-785-4631 Juan Pulido jmpulido@mmm.com 512-984-5188 Tomoki Saito saito@ccm.cl.nec.co.jp +81 44 856 2082 Brad Saunders bradley.saunders@rss.rockwell.com 714-221-6513 Dick Scheel dicks@lsi.sel.sony.com 408-955-4295 Khoruash Sefiduash khoruash.sefiduash@symbios.com 714-474-7095 Haim Shafir hshafir@ixrnetcom.com 408-343-0192 Masood Shariff mshariff@lucent.com 732-957-5479 Michael Shinkarovsky mshinkarovsky@lucent.com 610-712-2938 Martin Sodos msodos@issiusa.com 408-969-4683 John Ta john.ta@tus.ssil.com 714-573-6957 Ju-Ching Tang jctang@corp.cirrus.com 510-623-8300 x5189 Ken Taylor ktaylor@bostonoptical.com 508-342-3309 Peter Teng pteng@mail.com 408-588-5555 Sushant Verman sushant@lsil.com 416-620-7400 Hirosha Wakai wakai@slab.sharp.co.jp +81 743 65 4529 Kenji Watanabe mabeken@sslab.sony.co.jp +81 3 5448 5362 Colin Whitby-Strevens colinws@bristol.st.com +44 1454 611 500 Lee Wilson leewils@us.ibm.com 512-838-6569 Mike Winchell mike.winchell@symbios.com 970-225-4807 David Wooten david.wooten@compaq.com 281-518-7231 Shuntaro Yamazaki yamazaki@ccm.cl.nec.co.jp +81 44 856 2082 Patrick Yu patrick_yu@el.nec.com 408-588-5436 Peng Zhang pzhang@ti.com 972-480-3109