InfoMagic Standards 1993 July

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

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

Wrap

Internet Message Format | 1992-10-01 | 27.2 KB

Date: Sat, 29 Aug 92 16:29:14 MDT Message-Id: <16985.9208292229@inmos-c.inmos.com> Received: from CDPVAX.isnet.inmos.COM by inmos-c.inmos.COM with DniMail (1.33-inmos-c) Sat Aug 29 16:28:12 1992 MST From: CROWELLF@isnet.inmos.COM To: p1394@Sun.COM Subject: Cable jitter margins and DS encoding Status: R Effects of DS Bit-level Encoding on P1394 Cable Jitter Margin Forrest Crowell SGS-THOMSON September 3, 1992 At the August P1394 meeting in Seattle, Roger Van Brunt of Apple presented Jitter Budget figures for clocked 8B/10B operating at 10 meters. These figures were troubling due to little or no margin, especially at the higher bit rates. Although DS bit- level encoding had been previously voted down in favor of clocked 8B/10B, SGS-THOMSON decided to rework the Jitter Budget figures for the Data Strobe case. Using DS encoding significantly improves the jitter margin, as shown in the following table. Utilizing the 8B/10B code is actually an independent issue from clocked Vs strobed, so margins for both 8B/10B across Data Strobe and NRZ across Data strobe are presented, along with the figures from Roger's presentation for comparison. The 400 Mbit "uncorrected" is without deskew and receive offset correction. The complete calculations for these margins are given below. P1394 Cable Jitter Margin in nS 10 meter, 22 Gauge Wire Data Strobe Data Strobe Clocked Bit Rate 8B/10B NRZ 8B/10B 400 Mbit corrected 0.90 1.41 0.01 400 Mbit uncorrected 0.19 0.70 --- 200 Mbit 1.97 2.99 0.04 100 Mbit 4.98 7.01 0.92 A few points should be made about these figures: 1. DS coding, with or without 8B/10B, is NOT DC-balanced. Thus electrical isolation in the cable is not possible. Before the committee can address DS encoding for the cable, it must resolve the isolation issue. 2. Using 8B/10B on top of DS would allow for future self- clocked implementations, but would require two licenses in the present. It also gives less margin. 3. The significant margins provided by DS with NRZ raises the possibility of specifying smaller gauge cable and/or less robust transceivers for the 100 and 200 Mbit/S rates, thereby reducing cost. It also allows for operation at 400 Mbit/S without deskew and receive offset correction circuitry. Pending and perhaps influencing a decision on cable isolation, SGS-THOMSON proposes that DS bit-level encoding be reconsidered for the cable physical environment. Retaining 8B/10B on top of DS encoding also needs to be discussed. SGS-THOMSON is prepared to extend the same licensing policy as was indicated for the backplane physical environment. Please voice any reactions on the reflector prior to the September 14 meeting in Colorado Springs. Methodology for DS Jitter Margin: For the most part, the format and data from Roger Van Brunt's presentation "P1394 Physical Channel Update," dated 8/13/92 and presented 8/19/92 was used unchanged. The three things that could change for DS are the total jitter budget time, the cable intersymbol interference, and the removal of deskew and receive offset correction in the 400 Mbit/S case. The following table gives the bit period used for the total jitter budget time. Because of the DS encoding scheme, the full period T can be used, instead of a half period T/2 for the clocked scheme. The period for NRZ and the shortened period for the faster rate required by 8B/10B are given. Bit Periods Used to Determine Total Jitter Budget Base Rate NRZ T 8B/10B T (Bits/S) (Seconds) (Seconds) 100 Mbit 9.83E+07 1.02E-08 8.14E-09 200 Mbit 1.97E+08 5.09E-09 4.07E-09 400 Mbit 3.93E+08 2.54E-09 2.03E-09 For cable intersymbol interference in the DS case, the ISI on the Strobe line must be accounted for as well as Data ISI. The Strobe ISI would be the same as standard NRZ. The Data ISI will be the same as Roger's figures for 8B/10B, or standard NRZ. At SGS-THOMSON's request, Apple conducted ISI tests on P1394 cables carrying uncoded NRZ data. To everyone's surprise, the ISI for uncoded NRZ data was identical to that of 8B/10B within tester resolution. Apparently, at the rates and distances tested, the signal dispersion was so small that the excellent ISI characteristics of 8B/10B did not come into play. Finally, to remove deskew in the 400 Mbit/S case, the 0.6 nS sum was used rather than the corrected 0.05 nS value. The uncorrected receive offset time of 0.14 nS is the result of 25 mV divided by 175 mV/S. With these changes applied to Roger's original data, here are the complete cases for DS encoding, with and without 8B/10B, at 400, 400 uncorrected, 200, and 100 Mbit/S. DS Encoding Jitter Budget 400 Mbit, trf=1ns, 8B/10B, 10 meter, 22 Gauge Wire Deskew and Receiver Offset Correction (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.20 Transmit Pins 0.10 0.10 Cable Reflections 0.11 0.11 Cable Intersymbol 0.12 0.12 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.33 0.33 0.05 Receiver Offset 0.06 0.06 Receiver Intersymbol 0.10 0.10 Flip Flop Tolerance 0.10 Total Jitter 0.59 0.49 0.05 Budget 2.03 Skew+Jd+Js = 1.13 Margin 0.90 DS Encoding Jitter Budget 400 Mbit, trf=1ns, NRZ, 10 meter, 22 Gauge Wire Deskew and Receiver Offset Correction (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.20 Transmit Pins 0.10 0.10 Cable Reflections 0.11 0.11 Cable Intersymbol 0.12 0.12 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.33 0.33 0.05 Receiver Offset 0.06 0.06 Receiver Intersymbol 0.10 0.10 Flip Flop Tolerance 0.10 Total Jitter 0.59 0.49 0.05 Budget 2.54 Skew+Jd+Js = 1.13 Margin 1.41 DS Encoding Jitter Budget 400 Mbit, trf=1ns, 8B/10B, 10 meter, 22 Gauge Wire No Deskew or Receiver Offset Correction (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.20 Transmit Pins 0.10 0.10 Cable Reflections 0.11 0.11 Cable Intersymbol 0.12 0.12 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.33 0.33 0.60 Receiver Offset 0.14 0.14 Receiver Intersymbol 0.10 0.10 Flip Flop Tolerance 0.10 Total Jitter 0.67 0.57 0.60 Budget 2.03 Skew+Jd+Js = 1.84 Margin 0.19 DS Encoding Jitter Budget 400 Mbit, trf=1ns, NRZ, 10 meter, 22 Gauge Wire No Deskew or Receiver Offset Correction (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.20 Transmit Pins 0.10 0.10 Cable Reflections 0.11 0.11 Cable Intersymbol 0.12 0.12 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.33 0.33 0.60 Receiver Offset 0.14 0.14 Receiver Intersymbol 0.10 0.10 Flip Flop Tolerance 0.10 Total Jitter 0.67 0.57 0.60 Budget 2.54 Skew+Jd+Js = 1.84 Margin 0.70 DS Encoding Jitter Budget 200 Mbit, trf=2ns, 8B/10B, 10 meter, 22 Gauge Wire (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew Transmit Pins 0.15 0.15 0.20 Cable Reflections 0.10 0.10 Cable Intersymbol 0.10 0.10 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.35 0.35 0.60 Receiver Offset 0.20 0.20 Receiver Intersymbol 0.15 0.15 Flip Flop Tolerance 0.10 Total Jitter 0.80 0.70 0.60 Budget 4.07 Skew+Jd+Js = 2.10 Margin 1.97 DS Encoding Jitter Budget 200 Mbit, trf=2ns, NRZ, 10 meter, 22 Gauge Wire (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew Transmit Pins 0.15 0.15 0.20 Cable Reflections 0.10 0.10 Cable Intersymbol 0.10 0.10 Cable Delay Mismatch 0.40 Channel Margin 0.00 0.00 Receive Pins 0.35 0.35 0.60 Receiver Offset 0.20 0.20 Receiver Intersymbol 0.15 0.15 Flip Flop Tolerance 0.10 Total Jitter 0.80 0.70 0.60 Budget 5.09 Skew+Jd+Js = 2.10 Margin 2.99 DS Encoding Jitter Budget 100 Mbit, trf=3ns, 8B/10B, 10 meter, 22 Gauge Wire (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.30 Transmit Pins 0.30 0.30 Cable Reflections 0.13 0.13 Cable Intersymbol 0.10 0.10 Cable Delay Mismatch 0.40 Channel Margin 0.10 0.10 Receive Pins 0.63 0.53 0.70 Receiver Offset 0.40 0.40 Receiver Intersymbol 0.15 0.15 Flip Flop Tolerance 0.20 Total Jitter 1.38 1.08 0.70 Budget 8.14 Skew+Jd+Js = 3.16 Margin 4.98 DS Encoding Jitter Budget 100 Mbit, trf=3ns, NRZ, 10 meter, 22 Gauge Wire (All values in nS) Data Jitter Strobe Jitter Skew Transmit Skew 0.30 Transmit Pins 0.30 0.30 Cable Reflections 0.13 0.13 Cable Intersymbol 0.10 0.10 Cable Delay Mismatch 0.40 Channel Margin 0.10 0.10 Receive Pins 0.63 0.53 0.70 Receiver Offset 0.40 0.40 Receiver Intersymbol 0.15 0.15 Flip Flop Tolerance 0.20 Total Jitter 1.38 1.08 0.70 Budget 10.17 Skew+Jd+Js = 3.16 Margin 7.01 Margin 7.01 ===================================================================== Date: 3 Sep 92 14:45:06 U From: Dave Gustavson <dave_gustavson@QMAIL.SLAC.STANFORD.EDU> Subject: ReThinking the Physical Lay To: P1394@Sun.COM Message-Id: <1EC16B74D0C04834@SCS.SLAC.STANFORD.EDU> X-Envelope-To: P1394@sun.com Status: R Subject: Time:2:27 PM OFFICE MEMO ReThinking the Physical Layer Date:9/3/92 It seems to me, given: "At SGS-THOMSON's request, Apple conducted ISI tests on P1394 cables carrying uncoded NRZ data. To everyone's surprise, the ISI for uncoded NRZ data was identical to that of 8B/10B within tester resolution. Apparently, at the rates and distances tested, the signal dispersion was so small that the excellent ISI characteristics of 8B/10B did not come into play." from F. Crowell's message today, when combined with Florin Oprescu's powerful arguments of early August, leads me to conclude that 8b/10b is not the essential savior of P1394 that we were given to believe, and that in fact the indirect consequences of its adoption completely destroy the well-balanced system design that had formerly characterized P1394. Therefore, we should drop 8b/10b and go back to a DC signalling mechanism, performing the isolation on the other side of the PHY chip as before. This does open the possibility of using the DS encoding, which seems to have some real advantages, so I propose we consider it seriously. Just in case the 8b/10b enthusiasts think I'm biased arbitrarily against them, let me point out that I am supporting an effort to use 8b/10b for a future serial SCI link at 2.4 Gbit/s, where it has actual technical advantages. I only oppose it for SerialBus because it screws up so much of the architecture that made SerialBus potentially useful and cost-effective for my applications. David B. Gustavson, IEEE P1596 Scalable Coherent Interface chairman ===================================================================== Date: Fri, 4 Sep 92 12:00:58 PDT From: Barry_Thompson@NeXT.COM Received: by NeXT Mailer (1.63) To: P1394@Sun.COM Subject: Get Rid of 8B/10B Status: R I would like to voice my support for the elimination of 8B/10B coding from the P1394 standard. It is my opinion that this coding scheme adds significant complexity and power requirements without providing significant performance enhancements. The inclusion of 8B/10B coding also detracts from the well-balanced system design that existed before the coding was added. The principal benefits of 8B/10B coding are a guaranteed transition density for clock recovery and DC balance. The committee has already decided not to do clock recovery and thus a second communication channel has been added for the purpose of transmitting the clock. I believe this was a good decision as clock recovery is difficult, the additional channel can be used in arbitration, and skew between the signal pairs does not seem to be a major problem. The DC balance property of 8B/10B could benefit the standard by allowing DC isolated data transmission. The problem here is that acceptable solutions to connection sensing, power distribution, speed signaling, and arbitration have not been proposed. We are therefore likely to end up with the worst of both worlds --- 8B/10B coding and DC connections. The final alleged benefit of 8B/10B coding is a reduction of intersymbol interference. The Apple experiments do not confirm this gain. In fact, jitter margin would be reduced with 8B/10B coding since the baud rate would have to be increased by 25% for equivalent channel capacity and intersymbol interference is not significantly decreased. Finally, I would like to express my support for the original goals of P1394 -- a high speed, low cost desktop bus. While there is some similarity to a network, P1394 is not a network and the inclusion of network-like complication and features should be carefully examined. Barry Thompson NeXT Computer ===================================================================== Date: Thu, 10 Sep 1992 11:22:56 -0400 (EDT) From: POTYRAJ@CAPSRV.JHUAPL.EDU (Thom Potyraj) Message-Id: <920910112256.43802845@CAPSRV.JHUAPL.EDU> Subject: p1394 backplane meeting, 2Sept92 To: teener@apple.com X-Vmsmail-To: smtp%"teener@apple.com" Status: R P1394 BACKPLANE MEETING, 2 SEPTEMBER 1992 IN NEWPORT RI. DS Bit Level Encoding The group addressed the issue of DS bit level encoding. At the last meeting the group voted to recommend the adoption of DS bit level encoding method. This patent for this protocol is owned by SGS Thomson. Following the last backplane meeting 16 July 92 at Del Mar, CA) SGS Thomson distributed their proposal for license fees for comment. This proposal included a license fee of $5000 to be charged to all users. This fee, as the meeting attendees understood it, would apply not only to silicon vendors, but also to companies that used the chips, such as card manufacturers. It was not clear if companies that incorporated such cards into "boxes" would have to pay the fee as well. At the meeting the license proposal caused some concern among the silicon vendors and end users. It was decided that the NRZ method should be reinvestigated to determine what skew margins are available for both TTL at 24.576 MHz and BTL at 49.152 MHz. It was also decided that SGS Thomson be asked to review their proposal. The group thought that it was impractical to attempt to collect license fees from all users. It was recommended that SGS Thomson negotiate with the silicon vendors or anyone that developed silicon implementing the protocol. As an example, Chris Koehle (National Semiconductor) mentioned that GTL technology is being licensed for a one time fee of $10,000 from the silicon vendor. He considered GTL to be a more "significant" technology. Arbitration and Gap Timing After the methods and parameters for calculating the arbitration bit length and gap times were established at the last backplane meeting, the values were calculated by Kim Clohessy and Thom Potyraj. At the meeting, the arbitration bit period was announced to be 8 base rate bit times (at 49.152 MHz) with the sample time at 5 base rate bit times. Gap timing was stated to be 8 base rate bit times for the acknowledge gap, 14 bit times for the subaction gap, and 20 bit times for the arbitration reset gap. Extended Arbitration Both Kim and Thom recommended that extended arbitration be reconsidered for the P1394 specification. Extended arbitration allows for a process by which nodes on a backplane can dynamically determine a unique address to be used during arbitration. Such a scheme is necessary in backplanes (such as VME) which do not provide a slot ID or a geographic address. Extended arbitration would be available (but not required) in such a case. The question arose if the incorporation of such a scheme would impact the link layer chip, which must operate in both the backplane and the cable environment. Futurebus+ Concerns Ralph Lachenmaier, chairman of the Futurebus+ mil profile group, stated that particular Futurebus+ applications have a very tight latency requirement and requested that serial bus backplanes support rate monotonic scheduling. Several present described isochronous transfers and suggested that such transfers could satisfy his latency requirement. Further discussion suggested that this was not the case. To get the desired level of bandwidth allocation with the low latency that his application required, he stated that is was necessary to have multiple levels of priority with an algorithm for guaranteeing transfers before a "deadline". An algorithm like rate monotonic scheduling requires 64 levels, or 6 bits, of priority for tasks (although 256 levels, or 8 bits, would be best). Since it is possible for more than one task to have the same priority, a unique identifier would be need to be appended to the priority level during arbitration. After much discussion, it was decided that rate monotonic scheduling is inconsistent with the bandwidth allocation scheme presently defined by the P1394 specification. It is likely that backplanes incorporating rate monotonic scheduling would have to give up isochronous transfers (this appeared to be acceptable to the attendees). It was decided, however, that the group was concerned about any changes to be made to the current design for the link layer chip. It is assumed that the "PHY" chip manages arbitration, but it is still questionable if the PHY gets its arbitration sequence (priority plus unique identifier) from the link layer chip. Ralph suggested that serial bus be compatible with backplanes which supportted live insertion. This means that serial bus should support "pre-charging" on its transceivers and the necessary protocols. Ralph also questioned whether an address space of 63 nodes was enough (he hopes to connect multiple backplanes). It was suggested that larger numbers of nodes could be accomodated with multiple backplanes connected by bridges. He asked what extra CSRs would be required to support dual redundant serial busses. It was stated that more work is required to define levels of redundancy and fault tolerance before this subject could be addressed (if at all). Ralph also asked if it was possible to incorporate suspend/resume protocols or to limit the tenure on the backplane. The group felt that higher level management could limit tenure, but that suspend/resume protocols were not (and should not be) supported. Default Electrical characteristics It was agreed that it would be appropriate to include default electrical characteristics for the various interface technologies (BTL, TTL, ECL). It is proposed that the specification will recommend the use of transceivers and terminations which are similar to the backplane which contains it, but that a default set of characteristics will be available when the host backplane specification does not specify other characteristics, or the host backplane specification refers to the P1394 specification for these characteristics, or when the serial bus does not reside on a host backplane. P1394 Specification Revisions for the Backplane Proposed revisions to the P1394 specification were distributed. Thom stated that these revisions address portions of the specification which apply to the backplane environment, and asked attendees to review the revisions so that they could be proposed for incorporation into the specification in the near future. Some of the issues brought up at the meeting need to be addressed before the revisions can be completed. Further Analysis Chris Koehle mentioned that a number of analyses could be undertaken to help resolve the encoding issue and to fill in the TBD's within the specification. These analyses include: a backplane analysis to determine setup, hold, or edge separation times; a rise/fall time vs. noise margin analysis to determine how fast transitions can be so that a minimum transition time can be specified for the interface technologies; and a skew analysis to determine the maximum change in propagation delay between two signals on a backplane. He offered to assist in some of the analyses. Next Backplane Task Group Meeting: The next meeting will be held in San Antonio, TX on 11 November 92 in conjunction with the Futurebus+ meetings. ===================================================================== Date: Sun, 13 Sep 92 18:58:18 EDT From: lachenma@NADC.NADC.NAVY.MIL (R. Lachenmaier) Message-Id: <9209132258.AA08845@NADC.NADC.NAVY.MIL> To: P1394@Sun.COM Subject: Need for more priority bits to allow Rate Monotonic Scheduling Cc: bpswg@NADC.NADC.NAVY.MIL, hsdtnswg@NADC.NADC.NAVY.MIL Status: R One more time I would like to state that there is a need for more priority bits in the Backplane version of Serial Bus. Rate Monotonic Scheduling is generally the algorithm of choice for real time systems of which the military has many. Serial Bus does not have enough priorities to support Rate Monotonic Scheduling. At least 6 bits (in addition to the geographic address used for tie breaking) are needed. 8 bits of priority is desirable. With adequate priorities to support Rate Monotonic, Serial Bus could be used without Futurebus+ for those applications where only a low bandwidth bus is needed. One example is use as an RF Control Bus to control modules which contain primarily RF circuitry (radios, electronic listening devices, etc) but which in the future will be controlled digitally. Another example of a low bandwidth bus need is for flight control systems. One company has described a flight control system with a number of modules which need to be updated on a 64 Hertz basis. Clearly this is a low bandwidth need, but deadlines cannot be missed or (at least in some cases) the wings will be torn off the airplane. If the military cannot get the needed priorities, I suggest that maybe we should start looking at other serial buses to fill some of our needs. For example, I have been tracking the AIRINC bus being developed for commercial airliners. It is a serial bus design for backplane usage. It is designed for a high degree of fault tolerance. I do not know at this point what kind of a priority system it contains, but I think there is a chance of influencing its design. We could also survey other proprietary serial buses. The bottom line is that without priorities, 1394 fulfills only part of the military needs for a serial bus. We need to do something about the unfulfilled needs. Ralph Lachenmaier Chair, Navy Next Generation Computer Backplane Working Group