Improving Networks Worldwide. UNH InterOperability Lab SATA Chapters 11 and 12 Device Command Layer...

Improving Networks Worldwide.

UNH InterOperability Lab

SATA Chapters 11 and 12Device Command Layer Protocols

SATA Device Command Layer Protocols

Presentation Topics

• Device Command Layer Protocol– Power-on and COMRESET– Device Idle– EXECUTE DEVICE DIAGNOSITC– DEVICE RESET– DMA data-in– FPDMA QUEUED (Host and Device)

• Other Command Layer Protocols

Command Layer Protocols

• Series of inter-related state machines

• Guidelines for devices and hosts on steps to take when processing and incoming or outgoing command

Presentation Topics

• Device Command Layer Protocol– Power-on and COMRESET– Device Idle– EXECUTE DEVICE DIAGNOSITC– DEVICE RESET– DMA data-in– FPDMA QUEUED (Host and

Device)

Power-on and COMRESET

• On reception of COMRESET from a Host, devices shall execute the hardware reset protocol regardless of current device command layer state or power management state

• Covers the basic power on procedures to be used by both Packet and Non-packet devices

• DHR0: Hardware_reset_asserted– Command Layer has received a

message from the Transport Layer that a COMRESET has been asserted

– Device stays in this state until message from Phy State Machine is received saying that the hardware reset has been negated

– Only transitions to DHR1

• DHR1: Execute_diagnostics– During this state, a Device

initializes its hardware and executes its power up diagnostic routines

– Upon completion of power up diagnostic routines a Device can transition to DHR2 or DHR3

• DHR2: Send_good_status– In this state, a Devices transmits

a Register FIS to the Host indicating that the power up diagnostics have been completed successfully

– The Device then transitions to DI0: Device_idle

• DHR3: Send_bad_status– In this state, a Devices transmits

a Register FIS to the Host indicating that the power up diagnostics have NOT been completed successfully

– The Device then transitions to DI0: Device_idle

Presentation Topics

Device)

Device Idle Protocol

• The default state for all SATA Devices

– Awaiting the reception of a FIS from the Host

– State machine defines how to process commands and how to decide which command specific state machine to enter based on the received FIS

• DI0: Device Idle– Default State– Just waiting for something to

happen from the Host– Numerous possible transitions

from this state based on Host actions

• DI1: Check_FIS– Entered from DI0 upon reception

of a FIS– Check C-bit and SRST-Bit of the

FIS• If C-bit asserted → DI2:

Check_command• If SRST-bit asserted → DSR0:

Software_reset_asserted

– Any other FIS → DI0: Device_idle

• DI2: Check_command– Check the fields of the command– 15 possible transitions out of this

state based on the command type found when checking fields

Device Idle Protocol• DI3: No_Command

– Entered when a Device receives a command not supported

– ABRT-bit of command set to one → DI0: Device_idle

• DI4: Set_service– Entered when Device is ready to

complete data transfer for a queued command

– SERV-bit of command set to one → DI0: Device_idle

• DI5: Service_test– Entered when a SERVICE

Command is received– Check the command to see if a

Register FIS needs to be transmitted for DRQ bit and to set the Tag

– If PACKET PIO In/Out → DI7: Service_decode

– Else → DI6: Service_send_tag

• DI6: Service_send_tag– Entered when a SERVICE

command has been received– Device waits for a Register FIS

with the BSY-bit de-asserted, DRQ-bit asserted, and an appropriate tag

– Upon reception of the FIS → DI7: Service_decode

• DI7: Service_Decode– Check the command that has

been received after the required Register FIS has been received

– 6 Possible transitions based on the command type

Presentation Topics

Device)

SATA Device Command Layer ProtocolsExecute Device Diagnostics

Protocol• Command Class for the EXECUTE

DEVICE DIAGNOSTIC command– If COMRESET or a FIS with SRST-

bit asserted is received, the Device shall execute the COMRESET Command Protocol or the Software Reset Command Protocol respectively

• Describes the process for EXECUTE DEVICE DIAGNOSTIC command

SATA Device Command Layer ProtocolsExecute Device Diagnostics

Protocol• DEDD0: Execute_device_diag

– In this state, a Device will execute its internal diagnostic procedures

• If diagnostics completed successfully → DEDD1: Send_good_status

• Else → DEDD2: Send_bad_status • From DEDD1 and DEDD2 → DI0:

Device_Idle

Presentation Topics

Device)

Device Reset Protocol

• Command Class for the DEVICE RESET command

– If COMRESET or a FIS with SRST-bit asserted is received, the Device shall execute the COMRESET Command Protocol or the Software Reset Command Protocol respectively

• When this command is received, a Device will stop all activity

Device Reset Protocol• DDR0: Device_reset

– Upon reception of this command, a Device will halt all execution of any outstanding commands and will hald all background activity

– When activity has ceased → DDR1: Send_good_status

• DDR1: Send_good_status– Device requests the Host transmit a

Register FIS– Upon reception of this FIS → DI0:

Device_Idle

Presentation Topics

Device)

DMA Data-in Protocol

• Command Class for the READ DMA and READ DMA EXT commands

• Execution of this command induces the transfer of one ore more blocks of data from the device to the host use using a DMA transfer

• Command Protocol for most read operations in modern, non-packet devices

• DDMAI0: DMA_in– In this state, a Device will prepare

the date for transfer to the host – When Data FIS is ready →

DDMAI1: Send_data– Otherwise, command has been

completed or aborted → DDMA2: Send_status

• DDMAI1: Send_data– In this state, the Device shall

transmit the prepared FIS to the host

• DDMAI2: Send_status– A Device enters this state when

all the data for a command has been transmitted to a Host or an error has caused the command to abort

Presentation Topics

Device)

FPDMA Queued Protocol

• Command Class for READ FPDMA QUEUED and WRITE FPDMA QUEUED commands

– Special Read and Write commands for Native Command Queuing features found in SATA2+

• DFPDMAQ1: AddCommandToQueue

– Upon determining a FPDMA command has been received, a Device will add the command to its internal queue and store the command's TAG value

– Successful en-queuing → DFPDMAQ2: CleareInterfaceBsy

– Else → DFPDMAQ12: BrokenHost_ClearBusy

• DFPDMAQ2: ClearInterfaceBsy– Transmit a Register FIS to the

host with BSY and DRQ bits deasserted, indicating the Device is ready to receive the next command

– Upon transmission → DI0: Device_idle

• DFPDMAQ3: DataPhaseReadSetup– State entered when the device is

ready to transmit data from a previously queued READ FPDMA QUEUED command

– In this state, a Device will attempt to setup up a host memory write DMA connection with the Host

– Once the connection is established, a Device will transition to DFPDMAQ8

FPDMA Queued Protocol• DFPDMAQ4:

DataPhasePreWriteSetup– State entered when the device is

ready to receive data from a previously queued WRITE FPDMA QUEUED command

– In this state a Device needs to determine if Auto-Activate is supported an enabled • If yes, → DFPDMAQ5:

DataPhase_WriteSetup• Else → DFPDMAQ6:

DatePahse_OldWriteSetup

• DFPDMAQ5: DataPhase_WriteSetup– This state is entered when a

Device is ready to Auto-Activate– A device transmits a DMA Setup

FIS to the host with a DMA buffer Id, the queued TAG value, the direction bit cleared (Host Memory Read), and the AA bit set to one

– Once Setup FIS is completed → DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol• DFPDMAQ6: DataPhase_OldWriteSetup– This state is entered when Auto-

Activate is not supported or enabled– A device transmits a DMA Setup FIS

to the host with a DMA buffer Id, the queued TAG value, the direction bit cleared (Host Memory Read), and the AA bit set to zero

– Once Setup FIS is completed → DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol• DFPDMAQ7: DataPhaseXmit_Activate

– This state is entered after a device completed setup for a WRITE DPDMA QUEUED command

– While in this state a Device transmits a DMA Activate FIS indicating its readiness to receive DATA FISes

– The device then transitions to DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol• DFPDMAQ8: DataXmitRead

– This state is entered after a device has completed setup for a READ FPDMA QUEUED command

– A device continues to transmit Data FISs until the command has been completed or an error has been encountered

– Device transitions to DI0: Device_idle upon completion

FPDMA Queued Protocol• DFPDMAQ9: DataXmitWrite

– This state is entered after a device has completed setup for a WRITE FPDMA QUEUED command

– A device continues to receive DATA FISes until the command has been completed or an error has been encountered

– Device transitions to DI0: Device_idle upon completetion

FPDMA Queued Protocol• DFPDMAQ10: SendStatus

– This state is entered after a device has completed the data transfer associated with a command

– In this state, a device will transmit a Set Device Bits FIS to the host indicating the completion of the command

– Following the transmission of this FIS, a device will transition to DI0: Device_idle

FPDMA Queued Protocol• DFPDMAQ11: Error

– This state is entered when a device has encountered an unrecoverable error

– When this state is entered, a device halts all transmissions and transmits a Set Device Bits FIS to the host indictating the error condition

– A device then transitions to DFPDMAQ13: WaitforClear

FPDMA Queued Protocol• DFPDMAQ12: BrokenHost_ClearBusy

– This state is entered when a device receives a READ or WRITE FPDMA QUEUED command with a tag that exists already in the queue or a non-queued command is received while there are still outstanding commands in the queue

– Upon entering this state, a device will transmit a Register FIS to the host indicating the error condition and then transition to DFPDMAQ13

FPDMA Queued Protocol• DFPDMAQ13: WaitforClear

– This state is entered when a device has transmitted an error FIS and is waiting for a READ LOG EXT command or a Soft-Reset

– All other commands will be responded to with an Error FIS

– When the READ LOG EXT command is received the device shall transition to DFPDMAQ12

FPDMA Queued Protocol• DFPDMAQ14: SendQueue_CleanACK

– This stae is entered when the Host has responseded to an error FIS with a READ LOG EXT command

– The Device will discard all queued commands remaining and transmit a Set Device Bits FIS with the ERR bit cleared, Error Field cleared, and Sactive = FFFFFFFFh and interup cleared

– Upon transmission of this FIS, the device shall transition to DPIOI0:PIO_in

SATA Device Command Layer ProtocolsFPDMA Queued Protocol

(Hosts)• This state machine describes the

behavior for Native Command Queuing Hosts

• This class is largely similar to the behavior of the devices but also covers:

– TAG assignment – Error Recovery– Retrying Failed Commands

Presentation Topics

• Device Command Layer Protocol– Power-on and COMRESET– Device Idle– EXECUTE DEVICE DIAGNOSITC– DEVICE RESET– DMA data-in– FPDMA QUEUED (Host and Device)

Software Reset Protocol

• This state machine covers how a device handles receiving a FIS with the SRST bit asserted

• Essentially the same as the DEVICE RESET Command Protocol

Non-Data Protocol

• This state machine describes how a device will handle receiving a non-data command FIS

• Commands include: FLUSH CACHE, IDLE, MEDIA LOCK, SEEK, NOP, and SET MULTIPLE MODE among others

SATA Device Command Layer ProtocolsPIO Data-in and Data-out

Protocol• These two state machines describe how

commands will responds to PIO requests (Diagnostic and legacy commands from previous ATA standards)

• Commands include IDENTIFY DEVICE, READ SECTORS, SMART READ DATA, DOWNLOAD MICROCODE, and WRITE SECTORS among others

Packet Protocol

• This state machine describes how a device will handle receiving a packet based commands. Packet commands are used by Optical Disc Drives and other ATAPI device which do not utilize the traditional PIO and DMA interfaces defined with ATA

Improving Networks Worldwide. UNH InterOperability Lab SATA Chapters 11 and 12 Device Command Layer...

Documents

10GBASE-T PMA Test Suite - UNH InterOperability … · The University of New Hampshire InterOperability Laboratory 10 Gigabit Ethernet Consortium 3 Clause 55 PMA Test Suite v1.3 MODIFICATION

Improving Networks Worldwide. UNH InterOperability Lab Interoperability & Conformance Testing And Test Suite Harmonization Erica Johnson May, 2007

Bridge Functions Consortium - UNH InterOperability … University of New Hampshire InterOperability Laboratory BRIDGE FUNCTIONS TEST SUITE - i - 802.1Q VLAN Operation MODIFICATION

IoT IP Consortium - UNH InterOperability Laboratory · IoT IP Consortium 5 IoT IP Interoperability Test Suite Introduction The University of New Hampshire’s InterOperability Laboratory

IP Training Overview, Part 2 © UNIVERSITY of NEW HAMPSHIRE INTEROPERABILITY LAB Specific Routing Protocols And MORE Ben Schultz UNH InterOperability Lab

MPLS Ready To Serve The Enterprise - UNH … MPLS & Frame Relay Alliance SUPERDEMO 2004 Public Interoperability Event Test Areas and Test Plan The interoperability evaluation focused

Improving Networks Worldwide. UNH InterOperability Lab SCSI Commands Overview

Wireless LAN Consortium - UNH InterOperability Laboratory...Wireless LAN Consortium ERP Physical Layer Test Suite v3.1 Report UNH InterOperability Laboratory — 121 Technology Drive,

© UNIVERSITY of NEW HAMPSHIRE INTEROPERABILITY LABORATORY UNH InterOperability Laboratory ADSL Consortium Benefits and Testing Capability

UNH IOL SAS Consortium 3.0... · UNH IOL SAS Consortium SAS-3 Phy Layer Test Suite v1.0 . InterOperability Lab — 121 Technology Drive, Suite 2 — Durham, NH 03824 — (603) 862-0701

100BASE-TX - UNH InterOperability Laboratory of NEW HAMPSHIRE INTEROPERABILITY LABORATORY 100BASE-TX PMD Interface with the Medium •The PMD converts MLT-3 symbols into electrical

UNH IOL SERIAL A SCSI (SAS) CONSORTIUM · 2015-09-21 · The University of New Hampshire InterOperability Laboratory UNH IOL SAS Consortium 2 Clause 5 SAS Speed Negotiation Test Suite

Improving Networks Worldwide. UNH InterOperability Lab Serial ATA (SATA) Clause 9 Considerations

MAC Test Suite v5 - UNH InterOperability Laboratory · interoperability of standards based products by providing an environment where a product can be tested against other implementations

UNH–IOL NVMe Testing Service · 2020-11-02 · University of New Hampshire InterOperability Laboratory – NVMe Cloud SSD Conformance Test Suite UNH–IOL NVMe Testing Services

Power over Ethernet - UNH InterOperability Laboratory · PDF fileThe University of New Hampshire InterOperability Laboratory Power Over Ethernet Consortium 1 Clause 33 PD Parametric

UNH IOL SATA Consortium

IPv6 Ready Logo Phase-2 - UNH InterOperability Laboratory...IPv6 Ready Logo Phase-2 Interoperability Test Scenario IKEv2 Technical Document ... Part EE, FF, KK, and LL Cryptographic

UNH InterOperability Lab

UNH-IOL Physical Layer Knowledge Document · UNH-IOL Physical Layer Knowledge Document University of New Hampshire InterOperability Laboratory Fibre Channel Consortium ... Document