T13/1612DT revision 0

Working T13Draft 1612DT

Revision 0.0December 13, 2004

ATA/ATAPI AV Streaming Command Set Usage Guidelines

This is an internal working document of T13, a Technical Committee of Accredited Standards Committee INCITS. The T13 Technical Committee may modify the contents. This document is made available for review and comment only.

Permission is granted to members of INCITS, its technical committees, and their associated task groups to reproduce this document for the purposes of INCITS standardization activities without further permission, provided this notice is included. All other rights are reserved. Any commercial or for-profit replication or republication is prohibited.

T13 Technical Editor:Dan ColegroveHitachi Global Storage Technologies2505 Anthem Village Dr. Suite E-221Henderson NV, 89052 USA Tel: 408-230-4284 Fax: 408-230-7955Email: daniel.colegrove@hitachigst.com

D1612r0

Other Points of Contact:

T13 Chair 13 VicechairDan ColegroveHitachi Global Storage Technologies2505 Anthem Village Dr. Suite E-221Henderson, NV 89052Tel: 702 614-6119Fax: 702 614-7955

INCITS SecretariatAdministrator Standards Processing1250 Eye Street, NW Suite 200Washington, DC 20005Tel: 202-737-8888Fax: 202-638-4922Email: INCITS@ITIC.ORG

T13 ReflectorInternet address for subscription to the T13 reflector: majordomo@t13.orgSend email to above account and include in BODY of text, on a line by itself the following:

"subscribe T13"Internet address for unsubscribing to the T13 reflector: majordomo@t13.orgSend email to above account and include in BODY of text, on a line by itself the following:

"unsubscribe T13"

Internet address for distribution via T13 reflector: forum@t13.org

T13 Web Site

http://www.t13.org

T13 Anonymous FTP Site

ftp.t13.org

T13 mailings

Global Engineering15 Inverness Way EastEnglewood, CO 80112-5704Tel: 303-792-2181 or 800-854-7179Fax: 303-792-2192

T13/1612DT revision 0DOCUMENT STATUS

Revision 0 – October 17, 2004Document created. Boilerplate lifted from the ATA Adapter Standard. Rough outline of technical report. Old AV model document appended. AV model text to be placed in correct location in future documents.

ANSI®

INCITS.***-xxxx

American National Standardfor Information Systems

ATA/ATAPI AV Streaming Command Set Usage Guidelines

SecretariatInformation Technology Industry Council

Approved mm dd yy

American National Standards Institute, Inc.

Abstract

This technical report describes techniques and guidelines for the use of the AV Command Set described in TC/T13 Project 1532D ATA/ATAPI-7.

T13/1510D 1612DT revision 0h10

AmericanNationalStandard

Approval of an American National Standard requires verification by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that effort be made towards their resolution.

The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards.

The American National Standards Institute does not develop standards and will in no circumstances give interpretation on any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard.

CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute.

Published byAmerican National Standards Institute11 West 42nd Street, New York, New York 10036

Copyright nnnn by American National Standards InstituteAll rights reserved.

ContentsIntroduction........................................................................................................................................................... vii

1 Scope.................................................................................................................................................................. 1

2 Normative References........................................................................................................................................ 12.1 Content Imported from Normative Standards...................................................................................................12.2 Industry Standard References......................................................................................................................... 13 Definitions, Abbreviations, and Conventions.......................................................................................................13.1 Definitions and Abbreviations........................................................................................................................... 13.2 Conventions..................................................................................................................................................... 14 Streaming Feature Set........................................................................................................................................ 54.1 Configure Stream............................................................................................................................................. 54.2 Read Stream.................................................................................................................................................... 54.3 Write Stream.................................................................................................................................................... 55 Read Log Extended Streaming Logs.................................................................................................................. 55.1 Set Features.................................................................................................................................................... 55.2 Flush Cache..................................................................................................................................................... 55.3 Read Command Behavior................................................................................................................................ 55.4 Write Command Behavior................................................................................................................................ 5

Page i

D1612r0

Tables

Table QQ.1 - Example A/V Data Transfer Rates...................................................................................................6

Figures

Figure 1 State diagram convention...................................................................................................................... 3Figure QQ.1 - Data Transfer Model for A/V............................................................................................................7Figure QQ.2- Representation Of Stream Data in Disk Data Flow..........................................................................8Figure QQ.3 - Possible Representation Of Video Frames Within An Element.......................................................9Figure QQ.4- Representation Of Stream Data in Disk Data Flow..........................................................................9Figure QQ.5 - Unaligned A/V Transfer Example..................................................................................................10Figure QQ.6 - EPG Data Transfer Example.........................................................................................................10

Page ii

T13/1510D 1612DT revision 0h10Annexes

Page iii

D1612r0

Foreword (This foreword is not part of American National Standard ***-****.)

This standard was developed by the ATA ad hoc working group of Accredited Standards Committee INCITS starting in 2001. This document includes annexes that are informative and are not considered part of the standard.

Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome. They should be sent to the INCITS Secretariat, Information Technology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC 20005-3922.

This standard was processed and approved for submittal to ANSI by Accredited Standards Committee on Information Processing Systems, INCITS. Committee approval of the standard does not necessarily imply that all committee members voted for approval. At the time it approved this standard, the INCITS Committee had the Karen Higginbottom, Chair

(Vacant), Vice-Chair

Monica Vago, Secretary

Organization Represented Name of RepresentativeAMP, Inc John Hill, Charles Brill (Alt.)Apple Computer David Michael, Jerry Kellenbenz (Alt.)AT&T Thomas Frost, Paul Bartoli (Alt.)Bull HN Information Systems, Inc. Patrick L. HarrisCompaq Computer Corporation Steven Heil, Seve Park (Alt.)

Eastman Kodak Michael NierHewlett-Packard Karen Higginbottom, Donald Loughry (Alt.)

Hitachi America, Ltd. John Neumann, Kei Yamashita (Alt.)

Hughes Aircraft CompanyHarold L. ZebrackIBM Corporation Ron Silletti, Joel Urman (Alt.)

Institute for Certification of Computer Professionals Kenneth M. Zemrowski, Tom Kurihara (Alt.)

Lucent Technologies, Inc. Herbert Bertine, Tom Rutt (Alt.)

National Communications Systems Dennis Bodson, Frack McClelland (Alt.)

National Institute of Standards and Technology Michael Hogan, Bruce K. Rosen (Alt.)

Panasonic Technologies, Inc.. Judson Hofmann, Terry J. Nelson (Alt.)

Share, Inc. David Thewlis, Gary Ainsworth (Alt.)Sony Electronics, Inc. Masataka Ogawa, Michael Deese (Alt.)

Storage Technology Corporation Joseph S. ZajaczkowskiSun Microsystems, Inc. Gary RobinsonSybase, Inc. Donald Deutsch, Andrew Eisenberg (Alt.)Texas Instruments, Inc. Clyde Camp, Fritz Whittington (Alt.)

Unisys Corporation Arnold F. Winkler, Stephen P. Oksala (Alt.)

U.S. Department of Defense/DISA Jerry L. Smith, C. J. Pasquariello (Alt.)

U.S. Department of Energy Carol Blackston, Bruce R. White (Alt.)

Xerox Corporation John B. Flannery, Jean Baroness (Alt.)

Subcommittee T13 on ATA Interfaces, that reviewed this standard, had the following members:

Pete McLean, Chairman

Dan Colegrove, Vice Chairman

ATA/ATAPI ad hoc Working Group, that developed this standard, had the following additional participants:

Page iv

T13/1510D 1612DT revision 0h10

Page v

D1612r0

IntroductionThis standard encompasses the following:

Clause 1 describes the scope.

Clause 2 provides normative references.

Clause 3 provides definitions, abbreviations, and conventions.

Clause 4

AMERICAN NATIONAL STANDARD NCITS.***-200x

American National Standardfor Information Systems -

Information Technology -ATA/ATAPI AV Streaming Command Set Usage Guidelines

1 ScopeThis technical report provides non-normative information on the use of the ATA/ATAPI-7 Streaming Command Set. The purpose of this technical report is to provide advice and recommendations for application developers working with the ATA/ATAPI Streaming Command Set

1 Normative References

1.1 Content Imported from Normative StandardsWhere material within this standard has been imported from another, normative standard, in whole or in part, it is done so for the sake of readability of this document and the normative source document is identified. The source standard has precedence where there is a difference of definition. References are listed in this section. Each reference has an abbreviated reference form, enclosed within braces '{}'. This abbreviation, braces included, is used in the body of this document. Where the reference cites a standard and working drafts, the cross-reference is to the standard that was current at the time when this document was written.

1.2 Industry Standard References 1.2.1 ANSI Information Technology – AT Attachment with Packet Interface (ATA/ATAPI-7)

Abbreviation: {ATA Standard}

Draft Standard: Information Technology - AT Attachment Interface with Packet Interface Extensions – 7 (ATA/ATAPI-7), TC/T13 1532D

2 Definitions, Abbreviations, and Conventions2.1 Definitions and Abbreviations

2.1.1 Placeholder

A place for a definition or abbreviation to go.

Page vi

T13/1510D 1612DT revision 0h102.1.2 Computer System:

A conventional personal computer system that does not use the AV Streaming command set. The term computer system is used when illustrating the difference in design and function of non-streaming computer systems with the design and function of AV systems.

2.1.3 AV System:

A system that uses the Streaming command set. 2.1.4 Stream:

A set of related data that are being read from or written to a disk drive above some minimum data rate.

2.2 Conventions2.2.1 Keywords

2.2.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 implemented.

2.2.1.2 mandatory: A keyword indicating items to be implemented as defined by this standard.2.2.1.3 may: A keyword that indicates flexibility of choice with no implied preference.2.2.1.4 obsolete: A keyword used to describe bits, bytes, fields, and code values that no longer have consistent

meaning or functionality from one implementation to another. However, some degree of functionality may be required for items designated as “obsolete” to provide for backward compatibility. An obsolete bit, byte, field, or command shall never be reclaimed for any other use in any future standard.

Obsolete commands should not be used by the host. Commands defined as obsolete in previous standards may be command aborted by devices conforming to this standard. However, if a device does not command abort an obsolete command, the minimum that is required by the device in response to the command is command completion.

2.2.1.5 optional: A keyword that describes features that are not required by this standard. However, if any optional feature defined by the standard is implemented, the feature shall be implemented in the way defined by the standard.

2.2.1.6 retired: A keyword indicating that the designated bits, bytes, fields, and code values that had been defined in previous standards are not defined in this standard and may be reclaimed for other uses in future standards. If retired bits, bytes, fields, or code values are utilized before they are reclaimed, they shall have the meaning or functionality as described in previous standards.

2.2.1.7 reserved: A keyword indicating reserved bits, bytes, words, fields, and code values that are set aside for future standardization. Their use and interpretation may be specified by future extensions to this or other standards. A reserved bit, byte, word, or field shall be set to zero, or in accordance with a future extension to this standard. The recipient shall not check reserved bits, bytes, words, or fields. Receipt of reserved code values in defined fields shall be treated as a command parameter error and reported by returning command aborted.

2.2.1.8 shall: A keyword indicating a mandatory requirement. Designers are required to implement all such mandatory requirements to ensure interoperability with other standard conformant products.

2.2.1.9 should: A keyword indicating flexibility of choice with a strongly preferred alternative. Equivalent to the phrase “it is recommended”.

2.2.2 Precedence

If there is a conflict among text, figures, and tables, the precedence shall be: tables, then figures, and then text.2.2.3 Names of Registers, Words, Bytes, Bits, Etcetera

The names of registers, words, bytes, bits, and modes begin with uppercase letters. In addition, register names are prefixed with the acronyms PCI, ADMA, or ATA, to indicate which of these register sets they belong to. For example: ATA Status Register, Status Word, Bytes 0-3, and Error Bit.

The names of fields within registers or data structures begin with a lower-case letter followed by upper case letters. The lower case letter allows the reader to identify the structure or register where the field is defined. For example: “aGO” is bit field defined in the ADMA Control Register

Page i

D1612r02.2.4 Numbers

Numbers are decimal, unless specified otherwise.

Hexadecimal numbers are shown as a string of digits, 0 through 9 or A through F, followed by 'h': e.g., '1AB7h.'

Binary numbers are shown as a string of digits, 0 or 1, followed by 'b': e.g., '10110111b'.'2.2.5 Nomenclature

b - bitsB - BytesG – Giga (109)M – Mega (106)n – nano (10-9)m – milli (10-3)s - second

2.2.6 State Diagram Conventions

Figure 1 State diagram convention

Each state is identified by a state designator and a state name. The state designator is unique among all states in all state diagrams in this document. The state designator consists of a set of letters that are capitalized in the title of the figure containing the state diagram followed by a unique number. The state name is a brief description of the primary action taken during the state, and the same state name may appear in other state diagrams. If the same primary function occurs in other states in the same state diagram, they are designated with a unique letter at the end of the name. Additional actions may be taken while in a state and these actions are described in the state description text.

In device command protocol state diagrams, the state of bits and signals that change state during the execution of this state diagram are shown under the state designator:state_name, and a table is included that shows the state of all bits and signals throughout the state diagram as follows:

v = bit value changes.1 = bit set to one.0 = bit cleared to zero.x = bit is don’t care.V = signal changes.A = signal is asserted.N = signal is negated.R = signal is released.X = signal is don’t care.

Each transition is identified by a transition label and a transition condition. The transition label consists of the state designator of the state from which the transition is being made followed by the state designator of the state

Page ii

T13/1510D 1612DT revision 0h10to which the transition is being made. In some cases, the transition to enter or exit a state diagram may come from or go to a number of state diagrams, depending on the command being executed. In this case, the state designator is labeled xx. The transition condition is a brief description of the event or condition that causes the transition to occur and may include a transition action, indicated in italics, that is taken when the transition occurs. This action is described fully in the transition description text.

Upon entry to a state, all actions to be executed in that state are executed. If a state is re-entered from itself, all actions to be executed in the state are executed again.

It is assumed that all actions defined in a state are executed within the state and that transitions from state to state are instantaneous.

Page iii

D1612r0

3 Disk Drives in Audio / Video ApplicationsThe ATA/ATAPI disk drive interface standard was originally developed to meet the needs of personal computer systems. ATA/ATAPI-7 adds the new Streaming Feature Set, a group of commands and settings that are useful for audio and video applications.

3.1 AV Usage model The design of the Streaming Command Set was based on the requirements of digital video recording devices. Unlike video tape recording devices which record or play a single video signal, digital video recorders which use disk drives may record or play several video signals simultaneously. Like tape drives, disk drives can only read or record in a single location on the medium at any one time. The ability to record or play multiple simultaneous video streams from a disk drive results from three factors, that digital video data is produced or consumed at a steady rate, that digital video can be stored in buffer memory, and the disk drive’s ability to move quickly from one point on the medium to another. These system parameters are known as isochronisity, buffering and latency.

IsochronisityIn video and audio systems the data is produced at a maximum rate and consumed at some minimum rate. A rate is some quantity over time. In the case of AV it is units of data over time, such as 10 Megabytes/Second. Applications that require a certain amount of data over time are called isochronous. A simple model of an AV application may assume that the AV data is very isochronous with almost exactly the same amount of data being delivered in any unit of time. Unfortunately that is almost never the case due to data compression techniques. Video of a solid black image may require a very low data rate while a highly chaotic image like snow falling requires a high data rate. The maximum data rate during recording and the minimum during playback are what is of interest to the AV system designer.

Audio and Video, when recorded or played back, are isochronous data flows. The data are converted to sound or images at a some maximum rate. Disk drives are mechanical devices that have latencies, time delays, which are defined but pseudo-random. To maintain a uniform flow of data from a drive there must be a mechanism to accommodate and control drive latencies so that the flow not interrupted. Buffer memory in both the host system and the drive are used to manage normal drive latencies. Error latency is managed by setting a time limit policy for command execution and a policy for data that is unavailable or incorrect due to drive error.

3.2 Normal Latencies

Disk drives require some time to seek to the correct track and then wait for disk rotation to bring the data under the head for reading or writing. This delay, known as latency, can broken down into two categories, normal latency and error latency. Normal latency is the typical time needed to seek to a track and to rotate the media. Error latency occurs when the data is not read correctly and the drive must make another attempt to read the data. Disk drives may make many attempts to recover the data, creating a long error latency. The normal latency is described in the Streaming Command Set Identify Device data and in the Streaming Performance Log. The error latency is managed using the time limit value in streaming commands.

Latency is time delay. There are many causes of delays during the execution of a command. When a command is issued to an ATA drive, by writing the command register, there are a series of delay. For a read command the delays are:1. Command Processing 2. Seeking begins3. Seeking ends, including the delay to settle on track. 4. Wait for Rotational delay5. Transfer of data to drive buffer6a. Intra data seeks or head switches.

Page iv

T13/1510D 1612DT revision 0h106b. Wait for host to respond to the drive interrupt indicating data is to be transferred7. Transfer of the data8. Ending status read

3.2.1 Seek

Seek latency may also be reduced by grouping the AV data on the same region of the disk. This is an application and file system function.

3.2.2 Rotation

(describe rotation, fixed at some rpm)3.2.3 Interrupt

(describe delays due to waiting for host/drive interface delays such as interrupt latency)

3.3 BufferingWhile AV data is isochronous disk drives are not. When a drive is moving the read/write heads to the correct track, or waiting for the correct location to rotate under the head there is no data transfer to or from the media. When the heads are over the target location the data transfer is fast and uniform. There is no option to stop data transfer or change the rate when as the media is going by the head. Disk drives use buffer memory to be sure they have sufficient data to write and a place to put data that has been read. AV systems need additional buffer memory to smooth out the non-isochronous nature of disk drives.

3.4 Error LatenciesThe primary function of the Streaming Command Set is to allow management of error latency. Error latency occurs when correct data is not read from the disk within one revolution time after the head settles on track. The data went past the head and was not read or the data was not correctable by the error correcting code. Drives have error recovery procedures which attempt repeatedly to read the data. In computer systems this is the preferred behavior because it maximizes the likelihood that known good data will be read. In AV systems this may not be the preferred behavior because the time lost trying to recover perfect data may result in a larger problem than having partial data or no data returned.

Control the time allowed to recover from error Allow partially correct data to be returned

Unfortunately, the ATA protocol does not have a fast command abort capability. Once a command has started the only reliable way for the host to stop the command processing is to issue a soft reset. The soft reset itself is of a long and unpredictable duration. The Streaming Command Set uses a command completion timer to limit the time a streaming command is allowed to take. The command completion timer may be set using the Configure Stream command or in individual Read Stream DMA EXT and Write Stream DMA EXT commands. The data quality level may also be set during Streaming read and write commands using the Read Continous and Write Continusous bits. When a command is executed with the Continuous bit set the

3.4.1 Multiple AV Data Streams

AV applications may support multiple simultaneous isochronus data streams. The ability of a drive to support multiple streams is a function of the normal drive latencies and the policy for management of error latencies.

4 Using the Streaming Feature SetAudio/Video applications have different requirements for disk drives than do computer applications.

Computers need maximum average performance but can tolerate long delays for disk drive error recovery. Audio/Video applications require uniform performance. Long delays are a problem, while excess speed is not beneficial.

During normal operations the behavior of disk drives is nearly uniform. To read or write data the drive seeks to the correct track, waits for the location to rotate under the head, and read or writes. The read data is automatically checked for error using the ECC or error correcting code appended to each block of data. During

Page v

D1612r0normal operations the seek time depends on the distance, number of tracks, and the time to settle on the track. The rotation time is fixed, but since a seek may finish settling anywhere on the track there is an average rotation delay of one half a revolution. The variability is from nearly zero to one revolution.

During normal operations there is only one variable that can be adjusted for improved A/V function: seek time. For some A/V applications a disk drive may have more performance than is needed. A drive may have a low noise mode, which is essentially a slower seek mode. The rotation rate can not be adjusted, however the rotation speed control may be relaxed when the drive is idle.

The Streaming Performance Log provides a table describing a drive’s normal performance. There is a seek table which allows an A/V system to estimate the length of a seek, and a zone map table which describes the number of sectors per track and the data transfer rate for each zone. To maximize drive capacity the surface is divided into multiple zones with more data sectors per track as the zones go from the inner diameter to the outer diameter of the disk.

The Delayed Sector Log contains a list of sectors that take additional time to access. Usualy these are relocated sectors. When a drive detects a defect in a sector it marks the original location as being defective and substitutes a relocated sector. The relocated sector may be on a different track from the original location . This causes a seek to the relocated sector, a rotation delay and a seek back to the original location, a considerable delay. A/V systems may need to avoid using the delayed sectors because they add delay, even during normal operations.

4.1 Streaming Performance Log Reports Drive Seek time, Rotation Rate and Data Rate Used When an Unknown Drive is Attached to an AV System

The Streaming Command Set added the Streaming Performance Log to the Read Log Extended command. The Streaming Performance Log returns data that allows a host system to calculate the nominal time required to execute a Read Stream or Write stream command. Computer systems are insensitive to drive performance. A slow drive will work on a computer system. AV Streaming systems may not work if a drive’s nominal performance is too slow. An AV Streaming system may wish to adjust to having a fast drive by allowing more streams or allowing a higher data rate per stream. In order for a host system to make optimum use of an arbitrary drive the Streaming Performance Log was developed to characterizes drive streaming performance characteristics. This data is only useful in AV systems that allow field replacement of drives using drives that are not supplied by the AV system manufacturer. The Streaming Performance Log data is used to tune AV system behavior when an unknown type of disk drive is attached. For systems that do not allow attachment of unknown drives the preferred course is to specify the performance requirements for the drives used and then to test the drives to verify that they perform as required while developing the AV streaming system. The data in the streaming performance log is intended to be biased toward understatement of the drive performance. AV streaming systems may depend on achieving the stated performance during drive operation over the drive’s full temperature and voltage operating ranges, and over the population of drives. The data is the minimum performance the drive will supply. A drive operating at nominal conditions may exceed Streaming Performance Log performance.

4.1.1 Using the Streaming Performance Log4.1.1.1 The Streaming Performance Granularity Value (G)The Streaming Performance Granularity value is found in Identify Data words 99:98. The granularity value is a scaling factor to extend the range of the data in the streaming performance log. For examples in this report uses the symbol G for the Streaming Performance Granularity Value. 4.1.1.2 How Data is Arranged in the LogThe Streaming Performance Log is Read Log EXT command log 20h. The length of the log is found in the Log Directory, Read Log EXT command log 00h. The format of the Streaming Performance Log is specified in ATA/ATAPI-7 section 6.31.8.6.The log starts with four table descriptor words. The first word is the Stream Performance Parameters log version, which is 0001h for the ATA/ATAPI-7 version of the log. The second word is the size of the Sector Time Array. The third is the size of the Position Array. The fourth is the size of the Access Time Array.

Page vi

T13/1510D 1612DT revision 0h10Streaming Performance Array Example

Byte Data Notes0-1 1 Streaming Performance 2-3 160 Sector Time Array Size4-5 Position Array Size6-7 Access Time Array Size

8-167 See Below Sector Time ArrayPosition ArrayAccess Time Array

4.1.1.3 The Sector Time ArrayThe sector time array describes how fast data is transferred once the drive has positioned the head over the data track. An (array datum)*(G/65536) is the time required to read one sector. For hard disk drives the data area is divided into zones. Zones near the inner diameter of the disks have fewer sectors. Zones near the outer diameter have more sectors. The example shows 10 zones.

Sector Time Array ExampleByte Data Notes8-13 0 Start of Zone 0 is LBA 014-15 970 970*(512/65536)= 7.578 Microseconds/Sector 16-21 999,999,999 End of Zone 0 is LBA 999,999,99922-23 970 970*(512/65536)= 7.578 Microseconds/Sector 24-29 1,000,000,000 Start of Zone 0 is LBA 1,000,000,00030-31 821 821*(512/65536)= 6.414 Microseconds/Sector 32-33 1,999,999,999 Start of Zone 0 is LBA 1,999,999,99934-35 821 821*(512/65536)= 6.414 Microseconds/Sector

. . .152-157 9,000,000,000 Start of Zone 9 is LBA 9,000,000,000158-159 368 368*(512/65536)= 2.875 Microseconds/Sector160-165 9,999,999,999 End of Zone 9 is LBA 9,999,999,999166-167 368 368*(512/65536)= 2.875 Microseconds/Sector

4.1.1.4 The Position ArrayStreaming Performance Array Example

Byte Data Notes0-1 1 Streaming Performance 2-3 160 Sector Time Array Size4-5 Position Array Size6-7 Access Time Array Size

8-167 See Below Sector Time ArrayPosition ArrayAccess Time Array

4.1.1.5 The Access Time Array(insert access time array example)4.1.1.6 Dynamic Changes to the LogThe streaming performance log data may be affected by drive settings. 42h C2h 43h

Page vii

D1612r04.1.1.6.1 Streaming Performance Log

Table 1, Table 2, Table 3, and Table 4 define the format of the log returned by the READ LOG EXT command, when the LBA Low register is 20h. This data set is referred to as the Streaming Performance Parameters log, the length of which (in sectors) is statically indicated in READ LOG EXT log address 00h (Log Directory).

The contents of Streaming Performance Parameters Log may be affected by the host issuing a SET FEATURES subcommand 42h, C2h, or 43h and may also affect the Delayed LBA log.

NOTE The host should check the content of the Streaming Performance Parameters log and the Delayed LBA log after issuing SET FEATURES subcommands 42h, 43h, or C2h.

The host should base its calculations on the larger of its Typical Host Interface Sector Time and the device reported Sector Time values, and on the sum of the device reported Access Time values and any additional latency that only the host is aware of (e.g., host command overhead, etc).

Table 1 - Streaming Performance Parameters Log 1Error! Bookmark not defined.Bytes Description

2 Stream Performance Parameters log version2 K, Number of Regions in Sector Time Array2 L, Number of Positions in Position Array2 M, Number of Position-differences in Access Time Array

K*8 Sector Time Array (See Table 2)L*8 Position Array (See Table 3)M*4 Access Time Array (See Table 4)

Last sector remainder Reserved

Table 2 - Sector Time Array Entry (Linearly Interpolated) 2Error! Bookmark not defined.Byte Descriptions

n-(n+5) Logical Block Address of reference location (LBA(7:0)…LBA(47:40)) (n+6)-(n+7) (IDENTIFY DEVICE data words (99:98))/65536 time units per sector at

the reference location

Table 3 - Position Array Entry (Linearly Interpolated) 3Error! Bookmark not defined.Byte Descriptions

n-(n+5) Logical Block Address of start of region (LBA(7:0)…LBA(47:40))(n+6)-(n+7) Position number in the range 0…32767

Table 4 - Access Time Array Entry (Linearly Interpolated) 4Error! Bookmark not defined.Byte Descriptions

n-(n+1) Difference in position from last stream access to new stream access(n+2)-(n+3) Time that may be required to begin access at new stream access

position, in (IDENTIFY DEVICE data words (89:88))/256 time units.

4.2 Identify Data Idenfity Data words 95, 96,97,98:99, 104

4.2.1 Word 95 Stream Minimum Request Size

For disk drives and other storage devices, such as flash media, it may be more efficient to access the media in units larger than one logical block. Word 95 indicates to the host the most efficient address size. For example, a flash device may have internal block boundaries every 16K bytes. For maximum speed the data should be accessed in 16K byte units aligned every 16K bytes. For a block size of 16K bytes Word 95 would be set to 5 (512*25=16,384).

Page viii

T13/1510D 1612DT revision 0h104.2.2 Word 96 Streaming Transfer Time DMA

Word 96 reports the time to transfer a sector of data over the ATA interface using the DMA protocol. This differs from the sector time data reported in the Streaming Performance log as it is the time required to transfer data from the disk drive buffer to the host. The Streaming Performance Log provides the time required to transfer data from the media to the disk drive buffer. The data in word 96 is dependant on the current DMA mode setting. Word 96 is also dependant on Set Features function 43h data. Set Features 43h is used to indicate to the drive that the host system can not transfer data at the speed indicated by the DMA mode setting. If Set Features function 43h has been used to set the host data transfer rate below the DMA mode transfer rate then the value transferred for DMA in the Set Featues 43h is returned in word 96. See 4.3 Unfortunately, the data in word 96 is not usefull. The actual data transfer rate from the drive to the host system is controlled by the host for all DMA protocols except Ultra DMA reads. There is no practical reason to read the transfer rate from the drive. AV systems should be aware of the drive’s media to buffer data rate, returned in the Streaming Performance long, and set an interface data transfer rate high higher than the media to buffer data rate. Failure to transfer data to the drive above the media data rate will result in missed revolutions and significantly degraded performance.

4.2.3 Word 104 Streaming Transfer Time PIO

Word 104 reports the time to transfer a sector of data over the ATA interface using the PIO protocol. This differs from the sector time data reported in the Streaming Performance log as it is the time required to transfer data from the disk drive buffer to the host. The Streaming Performance Log provides the time required to transfer data from the media to the disk drive buffer. The data in word 104 is dependant on the current PIO mode setting. Word 104 is also dependant on Set Features function 43h data. Set Features 43h is used to indicate to the drive that the host system can not transfer data at the speed indicated by the PIO mode setting. If Set Features function 43h has been used to set the host data transfer rate below the PIO mode transfer rate then the value transferred for DMA in the Set Featues 43h is returned in word 104. See 4.3 Unfortunately, the data in word 104 is not usefull. The actual data transfer rate from the drive to the host system is controlled by the host for all PIO protocols. There is no practical reason to read the transfer rate from the drive. AV systems should be aware of the drive’s media to buffer data rate, returned in the Streaming Performance long, and set an interface data transfer rate high higher than the media to buffer data rate. Failure to transfer data to the drive above the media data rate will result in missed revolutions and significantly degraded performance.

4.2.4 Word 97 Streaming Access Latency

Word 97 indicates the maximum normal seek and rotation latency, a full stroke seek, settle time, plus a rotation time. More performance data is available in the Streaming Performance Log.

4.2.5 Word 99:98 Streaming Performance Granularity

The Streaming Command Set was designed to be extensible over time. The Streaming Performance Granularity is a scaling factor used to extend the range data values in Identify Data and in the Streaming Performance Log. The unit is microseconds. See 4.1

4.3 Set Features4.3.1 Streaming Command Set Feature

Set Features Function 43h 4.3.2 Set Features That Affect Streaming Command Set Function

4.4 Configure Stream4.4.1 Stream Numbers

(describe stream numbers and how they are used)4.4.2 Buffer Management

(describe how using configure stream enables a drive to buffer more efficiently)

Page ix

D1612r04.5 Read Stream

Register 7 6 5 4 3 2 1 0Features Current URG RC NS HSE r Stream ID

Previous Command Completion Time Limit (7:0)Sector Count Current Sector count (7:0)

Previous Sector count (15:8)LBA Low Current LBA (7:0)

Previous LBA (31:24)LBA Mid Current LBA (15:8)

Previous LBA (39:32)LBA High Current LBA (23:16)

Previous LBA (47:40)Device obs LBA obs DEV Reserved

Command 2AhNOTE The value indicated as Current is the value most recently written to the register. The value

indicated as Previous is the value that was in the register before the most recent write to the register.

4.5.1 Read Continuous Bit (RC)

Read Continuous allows a drive to return data with known bad data. The number of sectors of data requested should be transferred before the command completion time limit has been reached. The time required to transfer data to the host is not under disk drive control so achieving the goal of transferring the requested amount of data before the time limit requires an estimate of the time required to transfer enough null data. The drive has to track how much data remains to be transferred and compare that to the amount of time left. The drive has to start transferring null data before the command completion time limit has expired to insure that the full count of data is transferred before the time limit expires.

4.5.2 Non-Sequential Bit (NS)

Non-Sequential is advice to the drive for drive buffer management. Non-Sequential indicates that the next data to be read in the stream is not the next contiguous logical block addresses. Drives may buffer read look ahead data on a stream basis, assuming that the next data to be read in a stream is contiguous. When a new command is not presented to the drive immediately after a read command has completed the drive has time to speculatively read data into the drive buffer. This read look ahead data is kept until the next read command for the stream. If the Non Sequential bit is set there is no need to buffer the data as the next data to be read will not be contiguous with the current read command.

Since there is little to be gained by not doing read look ahead when the drive is idle it may not be possible to detect the effect of the NS bit.

4.5.3 Urgent Bit (URG)

In the ATA specification the Urgent bit indicates that the drive should complete the command in the minimum possible time. When Read Continuous is set to 0 data erroneous data shall not be transferred so the minimum possible time is the typical drive behavior, therefore the Urgent bit has no effect. When Read Continuous is set to 1 and the Urgent bit is set to one erroneous data may be transferred so the minimum time1 to perform the command is one pass over the data with no retries.

The interaction between the Urgent bit and automatic acoustic management has not been defined. It is possible to conclude from the standard definition that setting the Urgent bit could disable slow seeking for acoustic management for the duration of the command but this is not explicitly stated.

The usefulness of the Urgent bit is not clear. The idea was to have an emergency method of getting data from the drive when a buffer is running low. It is not clear how drives can do anything faster when the Urgent bit is on. Drives accomplish commands in the minimum time under normal circumstances. It is only during error conditions that the Urgent bit would be of use and then only to return known bad data. Use of the Urgent bit is not recommended. The Urgent bit may be obsoleted in future standards.

1 Since there is no data quality requirement with RC=1 the Urgent bit definition could be read to mean don’t even seek to the data or try to read it, just transfer all 0’s, but that would make the Urgent bit totally useless.

Page x

T13/1510D 1612DT revision 0h10

4.5.4 Handle Stream Error Bit (HSE)

The purpose of the Handle Stream Error (HSE) bit is to allow full depth error recovery to be interleaved between other streams. When the HSE bit is set error recovery re-starts where it left off on the last command to the stream ID. This requires drives to remember the error depth when a command times out during error recovery.

4.5.5 Command Completion Time Limit4.5.6 Interactions between Read Stream command bits

4.6 Write Stream 4.6.1 Write Continuous4.6.2 Non-Sequential Bit4.6.3 Urgent Bit4.6.4 Flush to Disk Bit4.6.5 Handle Stream Error Bit4.6.6 Interactions between Write Stream command bits

4.7 Streaming Error Logs Log Description

Using the logs

5 – Compatibility Mode Standard I/O Register Addresses6 7 8 9 10

PCI-Native Mode

This mode is only applicable to adapters bridging to the PCI bus. In this mode the control of the transfer is through the ATA Command and Control Block Registers and registers in the adapter. The addresses of the Command or Control block are defined in the Base Address Register (BAR) of the adapter and are defined by the Host software. There is only one Host interrupt line for all the channels attached to an adapter. There is no restriction on the number of adapters there can be in the system.

ADMA Mode

In this mode the ATA Command and Control Block registers are not accessible to the Host. Control is exercised through a data structure held in host memory and adapter registers.

ISA Bus Adapter

This type of adapter is commonly called a paddle card for use in PC compatible systems. The function of the adapter is to decode the I/O addresses appropriate to the channels it controls.

Mode of Operation

Only operates in Compatibility Mode.

Detection

Page xi

D1612r0There is no standard method to detect the presence of this type of adapter. Software may be able to detect the presence of ATA drives by examining the ATA registers at the standard I/O addresses and thereby infer the presence of an adapter.

Adapter Set Up

There is no standard method used to set up these adapters. In most cases the I/O address banks are set by hard jumpers or by vendor specific registers.

ATA Bus Timings

ISA timings. No programmable timing is available.

Electrical and Physical

The electrical and physical specifications of the ATA bus are defined in the {ATA Standard}; the ISA bus characteristics are defined in the {ISA Spec}.

Registers

The compatibility register set shall be implemented.

PCI Compatibility and PCI-Native Mode Bus Master Adapters

PCI Adapters conforming to this standard may operate in Compatibility or Native-PCI Mode. Some adapters can be configured to operate in either mode; some are fixed to one of the modes. The mode configuration may be determined from the PCI Configuration registers.

Mode of Operation

Compatibility Mode

Adapters operating in Compatibility Mode support two channels conforming to the Primary and Secondary channel address and have a separate IRQ for each channel.

PCI-Native Mode

Adapters operating in Compatibility Mode may support one or two channels.

Detection

The Class Code fields determine the capabilities.

Adapter Set Up

The Class Code fields determine the capabilities of an adapter and may be used to configure the channels to Compatibility or PCI-Native mode. The PCI BARs may be used to configure and determine the I/O addresses to use to access the ATA and adapter registers.

ATA Bus Timings

Determination of the ATA PIO timings, DMA protocols and DMA timings supported is vendor specific. Consequently configuring these attributes is vendor specific.

Electrical and Physical

The electrical and physical specifications of the ATA bus are defined in the {ATA Standard}; the PCI bus characteristics are defined in the {PCI SPEC} specification.

PCI Registers

The PCI Adapter implements a subset of the PCI standard type 00h configuration header register set. All registers have the standard meaning as defined in the PCI Specification, Issue 2.2. The registers with specific meanings with respect to this standard are defined below. Register contents that are otherwise defined in the PCI standard are indicates as “PCI”. Fields marked 'reserved' are all zeros and read only.

Table

Page xii

T13/1510D 1612DT revision 0h10

PCI Class Code

Address Offset 09h

Size 24 bits

Table

Programming Interface Code

– ATA Bus Master Register Offsets

ATA Bus Master Command Register

Register Name: ATA Bus Master Command Register

Page xiii

D1612r0Address Offset: Primary Channel: Base + 00h

Secondary Channel: Base + 08h (for adapters that do not support this channel these registers shall return zero when read).

Default Value: 00h

Attribute: Read / Write

Size: 8 bits

– ATA Bus Master Command Register

Adapter Bus Master Status Register

Register Name: Bus Master ATA Status Register

Address Offset: Primary Channel: Base + 02h

Secondary Channel: Base + 0Ah (for adapters that do not support this channel these registers shall return zero when read).

Default Value: 00h

Attribute: Read/Write Clear

Size: 8 bits

– Bus Master ATA Status Register

Physical Region Descriptor (PRD) Table Pointer Register

Register Name: Descriptor Table Pointer Register

Address Offset: Primary Channel: Base + 04h

Secondary Channel: Base + 0Ch (for adapters that do not support this channel these registers shall return zero when read).

Default Value: 00000000h

Attribute: Read / Write

Size: 32 bits

– PRD Table Pointer Register

Page xiv

T13/1510D 1612DT revision 0h10

The PRD Table shall be Dword aligned. The Descriptor Table shall not cross a 65,536 (64KB) boundary in host memory.

Interrupt Line Considerations

When a channel is in Compatibility Mode the IRQ used by the channel shall be the compatibility IRQ. PCI interrupt lines shall not be affected by that channel's interrupt. Conversely, when the channel is in PCI-native mode the interrupt signals from both channels shall be connected to the appropriate interrupt pin number (INTA). Compatibility IRQs shall not be affected and if connected shall be released.

Connections of channel interrupt signals to the compatibility IRQs should be released until the adapter is enabled via the PCI Command register in PCI Configuration Space. The adapter is enabled when a one is written to the I/O enable bit (bit 0) in the Command register.

Error Conditions

If the adapter encounters an error while doing the bus master transfers it shall stop the transfer (i.e. reset the Active bit in the adapter Bus Master Command register) and set the Error bit in the adapter Bus Master Status register. The adapter does not generate an interrupt when this happens. The host software may use device or adapter specific information (e.g.; PCI Configuration Space Status register) to determine what caused the error. In any event the adapter should terminate any DMA burst in progress compliant with the ATA protocol being used. If the UDMA protocol is being used there may be a CRC error to report. The ATA device may be in an indeterminate state.

Automatic Direct Memory Access (ADMA) Adaptors - General Description

Background

The performance of ATA devices has increased dramatically over time, including the introduction of the Overlapped and Queued Feature Sets. However, systems using these faster devices have not shown all of the expected benefits. This limited performance improvement is a consequence of the demands the PCI compatibility and PCI-native mode bus master adapters places on the resources of the host. The problem is amplified by the design of the standard ATA host software used in some operating systems. This software effectively treats ATA transfers as a single-threaded entity, with correspondingly long latencies to fully service the interrupts. The Automatic DMA (ADMA) engine is designed to address these problems and add features that make it, and ATA devices, suitable for true multi-threading applications. This host adapter shall not support single or multiword DMA.

The ADMA Engine

The objective of the ADMA design is to drastically increase the performance of systems that use ATA devices.

To fully optimize the system throughput, the ADMA engine implements a command chaining technique to de-couple the host command sequence from the channel execution. This decoupling is accomplished by having the traditional host software-to-device I/O negotiation executed in hardware. This allows true multitasking and the ability to effectively exploit the Overlapped and Queued Feature Sets.

The ADMA engine works in two modes, termed ATA Register

Page xv

D1612r0

Capability ID

The capability ID indicates that the ADMA supports the {PCI PMS}.

Pointer to Next Capability

The next capability points to the next capability; 00h indicates the end of the linked list of capabilities.

Power Management Capability

Table

Power Management State Control Bits:

The power management states D0, D2 and D3 are defined in the PCI Power Management Specification.

Table

ADMA CPB Search Count Register (CCNT)

Address offset, Channel X: Base + 84h

Address offset, Channel Y: Base + A4h (If the device does not support channel this register shall be read only and cleared to zero).

Default value 0000h

Page xvi

T13/1510D 1612DT revision 0h10Attribute Read/Write

Size 16 bits

The purpose of this register is to limit the number of CPB’s scanned by the ADMA. This prevents the ADMA from requiring the PCI bus when there are no valid CPB’s. The ADMA CPB Search Count Register holds a value that is copied into the Internal Down-Counter each time either a write occurs to ADMCTL with the ADMA aGO Bit set or the ADMA reads a CPB with the cVLD Bit set and the cDONE Bit clear. The down-counter decrements each time the ADMA reads a CPB with the cVLD Bit clear, cREL set to one or the cDONE Bit set to one. When the down counter reaches zero, the ADMA sets aDONE and transitions to the IDLE state. The value loaded into this register is normally (but not necessarily) related to the number of CPBs in the chain. This value shall be greater than zero.

ADMA Current CPB Address (CCPB)

The ADMA Current CPB Address Register points to the address of the CPB currently being processed. It is loaded by the ADMA whenever a CPB is read or, in the case of queued operation, the CPB Lookup Table is read.

Address offset, Channel X: Base + 88h

Address offset, Channel Y: Base + A8h (If the device does not support channel this register shall be read only and cleared to zero).

Default value 00000000h

Attribute Read Only

Size 32 bits

ADMA Next CPB Address (NCPB)

Address offset, Channel X: Base + 8Ch

Address offset, Channel Y: Base + ACh (If the device does not support channel this register shall be read only and cleared to zero).

Default value 00000000h

Attribute Read/Write

Size 32 bits

The ADMA Next CPB Address Register is initialized by the host to point to the first CPB in a chain that the host has constructed in host memory. The address shall be a

Page xvii

D1612r0

Response Flags (Byte 0)

These flags are written by the ADMA during the processing of the CPB. Bit zero (cDONE) shall be set to one by the host when preparing the CPB. The host shall clear the byte to zero to indicate to the ADMA that the CPB is valid and ready to be processed. The Response Flags are in a byte by themselves, so that the ADMA does not have to do a read/modify/write operation.

cDONE – ATA Command Complete Flag (Bit 0)

This flag shall be set to one by the ADMA hardware when it has completed processing the command in this CPB entry. It is used by the ADMA to prevent processing the CPB again on subsequent passes around the CPB chain. When set, the host has control of the CPB.

The host sets cDONE to one when initializing a CPB in the CPB chain. The host first sets cVLD to one and then clears cDONE to zero to indicate to the ADMA that the CPB contains valid command information. Thereafter, with the exception of cVLD, the host shall not change anything in the CPB until cDONE is set to one by the ADMA. The host can then write new command information to the CPB, set cVLD to one and, finally, clear cDONE to zero. See – PCI Configuration Registers

Page xviii

T13/1510D 1612DT revision 0h10

10.1

Page xix

D1612r0Material from AV model document (d99135)

Annex QQ(informative)

Streaming Model And Definitions

QQ.1 A/V OverviewA/V data has a time based orientation. Delivery of A/V data must be within certain time constraints or it becomes valueless. For example, late delivery of data for a new video frame during a movie playback will cause visible artifacts such as skipping, audio noise, or corruption of the video frame. This time orientation differs from non-streaming hard drive applications where data delivery may be delayed without visible results. In typical hard drive applications the quality of data is of paramount importance rather than the time of delivery. Therefore, sophisticated error recovery algorithms implemented in non-streaming application drives provide the means to ensure the quality of the data.While the quality of A/V data is not insignificant it is of secondary importance to the time of the data delivery. Good A/V data delivered too late is generally equal in relevance to poor data delivered on time. The goal of the A/V capability for hard drives is to provide timely delivery of the best possible quality data. QQ.1.1Transfer Rates and CapacitiesData transfer rates varying depending on characteristics such as resolution, refresh rate, color depth, etc. Error: Reference source not found includes some examples of typical transfer rates. A/V applications can require large amounts of storage.Table QQ.5 - Example A/V Data Transfer Rates

Quality Avg. Mbits/s Gbytes/Hr.MP3 (CD Quality) .128 .0576MPEG2 (VHS Quality) 3 1.35DVD 5 2.25HDTV (1080i) 19 8.55DV 32 14.4

QQ. 2 Terminology

Allocation Unit (AU) -The minimum logically contiguous group of blocks on the media. An Allocation Unit is accessed with one or more Requests. Delivery Interval - Defined as the period of time in which an Allocation Unit must be delivered in order to support playback or recording of a stream at the required data transfer rate.

Frame – Refers to each individual image displayed as part of a video playback or record sequence.

Information Technology Command (IT Command) – This is a read or write command that is issued to access IT data.

Information Technology Data (IT Data) – Information Technology (IT) data is defined as reliability-critical data. The device shall not return errors to the host on IT data transfer commands until all possible data recovery procedures have been attempted.

Request – A READ STREAM or WRITE STREAM command minimum transfer length. Sequential Transfer – This term is used to refer to cases where the host issues consecutive commands to access sequentially addressed logical blocks. For the computations shown in this proposal, the drive shall assume that the host will issue counts sufficiently large (the size of an allocation block), and use transfer rates sufficiently fast (the fastest supported by the device) such that sequential transfer performance is maintained.

Stream – The time based transfer of data to or from the device. A Stream is composed of one or more Allocation Units.

Streaming Command – This is a read or write data command that is issued via the Streaming Feature Set command opcodes, which has an allotted time associated with it. Behavior of the device when it cannot successfully read or write the data within the allotted time depends on the control settings used for the stream command.

Stream Data – Stream data is defined as time-critical data, in contrast to the definition of IT data.

QQ 2.1 Illustrations for A/V DefinitionsError: Reference source not found provides an illustration of how the terms previously defined relate to each other. As shown, Streams consist of multiple Allocation Units. Allocation Units themselves consist of transfers

Page xx

T13/1510D 1612DT revision 0h10that are Request Size in length. All LBAs associated with a single Allocation Unit are logically contiguous, as shown by the figure. The number of LBAs in the Requests and Allocation Units are particularly important in order to maintain the stream data rate. The Request Size must be chosen to permit seek and rotational latency to occur between each Allocation Unit without impacting the stream transfer rate requirements.

Figure QQ.2 - Data Transfer Model for A/VQQ.2.2 CachingIt is possible for the host to indicate on a per-command basis, whether the device should perform caching (ion write stream commands) or continue pre-fetching sequential data (on read stream commands). Write caching allows the device to indicate to the host that a write has completed before the host’s data has actually been committed to the media. The benefit of this protocol is that subsequent sequential data, if written by the host quickly enough on a later command, can be written by the device more efficiently than if the device had to flush all of the host data to the media before indicating that a given write command was complete. In the case of writes, the device shall treat a command as equally time-critical whether it is cached or not. The caching mechanism enables the host to issue multiple commands to write one LBA range, without causing the device to lose performance due to flushing on command boundaries.

On reads, the caching (pre-fetching) indicator assists the device by informing it that sequential data will be accessed on the next command, thus keeping the device from losing performance when handling multiple sequential read commands that comprise one read LBA range.

To avoid the difficulty of tracking IT data and streaming data in the cache, devices may complete writing of cached IT data before caching streaming command data. Devices may complete writing of cached streaming command data before caching IT data. This may result in reduced performance if IT commands and Streaming commands are interspersed.

QQ.2.3 Error Handling/Reporting/LoggingThere are four possible error-handling strategies, the device may utilize after consuming all possible retries on a data transfer command2:

Report Erred Region(s) Do Not Report ErrorStop on error Normal IT data, streamed IT data N/AContinue through error

Streaming data, with feedback Streaming data, without feedback

The “stop on error” method may be most useful for data that requires data integrity (whether it was written by an IT command, or a streaming command). The “continue through error” modes have value when a system needs

2 Note: on a normal IT command, the “possible retries” include any recovery methods available to the device. For a streaming command, the “possible retries” include only those that can be performed without jeopardizing the command’s completion in the time allotted by the host.

Page xxi

D1612r0a “best effort in allotted time” on some data, and beyond that it may (“with feedback”, in table, above) or may not (“without feedback”, in table) care whether the transfer was actually flawless.

When the device does report an error, it does so without use of the Error Bit in the Status Register, thus enabling the host to ignore the error if it wishes3. This simplifies the device implementation of error handling and reporting, since it can always report errors, and only has to be directed to stop on or continue through errors.

The error reporting mechanism for streaming reads and writes is such that, for quick indication of error status, a single error region can be described in the task file registers. If more than one error occurs in a single command this single region shall be reported such that it fully includes both of the smaller actual erred regions. More precise error information shall be placed by the device into the Read Stream Error Log or Write Stream Error Log, as appropriate.

The Stream Error Logs are accessed via the Read Log Ext. and Write Log Ext. commands, and are described by Table 39 and Table 41 in Section 8.30.

QQ.3 A/V ModelMany different usage models are possible to support A/V applications. This document does not attempt to document all possible usage models. Two examples are described in the proceeding sections, however, these should not be assumed to be the only possible implementations.

QQ.3.1 Aligned A/V DataIn this example the A/V data is forced into alignment on fixed boundaries. The variation in frame sizes is padded up to the size of each Allocation Unit. This implementation results in a slightly less efficient storage format. This alignment does simplify the algorithms for re-positioning to support such functions as rewind, fast-forward, etc.

Error: Reference source not found illustrates the basic representation of how data from multiple streams might be interleaved in the data being read from or written to the hard disk. The amount of data represented by each Allocation Unit is implementation specific. AU A1 represents the data from AU 1 of Stream A. AU B1 represents the data from AU 2 of Stream B and so forth. There is no intended or implied correlation between Frames, as previously defined, and Allocation Units as illustrated in Error: Reference source not found.

Figure QQ.3- Representation Of Stream Data in Disk Data Flow

3 Many current host hardware implementations are purported to stop completely, in an inconvenient manner, if the Error Bit is seen set in the Status Register.

Page xxii

T13/1510D 1612DT revision 0h10Error: Reference source not found illustrates one possible method of representing or storing video Frames within an Allocation Unit. In this case each Allocation Unit contains five video Frames. As illustrated in Error: Referencesource not found, the sizes of the individual Frames within the elements need not be a fixed size.

Figure QQ.4 - Possible Representation Of Video Frames Within An ElementWithin the domain specified by Error: Reference source not found and Error: Reference source not found an A/V enabled hard drive could satify the requirement to provide data to the host by delivering one element for each Stream every Delivery Interval. In this example each Allocation Unit represents one Frame Set. Error: Referencesource not found further describes this by adding the Delivery Interval representation to the example defined in Error: Reference source not found.

Figure QQ.5- Representation Of Stream Data in Disk Data Flow

QQ.3.2 Un-aligned A/V DataIn this example the A/V data has no fixed alignment. There is no padding added to the content. Audio formats, such as MP3, are likely to have this type of un-aligned format since there is no Frame equivalent. Other types of A/V data such as video might also use such a transfer mechanism even though they are subdivided into individual frames.

Error: Reference source not found provides as an example five frames of A/V data. These are broken into four separate requests each of which contains more than a single frames worth of data. The host performs any necessary blocking or deblocking to separate out the individual frames.

Page xxiii

D1612r0

Figure QQ.6 - Unaligned A/V Transfer ExampleQQ.3.3 Inclusion Of Non-A/V DataWhile the primary purpose of the A/V model is to define operation when A/V content is being transferred instances do exist where A/V content and more traditional IT content are accessed concurrently. One example is the Electronic Program Guide (EPG) information which contains data regarding television program scheduling such as start/stop time, channel number, abstract, etc. This EPG data must be read and written without error. This is in direct conflict with the A/V data transfer model where errors are permissible to achieve timing constraints.

Error: Reference source not found illustrates an example of how EPG data might be accessed without eliminating the possibility of A/V data streaming meeting its timing constraints. In this example the EPG data is interleaved with the data for the two streams (A and B). Time is allocated for the drive to read or write the EPG data just as if it were another stream. Accessing the entire EPG takes multiple requests over several Delivery Intervals. Failure to read a block of EPG data is reported by the drive to the host as an error. The host may choose to retry the request at a later time. Accessing the EPG data is not identical to normal IT data access in that it is not unconstrained in terms of time. Although the time contraint may be different than for the A/V streams the constraints still exist and error recovery time available to the drive is not unlimited.

Figure QQ.7 - EPG Data Transfer Example

QQ.4 A/V Model Implementation Examples

QQ.4.1 Ax+B Usage Examples

The following examples use the assertion T£ Ax + B, where T is time, IDENTIFY DEVICE word 96 contains ‘A’, and IDENTIFY DEVICE word 97 contains ‘B’.

The value of these parameters is that:

The host and drive can agree on a baseline time required for a streaming command, assuming no retries are required, and the latency incurred on the device side is the worst-case. (See Read Stream and Write Stream commands for protocol by which the host can indicate to the device that it will have more time than that on a given command.)

The host can estimate how long an IT command might take, assuming that no retries are required, so that it can be taken account in a host’s priorities.

Examples:A. Simplistic host, transferring data to/from the drive at a constant rate of 10 Mb/s, utilizing a double-buffered memory where the total memory is comprised of 220 Bytes of storage:

((220)/2)/(10e6/8) = 419 ms per 1024 sectors. The host could simply request 1024 sectors to be read or

Page xxiv

T13/1510D 1612DT revision 0h10written for each command, with an allotted time of 419 ms for the entire command. Assuming that the host does not have any error recovery capability, it should direct the device to continue through errors, and additionally, the host could ignore the error status on each streaming command. In spite of the device’s “best effort” capabilities, there may be conditions under which the device cannot complete command processing in the allotted time, so the host should still support buffer under/over-run protection in the event that their double-buffer needs to be re-used before the device has finished transferring data to/from it.

If the device or host in this case does not support command counts beyond 256, then the host could issue 4 commands in a row (with the “cache” indication set for the first 3) to process the 1024 sectors. Each of these 4 commands could be allocated 104 ms, or the host could allocate the advisory time parameter “B” to the first command, and then divide the remaining time between all 4 commands. Note that this solution is less optimal for many reasons:1. The time allocated to each of these fractional-length commands may either be smaller, or unequal to the

others, due to rounding.

2. The host must be more sophisticated than this one to pass available time from one of the 4 commands to a later one, if the earlier one finished in less than its allocated time.

3. In the event that the host does track locations of errors, it must read the Stream Error Log to locate them, since error reporting on LBA ranges is no longer synchronized to individual commands.

The host could check the advisory data (words 95 and 96 in IDENTIFY DEVICE data) to ensure that the device can always (excepting rare conditions) keep up with this requirement. However, in this case, either the device can perform as directed, or not. If the device can finish any individual command in the time allotted, it will. If the advisory parameters indicate that the device cannot assure command completion in the allotted time, the device will perform the operation as fast as it can, which may cause a buffer over/under-run on the host if it takes longer than the allotted time to complete.

B. Host which still does not support error recovery (other than buffer under/over-run protection), but which needs to handle somewhat-variable rate streams of data, or is willing to arbitrate commands somewhat to improve data reliability:

Assume that the host has the following buffers for 3 streams of data (each is double-buffered, not shown), whose sizes are proportional to their maximum rates:

Stream Buffer Size [220 Bytes] Max Use Rate [220 Bytes/s]1 1.0 1.252 1.5 1.8753 0.5 0.625

When all three streams are requiring all of the host-allotted time to be serviced by the device, and all streams are running at their maximum rates, the access pattern looks very similar to the first example.

T1 = (1.0/(1.0+1.5+0.5))(1.0/1.25)= 266 ms

T2 = (1.5/(1.0+1.5+0.5))(0.8 s) = 400 ms

T3 = (0.5/(1.0+1.5+0.5))(0.8 s) = 133 ms

However, if the host wishes to access stream one at double its normal rate (to “fast-forward” play the stream, for example), the host can re-distribute the time in the following access frame:

T1 (160 ms) T2 (240 ms) T1 (266 ms) T3 (133 ms).

The disadvantages to this method are that since the buffers have not been resized, the accesses to stream one must be made on a rigid schedule, twice as often as before (to prevent buffer under/over-run on the host), but there are unequal amounts of data to transfer during the first and second halves of the access frame. Therefore, the data transfer during the T1 T2 part of the frame is pushed harder than the data transfer in the T1 T3 part of the frame. In addition, if the data is delivered at varying rates (rather than simply some number times a constant rate), the host must repeatedly recompute these “constant” stream time allotments, based on the order in which streams are ready for service, and the times at which they become ready for service.

C. Host which not only supports variable rate streams of data, but is willing to arbitrate time more precisely:

Assuming that this host has the same stream requirements as shown in the table in example B, above, it would ensure that each stream would get, as a minimum, the times shown above, even in the case where all of the (doubly-buffered) streams require service at the same time. However, since it is willing to arbitrate

Page xxv

D1612r0more, it can give the device more time, on average but not necessarily in the worst-case environment, to perform each operation, resulting in quieter operation and/or lower error rates. The trick is for the scheduler to keep track of when each of the double-buffers for each stream were last finished being serviced by the device, thus ensuring that those buffers cannot possibly require re-servicing until a full (Buffer Size)/(Max Stream Rate) amount of time in the future. The scheduler can then lay out the T i(min) times, as computed from the Ax+B equation (in the advisory data section), working backwards from the latest possible service requirement, to find out when the next-to-first command may need to be started, thus showing when the first stream to be serviced may need to be complete. The allotted time thus allocated to the first stream servicing is therefore often much larger than the times shown above in example B. In general, the extra time will not be required for the device to service the command, but by giving the extra time to the device, the result will sometimes result in an acoustically quieter command, and more reliable data.

D. Arbitrating host, which handles variable rate data streams, also has lower-priority “maintenance” data to transfer to/from the device, and is able to perform extensive error recovery:

This host would likely use the advisory data provided by the device regarding detailed data rates and seek times to estimate the fastest that each required stream command could be handled by the drive, and intentionally squeeze some commands to ensure that there is time left over to service other non-stream commands occasionally. (See Streaming Logs, section 6.23.2.) The host should continue using read and write stream commands to perform this other work, to ensure that command handling times are well-constrained. By locating data in “nearby regions” (implied by short access times in the advisory data), the host can significantly improve their average performance.

QQ.4.2 Ax+B Performance Table ExamplesA. A 500 sector/second (256 KB/s) spirally-written, somewhat-constant linear velocity drive may return tables as follow. Assume that the IDENTIFY DEVICE command returned data from the drive with words 98-99 containing 10,000, i.e. a 10 ms time unit. Note that the numbers do not represent a CLV drive, but show the data trends that would be seen for a CLV drive.

Page xxvi

T13/1510D 1612DT revision 0h10Table QQ.2 Example Streaming Performance Parameters Log5

Bytes Description Contents2 Stream Performance Parameters log version 00012 K, Number of Regions in Sector Time Array 00022 L, Number of Positions in Position Array 00052 M, Number of Position-differences in Access Time Array 0009

16 Sector Time Array See below40 Position Array See below36 Access Time Array See below

412 Reserved 00

Table QQ.3 Example Sector Time Array (linearly interpolated)5LBA (6 bytes) [IDENTIFY DEVICE words 98-99]/65536 units of time/Sector at this LBA (2

bytes)0 13107 (note: 13107 * [IDENTIFY DEVICE words 98-99] ms / 65536 = 2 ms/sector

MAX_LBA 13107

Table QQ.4 Example Position Array (linearly interpolated)5LBA (6 bytes) Position Number (arbitrary units, 2 bytes)

0 0MAX_LBA/2 1000

MAX_LBA*3/4 2000MAX_LBA*7/8 3000

MAX_LBA 4000

Table QQ.5 Example Access Time Array (linearly interpolated)5Difference in

Positions(2 bytes)

Time that may be required to begin access at new stream access position (in [IDENTIFY DEVICE words 98-99]/256 units, 2 bytes)

-4000 12800 (note: 12800 * [IDENTIFY DEVICE words 98-99] ms / 256 = 500 ms)-3000 7680 (note: 7680 * [IDENTIFY DEVICE words 98-99] ms / 256 = 300 ms)-2000 2560 (note: 2560 * [IDENTIFY DEVICE words 98-99] ms / 256 = 100 ms)-1000 2048 (note: 2048 * [IDENTIFY DEVICE words 98-99] ms / 256 = 80 ms)

0 1664 (note: 1664 * [IDENTIFY DEVICE words 98-99] ms / 256 = 65 ms, this includes a full revolution, plus the time to seek within any one position, above)

1000 1920 (note: 1920 * [IDENTIFY DEVICE words 98-99] ms / 256 = 75 ms)2000 2304 (note: 2304 * [IDENTIFY DEVICE words 98-99] ms / 256 = 90 ms)3000 6144 (note: 6144 * [IDENTIFY DEVICE words 98-99] ms / 256 = 240 ms)4000 10240 (note: 10240 * [IDENTIFY DEVICE words 98-99] ms / 256 = 400 ms. The

numbers here assume that it is easier for the drive to slow the spindle than to speed it up, which might be explainable by back-EMF braking.)

What these tables mean to the host are that for any data region, once they have performed the seek to the position, they will be able to maintain 500 sectors/second, as this value is the result of interpolation from the Sector Time Array for all LBAs. The other two tables allow the host to compute the time that it may take to seek from one LBA to another. An example would be from 0.9*LBA_MAX to 0.1*LBA_MAX, in which case the host looks up 0.9*LBA_MAX in the table, and interpolates that to position 3200, and 0.1*LBA_MAX, and interpolates that to position 200. The difference of these positions is (Destination Position – Start Postion) = (200 3200) = 3000. This value is then looked up in the Access Time Array, and the host interpolates that it should expect the access to take 300 ms before the drive will be ready to transfer data at 500 sectors/second.

B. A constant-angular velocity drive, with 3 discrete data zones in a 1 inch actuator stroke, rotating at 6000 RPM, and with a head and cylinder skew of ¼ revolution. Assume that the IDENTIFY DEVICE command returned data from the drive with words 98-99 containing 2000.

Assume that the drive has the following internal data zoning:

Page xxvii

D1612r0Table QQ.6 Example Internal Data Zoning

Starting LBA Number of sectors/track Radius0 500 1.0 inch

5,000,000 300 0.5 inch6,800,000 200 0.2 inch7,600,000 0.0 inch

And that the drive has a seek profile approximated reasonably well by:

Figure QQ.7 – Example Seek Profile

Page xxviii

T13/1510D 1612DT revision 0h10Then the drive can be reasonably described with respect to performance by the following Stream Performance Parameters Log:

Table QQ.7 Example Streaming Performance Parameters LogBytes Description Contents

2 Stream Performance Parameters log version 00012 K, Number of Regions in Sector Time Array 00062 L, Number of Positions in Position Array 00042 M, Number of Position-differences in Access Time Array 0011

48 Sector Time Array See below32 Position Array See below44 Access Time Array See below

380 Reserved 00

Table QQ.8 Example Sector Time Array (linearly interpolated)LBA (6 bytes) [IDENTIFY DEVICE words 98-99]/65536 units of time/Sector at this LBA (2

bytes)0 820 (note: 820 * [IDENTIFY DEVICE words 98-99] ms / 65536 = 25 ms/sector)

4999999 8205000000 1366 (note: 1366 * [IDENTIFY DEVICE words 98-99] ms / 65536 = 41.7

ms/sector)6799999 13666800000 2048 (note: 2048 * [IDENTIFY DEVICE words 98-99] ms / 65536 = 62.5

ms/sector)7590000 2048

Note that two entries are required per data zone because the host is allowed to linearly interpolate between the entries in the table. Each of these entries is the average time per sector, taking one average track skew into account for every track’s worth of data.

For a large number of zones, the device vendor can choose to limit the Sector Time array size by giving only a few table entries between which the host can linearly interpolate. The table entries shall be such that linear interpolation gives a conservative result.

Page xxix

D1612r0QQ.9 Example Position Array (linearly interpolated)

LBA (6 bytes) Position Number (arbitrary units, 2 bytes)0 1000 (1.0 inch radius, arbitray unit)

5000000 500 (0.5 inch radius)6800000 200 (0.2 inch)7600000 0 (0.0 inch radius)

QQ.10 Example Access Time Array (linearly interpolated)Difference in

Positions (2 bytes)

Time that may be required to begin access at new stream access position (in [IDENTIFY DEVICE words 98-99]/256 units, 2 bytes)

-1000 5440 (note 5440 * [IDENTIFY DEVICE words 98-99] ms / 256 = 42.5 ms = 30+10+2.5 ms)

-875 5408 (note 5408 * [IDENTIFY DEVICE words 98-99] ms / 256 = 42.25 ms = 29.75+10+2.5 ms)

-750 5248 (note 5248 * [IDENTIFY DEVICE words 98-99] ms / 256 = 41 ms = 28.5+10+2.5 ms)

-500 4800 (note 4800 * [IDENTIFY DEVICE words 98-99] ms / 256 = 37.5 ms = 25+10+2.5 ms)

-250 4160 (note 4160 * [IDENTIFY DEVICE words 98-99] ms / 256 = 32.5 ms = 20+10+2.5 ms)

0 1600 (note 1600 * [IDENTIFY DEVICE words 98-99] ms / 256 = 12.5 ms = 10+2.5 ms)

250 4160500 4800750 5248875 54081000 5440

Note that every entry in this table has a full revolution (10 ms) plus a worst case skew time (2.5 ms) added to the seek time for the given difference in positions. This is because, after just arriving on a seek, in addition to waiting for a worst-case rotational latency (a full revolution), the data may be split across a track boundary, thus requiring an extra skew beyond the one-per-track that is averaged into the Sector Time Array.The choices regarding number of and distribution of regions and positions is left up to the device vendor. The table entries shall be such that linear interpolation gives a conservative result.

Page xxx