AV/C Audio Video Control CHF CIP Header Field CIP Common Isochronous Packet CMP Connection Management Procedures CSR Command and Status Register CTS Command/Transaction Set CRC Cyclic Re
Cable physical layer
All physical layer implementations of cables must adhere to the performance standards set by IEEE 1394 This includes using either the cables and connectors specified in IEEE 1394:1995 or those defined in IEEE 1394a:2000.
An AV device must adhere to the IEEE 1394a:2000 standard, specifically section 8.2.1, when generating a bus reset It is recommended that the device initiates a short bus reset, as outlined in IEEE 1394a:2000, rather than the long bus reset defined in IEEE 1394:1995.
Link layer
All link layer implementations conforming to this standard shall meet the specifications of IEEE 1394.
Transaction layer
All transaction layer implementations conforming to this standard shall meet the specifications of IEEE 1394
A node shall conform to the following requirements
– A node shall be cycle master capable This is because every node has the possibility to be assigned as a root
− A node shall be isochronous resource manager capable, as specified by IEEE 1394:1995, and shall implement the additional isochronous resource manager facilities and responsibilities specified by IEEE 1394a:2000 in 8.3.1.5, 8.3.2.3.8, 8.3.2.3.11, 8.4.2.3 and 8.4.2.6A
− A node which transmits or receives isochronous packets shall have plug control registers (see 7.2).
Serial bus management
Bus manager capability is optional for AV devices, but, if implemented by devices conforming to this standard, shall conform to IEEE 1394.
Command and status registers
CSR core registers
This standard conforms to the CSR architecture Details of its registers are specified by IEEE 1394
The STATE_CLEAR.cmstr bit shall be implemented as specified by IEEE 1394a:2000, 8.3.2.2.1
The cmstr bit is automatically set by system software or hardware when a node becomes the new root after a bus reset, ensuring quick resumption of data transmission critical at the microsecond level This rapid activation of a new cycle master minimizes the risk of gaps in the transmission of cycle start packets, which is essential for delivering isochronous data within its latency requirements at nominal 125 µs intervals.
Serial bus node registers
Implementation requirements for bus-dependent registers in this standard conform to IEEE 1394 A node shall have the following registers:
A node should have the following register specified by IEEE 1394a:2000:
Configuration ROM requirements
A node must adhere to the general ROM format specified by IEEE 1212:2001 and IEEE 1394 Any additional information necessary for implementing this standard should be included in one of the unit directories An example of the configuration ROM implementation for this standard is illustrated in Figure 1.
04 16 crc_length rom_crc_value
Root_directory root_length CRC
03 16 module_vendor_id 0C 16 node_capabilities unit_directory offset D1 16
Unit_directory unit_directory_length CRC
Optional chip_id_hi chip_id_lo
Reserved max_rec cyc_clk_acc
Reserved irmc cm c is c bm c
Node_unique_id leaf chip_id_hi chip_id_lo node_vendor_id
Implementation requirements for the Bus_Info_Block in this standard shall conform to IEEE 1394
The following entries shall be present:
− Unit_Directory (offset to a unit directory defined by this standard)
Other entries may be implemented in addition to the above required entries
The following entries shall be present:
The value of the Unit_Spec_ID and the Unit_SW_Version for this standard are given as follows:
Unit_Spec_ID: First octet = 0016
Unit_SW_Version: First octet = 0116
The second and third octets of the Unit_SW_Version, as detailed in Table 1, specify the capabilities for command and transaction sets This field is essential for identifying the supported protocol of a device In cases where a device supports multiple protocols, it must maintain a separate unit directory for each one.
Table 1 – Unit_SW_Version code assignment
Unit_SW_Version Command/transaction set
01 00 02 16 Reserved for standardization by CAL
01 00 04 16 Reserved for standardization by EHS
01 40 01 16 Vendor unique Other values Reserved for future standardization
6 Real time data transmission protocol
Common isochronous packet (CIP) format
Isochronous packet structure
The isochronous packet structure defined by this standard is depicted in Figure 2 The initial two quadlets consist of the packet header and header CRC in an IEEE 1394 isochronous packet Following this, the CIP header is positioned at the start of the data field, succeeded by zero or more data blocks.
CIP header and real time data
Header_CRC Data_length Channel Tcode Sy
Zero or more data blocks
Packet header structure
The packet header consists of the following items as specified in IEEE 1394
Data_length: specifies the length of the data field of the isochronous packet in bytes, which is determined as follows:
CIP header size + signal data size
Tag: provides a high level label for the format of data carried by the isochronous packet
01 2 = CIP header included as specified in 6.1.3
112 = Reserved Channel: specifies the isochronous channel number for the packet
Tcode: specifies the packet format and the type of transaction that shall be performed
(fixed at 1010 2 ) Sy: application-specific control field
CIP header structure
The CIP header, located at the start of the data field in an IEEE 1394 isochronous packet, provides essential information about the type of real-time data that follows The structure of the CIP header is illustrated in Figure 3.
The definitions of the fields are given as follows:
EOH_n (End of CIP header): means the last quadlet of a CIP header
1 = The last quadlet of a CIP header
Form_n: in combination with EOH, shows the additional structure of
CHF_n (CIP header field): CIP header field of n th quadlet The additional structure of
CHF_n depends on EOH_0, form_0, EOH_1, form_1, EOH_n, and form_n
Transmission of fixed length source packet
Two-quadlet CIP header (form_0=0, form_1=0)
The standard outlines the two-quadlet CIP header for fixed-length source packets, featuring two structural types: one with the SYT field and another without it, as illustrated in Figure 5 Devices transmitting real-time data, indicated by the FMT, must utilize the SYT format to include a timestamp in the CIP header.
Figure 5a – CIP header with SYT field
Figure 5b – CIP header without SYT field Figure 5 – Two quadlets CIP header (Form_0, Form_1=0)
The definitions of the fields are given as follows
− SID: Source node ID (node ID of transmitter)
− DBS: Data block size in quadlets
DBS field is 8 bits because 256 quadlets is the maximum payload size for S100 mode When 8 bits are all 0, it means 256 quadlets; and 00000001 2 to 11111111 2 means
Several data blocks may be put into a bus packet, which is a packet to be transmitted on the bus, if a higher bandwidth is required for S200 and S400 speed
NOTE S100, S200 and S400 are transmission speeds as defined in IEEE 1394
The number of data blocks into which a source packet is divided The allowable numbers and allocated FN codes are listed in Table 2
Table 2 – Code allocation of FN
01 2 Divided into two data blocks
10 2 Divided into four data blocks
11 2 Divided into eight data blocks
− QPC: Quadlet padding count (0 quadlet to 7 quadlets)
Dummy quadlets are added at the end of each source packet to ensure that the data can be divided into equally sized blocks, with all bits in the padding quadlets set to zero.
The number of padding quadlets shall be less than the number of data blocks into which every source packet is divided, as encoded by FN
The number of padding quadlets shall be less than the size of a single data block, as encoded by DBS Consequently, a data block shall never consist entirely of padding quadlets
The value of one signifies the presence of a source packet header, as illustrated in Figure 6 The time stamp field's code allocation is detailed in Table 3, where the time stamp is encoded using the lower 25 bits of the IEEE 1394 CYCLE_TIME register, with the remaining bits reserved for future extensions and set to zero.
Figure 6 – Source packet header format
Table 3 – Time stamp field of source packet header
Time stamp field Higher 13 bits Lower 12 bits Description
− Rsv: Reserved for future extension and shall be zeros
− DBC: Continuity counter of data blocks for detecting a loss of data blocks
The value represents the initial data block following the CIP header in the bus packet, where the lower FN bits indicate the sequence number of the data block within its source packet The remaining 8-FN bits constitute the sequence number of the source packet, with the first data block of any source packet assigned a sequence number of zero In cases where FN is zero, all 8 bits of DBC are utilized to denote the source packet sequence number For further details, refer to Table 4.
Table 4 – Placing of data block sequence
FN Bits of DBC showing the place of data block sequence
01 2 Shown in the lowest 1 bit
10 2 Shown in the lowest 2 bits
11 2 Shown in the lowest 3 bits
Table 5 – Code allocation of FMT
The code allocation is illustrated in Table 5
When FMT is set to 1111112, no data blocks are transmitted, and the fields for DBS, FN, QPC, SPH, and DBC are disregarded For any other FMT values, data is available, with the most significant bit of the FMT field indicating the presence of a time stamp in SYT format If this bit is zero, the FMT-dependent field includes a time stamp as defined by SYT; if it is one, the field does not contain an absolute time stamp Refer to Figure 5 and Table 5 for additional details.
Understanding the difference between absolute and relative time stamps is essential for the functionality of Serial Bus bridges Absolute time stamps, such as those in the SYT format, necessitate readjustment by each bridge, while relative time stamps do not require this adjustment For more information, refer to IEEE 1394.1:2004.
This field is defined for each FMT
The SYT field's code allocation is detailed in Table 6 When the time stamp is represented by the most significant bit of the FMT field, the SYT field is encoded using the lower 16 bits of the IEEE 1394 CYCLE_TIME register.
Table 6 – Time stamp of SYT field
SYT Higher 4 bits Lower 12 bits Description
Isochronous packet transmission
Active transmitters must transmit an isochronous packet in each cycle, and if no data block is available, an empty packet will be sent instead This empty packet will always include a two-quadlet CIP header, with the DBC field indicating the count for the first data block in the subsequent non-empty IEEE 1394 isochronous packet for the same transmission stream Additionally, the other fields in the empty packet will align with those of non-empty packets within the same transmission stream.
General
The management of isochronous data flows on the bus, including their initiation and termination, relies on the use of plugs and plug control registers These plug control registers serve as specialized CSR registers designed for this purpose.
Plugs are not tangible components of an AV device; rather, they serve as a conceptual analogy This analogy helps illustrate how information flows through existing AV devices, where each stream of data is directed via a physical plug.
This clause outlines the contents and modification methods of the plug control registers The procedures utilizing these registers to manage isochronous data flow are referred to as connection management procedures (CMP) Clause 8 details the specific CMPs that must be employed by AV devices.
Plugs and plug control registers
An isochronous data flow flows from one transmitting AV device to zero or more receiving AV devices by sending isochronous packets on one isochronous channel of the IEEE 1394 bus
An isochronous channel shall carry not more than one isochronous data flow and each isochronous data flow shall be carried on one isochronous channel
Isochronous data flows are transmitted to a dedicated isochronous channel via a single output plug on the transmitting AV device Each receiving AV device connects to this channel through one input plug, ensuring that each plug handles only one isochronous data flow at a time.
The transmission of isochronous data through an output plug is managed by the output plug control register (oPCR) and the output master plug register (oMPR) on the transmitting AV device Each AV device features a single OUTPUT_MASTER_PLUG register that governs the common attributes of all isochronous data flows In contrast, the OUTPUT_PLUG_CONTROL register manages the specific attributes of each individual isochronous data flow, independent of other flows transmitted by the same AV device.
The reception of isochronous data flows in an AV device is managed by an input plug control register (iPCR) and a single input master plug register (iMPR) Each AV device features only one INPUT_MASTER_PLUG register, which oversees the common attributes of all isochronous data flows In contrast, the INPUT_PLUG_CONTROL register governs the specific attributes of each individual isochronous data flow, ensuring independence from other flows received by the device.
An isochronous data flow on the IEEE 1394 bus can be managed by any connected device through adjustments to the plug control registers These registers can be altered via asynchronous transactions on the bus or through internal changes if they reside on the controlling device.
The use of plugs and plug control registers is illustrated in Figure 7
AV–device iMPR iPCR[0] iPCR[1] iPCR[0] oPCR[1] iMPR oMPR oPCR[0] oPCR[1] oPCR[2] oMPR
Figure 7 – Plug and PR usage
#iPCR and #oPCR represent the number of isochronous data flows that an AV device, like a multiple viewing or multiple tuner device, can simultaneously receive and transmit, respectively These values are constants that vary depending on the AV device, falling within the range of 0 to 31.
Each AV device must include #oPCR output plugs, each managed by a distinct OUTPUT_PLUG_CONTROL register, and #iPCR input plugs, each governed by a separate INPUT_PLUG_CONTROL register For devices with INPUT_PLUG_CONTROL registers, the registers are labeled as INPUT_PLUG_CONTROL[i], where i ranges from 0 to #iPCR-1 The INPUT_MASTER_PLUG register is optional if #iPCR equals 0, but required otherwise Similarly, for devices with OUTPUT_PLUG_CONTROL registers, these are designated as OUTPUT_PLUG_CONTROL[i], with i ranging from 0 to #oPCR-1.
OUTPUT_MASTER_PLUG register is optional if #oPCR = 0 and required otherwise
The relationship between the INPUT_PLUG_CONTROL register and the isochronous data flow in a receiving AV device, as well as the connection between the OUTPUT_PLUG_CONTROL register and the isochronous data flow in a transmitting AV device, varies depending on the specific AV device.
Connections
To transmit isochronous data between two AV devices over the IEEE 1394 bus, an application must establish a connection from an output plug on the transmitting device to an input plug on the receiving device via a single isochronous channel This configuration, involving one input plug, one output plug, and one isochronous channel, is referred to as a point-to-point connection.
A point-to-point connection can only be broken by the same application that established it
An application can initiate the transmission or reception of an isochronous data flow by connecting its output or input plug to an isochronous channel This establishes a direct relationship between the output plug and the isochronous channel.
The IEC 3066/02 isochronous channel, known as a broadcast-out connection, establishes a relationship with one input plug referred to as a broadcast-in connection Together, these are termed broadcast connections While a broadcast connection can only be initiated by the AV device housing the plug, it can be terminated by any device This concept of connections is visually represented in Figure 8.
AV–device iMPR iPCR[0] iPCR[1] iPCR[0]
Isochronous data flow iPCR[1] oPCR[0]
Point to point–connection Broadcast connection iMPR iMPR iMPR oMPR
In an output plug, only one broadcast-out connection and one broadcast-in connection can be established, while a single broadcast connection can coexist with multiple point-to-point connections within the same plug This is accomplished by overlaying connections in the same input or output plug It is important to note that all connections within a plug share the same isochronous channel and transport identical isochronous data flows Additionally, multiple independent applications are capable of creating point-to-point connections between the same input and output plug.
Plug states
A plug can be in four states as described in Figure 9: idle, ready, active and suspended
The internal triggers for actions include key a, which has no action, and key e, which suspends isochronous data flow transmission/reception Key b also has no action, while key f resumes isochronous data flow transmission/reception The establishment of the first connection triggers key c, initiating isochronous data flow transmission/reception, whereas key g, also triggered by the first connection, has no action Conversely, breaking the last connection triggers key d, which stops isochronous data flow transmission/reception, and key h, which has no action Additionally, key i is triggered by a bus reset, with specific actions detailed in section 7.10.
A plug is either on-line or off-line Only a plug that is on-line is capable of transmitting or receiving an isochronous data flow
NOTE 1 Being capable does not mean that the plug is actually transmitting or receiving an isochronous data flow
A plug may be off-line, for example, because it relies on resources that are (temporarily) unpowered or otherwise unavailable
The reasons for a plug's transition between on- and off-line states are inherent to the AV device it is connected to and are not addressed by this standard.
An unconnected plug has no existing connections, while a connected plug has one or more connections An active plug is both connected and online, and it is the only type of plug that can transmit or receive an isochronous data flow, except during a bus reset, when the data flow resumes immediately afterward as outlined in section 7.10 Additionally, a plug must stop transmitting an isochronous data flow within 250 μs after it becomes unconnected, as indicated by transition d in Figure 9.
In Figure 9, all possible transitions from one state to another are given Transitions are atomic and are effected by modifying the corresponding plug control register as described in 7.9
To ensure the reliability of plug register contents, intermediate results during state transitions must remain inaccessible This can be achieved by disabling access to the plug registers, such as by masking relevant interrupt mechanisms, once a state transition is initiated It is crucial that the state transition occurs as an indivisible process, free from interruptions, suspensions, or modifications Under these conditions, the transition is considered atomic.
OUTPUT_MASTER_PLUG register definition
The OUTPUT_MASTER_PLUG register, as shown in Figure 10, provides information about and permits control of common aspects of a node’s oPCR registers
The persistent extension persistent_ext and non-persistent extension nonpersistent_ext fields are defined for future extensions
The spd field defines the maximum speed for isochronous data transmission for the oPCR registers, as detailed in Table 6 If the spd value is three, the xspd field will indicate the maximum speed for isochronous data transmission, also according to Table 6 However, if the spd value is less than three, the xspd will be set to zero.
Table 1 – oMPR/iMPR/oPCR speed encoding spd and extended speed encoding xspd spd IEEE 1394 speed xspd IEEE 1394 speed
11 2 Maximum data rate specified by xspd 11 2 Reserved for future standardization
The broadcast channel's base field, known as broadcast_base, defines the base channel number for broadcast out connections When a broadcast out connection is created without a simultaneous point-to-point connection, the oPCR register's channel field is set to 63 if broadcast_base is 63 Otherwise, it is calculated as (broadcast_base + n) modulo 63, where n represents the ordinal of oPCR[n].
The output_plugs field indicates the total number of output plugs an AV device supports, as outlined in section 7.2 This field specifies the count of oPCR registers implemented by a node, which can range from zero to 31 If any oPCR registers are present, they must be located within the contiguous address range from FFFF F000 090416 to FFFF F000 090016 plus 4 times the number of output plugs.
INPUT_MASTER_PLUG register definition
The INPUT_MASTER_PLUG register, as shown in Figure 11, provides information about and permits control of common aspects of a node’s INPUT_PLUG_CONTROL registers
The spd field shall specify the maximum speed at which any of the node’s input plugs may receive isochronous data, as encoded by Table 7
The nonpersistent_ext and persistent_ext fields are reserved for future standardization
When the spd field is set to three, the xspd field indicates the maximum speed for isochronous data reception at the node's input plugs, as detailed in Table 7 Conversely, if the spd value is less than three, the xspd value must be zero.
The input_plugs field indicates the total number of INPUT_PLUG_CONTROL registers implemented by a node, as outlined in section 7.2 A node may implement between zero and 31 INPUT_PLUG_CONTROL registers If any registers are implemented, they must be located within the contiguous address range from FFFF F000 098416 to FFFF F000 098016 plus 4 times the value of input_plugs, inclusive.
OUTPUT_PLUG_CONTROL register definition
The OUTPUT_PLUG_CONTROL register format is illustrated in Figure 12, allowing for the management of both broadcast and point-to-point connections initiated by the corresponding plug These registers are organized within a contiguous address space and are identified by an ordinal n, starting from zero; specifically, oPCR[n] corresponds to the register address at FFFF F000 090416 + 4 x n.
The online bit, represented as "o" in Figure 12, indicates the status of plug resources managed by the OUTPUT_PLUG_CONTROL register A value of zero signifies that the plug is offline and unable to transmit isochronous data, while a value of one indicates that the plug is available for configuration and can be used for isochronous data transmission.
The plug status can fluctuate between off-line and on-line based on the availability of device resources The reasons for changes in plug status, as indicated by the online bit, vary depending on the vendor.
The broadcast bit (abbreviated as b in Figure 12) shall specify whether a broadcast connection exists for the output plug A value of zero indicates that no such connection exists
The point_to_point field shall specify the number of point-to-point connections that exist for the output plug
When the spd field is set to three, the xspd field must indicate the speed for isochronous data transmissions for the plug, as defined in Table 6; otherwise, xspd should be zero If spd is three and xspd exceeds OUTPUT_MASTER_PLUG.xspd, isochronous data transmissions for the plug will be disabled.
The channel field shall specify the channel number used in isochronous data transmissions for the plug
The spd field determines the speed for isochronous data transmissions for the plug, as outlined in Table 6 If the spd value exceeds that of the OUTPUT_MASTER_PLUG register, isochronous data transmissions for the plug will be disabled.
The overhead field encodes a value essential for calculating the isochronous bandwidth allocation required for isochronous data transmissions, as detailed in Table 8 According to IEEE 1394, isochronous bandwidth is measured in bandwidth allocation units, where one unit corresponds to the time needed to transmit a quadlet of data at the S1600 data rate, approximately 20 ns When overhead is non-zero, the total bandwidth allocation is calculated using the formula: overhead × 32 + (payload + 3) × 24 − (xspd + spd) If the overhead is zero, the total bandwidth allocation can be determined from 512 + (payload + 3) × 24.
24 − (xspd + spd) In the preceding formulae, overhead, payload, spd and xspd represent the values of these fields in the OUTPUT_PLUG_CONTROL register
In the formulas provided, the S3200 data rate features a negative exponent When performing division by two at this data rate, it is essential to round the result up to the nearest larger integer.
Table 8 – oPCR overhead ID encoding
Overhead ID IEEE 1394 bandwidth allocation units
The payload field defines the maximum number of quadlets that can be transmitted in a single isochronous packet for a specific plug, with its interpretation varying based on the value of OUTPUT_PLUG_CONTROL.spd If spd is less than three, a payload value of zero allows for a maximum of 1024 quadlets, while other values indicate the maximum number of payload quadlets Conversely, when spd equals three, a payload value of zero permits a maximum of \(1024 \times 2^{spd} + 1\) quadlets, and all other values correspond to a maximum of \(payload \times 2^{spd} + 1\) quadlets.
The payload value exclusively accounts for the quadlets within the isochronous data payload, excluding the isochronous header, header CRC, and data CRC that are necessary components of an isochronous packet.
INPUT_PLUG_CONTROL register definition
The INPUT_PLUG_CONTROL register enables the management of point-to-point connections at the corresponding plug, as illustrated in Figure 13 These registers must be implemented in a contiguous address space and are identified by an ordinal n, starting from zero; specifically, iPCR[n] corresponds to the register address at FFFF F000 098416 + 4 × n.
The online bit, represented as "o" in Figure 13, indicates the on-line status of plug resources managed by the INPUT_PLUG_CONTROL register A value of zero signifies that the plug is off-line and unable to receive isochronous data, while a value of one indicates that the plug is ready for configuration and can receive isochronous data.
The plug status of a device can fluctuate between off-line and on-line based on the availability of its resources The reasons for these changes in plug status, as indicated by the online bit, vary depending on the vendor.
The broadcast bit (abbreviated as b in Figure 13 shall specify whether a broadcast connection exists for the input plug A value of zero indicates that no such connection exists
The point_to_point field shall specify the number of point-to-point connections that exist for the input plug
The channel field shall specify the channel number used in isochronous data reception for the plug.
Plug control register modification rules
The plug control register can be modified either internally by the AV device or externally through the IEEE 1394 bus using a quadlet compare_swap lock transaction The external modification is referred to as the "lock effect," as illustrated in Figures 10 to 13 and detailed in sections 7.5 to 7.8 Internal modifications will also function as a compare_swap lock transaction according to IEEE 1394 standards.
Each plug control register defined in 7.5 to 7.8 shall store any value according to the definition of write/lock effect if and only if the compare/swap lock transaction returns
“resp_complete” A plug shall behave according to the requirements of 7.5 to 7.8 for the values that are stored in the plug control registers
The following rule for modifying the contents of an INPUT_MASTER_PLUG register and OUTPUT_MASTER_PLUG register is specified:
− all modifications shall adhere to the definitions of the OUTPUT_MASTER_PLUG register and INPUT_MASTER_PLUG register as specified in 7.5 and 7.6 respectively
The following rules for modifying the contents of an INPUT_PLUG_CONTROL register and OUTPUT_PLUG_CONTROL register are specified as follows:
− all modifications shall adhere to the definitions of the OUTPUT_PLUG_CONTROL register and INPUT_PLUG_CONTROL register as specified in 7.7 and 7.8 respectively;
− the channel and associated bandwidth (see 7.7) as stored in an OUTPUT_PLUG_CONTROL register shall be allocated during the entire time the corresponding output plug is connected;
− the channel number field and data rate field of an OUTPUT_PLUG_CONTROL register shall not be modified while the corresponding output plug is connected;
− the channel number field in an INPUT_PLUG_CONTROL register shall not be modified while its point-to-point connection counter field is not equal to zero;
− the broadcast connection counter field shall be set internally;
When an output plug is connected, the data rate field, overhead_ID field, channel number field, broadcast connection counter field, and point-to-point connection counter field must all be updated within the same compare_swap lock transaction.
If the broadcast connection counter of an OUTPUT_PLUG_CONTROL register changes from zero to one while the point-to-point connection counter remains at zero, the channel number must be updated in the same compare_swap lock transaction using the formula specified in section 7.5.
Bus reset
During a bus reset, all AV devices with connected input and output plugs will continue to receive and transmit isochronous data flow immediately after the reset, based on the values in the plug control registers prior to the reset Additionally, these devices will operate according to the corresponding plug control register values after a delay of 1.0 seconds following the bus reset.
Plug control register access rules
The plug control registers occupy part of a node's address space, as shown by Figure 14
FFFF F000 097C FFFF F000 0980 FFFF F000 0984 FFFF F000 0988 FFFF F000 098C
16 oMPR oPCR[0] oPCR[1] oPCR[2] oPCR[30] iMPR iPCR[0] iPCR[1] iPCR[2] iPCR[30]
A node with plug control registers must support quadlet read requests for all implemented registers It should also accommodate lock requests for these registers, provided the destination offset is quadlet aligned, the extended transaction code is two (indicating compare and swap), and the data length is four However, neither quadlet write nor block write requests are permitted for any plug control registers, regardless of their implementation status.
If a valid request is made for an unimplemented plug control register, the node should respond with a resp_address_error, although it may also complete the transaction with resp_complete and return zero data The node can support block read requests for the plug control register address space, but if the destination_offset and data_length include unimplemented registers, the request may be rejected with a resp_address_error If the transaction is completed successfully, the response data for the unimplemented registers will be zero.
Introduction
This clause outlines the procedures for managing connections between input and output plugs of AV devices by adjusting plug control registers as specified in Clause 7 Only the connections defined in Clause 7 of this standard are eligible for management The management procedures for each connection type are detailed as follows.
The operations for incrementing and decrementing connection counters in plug control registers are illustrated in Figure 15, which outlines the relationship between different connection types Flow diagrams in Figures 16 to 28 detail the procedures for each connection type, indicating that no changes to a plug control register occur until the first modify operation in the flow diagram These diagrams represent potential implementations of the procedures, with other conforming implementations also being feasible.
An implementation conforms if, and only if, it does not violate the plug control register modification rules (see 7.9) and the state transition diagram of Figure 15
Point-to-point connection counter = 0 a c d b c b c b c b c f e f e f
Point-to-point connection counter = 1 Broadcast connection counter = 0
Point-to-point connection counter = 2 Broadcast connection counter = 0
Point-to-point connection counter = 0 Broadcast connection counter = 1
Point-to-point connection counter = 1 Broadcast connection counter = 1
Establishing a point-to-point connection is allowed by any application, while overlaying such a connection is also permitted An application that has previously established or overlaid a point-to-point connection can break it Additionally, establishing a broadcast connection is permitted by an application located on the device where the PCR is situated, and overlaying a broadcast connection is allowed by an application located on the same device Finally, breaking a broadcast connection is permitted by any application.
Figure 15 – Point-to-point and broadcast connection counter modifications
Managing point-to-point connections
Procedure for establishing a point-to-point connection
This procedure creates a protected connection between one unconnected input plug and one unconnected output plug using one unused channel Figure 16 shows an implementation conforming to this procedure
The selection of the OUTPUT_PLUG_CONTROL and INPUT_PLUG_CONTROL registers for transmitting and receiving AV devices is not covered by this standard Additionally, the choice of channel, data rate, and overhead_ID is also outside the scope of this standard.
Set allocate channel in oPCR and iPCR
Set oPCR data rate and overhead-ID
Set oPCR and iPCR point-to-point connection counters from zero to one
"breaking a point-to-point connection" for modified PCR
Figure 16 – Establishing a point-to-point connection
Procedure for overlaying a point-to-point connection
This procedure establishes a secure connection between an output plug and an input plug by utilizing the isochronous channel already in use for transmitting isochronous data Figure 17 illustrates a compliant implementation of this procedure.
NOTE The choice of which INPUT_PLUG_CONTROL register on the receiving device is used does not fall within the scope of this standard
Fail Copy channel from oPCR to iPCR
Increment oPCR and iPCR point- to-point connection counters by one
"breaking a point-to-point connection" for modified PCR
Figure 17 – Overlaying a point-to-point connection
Procedure for breaking a point-to-point connection
This procedure removes a protected connection between a connected input plug and a connected output plug If the point-to-point connection is severed, the output plug will cease transmitting the isochronous data flow An implementation of this procedure is illustrated in Figure 18.
The responding application shall not reject the decrementing of the point-to-point connection counters in the OUTPUT_PLUG_CONTROL and INPUT_PLUG_CONTROL registers
Decrement point-to-point connection counters in oPCR and iPCR by one
Figure 18 – Breaking a point-to-point connection
Managing broadcast-out connections
Procedure for establishing a broadcast-out connection
This procedure creates an unprotected connection between one unused channel and one unconnected output plug Figure 19 shows an implementation conforming to this procedure
The selection of the OUTPUT_PLUG_CONTROL register on the transmitting AV device is not addressed by this standard Additionally, the determination of the data rate and overhead_ID is also outside the scope of this standard.
The channel according to the formula in 7.5 shall be allocated It should be noted that, if that channel is in use, the procedure fails
Set allocated channel in oPCR
Set oPCR data rate and overhead-ID
Set oPCR broadcast connection counter from zero to one
Figure 19 – Establishing a broadcast-out connection
Procedure for overlaying a broadcast-out connection
This procedure establishes an unprotected link between a connected output plug and the channel utilized for transmitting isochronous data flow, as illustrated in Figure 20.
Set oPCR broadcast connection counter from zero to one
Figure 20 – Overlaying a broadcast-out connection
Procedure for breaking a broadcast-out connection
This procedure removes an unprotected link between a connected output plug and its corresponding channel for transmitting isochronous data If this disconnection results in the output plug becoming unlinked, the output plug will no longer be connected.
IEC 3079/02 shall stop transmitting the isochronous data flow Figure 21 shows an implementation conforming to this procedure
The responding application shall not reject the decrementing of the broadcast connection counter in the OUTPUT_PLUG_CONTROL register
Set oPCR broadcast connection counter from one to zero
Figure 21 – Breaking a broadcast-out connection
Managing broadcast-in connections
Procedure for establishing a broadcast-in connection
This procedure creates an unprotected connection between one channel and one unconnected input plug Figure 22 shows an implementation conforming to this procedure
The selection of the INPUT_PLUG_CONTROL register and the choice of channel on an AV device are not addressed by this standard.
Set iPCR broadcast connection counter from zero to one
Figure 22 – Establishing a broadcast-in connection
Procedure for overlaying a broadcast-in connection
This procedure establishes an unprotected link between a connected input plug and the channel utilized for receiving isochronous data flow, as illustrated in Figure 23.
Set iPCR broadcast connection counter from zero to one
Figure 23 – Overlaying a broadcast-in connection
Procedure for breaking a broadcast-in connection
This procedure removes an unprotected link between a connected input plug and its associated channel for receiving isochronous data The input plug will cease to receive the isochronous data flow only if the disconnection results in it becoming unconnected An implementation of this procedure is illustrated in Figure 24.
The responding application shall not reject the decrementing of the broadcast connection counter in the INPUT_PLUG_CONTROL register
Set iPCR broadcast connection counter from one to zero
Figure 24 – Breaking a broadcast-in connection
Managing connections after a bus reset
Procedure for restoring a point-to-point connection after a bus reset
Figure 26 shows an implementation conforming to the procedure to restore a point-to-point connection that it had established prior to the bus reset
The channel and bandwidth that are to be allocated shall be calculated using the contents of the OUTPUT_PLUG_CONTROL register after the bus reset
Wait until broadcast or point-to-point connection counter in oPCR is unequal to zero isoch_resource_delay expires OR
"overlay point-to-point connection"
Figure 26 – Restoring a point-to-point connection
Procedure for restoring a broadcast-out connection after a bus reset
Figure 27 shows an implementation conforming to the procedure to restore a broadcast-out connection that it had established prior to the bus reset
The channel and bandwidth that are to be allocated shall be calculated using the contents of the OUTPUT_PLUG_CONTROL register after the bus reset
Wait until point-to-point connection counter in oPCR is unequal to zero isoch_resource_delay expires OR
Figure 27 – Restoring a broadcast-out connection
Procedure for restoring a broadcast-in connection after a bus reset
Figure 28 shows an implementation conforming to the procedure to restore a broadcast-in connection that it had established prior to the bus reset
Figure 28 – Restoring a broadcast-in connection
Introduction
The Function Control Protocol (FCP) is specifically designed to manage devices connected via an IEEE 1394 bus It utilizes various command sets and transactions to facilitate communication FCP operates on the IEEE 1394 standard, employing asynchronous packets for the transmission of commands and responses.
A node that controls other node(s) by FCP commands is called a controller, and a node that is controlled by FCP commands is called a target
An FCP frame is an entity of data to be transferred from a controller to a target or vice versa
In the context of FCP (Fibre Channel Protocol), a command frame is transmitted from a controller to a target, while a response frame is sent from a target back to a controller The command register is designated for receiving command frames, whereas the response register is specifically prepared for receiving response frames.
Figure 29 – Command register and response register
Asynchronous packet structure
The asynchronous packet structure used for sending an FCP frame is shown in Figures 30 and 31
In FCP, the payloads of write requests for data block packets and data quadlets are referred to as FCP frames A write request for a data quadlet qualifies as an FCP frame only when its length is precisely four bytes FCP frames are categorized into command frames, which are stored in a command register on a target, and response frames, which are recorded in a response register on a controller These registers are distinct, and their destination offset addresses are specified within the FCP.
Base address of FCP command register (offset) FFFF F000 0B00 16
Base address of FCP response register (offset) FFFF F000 0D00 16
Only write requests that specify FFFF F000 0B0016 or FFFF F000 0D0016 as the destination_offset are permitted
Data field (FCP frame) Header_CRC
Source_ID Destination_ID Transmitted first
Zero pad bytes (if necessary)
Figure 30 – Write request for data block packet of IEEE 1394
Quadlet_data (FCP frame) Header CRC
Figure 31 – Write request for data quadlet packet of IEEE 1394
FCP frame structure
Vendor unique command/transaction set
If the CTS code is 11102, it indicates that the FCP frame belongs to vendor unique CTS
An FCP frame structure that belongs to vendor unique CTS is shown in Figure 33
Each vendor may specify a frame structure (except company_ID), a command set and rules for sending commands/responses
Command/Response field (free format)
Zero pad bytes (if necessary)
Company_ID: refer to ISO/IEC 13213
Figure 33 – Vendor unique frame format
Extended command/transaction set
CTS code 11112 is reserved for future extensions of CTS