PDI1394L41 Datasheet, PDF (12/81 Pages) NXP Semiconductors – 1394 content protection AV link layer controller

Philips Semiconductors
1394 content protection AV link layer controller
Preliminary specification
PDI1394L41
12.0 FUNCTIONAL DESCRIPTION
12.1 Overview
The PDI1394L41 is an IEEE1394–1995 and IEEE1394.a compliant link layer controller. It provides a direct interface between a 1394 bus and
various MPEG–2 and DVC codecs. The AV Link maps and unmaps AV data streams and similar data onto 1394 isochronous packets. Data can
be ciphered or deciphered according to the ‘5C’ standard method of content protection. The AV Link also provides an 8 bit or 16 bit wide host
interface for an attached microcontroller. Through the host interface port, the host controller can configure the AV layer for transmission or
reception of AV datastreams. The host interface port also allows the host controller to transmit and receive 1394 asynchronous data packets.
12.2 AV interface and AV layer
The AV interface and AV layer format “application packets” according to the IEC 61883 specification for isochronous transport over the 1394
network. The AV transmitter and receiver within the AV layer perform all the functions required to pack and unpack AV packet data for transfer
over a 1394 network. Once the AV layer is properly configured for operation, no further host controller service should be required. The operation
of the AV layer is full-duplex, i.e., the AV layer can receive and transmit AV packets on the same bus cycle.
12.2.1 IEC 61883 International Standard
The PDI1394L41 is specifically designed to support the IEC61883 International Standard of Digital Interface for Consumer Electronic
Audio/Video Equipment. The IEC specification defines a scheme for mapping various types of AV datastreams onto 1394 isochronous data
packets. The standard also defines a software protocol for managing isochronous connections in a 1394 bus called Connection Management
Protocol (CMP). It also provides a framework for transfer of functional commands, called Function Control Protocol (FCP).
12.2.2 CIP Headers
A feature of the IEC61883 International Standard is the definition of Common Isochronous Packet (CIP) headers. These CIP headers contain
information about the source and type of datastream mapped onto the isochronous packets.
The AV Layer supports the use of CIP headers. CIP headers are added to transmitted isochronous data packets at the AV data source. When
receiving isochronous data packets, the AV layer automatically analyzes their CIP headers. The analysis of the CIP headers determines the
method the AV layer uses to unpack the AV data from the isochronous data packets.
The information contained in the CIP headers is accessible via registers in the host interface.
(See IEC61883 International Standard of Digital Interface for Consumer Electronic Audio/Video Equipment for more details on CIP headers).
12.2.3 The AV Interface
The AV link’s 8-bit parallel interface is synchronous with AVxCLK, and was designed to interface with various MPEG-2 and DVC codecs. The
AV interface port buffer, if so programmed, can time stamp incoming AV packets. The AV packet data is stored in the embedded memory buffer,
along with its time stamp information. After the AV packet has been written into the AV layer, the AV layer creates an isochronous bus packet
with the appropriate CIP header. The bus packet along with the CIP header is transferred over the appropriate isochronous channel/packet.
The size and configuration of isochronous data packet payload transmitted is determined by the AV layer’s configuration registers accessible
through the host interface.
The AV interface port waits for the assertion for AVxVALID and AVxSYNC. AVxSYNC is aligned with the rising edge of AVxCLK and the first
byte of data on AVxDATA[7:0]. The duration of AVxSYNC is one AVxCLK cycle. AVxSYNC signals the AV layer that the transfer of an AV packet
has begun. At the time the AVxSYNC is asserted, the AV layer creates a new time stamp in the buffer memory. (This only happens if so
configured. The DVC format does not require these time stamps). The time stamp is then transmitted as part of the source packet header. This
allows the AV receiver to provide the AV packet for output at the appropriate time. Only one AVSYNC pulse is allowed per application packet; if
additional sync pulses are presented before the full packet is inputted, a new packet will be started and the previously inputted packet data will
be discarded (and not transmitted) in conjunction with the input error interrupt bit (INPERR, bit 3 of register 0x02C) being set to flag the error.
An additional synchronization mechanism is defined by the IEC 61883 specification, called frame sync. The frame synchronization signal
AVxFSYNC is time stamped and placed in the SYT field of the CIP header. The default delay value for the frame sync is 3 bus cycle times
(duration of 125 µs each) in the future, and is transmitted on the very next isochronous cycle regardless of available data. The PDI1394L41
allows this value to be programmable from 2 to 4 cycle times (see section 13.2.1). Additionally, for some audio applications, the SYT value can
be programmed to be appended only to isochronous cycles that have application data attached to them. This mode is enabled via the ‘mLAN’
bit (again, see section 13.2.1). When the mLAN mode is enabled, two additional cycle delays are automatically added to the SYT_DELAY value
(bits 6 and 5 of the ITXPKCLT register). On the receiver side, when the SYT stamp matches the cycle timer register, a pulse is generated on the
AVxFSYNC output. The timing for AVxFSYNC is independent of AVxCLK.
Some applications would like to create their own transmit timestamps independent of the AV Layer. On receive, these applications would like to
process the embedded time stamps instead of allowing the AV Layer to process these time stamps. This can be accommodated via the
ENXTMSTMP bit in the ITXPKCTL register for transmit and DIS_TSC bit in the IRXPKCTL register for receive. In conjunction with this mode,
additional means of flow control are enabled via the AVxREADY signal.
2000 Apr 15
9