VersaPHY Products

VersaPHY Overview

For a VersaPHY technology brochure  please  select here.

What is VersaPHY

VersaPHY 1394 Extensions are backward-compatible extensions to the IEEE-1394 PHY layer. In fact, VersaPHY is so compatible it can be implemented with existing PHY silicon and external logic.

VersaPHY technology is specified in an approved 1394 Trade Association specification, "VersaPHY Additions to IEEE-1394". Please contact the 1394 Trade Association for details (www.1394ta.com).

Why VersaPHY

VersaPHY 1394 Extensions enable a new class of lower-cost 1394 devices. New VersaPHY packets, addressing, and registers eliminate requirements for extensive link logic and microprocessor control for simple peripheral devices.

VersaPHY 1394 devices operate compatibly with existing full-featured 1394 devices. Together, these protocols provide cost-effective solutions for a wide range of applications. Most importantly, all these devices, from simple VersaPHY sensors to 1394 HD camcorders, can leverage a single network infrastructure.

VersaPHY DEVICE BLOCK DIAGRAM

What's new with VersaPHY

VersaPHY implements three new feature sets:

•  VersaPHY labels
•  VersaPHY registers
•  VersaPHY packets

The new features can be implemented using existing PHY silicon, external logic, and VersaPHY aware software on a controller.

VersaPHY Labels

Perhaps the most important new feature of the VersaPHY is static labels (VP-label). VersaPHY enables semi-permanent and permanent device/function addressing that enables simple, and in some cases eliminates, device discovery.

The VersaPHY definition makes available 16K labels (14-bits). In the simplest case, labels can be used as addressable names for nodes. In more complex implementations, labels can be used as addressable names for sub-functions (profiles) within nodes. Nodes are still addressable using node-ids, but many implementations may exclusively use VP-label addressing.

VersaPHY Registers

VersaPHY defines a register set that may be read and written remotely using VersaPHY packets. These registers are addressed with existing node-ids or the new VP-labels. A minimal set of registers are defined by the VersaPHY specification; the rest are to be determined by implementation-specific profiles. This allows simple to complex implementations to utilize VersaPHY technology. Node-id addressing allows up to 4K (12 bits) byte-wide registers. VP-label addressing allows each profile up to 1M (20 bits) byte-wide registers.

VersaPHY Packets

One of the fundamental enhancements for the VersaPHY is the addition of writable PHY registers. This allows PHY-only devices to communicate in a way only transaction-capable nodes could previously. There are two sets of new PHY packets defined for VersaPHY: one using node-id addressing and another using VP-labels. Each set contains read request, read response, write request, and write response packets, for a total of eight new packet formats. The new packets are all fixed 2 quadlet packets, like the existing IEEE-1394 defined PHY packets.

VersaPHY Use Model

Fundamentally, the VersaPHY interaction model consists of a Controller and one or more VersaPHY devices (VP-device). A Controller node may be any existing 1394 node with software to send and receive VersaPHY packets. The VP-device will contain the VersaPHY register set and profile-specific logic to manage those local registers. In some cases, multiple Controllers may exist and may even control the same VersaPHY device. How that is accomplished is implementation dependent.

Polling

The VersaPHY architecture supports polling of the VP-device by a Controller. Using the polling model the Controller simply reads VP-device registers, using node-ids or VersaPHY labels (VP-label), to get information from the VP-device. This model has the advantages of being simpler, and providing an acknowledgement for each read. However, it requires more Controller CPU cycles than other models, and loading of the Controller may affect how often each VP-device is polled.

Response

The VersaPHY architecture supports a VP-device initiated, unsolicited response mechanism. Using this model, the Controller configures the VP-device to autonomously send either write or read response PHY packets to the Controller. The response packets contain the VP-label of the VP-device sending the response. This allows the Controller to simply listen to the bus and collect data from all VP-devices, without expending any extra cycles. This approach also places the timing of when the data is sent in the VP-device that is generating the data. Therefore, no unnecessary bus traffic is created.

Streaming

The VersaPHY architecture also supports isochronous and asynchronous (non-transaction) streaming. To use streams, all IEEE-1394 rules regarding resource allocation, packet format, and verification must be followed. However, by using the VersaPHY architecture, the VP-device requirements are limited to packet format, CRC generation/verification, and cycle timer support. This permits very simple stream-consumer and stream-producer implementations. Typically, the Controller handles all resource reservations and then configures the streaming VP-device accordingly.

VersaPHY Advantage: Practical Examples

Reduced Cable and Connector Costs

1394 is being considered in a variety of applications where installation, maintenance support, cost, and even weight of cable wiring are a concern. Many times in these applications, the 1394 bus is adjacent to a device that could be controlled, monitored, and even powered via 1394. Often implementers elect to not use 1394 because of the complexity and expense of implementing a transaction-capable node. The VersaPHY architecture eliminates these obstacles and allows the implementer to take advantage of reduced cable and connector costs, reduced weight, and easier wire harness installation and support.

VersaPHY Streaming

Streaming as defined by 1394 is not a transaction; it is a datagram. Using this model the link layer connects directly to the application. The VersaPHY architecture takes advantage of this fact by removing the asynchronous transaction requirements from the streaming device and replacing them with a simpler set of VersaPHY requirements. This allows simple streaming devices such as digital cameras, speakers, microphones, etc. to be implemented with lighter hardware and no 1394 specific software by eliminating the link controller, microprocessor, and 1394 transaction software.