The T13 Committee held and Ad Hoc Teleconference on September 19, 2003 at 9:00 am PDT.

Transcription

1 The T13 Committee held and Ad Hoc Teleconference on September 19, 2003 at 9:00 am PDT. The attendees were: Jim Hatfield (Seagate) Dan Colegrove (Hitachi GST) (Acting Secretary) John Masiewicz (Western Digital) Tim Thompson (LSI Logic) Tony Goodfellow (Pacific Digital) Tony Priborsky (Seagate) Knut Grimsrud (Intel) SATA II Work Group Questions We went through the list of questions sent to the SATA II Working Group. The results of the teleconference is indicated with a TC> bullet. I. Phy Issues 1. Signal Integrity Test Configuration ( ) What is meant by this statement in : Open or shorted traces with the same length as the input signal traces shall be provided to measure the system input risetime and to synchronize pulses. Traces for crosstalk measurements diverge from each other. Provisions for attenuation reference measurement shall also be provided. What end diverges? Is divergence a requirement? What provisions for attenuation? What are input signal traces? What is meant by this statement in : Unless otherwise specified, the requirements in are for the entire signal path from the host mated pair connector to the device mated pair connector, but not including PCB traces. A picture is worth a 1000 words. This can probably be resolved with a diagram that shows a SATA connector with diverging signal traces to instrumentation connectors and the extra traces needed for risetime measurement. Provision for attenuation reference measurement needs additional description. I assume input signal traces are the SATA connector to instrumentation connector signal lines. Do the unconnected traces used for risetime measurement have connectors of some type? Alternatively we could remove the board design requirements and not specify it. It would be up to the person doing the test to select the SATA connector to test equipment adapter. A picture of the transmitter-traces-connector-cable-connector traces-receiver path with the measured section would clear up the second part.

2 KSG> In the 1.0a spec this is section Refer to the PHY team to address TC> Wait for phy team response 2. Host Side Signal Conditioning In reference to Volume item a) There is host side signal conditioning that will pull the host TX and RX pairs low if power is off. Is this statement correct? Should this be there shall be host side signal conditioning, there may be host side signal conditioning, or no statement. Does this apply to both DC and AC coupling? KSG> In the 1.0a spec this is section line item number 1 in the sequence. The first line in section indicates that this section is informative for the sake of clarifying the sequence. It would therefore not be appropriate to make use of the term shall in this descriptive/informative sequence clarification. As an informative explanation of the sequence illustrated in a corresponding figure, I believe this is correct as written since the text is narrating a sequence of events in a given example. In the example shown the host has the signals floating low. TC>Confirm this resolution with PHY team. Add note that the signal voltage limits (see table 11) apply in the low power states and when the phy is powered off. 3. Idle Bus Common Mode Voltage Requirement Dan Colegrove to pass along question to the SATA PHY Working Group: In reference to Volume 3 section (During the idle bus condition, the differential signal diminishes to zero while the Common mode level of 250 mv remains.), does the requirement for 250 mv apply to DC coupling only? none KSG> In the 1.0a spec this is section In the 1.0a version this section refers to the requirements listed in the section/table on electrical parameters and refers to the 250mV value in a parathetical explanatory way. The electrical parameters section defines unambiguously what the common mode voltage allowances are for both AC and DC coupled designs, and this section

3 stipulates that those requirements must be satisfied when in a power management state. If it is helpful, the parenthetical reference to the 250mV may be removed without any loss of content. TC>This is the same problem as #2. The 250mV value should be replaced with a table reference. (closed) Dword Latency Example In reference to Volume , in the example of the 20 Dword Latency, the entries only add to 18 Dwords. Are the additional 2 words added for margin? none KSG> The purpose of the example accounting for signaling latency is to justify the 20dword latency value selected by the spec and to show the feasibility of meeting this requirement. 20 dword latency is the requirement, and the example shows that it can be satisfied using common design assumptions. TC> Remove the term worst case and make it clear that this is an example. Take out 20 Dword from title. (close with edits for review) 5. Time to Present Status After Reset In section , OOB signaling sequence failure, Volume 3, COMINIT must be returned within 10ms. This conflicts with the parallel requirement of 2ms and appears to be a loosening of the spec and could lead to interoperability problems. We could add language to say that additional time (10ms) is required in SATA for bridges and COMINIT retries. Have there been any reports of interoperability problems in due to this difference between parallel and serial behavior? Serial ATA is based on high-speed serial technology which has some technical realities that the spec must consider. Analog PLLs used for precision clock references to not have an instantaneous lock time, and at the time the spec was written the industry consensus for reasonable technology was for PLL lock times on the order of 10ms should be generally realizable. Because the clocking sources at the heard of Serial ATA have this lock-time reality, it is not technically feasible to rely on power-on to ready response times faster than this. This 10ms recovery time is also manifest in the SLUMBER resume latency allowance, which also has 10ms allotted due to the desire for this state to accommodate PLLs being powered off. The 10ms allowance is not a SATA bridge limitation, but a limitation in the analog PLL lock times seen by some circuits.

4 Because this initial initialization time discrepancy between SATA and PATA is observed at power-up, the impact to this is in BIOS software. Fortunately, BIOS software is generally hardware/system specific and would be in the best position to account for this timing discrepancy. Additionally, this timing issue has been well publicized and is highlighted specifically in the spec with design precaution that BIOS take this response time into account when doing initial device enumeration. In practice, BIOS software generally does even come out of POST within the time indicated, and I m not aware of any compatibility issues that have been caused by this discrepancy. TC> Add in volume 1 a comment(s) that document(s) the different time for parallel and serial. 6. Power on Sequence Timing Tony Priborsky will address the question in Volume 3, line item g). Should the line state 2048 Dwords at the appropriate speed or 54.6 us? Similar question in step f) and step d). Fixed time or 2048 Dwords? KSG> The timings would probably be most precisely specified in terms of the various dword times since this would then also result in the clocking tolerances getting carried along. TC>Change this line (item g) to match the other entries? This needs to be reviewed by the Phy Group. 7. COMINIT/COMRESET COMWAKE Timing Where do the > and <= go on the 175 ns values in table 11 COMINIT/COMRESET detector off threshold and COMWAKE detector maximum. This is splitting an infinitesimally small hair. KSG> I believe that the SAS guys have already applied the > and <= convention to address this mathematical singularity issue. I suggest that T13 adopt the same convention as the SAS guys did (although I m not positive which way they assigned it). TC> This whole discussion is pointless. No changes. 8. UL Test Requirement ( )

5 What is meant by this statement in : Material certification or certificate of compliance required with each lot to satisfy the Underwriters Laboratories follow-up service requirements. Do we want to require UL in the standard, or do we want the procedure (UL 94v-0) to be the requirement? Is actual submission of the connector to UL the requirement or is compliance with the UL procedure the requirement? Non-US companies may not use UL or have alternate certifying organizations in their country. The way the document reads now it requires use of the UL Company s services. KSG> In the 1.0a spec this is Table 8 in section regarding flammability. This should be referred to the CabCon group. My inclination is that it is correct as written and that this has potential far-reaching consequence/impact. I don t know all the regulatory issues, but I d hate to have Serial ATA be implicated in someone s house burning down because the connector flammability requirements did not meet regulatory requirements. I would think that the benefit of this requirement is actually having the UL recognition, since meeting the requirement without the recognition would not seem to provide the equivalent regulatory benefit. TC> Ask for SATA II Cab/Con group input. II. Protocol Issues 9. Non-Existent and Non-Selected Device State In the serial interface, what are the proper host/device protocols for selecting non-existent and non-selected device states? This is analogous to ATA/ATAPI-6 (now Table 18 in Volume 2). There is a discrepancy between this description for the handling of shadow registers after reset and the similar description in ATA/ATAPI-5 (Table 14). SATA seems to have taken the ATA/ATAPI-5 approach. The descriptive text in section in volume 1 also needs to be resolved with the SATA method. The problem is the response when there is only one device (device 0) and the nonexistent device 1 is selected. ATA and ATAPI devices have different responses in ATA-6. This difference can not be supported in SATA as host adapters do not know what type of device they are attached to. Parallel ATAPI devices are believed to be inconsistent in their behavior. It would be good to have a consistent SATA ATAPI behavior. KSG> The SATA 1.0a spec explicitly refers to the ATA/5 spec in its references as that was the available ratified ATA spec at the time SATA was developed. SATA therefore was designed to emulate the ATA/5 behavior.

6 Because the registers in question have different contents depending on what ATA version the devices comply with plus the device type of the device, the registers in practice have nondeterminate data in them. Because of the behavior differences, it is not feasible to rely on any particular register contents or behavior since a number of different behaviors are defined as permissible. Because of these behavior discrepancies, the registers/conditions in question should be documented as non-determinate in order to accurately reflect what can be relied on with those states. TC> Replicate the table in volume 2 in volume 3 in the section on parallel emulation with the ATA-5 requirements, note that the current parallel ATAPI method is different. 10. nien and I bit Behavior John Masiewicz to draft input for proper implementation of nien and I bit behavior in ATA/ATAPI-7 SATA Devices. The proposed text follows: 18.1 Device Emulation of nien with Interrupt Pending (Informative) This standard defines the I bit in Register Device to Host FIS's as the Interrupt pending state of the device, and it is not modified by the state of nien in received Host to Device FIS's. In this standard, devices ignore the nien bit in received Host to Device FIS's and always perform as if nien is cleared to zero. See clauses and Prior to the development of this standard, some devices used the nien bit of the Register Host to Device FIS as a pre-condition to the setting the interrupt pending flag (I-bit) of the Register Device to Host, and Set Device Bits FIS's. The purpose of using nien to enable the I-bit was to emulate the operation of the parallel implementation of ATA (See Clause 13.2). In the parallel implementation, when nien is cleared to zero, the driver is enabled for the INTRQ line to the host. When nien is set to one, the INTRQ line is put into the high impedance state by the device. This function is typically used in devices that support Device 0 and Device 1 operation (See ), and it is also required for Overlapped operation (See Volume 1). In this standard, the implementation of Device 0/Device 1 emulation is performed exclusively by the Host (see ). Since operation prior to this standard was not uniformly implemented, the system designer should be aware of the limitations of those implementations. In most cases, the prior implementations are compatible with this standard. Some commands, however, may not operate in the same manner, or may require new device drivers for compatible operation. One example of this is when Overlapped/Queued operations are implemented with host host-parallel to device-serial bridges. With proper management of the nien and INTRQ bit to the parallel host, it is possible to emulate the parallel operation. One serious side effect of device emulation of nien is the possibility of lost interrupts. In the parallel implementation, a host can disable interrupts, and upon re-enabling interrupts (by clearing nien to zero) see the INTRQ line again asserted. If a serial device is performing I-bit masking based on the state of nien, a Register Device to Host FIS may be received with I=0 (since it is masked by nien). The device, however, may have an

7 interrupt pending at that time. When the host writes the Control Register with nien cleared to zero, it will not see the pending interrupt reflected by the assertion of INTRQ as in the parallel case. There is no way for the device to "re-send" the I=1 condition to the host. In this instance, the host will have to resort to a polling operation to resume the operation. The system designer should be aware of the following: 1) The I bit is the interrupt pending flag for Serial ATA devices. 2) The behavior of the I bit may be modified by the state of the nien bit in devices implemented prior to this standard. Devices implemented prior to this standard may change the behavior of the I bit based on the current state of the nien bit, as last written by a Register Host to Device FIS with C=0 or C=1. Some devices do not write the nien bit when C=1. 3) There is no defined behavior for a device when nien bit changes and the modification of the behavior of the I bit by nien is vendor specific. 4) The host should only set nien=0 in Register HD FIS s. This will result in the highest compatibility with this standard. 5) If a device supports nien emulation, and the nien bit is set to 1 by the host, the device drivers should accommodate the case of no interrupt generation when nien is cleared to zero and the device has a pending interrupt. Is the proposed text OK? KSG> Digital group should review carefully. In general it appears that the device/host handling of nien only becomes a sensitive issue in the presence of legacy command queuing, and that for the other command protocols it appears that it matters much less how nien is handled by host and device. An informative section on this would seem to be the least contentious way to address as John suggests. Suggest review/discussion in the next scheduled digital meeting. TC> Verify that this new language is acceptable to the SATA II Digital group. Definition of Obsolete (e03129r0) We discussed the definition of Obsolete as it applies to the Time Limited Read Write Command Set. The consensus was that since the Time Limited Read Write Command Set is enabled with a set features command the meaning of the obsoleted bit could be reused. Jim Hatfield will turn a new rev showing that the bit definition will be obsolete when not in Time Limited mode and valid when the mode is set. DCO (e03111r0)

8 The group reviewed the DCO proposal and agreed it was OK. ATAPI Direction Bit Knut Grimsrud pointed out that there was no way for legacy software to understand the need for the proposed ATAPI direction bit when doing DMA operations. Knut recommended that ATAPI devices that have a SATA to PATA bridge chip that requires the direction bit turn off the current DMA support indication bits in Identify Packet. This would cause existing software to drop down to PIO mode. New bits should be allocated to say DMA supported if direction bit is provided. The next teleconference will be held October 2, 2003 at 9am PDT.