SPI-Slave im FPGA, Signal-Delay an MISO minimieren

> Falscher SPI-Mode?
SPI-Mode stimmt! Die Übertragung funktioniert bei niedrigeren Frequenzen 
gut (mit 25MHz getestet).

> Schlechtes Layout?
Ich arbeite noch mit einem Entwicklungsboard Hpe-mini von Gleichmann 
Electronics Research. SPI-Master und SPI-Slave sind im gleichen FPGA. 
Die Signale sind auf eine Stiftleiste rausgeführt (ca. 7cm vom FPGA 
entfernt), auf der ich die entsprchenden Stifte per Jumper bzw. kurze 
Drahtbrücken verbunden habe (MOSI-Master mit MOSI-Slave, MISO-Master mit 
MISO-Slave usw.).

> Leitung nicht terminiert?
Die Signalwege sind ja relativ kurz. Am Oszi sieht man zwar geringe 
Reflexionen, aber sie sind nicht das Problem. Wie gesagt, bei 
niedrigeren Frequenzen (25MHz) funktioniert es ja. Die Anstiegszeit der 
Signale ist doch bei 50MHz und bei 25MHz gleich.


> Hast du
> die Signale mal mit einem (ausreichend schnellen) Oszilloskop gemessen?

Ja. Ich arbeite mit einem Infinium von Hewlett Packard 500 MHz, 2 GSa/s.


> Was spricht dagegen, die Daten mit der steigenden Flanke an MISO
> auszugeben?
Dann muss der Master ja mit der fallender Flanke die Daten an MISO 
lesen. Der Abstand zwischen steigender und fallender Flanke bleibt aber 
bei 10ns. Das Delay bleibt auch bei 11ns und der Master wird auch dann 
ungültige Daten einlesen.


> So wie es aussieht hältst du die Hold-Zeit beim Master
> garantiert ein...
Sorry, leider verstehe ich nicht was Du damit meinst.

Danke für Deine Atwort!!!

noips schrieb:
>> Was spricht dagegen, die Daten mit der steigenden Flanke an MISO
>> auszugeben?
> Dann muss der Master ja mit der fallender Flanke die Daten an MISO
> lesen. Der Abstand zwischen steigender und fallender Flanke bleibt aber
> bei 10ns. Das Delay bleibt auch bei 11ns und der Master wird auch dann
> ungültige Daten einlesen.

nein! Der Master kriegt davon gar nix mit. Dein Slave nimmt einfach die 
Flanke, mit der er empfaengt und mit der schickt er auch die Daten raus: 
Also 10ns frueher. Damit hast du die 'Flugzeit' kompensiert.

Musst nur aufpassen, dass das erste Bit (wenn min neg.edge nCS 
losgeschickt) auch in das Raster passt. Da kannst du aber meist im uC 
eine sog. Leadtime einstellen.

berndl schrieb:
> nein! Der Master kriegt davon gar nix mit. Dein Slave nimmt einfach die
> Flanke, mit der er empfaengt und mit der schickt er auch die Daten raus:
> Also 10ns frueher. Damit hast du die 'Flugzeit' kompensiert.

Ah, so ist es gemeint! Dann ist es aber kein richtiges SPI-Protokoll 
mehr, denn bei allen vier möglichen SPI-Modes wird ja bei einer Flanke 
(steigend/fallend) geschrieben und bei der anderen Flanke 
(fallend/steigend) gelesen.

Vielen Dank für eure Hilfe!! Als Neuling auf diesem Gebiet bin ich in 
vielem noch ziemlich unsicher.

Ich habe Probleme mit den Angaben im Datenblatt. Könntet ihr bitte 
reinschauen und mich aufklären, falls sich jemand die Zeit dafür nehmen 
will.

Auf Seite 3-14 in der Tabelle "External Switching Characteristics":

t_CO (Clock to Output - PIO Output Register)  bei LFEC33 max 7.42 ns

Auf der Seite 3-16 in der Tabelle "Internal Switching Characteristics":

t_OUT_PIO (Output Buffer Delay) max 2.31 ns

Was besagen diese Angaben. Die erste verstehe ich als die Zeit von der 
positiven (oder negativen je nach dem) Flanke des CLK-Signals bis das 
Datensignal am Ausgang anliegt. Nur an welchem Ausgang? Ist damit schon 
der Ausgangspin gemeint oder der Ausgang des Registers intern. Da die 
Tabelle "External ...." heißt, würde ich sagen, der Pin ist gemeint, 
aber was bedeutet dann die zweite Angabe. Welcher Buffer ist gemeint? 
Ist das der Buffer zwischen Register-Ausgang und dem Ausgangspin? 
Irgendwie finde ich diese Angaben nicht deutlich genug, es liegt aber 
wohl nur daran, dass ich noch wenig Ahnung von der Materie habe.

Danke für jede Art von Hilfe!!!

In Deinen Fall kommen mehrerer Verzögerungen zusammen.
Da ich den Lattice Baustein nicht kenne, gehe ich einmal davon aus, wie 
es bei einem Xilinx wäre.

Zuerst einmal hast Du den Pin mit SCLK. Diese wird günstigerweise an 
einen Pin geführt, der als CLK Pin gedacht ist, da diese schneller an 
interne CLK-Verteilernetz angeschlossen ist.
Zwischen Pin und internem Netz gibt es eine Verzögerung. Diese kann man 
zwar bei den meisten FPGAs mit Hilfe einer DLL kompensieren, das geht 
aber mit dem SPI Clock nicht, da dieser  nicht konstant anliegt.
Du must also mit dieser Verzögerung leben.
Wenn den SCLK Pin nicht an einen speziellen Takteingang angeschlossen 
wird, muß man sehen ob das interne Taktverteiler-Netzwerk überhaupt 
verwendet wird.

Dann hast Du den MISO-Ausgang. Im Idealfall ist das ein spezielles FF in 
der Ausgangszelle, das nur mehr den Wert nach außen schaltet. In diesem 
Fall erscheint der Ausgangwert nach der Clock_to_Output Zeit (bezogen 
auf den internen Takt) am Pin. Dazu kommen  noch Verzögerungswerte, die 
mit der eingestellten Treiberstärke zusammenhängen.

Wenn dein Schieberegister aber komplett innerhalb des FPGAs liegt, dann 
zählen die interne Schaltzeit des FF, die Routing-Zeit zwischen diesem 
FF und der Pin, und das Pin (Output driver) hat auch noch eine 
Verzögerung.

Ich denke, ein SPI Interface mmit 50 MHz zu betreiben ist schon recht 
sportlich.
Die oben empfohlenen Abhilfen wie z.B. auf der falschen Flanke zu 
schalten, kann man zwar machen, aber wie Du erkannt hast, ist es dann 
eben kein richtiges SPI Interface mehr, sondern eine Sonderlösung, die 
nur unter bestimmten Bedingungen funktioniert.
Persönlich würde ich Dir empfehlen, das SPI Interface sauber zu halten, 
und wenn möglich mit der Taktfrequenz auf die Hälfte oder tiefer 
herunterzugehen.

Klaus Falser schrieb:
> Zuerst einmal hast Du den Pin mit SCLK. Diese wird günstigerweise an
> einen Pin geführt, der als CLK Pin gedacht ist, da diese schneller an
> interne CLK-Verteilernetz angeschlossen ist.

Hm, das kann ich nach einem Versuch nicht bestätigen. Wenn ich SCLK an 
einen CLK-Pin des FPGAs anschließe, wird das ganze noch langsamer. Im 
Physical View des Floorplanners kann man sehen, wie das SCLK-Signal dann 
geroutet wird. Es läuft zuerst bis ca. Mitte des Chips (weil dort 
wahrscheinlich das Zentrum des Taktverteilernetzes ist) und von dort 
wird es an die CLK-Eingänge der Logik geführt. Die Zeit, bis SCLK an der 
Logik ankommt beträgt in diesem Fall ca. 5 ns.

Wenn man dagegen dem Router-Tool die Verwendung des Taktverteilernetzes 
für SCLK-Signal verbietet ( Prohibit Both (Primary and Secondary 
Clock)), wird mit Verwendung der Local Wires in der Nähe der Logik 
geroutet und SCLK kommt mit einer Verzögerung von nur ca. 2 ns an der 
Logik an.



Klaus Falser schrieb:
> Dann hast Du den MISO-Ausgang. Im Idealfall ist das ein spezielles FF in
> der Ausgangszelle, das nur mehr den Wert nach außen schaltet. In diesem
> Fall erscheint der Ausgangwert nach der Clock_to_Output Zeit (bezogen
> auf den internen Takt) am Pin. Dazu kommen  noch Verzögerungswerte, die
> mit der eingestellten Treiberstärke zusammenhängen.

Ist damit gemeint, dass das letzte FF des Ausgangsschieberegisters ein 
spezielles FF ( in Ausgangszelle ) sein sollte und nicht ein normales 
aus den Logical Units des FPGAs?


Könnte mir jemand veilleicht erklären, was der folgende Wert auf Seite 
3-14 in der Tabelle "External Switching Characteristics" bedeutet:

t_CO (Clock to Output - PIO Output Register)  bei LFEC33 max 7.42 ns ?

Irgend wie kann ich den niergends zuordnen!

Danke schön!

Vielleicht ist doch jemand da, der Erfahrung mit Lattice FPGAs hat und 
mir sagen könnte, was das für ein Wert ist? Wenn ihr es nicht genau 
wisst, habt ihr vielleicht Vermutungen?

Was meint ihr, wenn ich die Frage an Lattice schreibe, kann ich mit 
einer Antwort rechnen?

Was kann man sich als Antwort von einer Firma erwarten, bei denen das 
Application Engineering im offiziellen Forum nicht einmal imstande ist, 
eine negative Setup-Zeit richtig zu erklären :

http://www.latticesemi.com/forums/forum/messageview.cfm?catid=921&threadid=12772&enterthread=y

Von Equation A auf B wird auf einmal aus einem Minus ein Plus und der 
ganze Rest stimmt dann auch nicht mehr.

Hallo Klaus!

Stimmt, da hat der Autor was total durcheinander gebracht! Zuerst müssen 
Daten 200 ps vor dem Clock da sein, dann kommt dazu, dass Daten eine um 
300 ps längere Laufzeit als Clock haben, aber als Ergebnis müssen sie 
jetzt nur noch 100 ps vor dem Clock da sein. Geniale Technik!

Übrigens, könntest du mir bitte die Frage zu deinem letzten Beitrag 
beantworten, die ich gleich danach gepostet habe?

Zuerst mal Danke für eure Antworten!

Jan M. schrieb:
>>t_CO (Clock to Output - PIO Output Register)
> Das ist die Zeit zwischen der Taktflanke am Ausgangs-Flipflop und dem
> Zeitpunkt, an dem die Daten am Pad ankommen.

OK. In der Tabelle auf der Seite 3-16 gitb es noch eine Angabe, die sehr 
ähnlich aussieht:

t_COO_PIO   Output Register Clock to Output Delay     0.4 ns

Wie ist dieser Wert zu verstehen? Anhand der Beschreibung würde ich 
denken, die Werte sind dasselbe, aber zahlenmäßig ist der Unterschied 
schon sehr groß, also müssen sie was unterschiedliches bedeuten.

Jan M. schrieb:
> Ich kann mich über die Arbeit des Supports bei Lattice nicht beschweren.

Im Lattice-Forum hat jemand die gleiche Frage schon gestellt, leider 
steht die Antwort bis jetzt nicht da.

http://www.latticesemi.com/forums/forum/messageview.cfm?catid=32&threadid=7825&enterthread=y

Übrigens, hast du dir schon die Erklärung zu negativen Setup/Hold-Zeiten 
angeschaut, auf die Klaus weiter oben gelinkt hat. Ziemlich peinlich, 
der Fehler, oder?

Thomas Reinemann schrieb:
> Nur wenn du den internen SCK verwendest. Du kannst den externen SCK
> wieder an ein Pin des FPGAs legen und damit dein Schieberegister takten.

Sorry, das habe ich jetzt nicht verstanden. Was meinst du mit internem / 
externem SCK? Meinst du, der SCK des Masters, der auf der Leitung zum 
Slave liegt, soll über einen Pin wieder dem Master zugeführt werden, und 
den MISO-Schieberegister des Masters takten? Habe ich das richtig 
verstanden?


@ Klaus

Du hast weiter oben empfohlen, den SCK an einen Takt-Pin des FPGAs zu 
führen, weil das schneller wird. Ich habe das ausprobiert komme zu einem 
anderen Ergebnis, wie weiter oben schon beschrieben. Habe ich da was 
falsch gemacht?

Danke!

Thomas Reinemann schrieb:
> Ich habe gedacht, der FPGA ist Master und erzeugt den Takt.

Doch, das ist evtl. was für mich. Ich implementiere zwar einen SPI-Slave 
im FPGA, aber der Master ist auch ein FPGA. Wenn ich es richtig 
verstanden habe, wird im SPI-Master der Empfangsregister (also MISO) 
nicht mit dem SCK im FPGA getaktet, sondern mit einem weiteren 
SCK-Signal, der so entsteht, dass man den SCK von dem Bus (extern) 
wieder über einen FPGA-Pin in den FPGA einführt.

Das klingt schon interessant. Ich frag mich halt nur, ob das Delay, das 
in diesem zweiten SCK-Signal auf diese Weise entsteht, ausreichend ist. 
Die Daten haben ja einen weiteren Weg, weil sie aus dem Schieberegisters 
des Slaves mit dem Clock rausgetaktet werden.

Thomas Reinemann schrieb:
> Im Slave muss das FF
> dan in den IOB.

Was ist IOB?

Thomas Reinemann schrieb:
> Im Slave muss das FF dan in den IOB.

Wenn man die Clock-to-Out Zeiten der FFs in Ausgangszelle (Buffer) und 
im FPGA-Kern vergleicht (Seite 3-16 im Datenblatt), dann ist ein Vorteil 
von Ausgangszellen-FFs nicht gerade ersichtlich:

t_CK2Q_PFU   Clock to Q Delay, D-type Register Configuration   0.44 ns

tCCO_PIO     Output Register Clock to Output Delay             0.40 ns

Wo liegt denn genau der Vorteil der Verwendung von Ausgangszellen-FFs 
für Ausgangssignale? Das ist mir noch nicht richtig klar?

Danke!

Thomas Reinemann schrieb:
> Das FF liegt eben im IOB am Rande des Dies, es fallen keine/kleinere
> Laufzeiten an, bis das Signal am Pin ist.

Gut, aber meistens durchläuft ein Signal ja mehrere Ebenen von Logik/FFs 
(auch wenn es nur 2 sind) und wenn die letzte Ebene (ein FF) in 
Ausgangszelle liegt und die vorletzte irgendwo in der Mitte des Chips, 
dann ist die längere Laufzeit nach außen eben an dieser Stelle (zwischen 
innenliegendem-FF und dem Ausgangszellen-FF) aber sie ist trotzdem da. 
Dann spielt es aber keine Rolle, wo das längste Glied der Kette ist, die 
Gesamtlaufzeit wird ja trotzdem lang bleiben. Ich hoffe, ich konnte 
verständlich erklären, was mir nicht klar ist. Oder sehe ich was falsch?

Thomas Reinemann schrieb:
> Es wird kein
> zusätzliches eingefügt. In dem Fall käme das Signal ja einen Takt
> später.

Ich glaube, ich habe was anderes gemeint, als du verstanden hast. Sorry, 
vielleicht ist meine Erklärung auch nicht so klar.

Ich habe auch nicht gemeint, dass ein FF zusätzlich eingefügt wird. Ich 
versuche es nochmal. Angenommen, mein Signal muss 2 FFs durchlaufen, 
bevor es den Chip verlässt. Die FFs können jetzt auf zwei 
unterschiedliche Weisen angeordnet werden:

1. Beide FFs sind eng zusammen irgendwo in der Mitte des Chips. Die 
Laufzeit zwischen den FFs ist sehr kurz. Es entsteht aber eine lange 
Laufzeit vom zweiten FF bis zu dem Rand des Chips, wo der Pin ist.

2. Das erste FF ist irgendwo in der Mitte des Chips und das zweite in 
einer Ausgangszelle am Rande des Chips. Dann gibt es eine lange Laufzeit 
vom ersten FF bis zum zweiten und die Verbindung zwischen dem zweiten FF 
und dem Pin ist sehr kurz.

In diesen beiden Fällen ist eine lange Laufzeit da, egal ob man das 
letzte FF in der Mitte oder am Rand des Chips anordnet. Darum verstehe 
ich nicht, wo der Vorteil der 2. Anordnung ist.

Besten Dank für die ausführlichen Erklärungen!!

Thomas Reinemann schrieb:
> Weil die Laufzeit eines Signals zwischen zwei FFs so groß sein kann wie
> deine Taktperiode. Es ist egal wie weit die FFs auseinander sind,
> hauptsache die Laufzeit (inkl. Setup und Hold-Time) ist kleiner als die
> Taktperiode. Das ist der Sinn von synchronen Designs, die FFs schalten
> eben synchron.

OK, endlich habe ich es verstanden, wo der Vorteil sein sollte. Es ist 
dann die Voraussetzung, dass die Laufzeit zwischen FFs (mit Setup und 
Hold) unter der Dauer der Takt-Periode bleibt. Wenn die FFS weit 
auseinander sind kann es dann schwer werden, wenn die Frequenz hoch ist 
(bei mir ist die Taktfrequenz 100 MHz). Dann entsteht ein Problem an 
einer anderen Stelle eben, aber das ist dann schon ein anderes Thema.

Danke schön!!

Übrigens, was diesen Fehler von Application Engineering auf der 
Lattice-Seite angeht ( siehe 
Beitrag "Re: SPI-Slave im FPGA, Signal-Delay an MISO minimieren"), ich habe über den 
Link "Report this to a Moderator" Lattice auf diesen Fehler hingewiesen, 
aber die Seite ist noch im Netz. Mal sehen ob die überhaupt darauf 
reagieren!