T13 Forum:
At the last ATA-7 Working Group in Longmont on July 31-Aug 1, the group responded to the Editor's request for guidelines to clarify certain ambiguous or contradictory descriptions in Volume 3 (the Serial ATA Volume). This resulted in discussions that made it clear there are Serial ATA devices and hosts with several different implementations already. These different implementations may be said to conform to the original SATA spec, but could have interoperability issues due to the various interpretations of the "intent" of the original specification. We want to clarify the ATA-7 standard with the least disruption to prior designs.
I have attempted to briefly describe the specification issues here, and listed the group's recommendations as rules so that we may reference them in further discussions. I will apply these rules to clarify the appropriate clauses of Volume 3, and I will mark all of the changes with change-bars for review and post it prior to the next T13 plenary meeting (Aug 19-21 in Boulder).
I encourage you to review these issues carefully. I expect these new guidelines may cause some discomfort, and initiate spirited discussion at the next T13 meeting. I look forward to seeing you there!
1) It is unclear whether writing the Control Register with a change to nIEN takes immediate effect on the host adapter, and does not wait for a FIS transmission. There was also a question on what the device should or should not do with nIEN.
Working Group Guidance:
(Rule 1) There are devices that change the behavior of the “I” bit based on the current state of the nIEN bit, as last written by either a Control FIS or a Command FIS.
(Rule 2) There is no defined behavior for a device when nIEN bit changes.
2) It is unclear whether the Register DH FIS with C=1 and C=0 are mutually exclusive (i.e. if the control reg only written if C=0 and Control Reg is not written if C=1). See Reg HD FIS description and host adapter descriptions. Also note that host and Device transport descriptions do not specify whether control or command FIS types write which registers and just says ‘registers’. Many descriptions imply that C=0 or C=1 write all of the registers. If the host optionally does not send the Control FIS to the device when the condition of nIEN is changed, then the host must manage the disabling or enabling of the interrupt on the host side. This is not specified. If you CAN set the Control register contents with a C=1, then there are some state machines that may be interpreted incorrectly (e.g. says if C=0 or says if C=1). What if C=1, but the SRST bit is also set =1? Another example; In state DI1:DI0, it does not say to transfer the contents to the control register if SRST is cleared to zero. Does this mean nothing to do if Control register is written unless state of SRST changes? (i.e. no changes to nIEN?)
Working Group Guidance:
(Rule 3) if C=1, and the SRST bit=1, the results are indeterminate.
(Rule 4) Reg DH FIS with C=1 will also write Device Control Register.
(Rule 5) Reg DH FIS with C=0 will only write Device Control Register.
3) In the device, is the I bit completely independent of the nIEN bit? In other words, will the I bit will always be set or cleared regardless of state of nIEN? Is this true for all Device to Host FIS types? Is it true that you cannot look at the I-bit to determine if the host will be interrupted? The definition of the I bit says it reflects the interrupt “bit line” in the device, which could make sense in a bridge, but in a non-bridge solution, does it reflect the interrupt pending condition of the device independent of nIEN? Notice in state DI4, it says to set I=1. This is only true if the service interrupts are enabled. There are other similar references to setting the I bit. In the description of PIO Setup FIS Command Protocol, it says the I bit shall be set=1. Is I=1 always in PIO Setup FIS’es for data-in? In PIO Data-out, it says all I=1 except first DRQ block. (Should these statements say IPF?) (Also in DMA Data-out & in ending state). How should we clarify these statements?
Working Group Guidance:
(Rule 6) The “I” bit is the interrupt pending flag for Serial ATA devices.
(Rule 7) The behavior of the “I” bit may be modified by the state of the nIEN bit.
(Rule 8) The modification of the behavior of the “I” bit by nIEN is vendor specific.
(Rule 9) The device should ignore nIEN in the Control Register
(Rule 10) The host should only set nIEN=0 in Register HD FIS’s
(Rule 11) Device drivers should accommodate the case of no interrupt generation when nIEN is cleared to zero and the device has a pending interrupt.
John Masiewicz
T13 Editor
Western Digital
949-672-7686
