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

Improving Networks Worldwide.

UNH InterOperability Lab

SATA Chapters 11 and 12Device Command Layer Protocols

2

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

3


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

4


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)


5


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

6



• 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

7



• 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

8



• 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

9



• 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

10


Presentation Topics


Device)


11


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

12



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

happen from the Host– Numerous possible transitions

from this state based on Host actions

13



• 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

14



• 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

15


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

16



• 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

17



• 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

18



• 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

19


Presentation Topics


Device)


20

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

21

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

22


Presentation Topics


Device)


23


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

24


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

25


Presentation Topics


Device)


26


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

27



• 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

28



• 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

29


Presentation Topics


Device)


30


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+

31



• 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

32



• 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

33



• 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

34


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

35



• 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

36


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

37


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

38


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

39


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

40


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

41


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

42


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

43


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

44


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

45

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

46


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)


47


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

48


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

49

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

50


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

Documents

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