I suspect we do not know what the device will do. It could be that it is counting the incoming words and as it receives the 255th it then goes into a state that expects the CRC. If it does not come in ( i.e. the protocol does not change) it might (1) go into the weeds, or (2)discard the incoming and wait for the CRC protocol or (3)it might recognize that excess data has been sent. In case (3)it might try to terminate the burst (stop-first) but the host will have undoubtedly shipped one more word before the stop gets to it so the extra words might be one or two on top of the two "stop period words". The device can then terminate the command with the "Check" bet set.
I strongly suspect however that case 1 or 2 is more likely than case 3.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29, 2002 12:15 PM
To: Hale Landis
Cc: T13 List Server
Subject: Re: [t13] U-DMA Quiz Time!!!
This message is from the T13 list server.
Hale;
I am not sure that in your Question #2, the third burst would get all the way up
to byte #106.
I would have expected that after the 2nd burst, both the device and the host
know that there have been a total of 408 bytes transferred, then comes burst #3.
When byte #102 has been transferred, I would expect the device to tell the host
to stop the transfers (assuming that it is done since it has received the full
510 bytes as in your Question #1), but then, the host is slow (and broken??), so
it continues (following your example) to transfer 4 more bytes. So, while there
will still be extra bytes, I would think it would be only 4 and not 8.
Am I missing something here???
Regards;
Rick
"Hale Landis" <[EMAIL PROTECTED]> on 01/28/2002 10:10:29 PM
Please respond to "Hale Landis" <[EMAIL PROTECTED]>
To: "T13 List Server" <[EMAIL PROTECTED]>
cc: (bcc: Richard Kalish/ALI_SJC/ACER)
Subject: [t13] U-DMA Quiz Time!!!
This message is from the T13 list server.
A U-DMA quiz...
=== Question #1
The "write" command tells the device to transfer 510 (0x1fe)
bytes. The host DMA engine is programmed to transfer 510 (0x1fe)
bytes. Three DMA bursts are required and the U-DMA speed is such
that when the receiver (device) says stop the sender (host) will
send 4 bytes before stopping.
1st DMA burst: The host has sent 200 bytes when the device says stop.
The host sends 4 more bytes before stopping.
2nd DMA burst: The host has sent 200 bytes when the device says stop.
The host sends 4 more bytes before stopping.
3rd DMA burst: The host sends the last 102 bytes. The host and device
stop at the "same time".
Question: Are there any "extra bytes"?
Answer below.
=== Question #2
The "write" command tells the device to transfer 510 (0x1fe)
bytes. The host DMA engine is programmed to transfer 1024
(0x400) bytes (this is a broken host!). Three DMA bursts are
required and the U-DMA speed is such that the that when the
receiver (device) says stop the sender (host) will send 4 bytes
before stopping.
1st DMA burst: The host has sent 200 bytes when the device says
stop. The host sends 4 more bytes before stopping.
2nd DMA burst: The host has sent 200 bytes when the device says
stop. The host sends 4 more bytes before stopping.
3rd DMA burst: The host has sent 106 bytes when the device says
stop. The host sends 4 more bytes before stopping.
Question: Are there any "extra bytes"?
Answer below.
Answers below... Scroll down...
=== Answers
Question #1: No, there are no "extra bytes". The command said
to transfer 510 bytes. The host DMA engine transferred 510
bytes. The device received 510 bytes.
Question #2: Yes, there are "extra bytes" transferred because
the host is broken. The host DMA engine thinks it needs to send
1024 bytes but the command and the device only want 510 bytes.
As soon as the device has received those 510 bytes
is tells the host to stop but by the time the host stops the host
has sent 8 "extra bytes". These 8 "extra bytes" in the last DMA
burst are included in the CRC of the last DMA burst but are
otherwise ignored by the device.
(Wasn't that fun?)
*** Hale Landis *** www.ata-atapi.com ***
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
