Today, we're going to talk all about FireWire 800 hardware and software in our new products, and we also have some interesting new tools to help you develop for FireWire 800. This session will review how Apple has deployed FireWire 800 in our products, how you can use this in your own products, in your hardware, and in your software. We'll briefly look at the impact of FireWire 800 on existing products, and that won't take long. Here's the specific agenda for the slides.

First, we'll introduce FireWire 800, just what is it, what are the benefits, how does it work. Mike will come up and talk about the hardware in great detail, and I will talk about the software. Together, we'll show you how you can deploy this new high-speed technology in your products.

Then we'll briefly go over some developer resources, and we have some new tools to introduce to you that should help in developing for FireWire 800. So, let's get started. What is it? I'm sure you've all figured out it's twice as fast as FireWire 400, but there's more to it than that.

FireWire 800 has a new connector. If you have one of our new products, you've probably seen it on the back. It's this rectangular connector. Why did we change this? The FireWire 400 connectors, the six-pin socket and all the cables, just can't carry higher-speed signals. 800 might have worked, but 1600, 3200 were definitely out, so it was time for a higher-grade signal path. The FireWire 800 connector has more pins, making this possible, but it remains fully backwards compatible with FireWire 400. With the right cable, you can connect all your old FireWire 400 devices to this port.

Clock speeds exactly double as far as the bitrate, FireWire 400, but there's many improvements in the arbitration, so the actual performance you can get may be more than double what you had at FireWire 400 speeds. And, of course, you get greater distances. The specification allows up to 100 meters rather than 4.5, and there's a variety of media that you can use to accomplish this. Mike will go into much more detail about that.

Our products with FireWire 800, the new G5 tower that was introduced on Monday, the 17-inch PowerBook G4, and the XServe all have built-in FireWire 800 ports. In fact, the XServe has two of them. All these products also have FireWire 400 ports. It's on the same FireWire bus, so you can still plug in your iPod, your camcorder, you don't have to go find a new cable just to keep using the same device. Okay, now I'd like to welcome Michael Teener. He's going to tell us in detail how all this new stuff in FireWire 800 really works. Please welcome, Mike. Hi. Hi.

So, I'll be talking a little bit about what FireWire 800 is, and the first thing you should do when you talk about something new is you should talk about what hasn't changed. So, from the point of view of pretty much the whole stack, from the hardware to the software, we have the same old connection model, and the difference is now, instead of just having trees and daisy chains and things like that, now we tolerate loops. So, you can literally connect anything to anything, and it will still work.

We also support the same old peer-to-peer operation. It's not like USB. You don't need a CPU. You can turn off your Mac, and everything will still connect and talk to each other. Has the same kind of user-friendliness, perhaps a little bit better, because we do tolerate the loops. And all the higher-level stuff, the transaction models and higher-level software, are all pretty much the same. And finally, the same kind of thing, the asynchronous and the isochronous transmit modes, they're all the same. They're just faster. Thank you.

So basically, everything above the link layer is the same. So all existing software should work unchanged, as long as you're gonna operate at the lower speeds. At the higher speeds, of course, you have to know about the higher speeds. So, what is FireWire 800 and a more technical thing? That's really Apple's name for IEEE 1394B, S800 bilingual. 1394 has these code terms, which are basically marketing numbers. So when we say S100, we really mean 98.304 megabits a second, but that's too hard to say, so we say 100. And S800 is exactly eight times faster than that.

We have an additional beta mode of operation that I'll talk about a little bit that you guys may want to take advantage of. And from now on, 13.4a operation is going to be called Legacy Mode. 13.4b PHYs, which are the silicon that actually connect to the ports on the back of the computer or your peripheral device.

We have three different types of ports. There's legacy ports, which when you say a FireWire 400 port, that's the legacy port we're connecting to. There are beta ports, which operate only in the new mode, and then there are bilingual ports, which operate in either one. When Apple says FireWire 800, we're talking about a bilingual port, one that can talk to either legacy peripherals or the new beta mode peripherals.

The beta mode is where we get our higher speeds, we get a longer distance, and in a little bit I'll talk about the higher efficiency and the better user experience as well. So, let's talk about higher speeds. We specify in 13.4b S800 and S1600 data transmission rates. It's all been carefully analyzed. And we future-proof it with an architecture and media that support up to 3200.

And as a matter of fact, in the labs we've shown that the existing FireWire 800 cable that you buy off the shelf right now has been validated all the way to 3.2 gigabit a second. So, we're set for whatever we can do in the future. uses the same old shielded twisted pair that crosses over in the middle. The electrical spec still uses the same.

The difference is, now it's what's called continuous dual simplex, which means the two pairs are continuously transmitting like this. In old legacy 1394, we would arbitrate for the bus, and then both wires would be used to transmit the data. One would carry clock, and one would carry data. Now, we're carrying encoded clock and data at the same time in both directions.

As I said, we're transmitting continuously in both directions. One thing that is new is because we're maintaining this connection is the transmission speed, once we negotiate the connection, never changes. So if we're running at 800 megabits between the two ports, we continue to run at 800 megabits between the two ports.

Any legacy packets that are running slower than that are basically byte stuffed to make them come out right. It's actually simpler and much more efficient than existing 1394. So if you have a device that only runs at 800 megabits a second, you'll probably save yourself a lot of trouble by going pure beta mode.

So, how do we get to all this speed? We have a new signal encoding. It's based on 10-bit symbols, which carry both the clock and the data. Every byte of data uses a 10-bit symbol. The data and arbitration states use the same IBM 8B10B encoding system that Fiber Channel and the copper forms of Gigabit Ethernet use.

The data is sent to the encoder, and the data is sent to the encoder. If you send a lot of repeating data out on a wire, even if it's encoded, you'll end up with peaks in your spectrum, which means it'll radiate. You don't want that. So, what we do is we scramble the data first, then we send it to the encoder, and the result is it looks like stealth. It looks like noise that we're sending out there. So, it smooths out the spectrum.

It's a lot easier to meet the FCC requirements. We also have some control symbols. Those are the start and the end of the packet. And unlike Ethernet and Fiber Channel, we use a unique set of codes. Those codes are like the 8B10B. They're all DC balanced. But they have what's called a hamming distance of two from each other and from all data symbols. A hamming distance of two means that it takes two-bit changes within that 10-bit symbol before we can ever confuse it with anything else. So, it's a very... robust encoding scheme.

Those are also scrambled as well, so if you have a bunch of packets that are all the same size, we don't get a little spectrum peak from the start and the end of the packets. We also have a very much shorter start and end packet time. The legacy 13.4 has the same time used to start a packet and end a packet, no matter how fast the packet is. So we start wasting bits. At S800, it gets pretty significant. In the case of FireWire 800, we have just two symbols, and that scales with speed. So we don't lose any time just because we're running faster.

"We have that same 8B/10B encoding scheme for all media, and that media, that's the same scheme we use for optical media. So we use the benefit of that PHY, that TI PHY that's currently shipping, can be used to drive optical media, twisted pair media, as well as the standard shielded media that we use." Another way we get a higher efficiency level is we have a brand-new arbitration scheme. We needed to do this because Legacy 1394 alternates between arbitrating for the bus and then sending the data.

That means that the arbitration is going to depend on the round-trip delay time. If you have a really big 1394 network, and say you ran it across the room here, I'd have to send my request over to the root, which could be anywhere, and I'd have to get my grant, and the grant would have to come back, and then I could send my data.

Well, that's not too bad as long as it's fairly slow and your network's like this. But once you get to really long networks, or you get to really high speeds, that's wasted bits going back and forth, and we don't want to waste any bits. Um, 13.104b uses an overlapped arbitration scheme, um, and the scheme is known as BOSS. The BOSS stands for Bus Owner Supervisor Selector. Of course, we came up with BOSS first and then came up with what the acronym meant.

Also, notice it's a four-letter acronym. That's because we're not Intel. Intel only uses three-letter acronyms. We're one letter better. BOSS is the currently transmitting node. That's an important state. We don't have the concept of a root, except for some specialized functions and error recovery. In beta mode, the important thing is whoever's transmitting owns the bus. Kind of a nice concept. And we use that node to decide who transmits next.

We have an explicit decision at the end of each sub-action. A sub-action is, you know, you're sending out a read, and then there's a little act coming back, and that act is ending the sub-action. That immediate decision that we make saves the arbitration time. Now, let me show you what that means. Here's a typical little system.

This is kind of the prototypical 1394 network. Node number zero is the boss. It's transmitting data. So this is the model of what you'll be seeing. I'm now sending some data. This could be an isochronous sending a video stream. 1394b says that this guy sending, he's the boss.

So what'll happen is requests are going to go in the opposite direction of the data. Remember now we're continuous half-duplex, so we're sending data all the time like this? So when we're sending data away from the boss, the reverse direction is available to us. So that's why we'll just start doing arbitration.

So we're going to start sending the request back up in the opposite direction while the data is being transmitted. So in this example, node number two makes a request. Node number one makes a request too, but it's lower priority. Ah, we get to have priorities too. We only use them for very special purposes, but we do have priorities. That request gets forwarded all the way to the boss. Now the boss basically knows what kind of requests are coming while it's transmitting data.

When the boss finishes sending data, it'll send a grant right on the end of the data. So that grant propagates down until it reaches a node that has a high-priority request. At node number three, we had a high-priority request and a low-priority request, so the one receiving the low-priority request just gets it into packet. It doesn't get the grant.

The grant is always percolated back to the node that has the highest priority request at any particular node. So it only ends up in one place. So, the result of this is gaps are removed. We don't have this send the data, arbitrate for the bus, win the bus, send the data. We can literally start sending the data immediately after getting the end of packet.

That end-of-packet sequence includes an optional grant symbol. In fact, the real way to think about it is there's two types of end-of-packet. One of them doesn't give a grant, and one of them does. And each node repeating that end-of-packet sends the grant to the highest priority request that it's getting. There's only going to be one direction for the grant.

A similar process removes the need for what's called the arbitration reset gap, so we don't have that gap either. The result is it's a much more efficient bus. The other thing we do is we get rid of loops. Sometimes it's called loop healing, but that's an unfortunate term because we're actually trying to break loops. But sometimes I use that term, so forgive me. I really mean loop breaking.

What we do during this loop-free build is we break all loops that can be removed by disabling a beta mode connection. A beta mode connection, remember, is a FireWire 800 to FireWire 800 connection. So any loop, so you could have a loop of all legacy connections with one FireWire 800 in the path, and we'll break it.

We'll make sure that it works. We will prune any branch containing a loop that cannot be healed. So if you have something that's sitting out here, it's a real complicated thing, and somehow somebody built a loop out of legacy 1394, we'll just take that branch and disconnect it, and the rest of the network will work.

We will not interfere with the operation of legacy FIs. They're out there. Things work. They don't even know what's happening. We don't require any software intervention, although software will know what's happening. So some of the stuff that Eric can tell you about, we'll be able to tell you that kind of thing. We re-enable connections whenever something has to be done. So, for instance, say we created that loop and we broke at one beta connection.

And then somebody broke the connection somewhere else, we would re-enable the one that was broken so that we keep the loop alive, I mean the network alive. It's kind of neat. You can actually build, if you want to build yourself a highly redundant system, you can just interconnect all of the nodes and everything will work. And if any one cable gets tripped over or pulled out, everything will reconfigure and it'll still work.

You haven't seen some of our labs, or you'd appreciate that joke. We don't interfere with the ability of software to determine the network topology. As a matter of fact, unless you're really smart, you can't even... It'll look like somebody's out there unplugging and plugging cables real fast. So that's the way it looks to most software. One thing to note, it is not deterministic. So I can't tell you ahead of time where the loop is going to be broken. It depends on some randomizing algorithms. So we can't tell you that. And there's no way to control it.

There we go. Didn't want to blast anybody with the laser. One of the things we need to do is we wanted to make sure we have the backwards compatibility built in, and 13.04b, of course, supports that. And remember I said a port on a PHY can either be a legacy PHY, which stands for a DS port, a beta-mode-only port, or a bilingual port. And we have some connector keying to make sure people don't do anything silly around here. A fly can have any mix of ports operating in the DS mode and the beta mode, and it can change dynamically.

A PHY can have a B-Link, which is what we use to get FireWire 800, or a Legacy Link or no link at all. So you can still build hubs, which is basically a PHY floating all by itself. So here's what we got. This is a typical hybrid bus. It's got these DS nodes of the legacy nodes. DS stands for data strobe. I'm not making a bad joke here, okay? And there are B nodes sitting out here, which are our new style nodes.

The first thing that happens after the bus gets up and running is you end up with all the B nodes clustering themselves into things called B clouds. This is kind of important because within those B clouds, the devices within those clouds will try to operate at the best speed they can. They'll use the beta mode connections to talk to each other, which are this highly optimized boss arbitration and all that kind of cool stuff.

The nodes that are on the edge of those clouds that talk to the data strobe are called border nodes, and that's where all the magic takes place that translates between the two modes. So, what do we get out of the hybrid operation? There are no restrictions on mixing legacy nodes and 134b nodes, beyond the fact that if you divide up two b-clouds with a legacy cloud, you're not going to get as much performance because you've got a 400 megabit path between two 800 megabit paths. Sorry. So, the best you can do is 400 between any of those two.

The key was, at least it'll work. The traffic within the bCloud can exploit all the benefits, including loop breaking and all that kind of cool stuff. The data strobe traffic operates as normal with a rather complicated set of gaps that need to be managed. They can all be done as well.

We have a better connector. The new connector, as Eric said, was needed for higher data rates. It was actually, if you look at the connector, it's actually slightly smaller than the existing six-pin connector. So, and it's also shallower, so it makes it a little bit easier to build your designs. It has keying to make sure there's compatibility, so you can build a beta-only node and you can't plug in a cable, an adapter cable to it.

And there's two variants. There's the bilingual connector and the beta connector, and two forms of plugs, a bilingual, a beta-only plug and a bilingual plug. And they look like this. There's really going to be three cable assemblies. As far as Apple's concerned, there really should be two, but, you know, we're stuck. There's the one that goes between the bilingual connector, a FireWire 800 port, and the four-pin connector on a camcorder. There's the one between the bilingual plug and the C-corder. a six circuit connector used in everything that was done right.

I shouldn't say it too much. It might be somebody from Sony here. And the beta mode connector is used for all other connections, anytime you want to run the higher speed. So what do we get? We also get this longer distance, and the goal was to get 100 meter. That's big enough even for my house. Just kidding. This is input from the Visa Home Network Committee, which must have gotten its input from Bill Gates. Unfortunately, the longer distance needs new media. We can't run the nice little shielded twisted pair for 100 meters. It doesn't work.

So we support category 5 wiring, standard Ethernet wiring. That can run at S100. Currently, we're working on a specification so we can handle that up to S800. Optical fiber for 200 megabits a second. In Japan, they have a form of it that runs at 400 megabits a second. And also multi-mode glass fiber for up to 3.2 gigabit a second.

So here's a little media summary thing that you can check out at your leisure. Basically, it's got all the cool stuff. Now I'm going to talk real briefly about something called the FireWire Design Guide. The FireWire Design Guide is something that started out as an internal project, but we're carrying it outside to the rest of the world, basically. And what it is, is a single reference source for all designers of FireWire-based systems. Not just computers, but everything.

It's got guidance to get you all the way through all those 1394 standards, because FireWire stuff is more than just IEEE 1394. There's a gazillion things that you have to know to do it. And it's a compilation of experience of Apple engineers, along with a lot of other people. A lot of application notes from various vendors, and presentations and whatnot from the 1394 developer conferences.

The whole thing's going to be web-linked where possible. And it's actually going to be presented as a website, which will be updated whenever I get around to it. Hopefully fairly quickly. The document itself will be available. The first version of it will be published at the Trade Association's meeting in Oxford this July.

These are now going to be what our recommendations are. It's a real brief summary of what's in there. We recommend using the 6- or the 9-pin connector if at all possible. The 4-pin connector is not really desirable for various reasons. It's not particularly rugged. People don't like it because you can never figure out how to plug it in. And besides, you can't carry power on this stupid thing.

The socket has to reverse backwards insertions. That means you can't plug it in backwards with anything more than about 220 newtons or something like that. This is something that we have run across. This is one of the reasons you don't want to buy the cheapest possible cables, because the cheapest possible cables, the mechanical tolerances are not wonderful. And the result is, it is possible to plug some of those suckers in with some force backwards, and bad things happen.

One of the things to help people not do that is we are encouraging everybody to have a plug-over mold, that's the part of the connector that's the plastic part you grip, that has keying on it that's tactile. Where you put your thumb is supposed to be flat, where your fingers curl around is supposed to be curved. In the case of the 9-pin connector, it's actually part of the 13-for-B specification. If you ever see a cable that doesn't have the nice little round on the side where you do that, it's a non-compliant cable. It doesn't meet the standard.

In the case of the legacy 13-for-B, we missed that, but this is the recommendation that's included. The connector orientation is the other half of that, which is people now know how to hold the cable. We need to make sure that the natural state of the plug is such that people will tend to do the right thing.

That means the thumb is on the top. When you plug it into something, don't make people do this, because they'll do this, and then you have a problem. Make sure that you do this. Now, the world is right-handed. I'm sorry. That means that the thumb, from my point of view, here we go, from your point of view, is going to be on your left.

We tried both ways. You know, we checked out people, which one they want to do. And most people want to do it this way, with their thumb on the left. So that's the orientation. It is particularly true when you try to plug in blind on something on the backside. Go like this. Try to do, you know, when you go around and you go like this, it's kind of awkward. So people tend to do this. So when you look at it, you end up doing the same thing, like there.

Um, the connector placement. Now we're getting to physical design. You have to tie these things as close together as possible. The electrical constraints of especially a FireWire 800 are really difficult. The rise time of the signal is only half a nanosecond. That's a one gigahertz signal. It turns out even FireWire 400 had that, and people built very fast PHYs, and the result was the rise time was very quick.

Um, if you want to have both front and back panel connectors, it is best to use two PHYs. You don't have to. If you're real, real careful and you have a big budget like Apple, it's possible to design the system so that you can have a connector far away from the PHY. But I warn you, it's hard. Save yourself a lot of design effort. Put us another PHY out there. A PHY is cheaper than a design effort unless you build a couple million of them.

XSERVs do this, by the way. If you use PHY ICs, make sure you use up-to-date parts. The technology is moving around real fast. And even on legacy PHYs, the new PHYs that have just come out in the last year or so are in much lower power, so you should consider using them. Power, yes, you should use power. You should be real familiar with the 34 Trade Association specifications for this. They're available.

The major system controllers, basically CPUs and television sets, some people say set-top boxes, but you know, should be power producers. It's really embarrassing to have your iPod and go up to your digital television set and the battery drains. You know, it's important. All Macs are power producers at least 7 watts. At least 7 watts. Okay, count on it.

All peripheral devices using 5 watts or less should be bus-powered. Consumers hate wall warts. Don't make them use them. They hate them. Unless you're plugging into a Windows PC, that's right. Be aware of the voltage and power limits. It can be 33 volts out there on the cable. Be aware of that.

Macs use anything from a low of about 9 volts, that's right, to a high of about 28 volts. So if you're going to plug into a Mac, you have to tolerate that kind of a range. The power providers have to limit the current outrush because, gee, there could be a short out there and, you know, people don't like flaming cables or smoking systems. So you can use that with various ways. Prefer a resettable fuse. There's some brand-new semiconductor devices that are very fast current limits. and they don't cost too much, and you should consider them as well.

Let's see. Isolation. Only needed for exceptional environments, but all you guys are exceptional, so I don't know. But really, it's needed for long cables. So if you're building anything that's a network or a performance system or something like that, you should consider isolation. If you're going to use isolation, use 1394b beta mode for that. You can do it doing the legacy 1394, but it's a pain. Once again, it's one of those really awful design efforts that you'd save yourself a lot of time. Just use the file you can buy off the shelf and build a beta connection.

Shielding. This is complicated because there's two types of shield in their system. There's the outer shield that's the one that you use to protect yourself from the various radiation modes. That should be AC-isolated from the ground, the power ground, the phi ground inside the system. It should be AC-isolated. That's because you've got a lot of noise in the outside world and you want that slipping into your system on the outside.

Similarly, you don't want the digital ground and all that mess, you know, that gigawatts of power in there getting out onto your shield. So those should be isolated. This is a pain in the butt for the four-pin connector, one of the primary reasons Apple hates it, because the shielding is awful. It's very hard to do. The cable shield, on the other hand, should be DC-connected to that same pair. The reason you want to be DC-connected is this is the backup connection for ground.

In case you have a dirty connector, you know, the ground pin is wrong or something, or you're using one of those cheap connectors that doesn't do it right, you want to make sure you get a good ground connection. If you don't, you can hear or see power going out and the only return path for that power coming back is on the twisted pair, the data pair, and you blow up your phi. It's bad. Don't do that.

So make sure you do that. Typically only one place in the system at the power supply or in a portable system like an iPod. There's something called a virtual ground where you connect everything together. This can be done through a ferrite if you don't want noise getting out, and that's typically what we do. What about protection from all that shocks and whatnot? You have to protect that.

Unfortunately, we can't give you a general guideline because it's very phi-dependent. Fortunately, all the phi vendors give very good app notes on what the right thing to do is. What about filters? There's various modes of filtering. The best thing we can suggest to you is if you can, don't.

Use really good design practices and don't put external components through there. They mess up the system, the signal quality of the system. If you have to, there's various ways you can do that. It's talked about here and some of the application notes I'll talk later. Layout rules for the data lines. These are the 800 megabit a second lines. No 90 degree corners. This is going to drive all the layout guys nuts. No 90 degree corners. No vias on the twisted pair. This will really drive your guys nuts.

So, that's the first thing. Next slide. Next slide. Equal distances for the signals in the pair, keep the pairs the same, minimize the distance between the connector and the PHY. Put the termination as near as the PHY as possible. One of the things that's going to happen when I publish, I'll give you an example layout of how to do all this the way I say. And then you can adapt it to your purposes.

Higher layers. You'll have to wait for a later edition, sorry. Testing. Prashant, have you already talked about this? Okay. So, anyway, the Trade Association does compliance testing. We highly encourage you to go through that procedure. If you came here, it was free. Oh, well. Yeah. If you want that real FireWire market that's going to say FireWire 1394 compliant, you have to go through this procedure.

Here's a set of references that you can get in your final thing. I particularly recommend this first one, which is EMI Board Design and Layout Considerations from TI, and the final one, which is the gear, how to build with the FireWire 322, 323. Even if you don't use those particular parts, they're really, really well written.

There will be a FireWire 800 version of the TI Design Guide, which will be really neat when it's finally finished. I'm reviewing it now. So, at this point, I'd like to pass it over to Eric, who will tell you the two slides that are necessary to do FireWire 800. Okay, thanks, Mike.

As I said, this won't take long because pretty much everything in FireWire 800 is in the hardware. We support FireWire 800 on these products that have the ports in Mac OS X, version 10.2.4, and later. These are the same products I showed earlier, all of our products that have FireWire 800. So if you make a FireWire 800 product, your customers don't need to download any new drivers from us.

It's already in there in the Mac that they bought. Now, let's look inside a Mac. Mike talked about the capability to have multiple speeds on a single PHY, and we do that in our current products, like the new G5 Tower. It's really important to understand how that works, because it's fairly easy to get it wrong.

In the Mac, at the very bottom of the software, or below the software stack, there's two pieces of silicon that make up the FireWire interface. The link is the layer that does DMA and knows what packets are. The PHY is the layer that actually drives signals on the bus. And with FireWire 800, the PHY can have different ports with different capabilities. The figure here shows one PHY that has two ports, each connected to nine-pin connectors for FireWire 800, and one port that's connected to a six-pin connector for FireWire 400.

It is essential that the PHY knows that it has a six-pin connector out there. Why is that? There's a cable that has a 9-pin connector at one end and a 6-pin connector at the other end. Suppose we connect that cable at the 9-pin end to a FireWire 800 device, and at the 6-pin end, we plug it into that 400 port up there.

Well, the PHYs at both ends of that cable are FireWire 800 PHYs. If they don't know any better, they'll try to establish a FireWire 800 connection, but they only have 6 pins to work with, so it's not going to work. There's no fallback. It doesn't say, this doesn't look so good, let's try 400.

It's not going to fall back to a reliable 400 connection. Instead, it's going to stick with an unreliable 800 connection. That would be really bad. Now, this problem is really easy to avoid. Just read the design notes for the PHY. Each port on the PHY has a pin that tells it what kind of connector is on there. All you have to do is tie it to ground or tie it to high.

The PHY will know what to do. But one developer already got this wrong on one product. We let them know, and they're fixing it. So if you're going to mix ports on your product, please be sure to do this right, otherwise the customer will have a bad experience.

Okay, here's the software stack from Mac OS X FireWire. There's much more detail about this in the other session, FireWire In-Depth. Let me briefly explain the layers here and how they relate to FireWire 800. Down there at the bottom, you see the two parts from the previous slide, the OHCI layer and the PHY. When those are detected, I/O Kit loads the higher layers into the kernel. FireWire's all in the kernel because it's a bootable service. We can take a page fault from a FireWire device. At the bottom, you see the controller. That's our device driver for OHCI.

In the middle, you see the family. That's the sharing layer. It lets different applications, devices, drivers, all peacefully cooperate on one FireWire bus without stepping on each other's toes. Above that, we have protocols. This is where devices begin to differentiate. A device could be SBP2, like an iPod or a printer or a camera. It could be DV, like a camcorder or a television or the set-top box Mike mentioned. We provide a variety of common protocols there in the kernel.

We also provide what's called user clients, or officially device interfaces, so that you can access all of these services from applications, either by writing an application or by writing a plug-in that executes in the context of an application. If you do that, the development, and especially debugging, is a whole lot easier. We've done everything we can to facilitate your doing that.

Now, what about FireWire 800? I didn't say anything there. Hardly anything has changed. There's a new speed code to indicate the 800 speed. The number's three, in case you need to know. There is new topology analysis. Because there can be PHYs out there with a mixture of speed capabilities, we have to go figure that out. In FireWire 400, every PHY had one speed. It was either 400 or 200 or 100. But some of our products have this mix, and some of yours might, too. So FireWire family knows how to figure that out.

Hardly anything else has changed. The SPP2 layer knows how to use Speed 3, but most drivers don't have to be changed at all. What might you have to do? If you're making hardware, of course you have to go get new silicon, a new link, and a new PHY that can do FireWire 800.

Like Mike described, please use the correct 9-pin socket. Today, the only silicon you can get supports fully bilingual operation. So unless you have some reason to lock that out, use the bilingual connector so your product can be connected to as many other products as possible. And as I said, configure the ports correctly if you do have a 6-pin or, for some reason, a 4-pin connector on that PHY.

As far as software goes, you probably don't have to do anything. Mac OS X performs a speed analysis on the bus, figures out the fastest path between your device and the Mac and every other device, and will automatically send your packets at the best speed that they can make it to your device.

You might need to know the speed for certain kinds of devices, such as an isochronous device. The IIDC, or so-called DCAM type of camera, for example, has a register in it where software tells it what speed it should send video at. If that's going to be 800, software will need to know to put a 3 in that register. So that's one case where you might need to know the speed.

Our Macintosh systems with FireWire 800 ports support FireWire 800 in the boot ROM, also known as Open Firmware. These products can all boot from FireWire 800 hard drives. They can boot through 400 hubs or other devices if you have an 800 hard drive at some remote location on the bus. And they all support target disk mode at the FireWire 800 speed as well.

What else is new? The other session went into some detail about some of these topics. We support the Internet Protocol on FireWire now, and we've made it a good deal faster in Mac OS X. We support SBP3, the Fast Start Speed-Up, which will improve disk performance for some kinds of I/O.

The other session has a great deal of information about how isochronous transfer works, so please check out those slides if you're interested in that. We've also improved what you can do with DCLs by adding error status and variable length capabilities. We've added a bunch of new features for AVC, especially allowing the Mac to be a target.

We were really good at telling other devices what to do. The camcorder should play, the TV should go to channel 12. Now we can let them tell us what to do. There are certain receivers or set-top boxes that may work. They may offer some great new capabilities if you write software to listen to them and let them tell the Mac what they're doing.

Now let's review some of the resources that we have to help you develop for FireWire 800. We publish software development kits. These are available for free download on the web. This is probably our biggest product as a software team, so please give us feedback if these aren't meeting your needs.

They have lots and lots of sample code, especially for developing in application space using the user clients. There's documentation, there's tools, there's pre-release components sometimes. If we have new versions of the FireWire software, you can try them out. Check out bug fixes before your customers see them. It's available on the web at the location listed there.

Apple now has an offering called the FireWire Reference Platform. This is completely different. It's a fully independent software stack. It's not related to Mac OS X. This is designed for embedded FireWire software or firmware development. If you're making a set-top box, a TV, some multi-function device, you can get a big head start using the FireWire Reference Platform. It has code especially for AVC command sets, SBP2, other protocols. You can save a lot of time by starting here. There's a whole session on this topic tomorrow afternoon. It's track 508.

We hold events for FireWire developers. We hold plug fests. As Mike mentioned, there is a TA-approved plug fest happening right now. We had 40 devices submitted by WWDC attendees. They're being tested now, and they can receive the FireWire compliance logo if they pass this testing. We hold these at Macworld and at WWDC.

We hold developer kitchens where we bring the FireWire software engineers. We get together with developers for hands-on debugging tutorials. Often we introduce a new SDK. A number of the engineers are here today in the front row. If you have questions after the session, they'll be happy to talk to you. If you'd like to attend one of these kitchens, please contact Developer Relations.

We simply hold them on demand when you're ready, either in Cupertino or in Tokyo. We've had about 10 of these to date. They're a lot of fun, so please let us know if you'd like to attend one. We also participate in the official 1394 TA interoperability workshops. These are a bit more formal than what we do at our own plug fests. There's the logo Mike mentioned earlier. There's three kinds of testing at this event.

You get really rigorous testing of your device. We always go because we learn a lot about our own devices as well as about developer devices. These are open to non-members. They're really valuable and I highly recommend that you participate. The 1394 TA promotes 1394. It organizes trade show events. It also publishes all of the AVC command set standards and a number of other standards that you may need to create drivers or devices on FireWire.

Now let's look at some FireWire tools. We have new tools to offer for you this year that will help you to develop for FireWire 800 and to develop for Mac OS X. Mike and I both talked about the PHY. What exactly does this chip do? There's a tool for it, so this is why I'm explaining it.

PHY stands for Physical Layer. It's the bottom of the interface. The PHY chip drives differential voltages on the cable to make ones and zeros on the bus, and then it receives the same signals and turns them back into packets that we can understand. If you have multiple ports, the PHY acts as a repeater.

The PHY also contains all of the arbitration. It's all done autonomously without software drivers, so it goes very fast. This means a hub can participate even though it doesn't have a link layer or a controller. In comparison, the link is a higher-level function. It knows how to form packets, compute checksums, it knows what isochronous cycle time is, and the link is where the DMA is located.

The PHY is not programmable, but it does have a small register file. Each register is 8 bits wide. Here's the map as shown from the 1394A spec. There's a lot of interesting things in here, like Mike talked about. Let's go to the 1394B PHY. You can see it added a few more bits. If there was a loop detected on the bus that had to be broken, there will be a bit set in the corresponding PHY telling you where this happened.

So we have a tool now that will let you look at what's in the FI register. You may not need to do this. This isn't something customers would do. But many interesting things that happen on the bus may be explained by examining the FI registers to find out why it's doing that particular interesting thing.

This tool is called FiTool. It's a real-time Fi Register viewer and editor. It has integrated documentation. If you find a bit in the Fi you don't remember quite what it does, just move the mouse over that bit, the documentation will appear right from the spec. You can look at the Fi in your own Mac to see what it's doing, or you can reach out across the FireWire bus and look at the Fi in another device if it's 1394a or 1394b and find out what it's doing. And this tool needs no special hardware. It runs on all the products that we sell today, anything with an open HCI interface. So let's take a demo of this. Let's move to the demo system.

Here's FiTool. What you can see in the main portion of the display is the Fi register map, just like on the slides. But now, the fields are pop-up menus and check boxes that actually do things to the Fi. And you can see the integrated documentation. As I move the mouse over the various fields, the documentation for that field appears right down at the bottom of the screen.

Right now, this particular machine is an older G4 tower that only has FireWire 400, so you can see some of the fields are reserved, and it's showing information from the spec for the 1394A. If you want to see the 1394B spec, because some of these things have changed, you can just pick that, and now you get a little new information, like the fact that this field no longer has any meaning in 1394B.

FiTool knows about all the registers in the spec. Although it doesn't show anything for the rest of them, there are type-in fields over here, so if you want to change a value in some vendor-unique register, you can still do that. Also, if you don't like binary numbering, you can change that to something a little more sensible.

On the left column over here, there's a real-time summary of each of the ports on this PHY. There's also a summary of what kind of PHY this is. We can see this PHY is made by Lucent. It has three ports. It's capable of S100 through S400. This is what the three ports are doing. Right now, none of them is plugged into anything. I'm going to connect my iPod to one of the ports, and it immediately shows up on port 1. We saw it flicker a little as the port was negotiated.

Port 1, the iPod is now switching from MP3 mode into FireWire Disk mode, and it causes a couple bus resets when that happens. So you saw the port change several times. But now it has settled down to an S400 connection. Connect and Bias are a summary of these bits over here.

But these are showing zero. Why is that? The bottom eight registers are paged. There's a page select... They're paged for different groups of information, and there's also a port select register to see each port. So if I ask to see port 1, now these registers correspond to port 1, and you can see connect is 1, bias is 1, child is 1, and the speed is 400. It all agrees with what's over here in the summary. We can go right in and make changes. I can click on the disable bit. Now that port is disabled. The iPod has been unplugged.

And now it's back. We can cause a bus reset. That bit is self-clearing, so the checkbox didn't stay on. We can also cause a better short bus reset down here. So you can change a lot of things in the PHY. You can't break anything with this tool. You can't damage anything, but you could get the Mac confused. So if you're changing things and you don't really know what they are, you may want to power down and unplug everything to get back to normal operation. Now, I'm going to unplug the iPod and plug the cable into this other Mac that has 1394B.

Because the tower here is an older system, we've established only a 400 connection. But now, let me show you how we can view the PHY in another device. The top pop-up menu lets you pick which FireWire interface to use. This Mac has only one built-in, so it's shown here.

This pop-up lets you choose which node you want to look at, and it knows how many nodes are on the bus at any given time. Which one is that other Mac? Well, we are node 0, that's what's in register 0, so the other guy must be node 1. We'll pick node 1. All these new registers have appeared because node 1 is a 1394B node. And we can see the general information. That PHY was made by TI. It also has three ports.

It's bilingual and it works up to S800. Right now, the port that I plugged into on that PHY is port 2. It shows that it's connected at S400. And all the new registers have appeared. So if I move this over to port 2, now we see the details of that port on the other device.

So you can learn a whole lot about what's going on. Here's the loop disable bit down here that Mike mentioned earlier. If this port was disabled in order to break a loop, you'd find a 1 in here. One thing you can't do, though, you can't change remote PHY registers.

I can click on, I can try to turn on disable on this port, nothing happens. And down at the bottom, it's explaining to me that that's a non-local PHY. 1394 doesn't provide any way to reach out and change the other PHYs. That was considered just a little too dangerous. All we can do is look and see what's going on.

So this tool runs on any hardware, just uses the OpenHCI interface. Even if you don't have a PHY problem to diagnose, I think you'll find it very interesting to try this out and poke around and see what's happening on your bus. Okay, let's go back to the slides.

We have another new tool to offer you called FireStarter. This tool was designed for use at plug fests. The commercial bus analyzers can draw a picture of the bus, but when you have 63 nodes on there, which is what we try to achieve at a plug fest, they can take an awful long time to do that. By the time they've got the nodes displayed, something's probably changed. FireStarter can draw a simple but accurate rendering of the bus topology, and it can do it 10 times per second, so you'll know exactly what the bus is doing at any moment.

FireStarter also provides some summary information about how many nodes are on the bus, what kind of nodes they are, and how long the bus has been stable. Here you can see on the right-hand side the topology of a bus with six nodes, and on the left-hand side various summary information about the bus. Here's what it looks like with 63 nodes. This is from one of our plug fests. You can see we had 4,650 bus resets until we got to 63 nodes, but the bus was then stable for more than a minute before anything went wrong.

We have another new tool called FireWire Busy Bus. If you want to make something go wrong, this may be the tool for you. This tool can generate traffic on the bus. It can generate any asynchronous packet. It can also generate bus resets, even generates bus reset storms. And it can enable and disable the ports, just like I did in FiTool, automatically to simulate hot plugging. So you can leave this tool running for extended periods and see if your device survives.

There's a rate adjuster. You can make it ramp up and down from total quiet to very intense testing. And you can select all the packet speeds, all the packet types. Like the other two, this tool works on OpenHCI. Now, be careful. This tool generates random packets. The default configuration is fairly safe. But if you change the settings, you can generate random packets that write random data into random addresses in the Mac's memory. And we might crash if you do that. So, be careful.

Here's a full screenshot of FFW Busy Bus. At the top, you can see the sliders for adjusting the rate. The center has all the check boxes for turning the individual tests on and off. The bottom has the very important start button and displays what the test is doing and some summary information about the bus. And on the left, we have the same information from FiTool, a summary of your Fi and a real-time status of all the ports on the local Fi.

Now, there's one more tool that you may need for developing FireWire on Mac OS X, and that's Firebug. And we're finally pleased to provide Firebug on Mac OS X. It is a real-time packet snooper. Now, this requires special hardware. OHCI doesn't have a snoop function, so just like on Mac OS 9, you need special hardware, but FireBug can show you every packet on the bus in real-time. It can decode the protocols like SPP2 and AVC, so you can actually see what's going on.

It even has bus configuration services, so that you can set who's the route, change the gap count, and so on. Now, at the same time we brought it to 10, we made some improvements. FireBug can decode more AVC commands. It tells you more information about SPP commands. For example, it can decode the RBC command set, common disk operations like read, write, synchronize cache.

SPP2 also survives a bus reset in almost every case now, whereas before it hardly ever figured out what was going on after a bus reset. There's a PHY register dump function. You can see it in the screenshot there. It's like PHY tool, so you don't have to use two Macs at once.

You can get the PHY registers dumped out in text right in Firebug's log. Other new features include node ID filtering, so you can view packets only going to, coming from, or going between whatever nodes you select. You can get an isochronous summary. By default, Firebug doesn't show isochronous packets because it would overwhelm the display. There's 8,000 of them per second.

Even if you have that suppressed, Firebug will tell you that isochronous traffic has started. It'll tell you what channel it's on, what speed it's going at, what node it's coming from, how big the packets are. It can even recognize DV and tell you whether it's NTSC or PAL format.

So that may be very handy in keeping track of what's happening on your bus. And Firebug running on Mac OS X supports dual processors. We use one processor to snoop all the packets, the other processor to keep the display up to date. Purists may scoff at this partitioning of work, but it works just fine for Firebug. Yes.

All of those tools are available today in FireWire SDK 17. It is live on the web, but it is an orphan link. There's no page you can go to that actually links to it. They updated the whole developer website on Monday. They're still filling in all the details, but you can get it today. Go find FireWire SDK 16, get that URL for the download, change the 6 to a 7, and you're all set. I tried it this morning. It's really there.

If you, and within a few days, the page will actually know how to find it. Here's where you can go to get the FireWire standards and specifications, the IEEE for FireWire itself, the Trade Association for AVC command sets, the IIDC camera, which the iSight, by the way, uses that standard, and the ISO. If you want to know the format for DV or other really detailed stuff about DV camcorders, many of those standards come from the ISO.

Oh, here's the-- OK, we've got the slides out of order. Here's the summary of all the new tools I showed. They all require OHCI, except Firebug, which still needs PCI links. They all require Mac OS X, version 10.2.5 or later. Every one of them, when they run, will displace the existing FireWire software.

This is so the tool won't interfere with Mac OS X and vice versa. So this is just like Firebug on 9. You really should have a dedicated machine running the tool. The tool will refuse to launch if it would cause you to unmount hard drives or anything else that might be bad.

And please be careful. These tools touch the hardware directly in order to do their thing. This means they could crash the machine. We've done everything we can to make them solid, but they're new. I'm sure one of you is going to find a way to crash the machine. So run this on a separate machine, or at least make backups. Don't try to surf the web and do your email at the same time this tool is running. Now there's the slide explaining that they're available today, and you have to change the link.

Okay, let's wrap up. Here's all the sessions this week at WWDC for FireWire. FireWire In-Depth was yesterday. FireWire Feedback Forum, together with USB Feedback Forum, is later this afternoon. Tomorrow, we have the session on the Reference Platform that I mentioned earlier. And tomorrow, during the Campus Bash, we have the FireWire USB and Bluetooth Plug and Unplug Fest.

If you want to talk to Apple, if you'd like to come to a FireWire kitchen, or if you need to know who to work with, Prashant Kanheri, who will be up here in a moment, Guillermo Ortiz are both available in Developer Relations. We also have mailing lists for FireWire developers. These are fairly active. You can subscribe. Anyone can join at the URL listed here.

Developers can post questions, developers can answer each other's questions, which is great, or we will answer questions if we have to. We also announced information about new tools, new SDKs, other announcements on this mailing list. There's one for FireWire in general, and there's one for the FireWire reference platform.

I was told yesterday that some of these links may be out of date, possibly because they revamped the ADC web page yesterday. So we'll post an update on the mailing list later if these aren't quite right. There's a document called "Working with FireWire Device Interfaces." This shows how to use the user clients to access FireWire from user space, which is, if you can, where you want to be writing your software. This FireWire SDK 17, as I just described, is available for free public download on the web, and it has additional reference information in it.