Date: 12 May 97 10:35:36 -0700
Subject: P1394B Musings
From: DavidW@bangate.compaq.com
To: p1394b@fireflyinc.com
X-Mailer: Cyberdog/2.0
MIMEEnabled: Y
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-0003FDCB"
Content-Transfer-Encoding: 7bit


--Cyberdog-MixedBoundary-0003FDCB
Content-Type: text/enriched; charset=macintosh
Content-Transfer-Encoding: 8bit
X-Fontfamily: Monaco
X-Fontsize: 9

<SMALLER><SMALLER><FIXED>Some food for thought (warning, it might be junk food.)


David Wooten


PMD


If we design the standard PHY around the 4.5M copper cable and assume some 

intelligence in the interface to alternate media we might be able to simplify 

the individual protocols at the expense of having to define protocols for each 

of the media.  In particular, I think that the start up protocol for the 

standard copper cable can be much simplified from that which may be required 

for fiber or cat 5 cable.  Also, I thing the signaling conditioning required 

for cat 5 (scramble and such) may not be appropriate for shielded cable that 

is running at a higher speed.  Seems to me that the problem with Gbit is not 

to move energy to the lower frequency range but to make sure that the energy 

is relatively evenly distributed.  Both the HP and Sony schemes presented at 

the 1394b meeting were fine if the max rate was 100 Mbaud but when 

transmitting at 1Gbaud, the 'low frequency' peaks seem to move into the range 

of interest to FCC.  So, assuming that I understand what the charts mean, we 

would be making things worse for Gb rather than better.


Another advantage of having intelligence in the PMD is that it allows us to 

use cat 5 to extend existing,  DS based S100 systems and to use fiber to 

extend DS based S100, S200 and S400 based systems (assuming that we can get 

power some place.)


Power


If we are going to want to stick fiber in at arbitrary places, we are going to 

have to make sure that all devices are providing power for the PMD in the 

cable.  Having each device provide power might actually be the lowest cost and 

simplest solution to the whole power mess.)  This might be something that we 

want to feed back to the 1394A folks.


I have noticed that the 1394.2 folks have called for a 12V power supply but 

things must be able to withstand 48V?


Home LAN


If we have wall boxes that contain intelligent converters (e.g., copper to 

fiber) and we have each device provide some power to the bus, then if someone 

connects a standard 1394 cable to the wall, the PHY in the wall can draw its 

operating power from the standard cable.  This means that a user would not 

need to have special wiring to get some DC supply to the device behind the 

wall.  The only case where someone would need a wall-wart would be when they 

are using a long cable to attach to the wall outlet.  Perhaps we need some 

keying to prevent this?


Baud Rates


I have a vague recollection of some mention of the issue of high speed baud 

rates vis a vis S100, S200 and S400 clocking. I don't remember what the 

conclusion was but it seems to me that 1.2G (actually 12*S100) would be 

easiest to deal with if one were doing a straight up PLL rather than a DLL.  

Is this worth looking at any more or are we going to be able to ?


If we let the PMD have some intelligence (basically be a two port PHY) then 

there is no reason for us to require that standard PHYs include support for 

100, 200, and 400 MbPS in beta mode.  The local PHY can talk to the cable PHY 

at any speed that's appropriate and then the cable PHYs can, if necessary, 

negotiate the speed that they talk at.  Only thing to watch out for is that we 

don't want the local-to-cable connection using a higher baud rate than the 

cable-to-cable connection.  However, the cable-to-cable connection can be at a 

higher rate than the local-to-cable connection.  This is not to hard to 

control.  First thing that happens is that the cable PHYs establish a 

cable-to-cable rate and then this rate is used as the maximum for the 

local-to-cable on each end.  It might be OK if one end has a higher speed 

local-to-cable connection than the other end.  The cable PHYs will filter 

traffic that is at too high a speed.  The speed map can be built correctly if 

we have the expanded selfID packets.


Note: The 1394A folks are working on the problem that a PHY may be able to 

repeat at a faster speed than it can talk to its link.  This means that there 

might be as many as three speeds that need to be reported: 1) maximum speed of 

PHY; 2) speed of PHY to parent node and 3) speed of PHY to link.


Low-speed byte packing


Seems that if we try to send lower speed data as a byte followed by the 

appropriate number of fill bytes then we will have to consider the impact that 

this has on latency.  I'm not sure this amounts to much but, when an S100 

device is talking, it takes about 80 nS to accumulate a byte's worth of data.  

This latency is incurred each time we go from a low speed link to a high speed 

link which, in the vast majority of cases, is only going to be once per 

transaction.  The issues with this latency are what it does to reported PHY 

delays (I think it makes PHY delays speed dependent.)


Don't get me wrong, I prefer the byte-at-a-time approach.  I just want to 

point out that it might not be as simple as it sounded when presented.



Startup


Again, assuming some intelligence in the fiber and cat 5 PMD, I think the 

startup is fairly straight forward.  Not all three type of media have the same 

startup so I'll break it down.  For 'simplicity', I'm going to call a PHY port 

that drives the standard 1394 cable a standard port, and a port that directly 

drives optical circuits an optical port. (Note, an optical port can be a cat 5 

port.  This doesn't mean that one can replace the optical media with cat 5 but 

rather that, in the text that follows,  one can substitute the term "cat 5" 

where I have used "optical".)


1) standard walkup and internal connections -- these are DC coupled.  A beta 

mode capable PHY can identify a beta mode capable PHY by sensing the TPB lines 

at connect/startup time.  When tpbias has been debounced, the PHY will look at 

the state of the TPA input.  If it is 0, this indicates that a beta mode PHY 

is present and the 'training' process begins. 


2) optical PHYs -  these PHYs would have a standard port and an optical port 

on the other.  The optical port is simplified from the standard port in that 

it only supports beta mode and doesn't need tpbias detection, arbitration 

comparators, or speed signal current sources.  They also only need a 

transmitter on the output and a receiver on the input (rather than a Tx/Rx 

pair like a standard port requires.  The optical connect detect could use a 

periodic burst of the sort that was outlined by Colin.  It would only generate 

the periodic burst (and power its receiver) if it detected tpbias on the 

standard interface side (indicates that cable is attached and there's an 

active PHY to talk to.)


There are a couple of ways to go about the training.  One way is for the 

optical PHYs to establish the connection at each end at the lower of the fiber 

data rate or the rate of the equipment to which it is attached.  This could 

lead to a case where one piece of equipment is talking to the fiber at S400 

and the piece of equipment at the other end is talking to the fiber at 1Gbaud. 

 The fiber PHYs would do the appropriate conversion (S400 to fiber speed at 

one end and fiber speed to 1Gb at the other end.)  About the only thing this 

does is make for some 'interesting' speed maps. ( I refer you here to the 

Speed Map discussion below.)


Another way to do the training is to make the training be end-to-end.  For 

this to work, the cable would probably have to configure itself first, and 

then let the two pieces of equipment take part.  I think this can be figured 

out but I think its not as simple as letting the speed be on a PHY pair basis 

rather than having to be end-to-end.  Main problem with end-to-end will be 

letting the cable limit the maximum speed at which the two standard PHYs try 

to communicate.  If we followed the process outlined by Colin (and friends) 

the standard PHYs keep trying to increase their speed of operation.  At some 

point, the standard PHYs may try to increase their speed beyond what the cable 

is capable of.  At this point, the cable PHYs will have to interceed and 

prevent the attempt to go to a higher speed.  This requires that the cable PHY 

monitor the progress of the training of the two standard PHYs.


If we have a non-beta mode PHY attached to the optical PHY, then there is no 

way to guarantee that we are going to get the speed map correct unless the 

optical cable is capable of at least S400.  This is because there is no way to 

communicate the speed code through the optical cable in a timely manner.  If 

the cable is only capable of S100 and the standard PHYs at either end are 

capable of S400, then nothing in the speed map is going to be able to 

represent the speed of the cable.  This can be fixed if we get the 1394A folks 

to include two speed values in the map (the maximum speed of the PHY and the 

speed of the connection to the parent.)



Speed Maps


We don't want the cable PHYs to have a node ID.  If the cable PHY has no node 

ID, then there is no selfID packet from the cable PHY to indicate the speed of 

the cable.  If we allow each end of the cable to establish the speed at which 

it talks to the cable in a manner that is independent of the speed of the 

connection at the other end, then selfID packet will not indicate the true 

speed of the connection.  It will only indicate the maximum data rate that the 

node can receive from the cable.  If the slower device is always further away 

from root, then this does not create a problem.  The slow device indicates the 

speed at which it is talking to the parent (the cable) and this is the maximum 

speed at which data can be sent between the devices.  However, if the fast 

device is further from root, the speed that the device reports for its 

connection to the parent is not the speed at which data is sent through the 

cable.  The other end limits the speed.  Take, for example, a case where we 

have an S400 device and a 1Gb device connected through a 2Gb cable.  The S400 

device establishes an S400 connection to the cable, the 1Gb device establishes 

a 1Gb connection to the cable and the two ends of the cable talk to each other 

at 2Gb.  Now, assume that the rule for speed reporting of a 1394B PHY is that 

it reports the speed of the connection to the parent (we do this because the 

link may not be as fast as the devices).  If the S400 device is 'downstream' 

of the 1Gb device, the S400 thing would report that it is connected at S400 

and the speed map is correct.  All S400 data that shows up at the 1Gb PHY will 

be sent to the S400 device.  However, if the 1Gb device is downstream of the 

S400 device, the 1Gb think will report that it has a 1Gb connection to its 

parent (the cable can support it.)  However, the cable will not pass 1Gb 

things to the S400 device.  Furthermore, if there is another 1Gb device 

downstream of the S400 PHY, the speed map will indicate that there are two 

devices that have a 1Gb connection to a common PHY which implies that they can 

communicate at 1Gb through the S400 PHY.


We may decide that this is OK.  Or we can try to make it 'right'.  There are 

two ways that come to mind to make it right.  First is to use the caboose 

packet to indicate the maximum speed that the PHY supports.  We still need the 

speed code to indicate the speed of the connection to the parent (hum, could 

reverse this and have the speed code be as it is currently defined -- max 

speed of the PHY -- and let the caboose indicate the speed of the connection 

to the parent.)  Another way to 'fix' the problem is to make sure that the 

connection through the cable is at a speed that both ends support.  Then, when 

the PHY reports the speed of the connection, it will accurately reflect the 

speed that data can be sent through the link.



PHY-link Interface


We need a definition for what this is going to look like for beta-mode PHYs so 

that we have the potential of including it in OHCI.


</FIXED></SMALLER></SMALLER>
--Cyberdog-MixedBoundary-0003FDCB--