P1394b meeting,
Fort Collins, CO, March 3, 1997,

Start of meeting -- 8:30 AM, coffee and such (the important stuff)

9:00 Administrivia

Agenda,

PAR status,
Voting -- not an official IEEE group, voting based upon past attendance, informal
concensus (90%) rules
Editor,
Request for Secretary
Next meeting, April 7, Santa Clara, hosted by Intel, Subsequent meeting, May 5, (in
conjuction with x3t10 [scsi])
Action item for Mike Teener -- call for confirmation of meeting room Located in Natick,
MA
Other possible meeting dates --
June 10-20, (x3t11 in Seattle(?), 9-13, Roger Cummings, chr.) (also check with Peter
Johansson re. p1394a)
July in conjuction with TA (Cirrus Logic?)
August, (x3t11, 11-15 in Honolulu? -- p1394a?)
October in conjunction with TA (Intel, Phoenix?)
November
January

First draft of p1394b in April. Intent remains to place protocol/arbitration issues in p1394a,
and place all speed enahncement issues in p1394b. An annex J enhancement may also be
part of p1394b

Continuous vs. Start-Stop, Power, Area and Risk Comparison

Dao-Long Chen, Symbios

Assumptions:
0.35um CMOS
800 Mb/s transceiver only (figures don't include the DS xcvr, encoder/decoder, etc.
????

1 port 3 ports 10 ports
Power Cont Active 275mW 710mW 2.2W
S/S Idle 450mW 500mW 675mW
Active 600mW 825mW 1.8W
Area Cont, 2.3mm**2 4.7mm**2 13.5mm**2
S/S, 3.5mm**2 4.0mm**2 5.8mm**2

S/S is anticipated to take .5 to 1 year longer to develop

Power(S/S)/Power(Cont.) results viewed as consistent with IBM and SGS-Thomson work

Area(S/S)/Area(Cont.) result viewed as largely consistent with IBM and SGS-Thomson
work, except for 10 port PHY


Other issues for S/S
initial charge-up

Symbios recommends continuous mode operation based upon these studies.

Symbios plans to use digitally assisted lock-up ....

Symbios preference is for AC coupling, which is apparently at variance with conclusions
of group at previous meeting (Mike's comments -- This is due to the requirement to be "A"
compliant when operating in common mode. [There was much drawing of the basic
circuits ....] "A" signals are about 200 mV, while "B" may be about 400 mV. Also,
transmitting on TPB allows for a wider voltage range than on TPA. No matter what, you
must be backwards compatible, so the external appearance of the recvr must comply, even
if the internal implementation becomes AC coupled.)

IBM progress

Keith W. Heilmann
email: heilmann@vnet.ibm.com

Mike Sorna was unavailable due to his wife's problems with pregnancy

Still plan to use 8b/10b coding. assume 8K max packet at 800 Mb/s. no insertion or
deletion of characters within a packet. 20 ns arbitration character assists ????

(Keith has an action item to determine the patent situation, including whether this is specific
to Widmer/Franaszek or to all 8b/10b.)

2-Byte ordered sets for arbitration, (K28.5,Dxx.y) First byte special K character, next ????

Data format would require 2-byte ordered set, speed determines which bits are valid ----

speed data format
100 DD00 0000 0000 0000
200 DDDD 0000 0000 0000
400 DDDD DDDD 0000 0000
800 DDDD DDDD DDDD DDDD

Initializing the Bus:
Normal -1995 tree-id and self-id, using 400 Mb/s analog speed signalling, with actual PHY
caps reported in SID packet
Record the peer speed for each port from the SID packet using the last SID packet received
from the child when the PHY receives indent_done. An algorithm created for digital speed
signalling is required to identify parents SID packet.
All PHYs enter A0 (idle) communicating with 400 Mb/s -1995 analog signalling.

Sending PLL Rcv Sync Packet:
All PHYs with a peer capable of 1394B communications issue a priority request to send
RCVR PLL Rcv Sync Packet

Ports convert to 1394 communications after transmittting the sync packet, PHY begins
transmitting on
TPB ...

Concern .... s400 and s800 bit rates (not data rates) are not integer multiples

Concerns
Serial Bus:
Cable attenuation and connector electrical performance
Should the 1394B connection remain over a bus reset? (This would require tree-id and self-
id over the Gbit interface.)
2 and 4 Gbit/s receive PLLs must be able to handle slower 1394B data rates.

Link/Phy interface
Should the interface remain at 50 MHz to support isolation Support older links? (Almost
certainly not ....) Can thel ink request the PHY to send a Receiver PLL synch packet?

(There was discussion regarding how to handle a fiber connection, with agreement that
there needs to be serious examination of the issues involved.)

Summary
Compatible with -1995. Digital speed signalling for speeds over 400 Mb/s. Continuous
stream of 8b/10b code. Minimizes changes to existing state machines.

IBM is currently evaluating cable transceiver specifications:
DC vs AC coupling
Signal amplitude boost (~600mV)
Analog current and voltage specs.

SGS-Thomson Design Homework for 1394 800 Mb/s PHY,

Colin Whitby-Strevens and Stephen Cowen

(PDF copy of Colin/Stephen presentation) Colin could not easily attend, sooo ...

Propose to call the high-speed link a "Beta" link and the way of working "Beta" mode.
Would have proposed B-link, but that was already taken

Presented typical circuit according to their current views

Modes of use discussed ...

Configuration 1 -- all branches are 55 ohms serious mismatch problems

Configuration 2 -- 110 ohms in most branches. still badly mismatched ("Why did he
increase the resistance?" and discussion followed.)

Configuration 3 -- different net, better results ...

Chip and board layout issues. Chip we need TPa(Beta)+ ....

AC coupling is highly desirable. AC coupling is possible. Requires a seperate pad for each
connection (two extra pads). DS link integrity may be affected in the best compromise that
we have identified minimized by careful board design. Board design challenges ...

First start-up proposal similar to IBM's
Second start-up proposal suggests an analog signalling from parent
Third " " " " uses "mutual blast" appoach

Power saving issues offered "No problem in stopping a link ...."

Highly desirable to be "fiber ready" .... seperate group to sort out PMD connector, etc.
Note the current debate in Gbit Ethernet .... Fiber cannot transmit DC. DC is currently used
for -- connection detection, Tree-ID, arbitration, speed signalling

Proposed "Fiber Ready" start-up technique

[Teener starts writing ....
3 ways to start
1. dead start, no Beta -> full ...
2. insert a new node
net is operating normally
add a node
link between new node and new parent comes up first
3. s/w reset, or the rest of the net in case (2)
direct map of -1995 bus init onto Beta
]

[Discussion of fiber cable continued .... How to detect the presence of cable/device at other
end? What signal levels are required?
]

1394 Connector and Cable Studies Eric Hannah, Intel

(PDF of Eric's presentation)

Presentation of white paper on empirical studies of the existing connector and cable,
showing existing problems with the both.

A mathematical model was generated, based upon the empirical data, for the connector.
Then the same was done for the cable.

Simulated eye diagrams for various speeds shows a deteriorating behavior, with ringing
present in the 400 Mb/s case.

Recommendation is that connectors be improved, and that (due to an expectation that a
transition from use of 800 Mb/s for disk interface to migration to 1600 Mb/s is about 1.5
years) any
selected connector should support 2 GHz data rates.

[If we are in fact pushing 1394b to 3200 Mb/s, might we need to support 3200 with any
connector/cable we select?]

IV. Michael Fogg, AMP

Differences Between 100 Mb/s and 800/1600 Mb/s Applications An Emphasis on ???

 

Impedences Discontinuities ...

Transmission line behavior ...

Crosstalk issues ...

[Connector discussion centered on whether we may break the connector at some point (we
are expected to), and the point at which we may do so (the later the better ... within limits).
Homework for any who wish to do it -- effects of short and very short cables. ]

[Question of whether we should go to a 64-bit CRC was raised. There was very little
interest.
]

Where?
www.fireflyinc.com
ftp.fireflyinc.com

Attendees

name company email phone
Dao-Long Chen Symbios Logic dao-long.chen@symbios.com (970)223-5100x9461
David Wooten Compaq davidw@bangate.compaq.com (281)518-7231
Don Tonn Adaptec dontonn@eng.adaptec.com (408)957-2110
Eric Hannah Intel eric_hannah@com.sc.intel.com (408)765-4441
Bill Pherigo HP WLP@fc.hp.com (970)229-3586
Keith Heilmann IBM heilmann@vnet.ibm.com (914)892-2413
David LaFollette Intel dlafolle@mipos2.sc.intel.com (408)765-2587
Stephen Cowen SGS-Thomson stephen.cowen@??.com (?03)772-9729
Jeff Morriss Intel jeff_c_morriss@ccm.intel.com (503)264-6228
Robbie Shergill National Semi rss@berlioz.nsc.com (408)721-7959
Bill Northey Berg northewa@bergelect.com (717)938-2119
Bob Godek Hirose BobG@hiroseusa.com (805)522-7958
Tatsuya Arai Hirose TatsuyaA@hiroseusa.com (805)522-7958
Michael Fogg Amp mike.fogg@amp.com (717)986-5802
Michael Nguyen Fujitsu michael.nguyen@fcpa.fujitsu.com (408)894-3542
Daniel Meirsman Philips Daniel.Meirsman@leu.ce.philips.com 216-390-733
David Thompson Lucent aluxpo!dt@lucent.com (610)712-2730
Charles Brill AMP CEBrill@amp.com (717)592-6198
Bob Whiteman AMP Whiteman@amp.com (717)592-5124
David Johnson TI dkjohnson@ti.com (972)480-3632
David Allen TI dallen@ti.com (972)480-3329
Richard Churchill Compaq richardc@bangate.compaq.com (281)514-6984
Patrick Yu NEC patrick_yu@el.nec.com (408)588-5436
Peter Teng S3 pteng@mail.com (408)588-8111
Tim Katynski LSI katynski@lsil.com (408)433-4175
Karl Nakamura LSI karln@lsil.com (408)433-4516
Michael Johas Teener Firefly mike@fireflyinc.com (408)461-4901