** This is the quasi-official and semi-temporary T13 email list server. **
Hello, My answers are embedded after the questions in the following. Please feel free to call or send an email to me if you have any additional questions or comments about this. Regards, Mark Evans Maxtor Corporation 500 McCarthy Boulevard Milpitas, CA 95035 USA Tel: 408-894-5310 FAX: 408-324-7432 email: [EMAIL PROTECTED] -----Original Message----- From: Keith Clausen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 2:42 AM To: [EMAIL PROTECTED] Subject: [temp t13] ANSI NCITS 340-2000 (ATAPI-5): PDIAG- & DASP- operation ** This is the quasi-official and semi-temporary T13 email list server. ** Here's something you might like to chew on in the meantime. Submitted some months ago, but no responses - are the questions too difficult? --- Forwarded mail from "Keith Clausen" <[EMAIL PROTECTED]> From: "Keith Clausen" <[EMAIL PROTECTED]> Date: Thu, 12 Jul 2001 16:34:47 +0100 To: [EMAIL PROTECTED] Subject: ANSI NCITS 340-2000 (ATAPI-5): PDIAG- & DASP- operation 4 questions on the above standard. ================================== Any answers - I'm particularly interested in the correct interpretation of the standard as opposed to what devices actually do - developing a tester for checking conformity. Note: paragraph 3.2.1 - Precedence states that figures take precedence over text (and tables over both), so I take the state diagram descriptions as taking precedence over any implied functionality in the text. _____________________ Figure 15, page 229 of the above standard (Device power-on or hardware reset state diagram) states that PDIAG- is only Asserted or Negated ON transition D1HR1:DI2 (exc. whatever it's state may have been in DHR0: RESET). However, table in Figure 21, page 241 (Device bus idle state diagram) states that PDIAG- is always Released. So, if transitions are instantaneous (last paragraph, section 3.2.7 , P8) how in reality can PDIAG- be ever anything but Released. It seems device 0 must Assert or Negate PDIAG- until at least device 0 has had the opportunity to sample it (D0HR2:Sample_PDIAG-). (Note: same for Figure 39, page 277 Device 1 EXECUTE DEVICE DIAGNOSTIC command state diagram - D1ED2:DI2 transition). Q1: When should Device 1 Release PDIAG- after D1HR1:DI2 (D1ED2:DI2) and where is this stated? Answer 1: I think that there are at least a couple of errors in this part of the standard (and they are in A/A-6, as well). Some of the words in A/A-4 for the Power on and hardware reset protocol for device 1 (on which we in T13 spent so much time) say: "e) Device 1 SHALL NEGATE [caps are mine] PDIAG- no later than 1 ms after RESET- is negated." "p) Device 1 shall continue to assert DASP- and PDIAG- until after the first command is received from the host or until at least 31 s after RESET- is negated or until detecting that the host has set the SRST bit to one in the Device Control register, whichever comes first. Device 1 shall release PDIAG- no later than command completion of the next command from the host except for the EXECUTE DEVICE DIAGNOSTIC command." It appears that these actions didn't make it into a state diagram or description and should now be included. ________ In a similar vein, DASP- is Asserted only whilst device 1 is in D1HR1:Set_status. Once finished and off idling (DI2), DASP- is Released (= Negated with 10K Pull Up [p11 4.2.1]) according to table in Figure 21. Meanwhile, device 0 passes to State D0HR1:Sample_DASP- . If Device 1 diagnostic is extremely quick (<1ms), Device 1 will already be in DI2 before Device 0 has reached D0HR1. Device 1 must Assert DASP- until at least device 0 has had the opportunity to sample it (D0HR1:Sample_DASP-). Q2: When should Device 1 Release DASP- after D1HR0 and where is this stated? Answer 2: I think this is covered in item (p) from the list from A/A-4 (see answer 1). As with PDIAG-, it appears that these actions for DASP- didn't make it into a state diagram or description and should now be included. _ _ _ _ I thought that DASP- Assert is a function of device 1 only (device 0 always keeps it released). Q3: When would Device 0 ever Assert or Release DASP-? - Implied by description of the function of D0HR0, or is this catering for a device designation switch?! (Was device 1, now device 0 - think not!) - Alternatively, is it time allowance for the OTHER device (device 1) to release DASP- (D0HR0)? Why - device 1 is only going to re-assert it? - Or is it time allowance for the devices to settle down after power application/reset? Answer 3: The protocol in question is for Power on or HARDWARE reset. It is quite possible that device 0 had been driving DASP- as a drive activity signal (that's what the DA stands for) before a hardware reset. Therefore, to allow the slave present function (that's what the SP stands for) during the reset protocol, device 0 has to release DASP- to allow device 1 to drive it. _ _ _ _ Q4.1: Is there a scenerio where the host ever samples DASP-? The cable definitions don't exclude it from reaching the host, but I haven't as yet detected a description of the host actually using it in the standard. I may have missed it! Q4.2 Can at least one instance in the standard (section number) be identified which describes the host using DASP-? Q4.3 Should DASP- be asserted by device 1 all/most of the time (to represent its presence)? Answer 4: There is no time during the reset protocol when the host should sample DASP. As is typical of the ATA standards, host-side behavior releative to DASP- is not detailed. The traditional use of this signal by many, many hosts is to drive an LED activity indicator. Hosts often connect this signal directly to an LED mounted on the front of the system to indicate when the device is doing something. There are some hints of this is the standards: In Table 3 in A/A-5, DASP- has a different current requirement from the other signals (12 mA sink current); In Table 5 in A/A-5, DASP- is described as an open collector driver with a 10K pull-up resistor at the device. These are requirements for driving an LED. Therefore, device 1 darn well better release DASP- after the specified event or time so that either device can drive it to indicate activity. Thanks in advance Keith -- Keith Clausen, STMicroelectronics, Mail: 1000 Aztec West, Bristol BS32 4SQ, UK Email: [EMAIL PROTECTED] Phone: +44 1454 462457 Fax: +44 1454 617910 ---End of forwarded mail from "Keith Clausen" <[EMAIL PROTECTED]> -- Keith Clausen, STMicroelectronics, Mail: 1000 Aztec West, Bristol BS32 4SQ, UK Email: [EMAIL PROTECTED] Phone: +44 1454 462457 Fax: +44 1454 617910 -- If you have any questions or wish to unsubscribe send a message to Hale Landis, [EMAIL PROTECTED] To post to this list server send your message to [EMAIL PROTECTED] For questions concerning Thistle Grove Industries or TGI's list services please send email to [EMAIL PROTECTED] -- If you have any questions or wish to unsubscribe send a message to Hale Landis, [EMAIL PROTECTED] To post to this list server send your message to [EMAIL PROTECTED] For questions concerning Thistle Grove Industries or TGI's list services please send email to [EMAIL PROTECTED]
