Negative Hold time margin mit Flash-Speicherbaustein

[Lay O. (layouter123)]

Hallo zusammen,

ich verwende einen STM32F7 in Kombination mit einem Flash-Speicher 
MX25L6433 über Quad-SPI mit 100 MHz.
Die Längen habe ich gemäß Layout-Guidelines gematched, sodass das 
maximale Delay 18,5 ps beträgt.
Um nun ganz sicher zu gehen, wollte ich die Setup Margin und die Hold 
margin berechnen.
Die Berechnung der Setup Margin ergab plausible Werte, bei der Hold 
margin erhalte ich allerdings negative Werte. Wie ist das zu 
interpretieren? Erkennt jemand, wo mein Fehler liegt?
Die Gleichung die ich verwendet habe lautet:
Hold Margin = TCO(min)+TOFD-Tsckewclk-TH
Die Werte für die Gleichung mit MCU als Treiber:
TCOmin(MCU)=1,5ns
TH(Flash)=3ns
TOFD=0,179ns
Tsckewclk=0,184ns

oder wenn mit Flash als Treiber:
TCOmin(Flash)=1 ns
TH(MCU)=3 ns
TOFD=0,179ns
Tsckewclk=0,184ns

Beide Gleichungen ergeben negative Werte.

Bin für jede Hilfe dankbar.

[Felix U. (ubfx)]

Lay O. schrieb:
> bei der Hold
> margin erhalte ich allerdings negative Werte. Wie ist das zu
> interpretieren?

Wenn ein negativer Wert rauskommt, heißt das, dass du die Haltezeit 
verletzt. Schreib doch noch mal welche Indizes bei deinen Zeiten was 
bedeuten, dann kann man eine Plausibilitätsprüfung machen.
Im Allgemeinen bedeutet das aber, dass deine Datenleitung gegenüber der 
Clock verzögert werden müsste um auf positive Werte zu kommen.

[Lay O. (layouter123)]

Felix U. schrieb:
> Schreib doch noch mal welche Indizes bei deinen Zeiten was
> bedeuten, dann kann man eine Plausibilitätsprüfung machen.

TCOmin=Minimum Propagation delay between Clock to Data at Driver
TH=Input Hold time for Flash/MCU
TOFD=Data Metal Delays in PCB (From Driver to Receiver)
TSCKEWCLK=Clock Metal Delays in PCB (From MCU to Flash)

Sprich du schlägst vor TOFD zu erhöhen und TSCKEWCLK zu verringern. Dann 
würde mein Length matching aber nicht mehr passen.

[Felix U. (ubfx)]

Wenn du wirklich negative Hold times bekommst, wirst du nicht 
umhinkommen, irgendeine Art der Verzögerung einzusetzen. Sind deine 
Zeiten denn relativ zu den gleichen Edges? Wenn TCO auf die rising edge 
bezogen ist, aber die Haltezeit auf die falling edge, dann musst du 
natürlich auch anders rechnen.

[Lay O. (layouter123)]

Felix U. schrieb:
> Wenn TCO auf die rising edge
> bezogen ist, aber die Haltezeit auf die falling edge, dann musst du
> natürlich auch anders rechnen.

Hallo Felix,

jetzt ist der Groschen gefallen!
TCO min ist beim MCU Datenblatt auf die falling edge bezogen und TH ist 
beim Flash auf die Rising Edge bezogen. Sprich ich müsste TCOmin mit der 
Zeit addieren in der die Clock high ist, richtig?

[Felix U. (ubfx)]

Lay O. schrieb:
> Sprich ich müsste TCOmin mit der
> Zeit addieren in der die Clock high ist, richtig?
Ich kann dir nicht auf Anhieb sagen, ob immer das richtige rauskommt, 
wenn du in Hin- und Rückrichtung was auf TCO addierst.

Am besten kann man sich das immer klar machen, wenn man mit 
"Ankunftszeiten" rechnet. Das kannst du dann ein mal für jede Richtungen 
und jeweils für Setup und Hold machen.

Also zum Beispiel:

Der STM32 erzeugt den Takt und die steigende Flanke verlässt den Clock 
Pin bei 0 ns. -> Die Ankunftszeit der steigenden Flanke am Flash ist 
TSCKEWCLK also 0,184 ns.

Die Daten verlassen die Daten-Pins gegenüber der steigenden Flanke um 
TCO verzögert, also bei 1,5 ns. Die Ankunftszeit der Daten ist dann TCO 
+ TOFD also bei 1,679 ns.

Die Haltezeit am Flash sagt, dass die (neuen) Daten frühestens 3 ns nach 
der Flanke ankommen dürfen, bei der gesampelt wird (bei DDR wären das 
natürlich beide). Wenn also auch bei der steigende Flanke gesampelt 
würde, dürften die neuen Daten frühestens bei 3,184 ns ankommen. Das 
könntest du in dem Szenario nicht einhalten.
Die letzte fallende Flanke kam aber bei 0,184 ns - 5 ns = -4,816 ns an, 
die Daten dürften sich also frühestens bei -1,816 ns ändern. Das kannst 
du dann erfüllen.
Bei den Setup-Zeiten musst du dann natürlich auch die unterschiedlichen 
Flanken berücksichtigen. Und auf dem "Rückweg" musst du bedenken, dass 
der Takt weiterhin vom STM32 generiert wird.