Hi,
It sounds like you have multiple issues.
First, I agree with most of what Gert says, but have a slightly
different view. The SATA system always has reflections since the return
loss on the load is not infinite. This is because there is capacitance
on the load. Problems arise when the transmission path has impedance
discontinuities and when the return loss of the source is not good.
Multiple reflections are what causes ripples in the frequency response
of the channel. These multiple reflections get worse when the channel
losses are low (yes, I said low not high). Your 3cm cable loss is low
and it might work better with a longer (yes, I said longer) cable.
Don't add any shunt capacitance.
Second, it is very suspicious that it works with a 128K buffer (10
seconds) but not a 4M buffer (lots of retries 1 minute). This sounds
like your application layer implementation is at fault. Without getting
more information as to the FISes that are being transferred, it's hard
to say what is wrong. My feeling is that this is the most likely cause.
Third, most SATA drivers detect the excessive retries and renegotiate
the link down from 6G to 3G to 1.5G. I guess yours doesn't do that,
bringing the host SATA driver into question. Perhaps you could try it
with a different host. Anyway, this is not part of the SATA spec itself.
Good luck,
Chuck Hill, consultant, SATAIO Phy WG chair
On 07/15/2015 05:52 AM, Havermann, Gert wrote:
SATA doesn't like reflections, thus I would first search for sources of
reflection (use TDR, VNA, or Oscilloscope and a Data Source). You can also
try to add losses (very long and lossy cables), or add capacitance to lower
the rising edge of the transmitted Signal. If this improves the data link,
then you can be certain that there are reflections. When there are no vias in
the link, then a bad current return path can be the troublemaker. Check if
there is a solid GND connection all along the transmission path.
I don't expect any timing problems in your SATA link.
BR
Gert
----------------------------------------
Absender ist HARTING Electronics GmbH, Marienwerderstraße 3, D-32339
Espelkamp; Registergericht: Amtsgericht Bad Oeynhausen; Register-Nr.: HRB
8808; Vertretungsberechtigte Geschäftsführer: Dipl.-Kfm. Edgar-Peter Düning,
Dipl.-Ing. Torsten Ratzmann, Dipl.-Wirtschaftsing. Ralf Martin Klein,
Dipl.-Ing. Uwe Gräff
-----Ursprüngliche Nachricht-----
Von: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] Im
Auftrag von Dimiter Popoff
Gesendet: Mittwoch, 15. Juli 2015 11:58
An: si-list@xxxxxxxxxxxxx
Betreff: [SI-LIST] Re: Longer SATA tx (host to drive) transfers issue
Hi Gert,
are you sure it sounds like a SATA link problem? It works fine when the
buffer is shorter (i.e. read 128 kilobytes then write them, this in a loop
taking about 10S, as expected).
Hey, I have to test with only a little longer buffer, 128k is exactly 256 512
byte sectors (IRQ handles this differently past that, may be this line is at
fault... not much hope as nothing would work if it were but I'll look into it
now :-) ).
Then making the cable better or worse did not affect things in the least....
There are no vias between the chip pads and the pads where the cable is
soldered to the board, the tx (the longer) traces are about 20-25mm long,
goint in parallel, meant to be 100 Ohm to each other...
I wish I knew how to tell the part to go 1.5GbpS and not 3, I can neither
measure what it does there nor do I know how to affect it (Marvell chip, no
datasheet).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/
From: "Havermann, Gert" <Gert.Havermann@xxxxxxxxxxx>
To: "dp@xxxxxxxxxxx" <dp@xxxxxxxxxxx>
Subject: AW: [SI-LIST] Longer SATA tx (host to drive) transfers issue
Date: Wed, 15 Jul 2015 09:27:35 +0000
Hi Dimiter,
sounds like a reflection problem. Check all via's in your design and
backrill every via stub that exeeds 1,3mm (when possible). You should
also TDR the Signal path if you have the equipment to do so.
BR
Gert
----------------------------------------
Absender ist HARTING Electronics GmbH, Marienwerderstraße 3, D-32339
Espelkamp;
Registergericht: Amtsgericht Bad Oeynhausen; Register-Nr.: HRB 8808;
Vertretungsberechtigte
Geschäftsführer: Dipl.-Kfm. Edgar-Peter Düning, Dipl.-Ing. Torsten
Ratzmann, Dipl.-Wirtschaftsing. Ralf Martin Klein, Dipl.-Ing. Uwe Gräff
-----Ursprüngliche Nachricht-----
Von: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
Im Auftrag von Dimiter Popoff
Gesendet: Mittwoch, 15. Juli 2015 11:13
An: si-list@xxxxxxxxxxxxx
Betreff: [SI-LIST] Longer SATA tx (host to drive) transfers issue
Hi everyone,
I have a new version of a board of ours on which I have put Marvells
88sa8052 ATA <-> SATA bridge.
I have tried it out using an off the shelf ATA <-> sata convertor and
it works fine. In fact I had soldered the convertor ATA side to the
former board version exactly as I (believe to) have routed the chip on
the board; and I put pulups/downs exactly as I saw them on the
convertor (unless I have made a mistake yet to be discovered but I have
checked a number of times already).
The chip I am using is taken from such a convertor (tested to work)
and... sort of works on my board. It does fine as long as I do not try
to write to the disk a longer buffer (100 megabytes copy via a 128k
buffer works just fine; give copy (I can do that easily, it is under my
control) a 4M buffer and I get lots of retries, takes forever (about a
minute vs. about 10S)...
I have checked the usual suspects - powers are stable and clean (during
the test, too), clock oscillator seems to run smoothly, the handshake
signals to the ATA side are OK.
The SATA cable is about 3 cm long, two pairs wound in copper foil,
properly connecting foil etc. to gnd points - and it seems to work OK,
no difference to 2 other - may be 2-3 times longer - cables (ATA
ribbon) I tried. Then it is just the longer write which causes the problem.
I realize this is a long shot but someone on the list might have had to
deal with this or something similar and something might click.
Thanks,
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
