P1394b Working Group Meeting,

DoubleTree Hotel (formerly Red Lion)

Seattle-Tacoma Airport

June 11, 1997.



chairman:  Michael Johas Teener

editor:    Eric Hannah

secretary: Richard Churchill


reflector: p1394b@fireflyinc.com

ftp site:  http://www.fireflyinc.com/p1394b/


<<<<<<<< Meeting called to order at 9:00 AM, by Mike Teener >>>>


Agenda

 1. Agenda and administrative

    a. Introductions

    b. PAR Status

    c. Chairmanship

 2. Action Item Review

 3. Task Group Status -- Long distance PMD

    a. High-speed (Colin Whitby-Strevens)

    b. Low-speed (Taka Fujimori)

 4. Contributions and action items

    a. Draft 0.03

    b. Coding schemes

    c. Spectral measurement

    d. Startup

    e. Beta mode Arbitration Enhancements

    f. new

 5. Meeting Schedule

    August, Honolulu HI

    September, Boston MA

    October, Chandler AZ

 6. New action items



 1. Administrivia

    Introductions

        Introductions around

    PAR Status

        We are still functioning without a PAR due to the present work load

    Chairmanship

        Mike Teener indicated that he could no longer serve as the group

        chair, due to various constraints upon his time.  David Wooten as

        Vice-chair will be faced with either serving as chairman or finding

        one.  The issue does not need to be resolved at this meeting, but

        will need to be resolved soon.


 2. Action items

    Mike Teener - background arbitration

    Taka Fujimori - determination of common speed between connected PHYs

    Jerry Hauck - verification of encoder, etc.

    Eric Hannah & Karl Nakamura - signalling requirements

    all - comments and proposals based on Colin's startup presentation and

          proposal


    [We should not touch the protocols of 1394 any more than necessary.

    (Teener)]

    [Comments made regarding bridges is that they are likely to operate at

    800 Mb/s, and no slower.  Thus there are problems with the idea of a

    S400 or slower 1394 Home Network.  Bridges will also want to be the

    roots of their respective busses.  (Wooten) In cases where bridge is

    not root, can we ask that there be means to synchronize the root with

    the bridge, etc.  Phase-lock and other issues of the Telecomm industry

    discussed by Teener, confirming need for this.  Bridges should end up

    looking like telecomm switches.]


    [Eric and Karl did not finish their task.

     Taka did not finish his task.

     Jerry finished and posted results.

     Mike did not finish his task.]


 3. Task Group Status

 a. High-speed PMD Group report, Colin Whitby-Strevens

     -- Agenda presented, with comments on items discussed, including

         -- requirements

         -- connectivity model (with discussion of SubPHY)

         -- user model (connection scenarios)

             -- Selected three scenarios of interest to the task group:

                 -- Scenario 1 is subject of the broader 1394b group

                 -- Scenario 2 place most components behind wall-plate

                 -- Scenario 3 supports long-haul outside wall, supporting

                    "free standing" app.

                    ....

         -- SubPHY properties discussed

             -- Requirement for 1394a PHY pinging to be completed in order

                to support long-haul stated.

         -- Issues of media and transceivers discussed

             -- Two media discussed in some detail

                 -- glass medium - 850 nm, 50 u, VCSEL

                 -- GI-POF

             -- Concensus of group was to prefer glass fiber.

             -- Mitsubishi will give a presentation on POF at the next

                meeting.

         -- We don't know how we will power the wall-plates, but have in-

            formation regarding assorted groups to establish liaison with

            in conjuction with this issue.


 b. Low-speed PMD Group report, Taka Fujimori

     -- Meeting held in Tokyo on May 28

     -- Agenda presented, with comments on items discussed, including

         -- requirements

             -- architecture

             -- PHY delay

             -- Maximum speed (S400)

             -- Startup

                ....

         -- Conclusion drawn regarding requirements

             -- 50m

             -- UTP-5, POF, HPCF

             -- speed up to S400

             -- Facilitate FCC Class B compliance

             -- amateur installable

             -- International guidelines for eye safety

         -- Schedule

             -- Phase I  -- S200 PMD, S400 PHY -- '97/E

             -- Phase II -- S400 PMD           -- '98/E

             -- UTP is only S100

     -- Provisional editors:  PHY -- Taka Fujimori

                              PMD -- TBD

     -- Various action items

     -- Tentative meeting schedule

         -- July 8, in Tokyo

         -- September 2, location TBD


 4. Contributions and action items

 a. Editor's report -- Eric Hannah

     -- Eric is seeking contributions from various companies to establish

        receiver sensitivity, launch voltages, etc.   Nothing has really

        changed in the electrical sections.  Intel will seek analog designers

        to contribute.

     -- Still planning to use IBM 8B/10B

     -- Plans to use K28.5 as the only escape character

     -- Discussed bit-stuffing, etc., in the context of IBM 8B/10B

        Expressed concern about the indeterminate disparity from arbitration

        symbols


    [Colin commented that he did not know of silicon that would synch up

    on + disparity, and that we may need two Idle symbols of opposite

    polarity, which will allow us return to a negative disparity.]


    [Extended discussion regarding arbitration, symbol lengths, etc.]


     -- "Dial tone" is provided as means to wake, etc.


    [We don't know what the requirements are for this, so we should beg the

    issue for some time, until resolved in 1394a and Power Rangers. (Colin)]


    [Discussion of reserved fields and values, in conjunction with present

    problems.  (Eric H.) When we come to the point of doing plug-fests, maybe

    we should tell people we will randomize the contents of reserved fields.]


     -- Clause 8 (Ports) presented, based upon work by Colin and Dave

        LaFollette, with associated hand-shakes, etc.


    [(Colin) A "port" in this clause applies to any port, whether on a PHY

    or a SubPHY.  Eric agreed with this observation.  (Colin) I forgot the

    property of a SubPHY that it must magically KNOW the speed on the fiber

    side.]


    [Discussion of transmitter problems by Mike Teener, recommending caution.

    Possible to use TpBias with a data zero to signal a 1394b component,

    which is definitely not a -1995 or 1394a behavior.  This can occur

    without use or availability of a clock, which means it can be done

    before/without first synching up.  TpBias with Z indicates D/S, while

    TpBias carrying "0" indicates beta-mode.  Further discussion regarding

    how to deal with a "chirp," versus "on" or "wake up" signal.

    "Conclusion" is that we need to address this, but must wait for the

    1394a folks to settle on a solution ...]


    [Discussion of "disconnected" versus "disabled" states.  One problem

    is telling when a "re-enable" is really a new connection.  There are

    problems with disconnect and reconnect of disabled devices, especially

    if the disconnected device is not the one subsequently connected, but

    which itself was disabled.]


    [A suggestion was made regarding simplifying our lives later, via proper

    selection of test loads.]


 b. Coding Schemes for 1394b -- Alistair Coles -- Handout should appear on

    reflector.


     -- Note on error detection

         -- 1394 uses CRC-32 can detect any three single error events at

            speeds up to S1600, BUT only TWO at S3200 speeds.

     -- FDDI 4B5B code

         -- It is NOT DC balanced!

         -- Detection of all three single bit errors is not guaranteed.

            There is no way for the coding scheme to save you, even when

            CRC-32 breaks.

         -- Control signals are repetitive resulting in discrete spectral

            lines, e.g. the proposed IDLE results in alternating 1's and

            0's for duration of IDLE.

     -- IBM 8B/10B code

         -- IS DC balanced, and disparity at end of a packet is indicated

            by the DATA_END following packet.

         -- Any odd number of signle error events during a packet will be

            detected, since DATA_END will be incorrect.

         -- However, when the packet is re-coded and forwarded, this infor-

            mation is lost.

            **diagram** showing communication from node A, through node B,

            to node C.

         -- Need a distinct DATA_END_ERROR signal to mark packets corrupted

            on a previous link: Similar to FDDI frame status field, and

            802.12 Invalid Packet Delimiter.


    [Questions whether this is indeed the case were raised.]


     -- IBM 8B/10B code continued

         -- Single error can change data codeword Dx.y to K28.5 (Hamming

            distance of 1 between control and data).

             -- Possibility of false DATA_END

             -- Possibility of false "embedded" control signals.

         -- [K28.5,Dx.y] ....

         -- .....


     -- HP 8B/10B code

         -- Control represented by single 10 bit codewords, which are Hamming distance of

            2 from data codewords.

         -- Compatible with use of scrambler -> good spectral properties

         -- ....

         -- ....


     -- Comparison of coding schemes (1)

         **table** showing pros and cons of three coding schemes

         Code        Pros                      Cons

         ----------- ------------------------- -----------------------------

         FDDI 4B/5B  Simple, low latency       Error detection is poor

                                               Unconstrained disparity

                                               No scrambler

         ----------- ------------------------- -----------------------------

         IBM 8B/10B  Well known, simple, good  Large latency for control

                     disparity control         No scrambler

                                               Poor error detection with em-

                                               bedded control signals

         ----------- ------------------------- -----------------------------

         HP 8B/10B   Good spectrum             New

                     Scrambler                 More complex

                     Good error detection


    [Discussion of relative merits.]


     -- Modified IBM 8B/10B scheme

        **diagram** showing additional mechanisms

         -- Replace 20 bit K28.5,Dx.y arbitration encoding with new set of

            sixteen 10 bit control codewords which are Hamming distance 2

            from IBM data codeword set.

         -- Add a scrambler.


     -- New control codeworkd set

        **table** showing new codeword set

        [Affords opportunities for very strong error detection properties.]


     -- Control State Mapping

        **table** showing 1394 arbitration signals mapped to a nibble code.

         -- Hamming distance 6 between +ve and -ve rds (disparity).

         -- Hamming distance 6 between SPEED_SIGNAL and DATA_PREFIX.


    [Questions regarding possible loss of various additional data-error-

    detection properties of IBM 8B/10B code, and how this new code deals

    with such problems.]


     -- Example packet structures

        **diagram** showing S100 packet transport over S800 link

        **diagram** showing S200   "      "   "    "    "    "

        **diagram** showing S800 (with error) packet forwarded on S800


    [Discussion of synchronization issues with scrambler.]


     -- Scrambler Operation

        **diagram**

         -- Use alternate bits of PRBS output to scramble control.


     -- Example of coding

        **table**


     -- Start-up procedure

         -- For start-up described by Colin Whitby-Strevens at May meeting,

            need S1, S2, and S3 patterns.

         -- Propose

            S1 = [K28.5,D10.2] = [0011111010][0101010101]

            S2 = [K28.5,D21.5] = [0011111010][1010101010]

            S3 = [K28.5,D28.5] = [0011111010][1100000101]

         -- Synchronize scrambler on first occurence of a Cx codeword.

         -- "Blind" codeword and scrambler synchronization is also possible,

            i.e. receiver can decude codeword and scrambler synchronization

            from the transmitted IDLE.


    [Scrambling is not active during start-up, but is started after start-up

    procedure is completed.  Node must know when a control is being received.

    Scrambler starts at end of S3.  Transmitter must send known C-word at

    prescribed points in time ....]

    [Questions regarding IP were raised, including whether we might still

    need to pay IBM licensing for a scheme based upon the IBM 8B/10B code.

    There must be discrete spectral lines during start-up for S1, S2 and S3.

    There is no reason why one couldn't start up scrambling before S1, S2

    and S3, which may obviate the problems of spectral lines during S1, S2,

    S3 and IDLE. (Colin)]


     -- Comparison of Coding schemes (2)

        **table** showing the four discussed coding schemes, with relative

        pros and cons.


    [Discussion of length of control words, and whether we are trying to fix

    something that isn't broken in the first place.  What we are doing isn't

    necessarily fixing a non-existent problem, but precluding new ones, etc.

    This is a different problem from that being addressed by Fiber Channel.

    (Teener) Based upon Telecomm experience, scramble everything anyway.  It

    helps prevent problems, and is virtually free.  Run lengths don't seem

    to be a serious problem .... We are really solving an unknown problem,

    here, as we don't know what the domestic environment will do to our

    signals, etc.  We are well advised to preclude problems, rather than

    wait for them to arise.]


     -- Comparison of Coding schemes (3)

        **table** showing properties of the four coding schemes.


    [We need to determine where we are relative to the best we can do (in

    emissions), which will help us determine whether any new proposal can

    actually yield a meaningful gain.]


<<<<<<<< Recessed at 12:49 PM, planned resumption at 2:00 PM >>>>

<<<<<<<< Actual resumption at 2:17 PM >>>>



 c. Spectral measurements and use of a scrambler -- Eric Deliot

     -- Outline


     -- IBM 8B/10B data spectrum

        **diagram**


    [Payload used was random characters.]


     -- FDDI data spectrum

        **diagram**



     -- Sending Idle -- IBM 8B/10B

        **diagram**

         -- Idle stream is the repetition of [K28.5,D5.0]


     -- Sending Idle -- Sony's control mapping

        **diagram**


    [(Taka) This is NOT Sony's proposal!]


     -- Byte padding -- IBM 8B/10B

        **diagram**


     -- Nibble padding -- FDDI 4B/5B

        **diagram**


     -- LSBs padding -- IBM 8B/10B

        **diagram**


     -- LSBs padding -- FDDI 4B/5B

        **diagram**


     -- Modified IBM 8B/10B -- Control System

        **diagram**


     -- Summary

         -- Repetitive signals cause spectral lines, and concentration of

            energy at a few frequency points.  Examples shown include:

             -- Sony 4B/5B Idle signalling (10101010...)

             -- IBM 8B/10B signalling (repeated K28.5,D5.0)

             -- Transmission of S100 packet over S800 link with zero padding

         -- This makes life harder to be sure that systems pass FCC class

            B ... Further testing should be done with emission measurements.

         -- Using a scambler gives smooth spectrum, and makes life easier at

            almost no cost.


    [This approach (scrambling) should significantly help us reduce spikes.]

    [Extended discussion of noise issues, over a range of issues.]


 d. P1394b Startup Procedure -- Colin Whitby-Strevens

     -- Modifications from previous proposal

         -- addition of an optional local PHY-PMD speed negotiation

         -- removal of "test until it fails"

         -- maintain start with slowest speed, and negotiate up

         -- positive "reject" of proposal for higher speed


    [These may be superceded by other proposals made so far in this sequence

    of meetings.  Considerable discussion as to whether the neogiation pro-

    cess is a virtual test-of-media, and how the logical process of negoti-

    ation to higher speeds will take place.  This proposal has the side-

    effect of determining what the highest speed the "cable" may operate

    at, which may indirectly indicate a problem.  Colin would like to start

    speed negotiation at S100, and work upward.  SubPHY to SubPHY is a

    special case, when we consider the case of objects behind wall-plates.

    (Wooten) I thought that Beta connections start up at S800 ... (Colin)

    That is what was indicated earlier, but this is an issue ... (Teener)

    You start where it is appropriate ... UTP at 100 and stop, glass fiber

    at 800+, etc. ... (Hauck) I'm confused -- How are we doing this?  A few

    minutes ago we were starting at a speed we knew would work, and now we're

    stepping upward through speeds ... These can be different cases ... All

    this is on a per-port basis.]


 e. Beta Mode Arbitration Enhancements -- Mike Teener

    -- Not really ready, but this is what my ideas are ...

       **diagram** Obtain from Mike.

        -- connections are now really full duplex.

        -- if listening to a parent, node sends parent any outstanding re-

           quest, which may be from a child, or further down-tree from the

           node.

        -- if a parent is listening to a child, node sends grants/stand-offs

           down to child being listened to.

        -- embed an arbitration code in packet

        -- arbitration reset and subaction gaps by explicit symbology


    [So, are we bit-stuffing, or byte-stuffing?]

    [S100 devices just use up bandwidth ... Grants, etc., would be at tail

    of packets they are attached to, which delays grant until last minute.]

    [Discussion of use of broadcast write for achieving some of the function

    of cycle-start packets -- correction to the cycle timer.  This is

    supported by Apple parts, and should be looked at by OpenHCI.]


 f. New

    Nothing new under the sun.


 5. Future meeting schedule

 -- August 6 & 8, Honolulu HI

 -- September 23-24, Boston MA

 -- October ??-??, Chandler AZ

 -- December, week of 8-12, Orlando FL

 -- January ??, Location TBD

 -- February ??, Location TBD

 -- March ??, Location TBD

 -- April ??, Location TBD, but NOT in Seoul, Korea!


    [Coding decision in September (August would be better)



 6. Action Items

 -- Closure discussion on coding at August meeting, with vote.  Final vote in

    September.

 -- Alistair Coles -- Look at problem of PLL lock-up with scrambled synch

    signals.

 -- "Failed" action items for this meeting are carried forward.

 -- Group to finally and conclusively decide on whether receiver is to be AC

    coupled.  Principally Dao-long Chen, Mike Sorna, Eric Hannah, et alia,

    for this and related items.



Mike Teener moved that we elect David Wooten the new chairman of the group.

Mike Brown seconds.

Mike voluntarily tabled the motion until the next meeting after Wooten asks

for time to consider.


Motion made to adjourn, and accepted without objection, at 4:26 PM.



-----------------------------------------------------------------------------

ATTENDEE LIST


 1. Mike Teener

    408-461-4901

    mike@fireflyinc.com


 2. Steve Bard

    503-264-2923

    steve_bard@ccm.jf.intel.com


 3. Alistair Coles

    +44 117 922 8750

    anc@hplb.hpl.hp.com


 4. Eric Deliot

    +44 117 922 9539

    ed@hplb.hpl.hp.com


 5. David Wooten

    281-518-7231

    david.wooten@compaq.com


 6. Dao-Long Chen

    970-223-5100x9461

    dao-long.chen@symbios.com


 7. Jack Merrow

    425-486-2222

    jmerrow@leviton-telcom.com


 8. Dick Scheel

    408-955-4295

    dicks@lsi.sel.sony.com


 9. Michael Nguyen

    408-894-3542

    michael.nguyen@fcpa.fujitsu


10. Mike Eneboe

    408-974-0615

    eneboe@apple.com


11. Jerry Hauck

    408-765-5528

    jerry_hauck@ccm.sc.intel.com


12. Dave LaFollette

    408-765-2587

    dlafolle@mipos2.sc.intel.com


13. Steve Midford

    408-765-8370

    steve_midford@ccm.sc.intel.com


14. Mike Brown

    602-554-3713

    mike_brown@ccm.ch.intel.com


15. Eric Hannah

    408-765-4441

    ehannah@mipos2.sc.intel.com


16. Richard Churchill

    281-514-6984

    richardc@bangate.compaq.com


17. Charles Brill

    717-592-6198

    cebrill@amp.com


18. Bob Atkinson

    717-592-4274

    rdatkins@amp.com


19. David E. Instone

    +44 1705 486363

    dinstone@uk.xyratex.com


20. Bill Prouty

    916-785-4631

    billp@hprnd.rose.hp.com


21. Colin Whitby-Strevens

    +44 1454 611500

    colinws@bristol.st.com


22. Taka Fujimori

    +81 3 5488 6353

    fujimori@arch.sony.co.jp