DMA issue while writing data to SATA hard disk

I don't think that your simple design approach using ping-pong buffering
has much hope of working with real HDs, due to error handling in the HD.
36 MB/s can be achieved as an STR (at least in the outer zones), but that
is a long-term average; you are expecting *every* 512KB write to be
completed in your ~15 ms window, which does not leave any time for the
HD to detect and recover from an error.

You might want to try replacing that WD800BD HD with the much faster
WD1500ADFD (10K RPM 150GB SATA Raptor), just because nothing else
would need to be changed in your design. But frankly, I doubt if any
HD will solve your problem; all HDs do error detection and recovery
behind your back, and they all stop transfering data to take care
of errors.

If the Raptor does not fix your problem, my next suggestion is to try a
pure flash SSD. (By pure, I mean not a hybrid which merely uses flash
as a buffer for a rotating mechanical HD.) You may need to try a bunch
of flash SSDs, since I don't expect vendors to spec worst-case write
times (if, indeed, those times are actually known).

Finally, if neither the Raptor nor flash solves your problem, it will be
time for a new design approach, using N (N>>2) buffers instead of 2 and
using far more than 1 MB of total buffering. Multi-buffering is more
complex than dual- but not enough to blow you out of a single FPGA;
however, a large (>>1MB) buffer pool will require external RAM (if you
don't already have that).

Good luck.
--
Cheers, Bob

Bob Willard wrote in news:rfidnUakO4hQoKDVnZ2dnUVZ_uidnZ2d@comcast.com
> I don't think that your simple design approach using ping-pong buffering
> has much hope of working with real HDs, due to error handling in the HD.
> 36 MB/s can be achieved as an STR (at least in the outer zones), but that
> is a long-term average; you are expecting *every* 512KB write to be
> completed in your ~15 ms window,

> which does not leave any time for the HD to detect and recover from an error.

The 'error' would have to be a servo error where the drive is unable
to find the start sector of a tranfer or a previously marked candidate
bad sector. While this can certainly happen this should be very rare.

What may be less rare is that logically consecutive sectors may not
be physically consecutive on the platters, causing a hickup in the STR.
This would be the case after some 'bad' sectors have been reassigned.

>
> You might want to try replacing that WD800BD HD with the much faster
> WD1500ADFD (10K RPM 150GB SATA Raptor), just because nothing
> else would need to be changed in your design. But frankly, I doubt if any
> HD will solve your problem; all HDs do error detection and recovery be-
> hind your back, and they all stop transfering data to take care of errors.

Error correction can be switched off if you use the streaming features.

>
> If the Raptor does not fix your problem, my next suggestion is to try a
> pure flash SSD. (By pure, I mean not a hybrid which merely uses flash
> as a buffer for a rotating mechanical HD.) You may need to try a bunch
> of flash SSDs, since I don't expect vendors to spec worst-case write
> times (if, indeed, those times are actually known).
>
> Finally, if neither the Raptor nor flash solves your problem, it will be
> time for a new design approach, using N (N>>2) buffers instead of 2 and
> using far more than 1 MB of total buffering. Multi-buffering is more
> complex than dual- but not enough to blow you out of a single FPGA;
> however, a large (>>1MB) buffer pool will require external RAM (if you
> don't already have that).
>
> Good luck.

SCSI disks usually have two controllers, one for bus-interface and commands,
and another controlling the disk hardware.
ATA disks usually use a single controller for both.
I suspect most of the ATA signals (except clocks) are handled by firmware,
not hardware, so you cannot guarantee the timing of DMA done.

You might try the T13 mailing list: http://t13.org/Reflector/Default.aspx

"maverick" <sheikh.m.farhan@gmail.com> wrote in message
news:5eb872dd-10d9-4707-8ab7-2f64fccaebd0@26g2000hsk.googlegroups.com...
>
>
> The data loss occurs due to delay in step 3 and step 6 where the FPGA
> waits for the DMA done signal from the SATA controller. At times, the
> SATA controller takes longer than anticipated and due to this, data
> buffers overflow. 36Mbytes/s should not be an aggressive data rate for
> the SATA controller + SATA HDD specially when the PCI link is
> dedicated only between the host and the SATA controller.. We have
> tried out different numbers with PCI bridge configuration and SATA
> controller PCI configuration but things have not improved. We are
> using UDMA 6 mode. Anyone out there to guide us how to handle this
> problem? Let me know if more information is required. Thanks in
> advance.
>