ISO/IEC 14776-232:2001

Information technology — Small computer system interface (SCSI) — Part 232: Serial Bus Protocol 2 (SBP-2)

This part of ISO/IEC 14776 defines a protocol for the transport of commands and data over High Performance Serial Bus. The transport protocol, Serial Bus Protocol 2 or SBP-2, requires implementations to conform to the requirements of this standard as well as to ISO/IEC 13213:1994 and permits the exchange of commands, data and status between initiators and targets connected to Serial Bus.

Technologies de l'information — Interface de petit ordinateur (SCSI) — Partie 232: Protocole 2 de bus de série (SBP-2)

General Information

• Status: Published
• Publication Date: 19-Dec-2001
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Drafting Committee: ISO/IEC JTC 1/SC 25 - Interconnection of information technology equipment
• Current Stage: 9093 - International Standard confirmed
• Start Date: 29-Jul-2008
• Completion Date: 12-Feb-2026

Relations

• Revised: ISO/IEC 14776-323:2017 - Information technology — Small computer system interface (SCSI) — Part 323: SCSI Block commands — 3 (SBC-3)
• Effective Date: 10-May-2014

Overview

ISO/IEC 14776-232:2001 - Information technology - Small computer system interface (SCSI) - Part 232: Serial Bus Protocol 2 (SBP-2) - defines the SBP-2 transport protocol for carrying SCSI commands, data and status over a High Performance Serial Bus. The standard specifies required behaviors, data structures and register models so that initiators and targets can exchange requests and responses reliably. Implementations must also conform to ISO/IEC 13213:1994 where indicated.

Key topics and requirements

• Transport protocol (SBP-2): Specifies how SCSI command, data and status are encapsulated and moved between nodes on a Serial Bus.
• Conformance: Implementations are required to follow this part of ISO/IEC 14776 plus referenced normative standards (notably ISO/IEC 13213:1994).
• Data structures: Detailed formats for Operation Request Blocks (ORBs) (command, management, dummy ORBs), page tables, and status blocks.
• Control and status registers: Core and serial-bus dependent CSR definitions and agent registers (e.g., ORB_POINTER, DOORBELL, AGENT_STATE).
• Configuration ROM: Layout and required directory entries (unit directories, command set IDs, Unit_Unique_ID, management agent, unit characteristics).
• Access and session management: Procedures for login, reconnect, logout, and access protocols between initiators and targets.
• Command execution and data transfer: Request lists, fetch agent behavior, data buffering (direct and indirect), completion status and unsolicited status handling.
• Task management: Task set model, task management requests (abort task, reset, etc.) and error conditions.
• Normative and informative annexes: Minimum node capabilities, SCSI encapsulation rules, security extensions, sample configuration ROMs and transaction error recovery.

Applications and who uses this standard

ISO/IEC 14776-232:2001 is primarily used by:

• Device manufacturers implementing SCSI-targets over a High Performance Serial Bus (firmware and hardware).
• Host adapter and controller vendors that build initiator implementations and drivers.
• Operating system and driver developers implementing SBP-2 device drivers and session management.
• System integrators and test labs validating interoperability, conformance testing and configuration ROM contents.
• Security and firmware engineers implementing the security extensions and management ORBs.

Practical uses include building interoperable storage devices, developing driver stacks for serial-bus attached SCSI devices, and defining device firmware behavior for login/reconnect and task management.

Related standards

• ISO/IEC 13213:1994 (referenced for conformance requirements)
• Other SCSI architecture and Small Computer System Interface standards for command set semantics and higher-level SCSI behavior.

Keywords: ISO/IEC 14776-232:2001, SBP-2, Serial Bus Protocol 2, SCSI over Serial Bus, Operation Request Block, configuration ROM, task management, control and status registers.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD
14776-232
First edition
2001-11
Information technology –
Small computer system interface (SCSI) –
Part 232: Serial Bus Protocol 2 (SBP-2)
Reference number
INTERNATIONAL ISO/IEC
STANDARD
14776-232
First edition
2001-11
Information technology –
Small computer system interface (SCSI) –
Part 232: Serial Bus Protocol 2 (SBP-2)
 ISO/IEC 2001
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office Case postale 56 CH-1211 Genève 20 Switzerland
• • •
PRICE CODE
X
For price, see current catalogue

– 2 – 14776-232  ISO/IEC:2001(E)
CONTENTS
FOREWORD. 6
1 Scope and object. 7
1.1 Scope. 7
1.2 Object . 7
2 Normative references . 8
3 Definitions and notation. 9
3.1 Definitions . 9
3.1.1 Conformance. 9
3.1.2 Glossary. 9
3.1.3 Abbreviations .12
3.2 Notation .12
3.2.1 Numeric values .12
3.2.2 Bit, byte and quadlet ordering.12
3.2.3 Register specifications .13
3.2.4 State machines .15
4 Model (informative).17
4.1 Unit architecture.17
4.2 Logical units.17
4.3 Requests and responses .17
4.4 Data buffers .18
4.5 Target agents.20
4.6 Ordered and unordered execution .21
5 Data structures.22
5.1 Operation request blocks (ORBs). .23
5.1.1 Dummy ORB .24
5.1.2 Command block ORBs .24
5.1.3 Management ORBs .26
5.2 Page tables. .33
5.2.1 Unrestricted page tables. .34
5.2.2 Normalized page tables.34
5.3 Status block. .35
5.3.1 Request status .37
5.3.2 Unsolicited device status.39
6 Control and status registers.40
6.1 Core registers .40
6.2 Serial Bus-dependent registers.40
6.3 MANAGEMENT_AGENT register.41
6.4 Command block agent registers .41
6.4.1 AGENT_STATE register .42
6.4.2 AGENT_RESET register.43
6.4.3 ORB_POINTER register .43
6.4.4 DOORBELL register .44
6.4.5 UNSOLICITED_STATUS_ENABLE register.45

14776-232  ISO/IEC:2001(E) – 3 –
7 Configuration ROM.46
7.1 Power reset initialization .46
7.2 Bus information block .47
7.3 Root directory.48
7.3.1 Module_Vendor_ID entry.48
7.3.2 Node_Capabilities entry .48
7.3.3 Unit_Directory entry .48
7.4 Unit directory.49
7.4.1 Unit_Spec_ID entry. .49
7.4.2 Unit_SW_Version entry .49
7.4.3 Command_Set_Spec_ID entry.50
7.4.4 Command_Set entry.50
7.4.5 Command_Set_Revision entry.50
7.4.6 Firmware_Revision entry.51
7.4.7 Management_Agent entry.51
7.4.8 Unit_Characteristics entry .51
7.4.9 Reconnect_Timeout entry.52
7.4.10 Logical_Unit_Directory entry.52
7.4.11 Logical_Unit_Number entry.52
7.4.12 Unit_Unique_ID entry .53
7.5 Logical unit directory .53
7.5.1 Command_Set_Spec_ID entry.54
7.5.2 Command_Set entry.54
7.5.3 Command_Set_Revision entry.54
7.5.4 Logical_Unit_Number entry .54
7.6 Unit unique ID leaf.54
8 Access .56
8.1 Access protocols .56
8.2 Login.56
8.3 Reconnection .57
8.4 Logout.58
9 Command execution.59
9.1 Requests and request lists .59
9.1.1 Fetch agent initialization (informative) .59
9.1.2 Dynamic appends to request lists (informative) .60
9.1.3 Fetch agent use by the BIOS (informative) .61
9.1.4 Fetch agent state machine .61
9.2 Data transfer .64
9.3 Completion status.64
9.4 Unsolicited status .65

– 4 – 14776-232  ISO/IEC:2001(E)
10 Task management .66
10.1 Task sets .66
10.2 Basic task management model .66
10.3 Error conditions.67
10.4 Task management requests.67
10.4.1 Abort task.67
10.4.2 Abort task set .68
10.4.3 Logical unit reset .69
10.4.4 Target reset.69
10.5 Task management event matrix.70
Annex A (normative) Minimum Serial Bus node capabilities .71
Annex B (normative) SCSI command and status encapsulation.73
Annex C (normative) Security extensions.78
Annex D (informative) Sample configuration ROM.81
Annex E (informative) Serial Bus transaction error recovery.85
Annex F (informative) SCSI Architecture Model conformance .87
Figure 1 – Bit ordering within a byte.13
Figure 2 – Byte ordering within a quadlet .13
Figure 3 – Quadlet ordering within an octlet.13
Figure 4 – CSR specification example.14
Figure 5 – State machine example.16
Figure 6 – Linked list of ORBs .18
Figure 7 – Directly addressed data buffer .19
Figure 8 – Indirectly addressed data buffer (via page table) .19
Figure 9 – Address pointer.22
Figure 10 – ORB pointer .22
Figure 11 – ORB family tree.23
Figure 12 – ORB format .23
Figure 13 – Dummy ORB .24
Figure 14 – Command block ORB .25
Figure 15 – Management ORB.27
Figure 16 – Login ORB .28
Figure 17 – Login response .29
Figure 18 – Query logins ORB .30
Figure 19 – Query logins response format.30
Figure 20 – Reconnect ORB .31
Figure 21 – Logout ORB .32
Figure 22 – Task management ORB .33
Figure 23 – Page table element (unrestricted page table) .34

14776-232  ISO/IEC:2001(E) – 5 –
Figure 24 – Page table element (when page_size equals four).34
Figure 25 – Status block format .36
Figure 26 – TRANSPORT FAILURE format for sbp_status .38
Figure 27 – MANAGEMENT_AGENT format .41
Figure 28 – AGENT_STATE format.42
Figure 29 – AGENT_RESET format .43
Figure 30 – ORB_POINTER format.44
Figure 31 – DOORBELL format.45
Figure 32 – UNSOLICITED_STATUS_ENABLE format.45
Figure 33 – Configuration ROM hierarchy .46
Figure 34 – Bus information block format .47
Figure 35 – Module_Vendor_ID entry format.48
Figure 36 – Node_Capabilities entry format .48
Figure 37 – Unit_Directory entry format .49
Figure 38 – Unit_Spec_ID entry format .49
Figure 39 – Unit_SW_Version entry format .49
Figure 40 – Command_Set_Spec_ID entry format.50
Figure 41 – Command_Set entry format.50
Figure 42 – Command_Set_Revision entry format.50
Figure 43 – Firmware_Revision entry format.51
Figure 44 – Management_Agent entry format.51
Figure 45 – Unit_Characteristics entry format .51
Figure 46 – Reconnect_Timeout entry format.52
Figure 47 – Logical_Unit_Directory entry format .52
Figure 48 – Logical_Unit_Number entry format .52
Figure 49 – Unit_Unique_ID entry format .53
Figure 50 – Unit unique ID leaf format.54
Figure 51 – Fetch agent initialization with a dummy ORB.60
Figure 52 – Fetch agent state machine .62
Figure B.1 – SCSI command block ORB .73
Figure B.2 – SCSI control byte.73
Figure B.3 – Status block format for SCSI sense data.74
Figure C.1 – Set password ORB .79
Figure D.1 – Basic configuration ROM .81
Figure D.2 – SCSI configuration ROM.83
Table 1 – Data transfer speeds .26
Table 2 – Management request functions.27
Table F.1 – SAM-2 Service responses .89

- 6 - 14776-232 © ISO/IEC:2001(E)
INFORMATION TECHNOLOGY –
SMALL COMPUTER SYSTEM INTERFACE (SCSI) –
Part 232: Serial bus protocol 2 (SBP-2)
FOREWORD
1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in
the development of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in
fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with
ISO and IEC, also take part in the work.
2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
3) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 14776-232 was prepared by subcommittee 25: Inter-
connection of information technology equipment, of ISO/IEC joint technical committee 1:
Information technology.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 3.
Annexes A, B and C form an integral part of this International Standard.
Annexes D, E and F are for information only.

14776-232 © ISO/IEC:2001(E) – 7 –
INFORMATION TECHNOLOGY –
SMALL COMPUTER SYSTEM INTERFACE (SCSI) –
Part 232: Serial bus protocol 2 (SBP-2)
1 Scope and object
1.1 Scope
This part of ISO/IEC 14776 defines a protocol for the transport of commands and data over
High Performance Serial Bus. The transport protocol, Serial Bus Protocol 2 or SBP-2, requires
implementations to conform to the requirements of this standard as well as to
ISO/IEC 13213:1994 and permits the exchange of commands, data and status between
initiators and targets connected to Serial Bus.
1.2 Object
Original development work for Serial Bus Protocol (SBP) was initiated out of a desire to adapt
SCSI capabilities and facilities to a particular serial environment IEEE 1394. Serial
interconnects offer a migration path for SCSI into the future because they may be better
suited to cost reduction and speed increases than the parallel interconnects first utilized by
SCSI.
As development of the standard progressed, it became evident that the solutions provided by
SBP-2 were of general applicability to large classes of Serial Bus peripheral devices. With this
in mind, the development work was redirected to provide mechanisms for the delivery of
commands, date and status independent of the command set or device class of the
peripheral. SBP-2 provides a generic framework that may be referenced by other documents
or standards that address the unique requirements of a particular class of devices. The
enhanced goals set for the design of SBP-2 are ranked below:
– the protocol should permit the encapsulation of commands, data and status from a
diversity of command sets, legacy as well as future, in order to preserve the investment in
an existing application and operating system software base;
– the protocol should allow the initiator to dynamically add tasks to this set while the target is
active in execution of earlier tasks. The addition of new tasks should not interfere with the
target’s processing of tasks currently active;
– although the protocol should enable varying levels of features and performance in target
implementations, strong focus should be kept on a minimal set deemed adequate for entry-
level environments;
– within the constraints posed by the preceding goal, the hardware and software design of
the initiator should not be unduly affected by variations in target capabilities;
– in order to promote the scalability of aggregate system performance, the protocol should
distribute the DMA context from the initiator adapter to the target devices.
Although SBP-2 has been designed for Serial Bus as currently specified by IEEE 1394, it is
believed that it will be appropriate for use with future extensions to Serial Bus as they are
standardized.
– 8 – 14776-232 © ISO/IEC:2001(E)
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO/IEC 9899:1999, Programming Languages – C
ISO/IEC 13213:1994, Information technology – Microprocessor systems – Control and Status
Register (CSR) Architecture for Microcomputer Buses
ANSI/IEEE 1394:1995, IEEE Standard for High Perfomance Serial Bus
1)
IEEE P1394a, Draft Standard for High Perfomance Serial Bus (Supplement)
2)
BSR X3 PN 1157-D, Information technology – SCSI Architecture Model 2 (SAM-2)
2)
BSR NCITS PN 1236-D, Information technology – SCSI Primary Commands 2 (SPC-2)

1)
Under development. Available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O.
Box 1331, Piscataway, NJ 08855-1331
2)
Under development. Available from the National Committee for Information Technology Standards, 1250 Eye
Street, NW, Suite 200, Washington, DC 20005-3922

14776-232 © ISO/IEC:2001(E)
3 Definitions and notation
3.1 Definitions
3.1.1 Conformance
Several keywords are used to differentiate levels of requirements and optionality, as follows:
3.1.1.1 expected: A keyword used to describe the behavior of the hardware or software in the design
models assumed by this standard. Other hardware and software design models may also be imple-
mented.
3.1.1.2 ignored: A keyword that describes bits, bytes, quadlets, octlets or fields whose values are not
checked by the recipient.
3.1.1.3 may: A keyword that indicates flexibility of choice with no implied preference.
3.1.1.4 reserved: A keyword used to describe objects—bits, bytes, quadlets, octlets and fields—or the
code values assigned to these objects in cases where either the object or the code value is set aside for
future standardization. Usage and interpretation may be specified by future extensions to this or other
standards. A reserved object shall be zeroed or, upon development of a future standard, set to a value
specified by such a standard. The recipient of a reserved object shall not check its value. The recipient of
an object defined by this standard other than reserved shall check its value and reject reserved code
values.
3.1.1.5 shall: A keyword that indicates a mandatory requirement. Designers are required to implement all
such mandatory requirements to assure interoperability with other products conforming to this standard.
3.1.1.6 should: A keyword that denotes flexibility of choice with a strongly preferred alternative. Equivalent
to the phrase “is recommended.”
3.1.2 Glossary
The following terms are used in this standard:
3.1.2.1 byte: Eight bits of data.
3.1.2.2 command block: Space reserved within an ORB to describe a command intended for a logical
unit that controls device functions or the transfer of data to or from device medium. The format and
meaning of command blocks are outside the scope of SBP-2 and are command set- or device-
dependent.
3.1.2.3 device server: A component of a logical unit responsible to execute tasks initiated by command
blocks that specify data transfer or other device operations.
3.1.2.4 initial node space: The 256 terabytes of Serial Bus address space that may be available to each
node. Addresses within initial node space are 48 bits and are based at zero. The initial node space in-
cludes initial memory space, private space, initial register space and initial units space. See either
ISO/IEC 13213 or ANSI/IEEE 1394 for more information on address spaces.
3.1.2.5 initial register space: A two kilobyte portion of initial node space with a base address of
FFFF F000 0000 . Core registers defined by ISO/IEC 13213 are located within initial register space as
are Serial Bus-dependent registers defined by ANSI/IEEE 1394.
14776-232 © ISO/IEC:2001(E)
3.1.2.6 initial units space: A portion of initial node space with a base address of FFFF F000 0800 . This
places initial units space adjacent to and above initial register space. The CSRs and other facilities de-
fined by unit architectures are expected to lie within this space.
3.1.2.7 initiator: A node that originates device service or management requests and signals these re-
quests to a target for processing.
3.1.2.8 kilobyte: A quantity of data equal to 2 bytes.
3.1.2.9 logical unit: The part of the unit architecture that is an instance of a device model, e.g., disk, CD-
ROM or printer. Targets implement one or more logical units; the device type of the logical units may differ.
3.1.2.10 login: The process by which an initiator obtains access to a set of target fetch agents. The target
fetch agents and their control and status registers provide a mechanism for an initiator to signal ORBs to
the target.
3.1.2.11 login ID: A value assigned by the target during the login process. The login ID establishes a rela-
tionship between an initiator and a task set. The login ID is used to identify subsequent requests from an
initiator; in some cases the login ID is not present in the operation request block and its value is implicit.
3.1.2.12 node: An addressable device attached to Serial Bus.
3.1.2.13 node ID: The 16-bit node identifier defined by ANSI/IEEE 1394 that is composed of a bus ID por-
tion and a physical ID portion. The physical ID is uniquely assigned as a consequence of Serial Bus ini-
tialization.
3.1.2.14 octlet: Eight bytes, or 64 bits, of data.
3.1.2.15 operation request block: A data structure fetched from system memory by a target in order to
execute the command encapsulated within it.
3.1.2.16 quadlet: Four bytes, or 32 bits, of data.
3.1.2.17 receive: When any form of this verb is used in the context of Serial Bus primary packets, it indi-
cates that the packet is made available to the transaction or application layers, i.e., layers above the link
layer. Neither a packet repeated by the PHY nor a packet examined by the link is "received" by the node
unless the preceding is also true.
3.1.2.18 register: A term used to describe quadlet aligned addresses that may be read or written by Serial
Bus transactions. In the context of this standard, the use of the term register does not imply a specific
hardware implementation. For example, in the case of split transactions that permit sufficient time be-
tween the request and response subactions, the behavior of the register may be emulated by a processor.
3.1.2.19 request subaction: A packet transmitted by a node (the requester) that communicates a trans-
action code and optional data to another node (the responder) or nodes.
3.1.2.20 response subaction: A packet transmitted by a node (the responder) that communicates a re-
sponse code and optional data to another node (the requester). A response subaction may consist of ei-
ther an acknowledge packet or a response packet.
14776-232 © ISO/IEC:2001(E)
3.1.2.21 split transaction: A transaction that consists of a request subaction followed by a separate re-
sponse subaction. Subactions are considered separate if ownership of the bus is relinquished between the
two.
3.1.2.22 status block: A data structure that may be written to system memory by a target when an opera-
tion request block has been completed.
3.1.2.23 store: When any form of this verb is used in the context of data transferred by the target to the
system memory of either an initiator or other device, it indicates both the use of Serial Bus write request
subaction(s), quadlet or block, to place the data in system memory and the corresponding response
subaction(s) that complete the write(s).
3.1.2.24 system memory: The portions of any node’s memory that are directly addressable by a Serial
Bus address and that accepts, at a minimum, quadlet read and write access. Computers are the most
common example of nodes that might make system memory addressable from Serial Bus, but any node,
including those usually thought of as peripheral devices, may have system memory.
3.1.2.25 target: A node that receives device service or management requests from an initiator. In the case
of device service requests, the commands are directed to one of the target’s logical units to be executed.
Management requests are serviced by the target. A CSR Architecture unit is synonymous with a target.
3.1.2.26 task: A task is an organizing concept that represents the work to be done by a target to carry out
a command encapsulated by an ORB. In order to perform a task, a target maintains context information
for the task, which includes (but is not limited to) the command, parameters such as data transfer ad-
dresses and lengths, completion status and ordering relationships to other tasks. A task has a lifetime,
which commences when the task is entered into the target’s task set, proceeds through a period of execu-
tion by the target and finishes either when completion status is stored at the initiator or when completion
may be deduced from other information. While a task is active, it makes use of both target resources and
initiator resources.
3.1.2.27 task set: A group of tasks available for execution by a logical unit of a target. This standard
specifies some dependencies between individual tasks within the task set but there may be others not
specified by this standard.
3.1.2.28 terabyte: A quantity of data equal to 2 bytes.
3.1.2.29 transaction: A Serial Bus request subaction and the corresponding response subaction. The
request subaction transmits a transaction code (such as quadlet read, block write or lock); some request
subactions include data as well as transaction codes. The response subaction is null for transactions with
broadcast destination addresses or broadcast transaction codes; otherwise it returns completion status
and possibly data.
3.1.2.30 unit: A component of a Serial Bus node that provides processing, memory, I/O or some other
functionality. Once the node is initialized, the unit provides a CSR interface that is typically accessed by
device driver software at an initiator. A node may have multiple units, which normally operate independ-
ently of each other. Within this standard, a unit is equivalent to a target.
3.1.2.31 unit architecture: The specification of the interface to and the services provided by a unit im-
plemented within a Serial Bus node. This standard is a unit architecture for SBP-2 targets.
3.1.2.32 unit attention: A state that a logical unit maintains while it has unsolicited status information to
report to one or more logged-in initiators. A unit attention condition shall be created as described else-
where in this standard or in the applicable command-set- and device-dependent documents. A unit atten-
tion condition shall persist for a logged-in initiator until a) unsolicited status that reports the unit attention
14776-232 © ISO/IEC:2001(E)
condition is successfully stored at the initiator or b) the initiator’s login becomes invalid or is released.
Logical units may queue unit attention conditions; after the first unit attention condition is cleared, another
unit attention condition may exist.
3.1.2.33 working set: The part of a task set that has been fetched from the initiator by the target and is
available to the target in its local storage.
3.1.3 Abbreviations
The following abbreviations are used in this standard:
CSR Control and status register
CRC Cyclical redundancy checksum
EUI-64 Extended Unique Identifier, 64-bits
LUN Logical unit number
ORB Operation request block
SAM-2 SCSI Architecture Model 2
SBP-2 Serial Bus Protocol 2 (this standard itself)
SPC-2 SCSI Primary Commands 2
3.2 Notation
The following conventions should be understood by the reader in order to comprehend this standard.
3.2.1 Numeric values
Decimal, hexadecimal and, occasionally, binary numbers are used within this standard. By editorial con-
vention, decimal numbers are most frequently used to represent quantities or counts. Addresses are uni-
formly represented by hexadecimal numbers. Hexadecimal numbers are also used when the value repre-
sented has an underlying structure that is more apparent in a hexadecimal format than in a decimal for-
mat. Binary numbers are used infrequently and generally limited to the representation of bit patterns within
a field.
Decimal numbers are represented by Arabic numerals without subscripts or by their English names.
Hexadecimal numbers are represented by digits from the character set 0 – 9 and A – F followed by the
subscript 16. Binary numbers are represented by digits from the character set 0 and 1 followed by the
subscript 2. When the subscript is unnecessary to disambiguate the base of the number it may be omit-
ted. For the sake of legibility, binary and hexadecimal numbers are separated into groups of four digits
separated by spaces.
As an example, 42, 2A and 0010 1010 all represent the same numeric value.
16 2
3.2.2 Bit, byte and quadlet ordering
SBP-2 is defined to use the facilities of Serial Bus, ANSI/IEEE 1394, and therefore uses the ordering con-
ventions of Serial Bus in the representation of data structures. In order to promote interoperability with
memory buses that may have different ordering conventions, this standard defines the order and signifi-
14776-232 © ISO/IEC:2001(E)
cance of bits within bytes, bytes within quadlets and quadlets within octlets in terms of their relative posi-
tion and not their physically addressed position.
Within a byte, the most significant bit, msb, is that which is transmitted first and the least significant bit,
lsb, is that which is transmitted last on Serial Bus, as illustrated below. The significance of the interior bits
uniformly decreases in progression from msb to lsb, see Figure 1.
most significant least significant
msb interior bits (decreasing significance left to right) lsb
Figure 1 – Bit ordering within a byte
Within a quadlet, the most significant byte is that which is transmitted first and the least significant byte is
that which is transmitted last on Serial Bus, see Figure 2.
most significant least significant
second next to
most significant byte least significant byte
most significant byte least significant byte
Figure 2 – Byte ordering within a quadlet
Within an octlet, which is frequently used to contain 64-bit Serial Bus addresses, the most significant
quadlet is that which is transmitted first and the least significant quadlet is that which is transmitted last on
Serial Bus, see Figure 3.
most significant
most significant quadlet
least significant quadlet
least significant
Figure 3 – Quadlet ordering within an octlet
When block transfers take place that are not quadlet aligned or not an integral number of quadlets, no
assumptions can be made about the ordering (significance within a quadlet) of bytes at the unaligned be-
ginning or fractional quadlet end of such a block transfer, unless an application has knowledge (outside of
the scope of this standard) of the ordering conventions of the other bus.
3.2.3 Register specifications
This standard defines the format and function of control and status registers, CSRs. Some of these reg-
isters are read-only, some are both readable and writable and some generate special side effects subse-
quent to a write.
In order to define CSRs, their bit fields, their initial values and the effects of read, write or other transac-
tions, the format illustrated by Figure 4 is used.
14776-232 © ISO/IEC:2001(E)
definition
most significant least significant
unit-dependent vendor-dependent sig r why not
bus-depend
initial values
F3 zeros 1 0 0 0
16 31
read values
last write last update w 0 u u
last write
write effects
stored ignored s i i e
stored
Figure 4 – CSR specification example
The register definition contains the names of register fields. The names are intended to be descriptive, but
the fields are defined in the text; their function should not be inferred solely from their names. However,
the following field names have defined meanings.
Name Abbreviation Definition
bus-dependent bus-depend The meaning of the field is defined by the bus standard, in this case
ANSI/IEEE Std 1394
reserved r The field is reserved for future standardization (see definitions)
unit-dependent unit-depend The meaning of the field shall be defined by the organization respon-
sible for the unit architecture
Vendor-dependent vendor-depend The meaning of the field shall be defined by the node’s vendor
or v
CSRs shall assume initial values upon the restoration of power (a power reset) or upon a write to the
node’s RESET_START register (a command reset). If the power reset values differ from the command
reset values, they are separately and explicitly defined. Initial values for register fields may be described
as numeric constants or with one of the terms defined for the register definition. Values for register fields
subsequent to a reset may be described in the same terms or as defined below.
Name Abbreviation Definition
unchanged x The field retains whatever value it had just prior to the power reset,
bus reset or command reset.
In addition to numeric values for constant fields, the read values returned in response to a quadlet read
transaction may be specified by the terms below.
14776-232 © ISO/IEC:2001(E)
Name Abbreviation Definition
last write w The value of the field shall be either the initial value or, if a write or
lock transaction addressed to the register has successfully com-
pleted, the value most recently stored in the field.
last update u The value of the field shall be that most recently updated by the node
hardware or software. An updated field value may be the result of a
write effect to the same register address, a different register address
or some other change of condition within the node.
The effects of data written to the register are specified by the terms below.
Name Abbreviation Definition
effect e The value of the data written to the field may have an effect on the
node’s state, but the effect may not be immediately visible by a read
of the same register. The effect may be visible in another register or
may not be visible at all.
ignored i The value of the data written to the field shall be ignored; it shall
have no effect on the node’s state.
stored s The value of the data written to the field shall be immediately visible
by a read of the same register; it may also have other effects on the
node’s state.
Reserved fields within a register shall be explicitly described with respect to initial values, read values and
write effects. Initial values and read values shall be zero while write effects shall be ignored. CSRs that
are not implemented, either because they are optional or they fall within a reserved address space, shall
abide by these same conventions if a successful completion response is returned for a read, write or lock
request.
3.2.4 State machines
All state machines in this standard are defined in the style illustrated by Figure 5.
______
4)
For clarity, read values for a field in a register that accepts lock transactions may be described as last successful
lock rather than last write. However, the abbreviation in both cases remains w. Similar liberties may be taken with
the use of conditionally stored in place of stored when the action occurs as the result of a lock transaction, but the
corresponding one-letter abbreviation, s, is also unchanged.
14776-232 © ISO/IEC:2001(E)
state label
S0: State zero S1: State one
Actions started on entry to S0 Actions started on entry to S1
Condition for transition from S1 to S0
S1:S0
Action taken on this transition
Condition for transition fro
...