www.mikrocontroller.net

Forum: FPGA, VHDL & Co. SPI-Slave im FPGA, Signal-Delay an MISO minimieren


Autor: noips (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

ich habe vor ein Paar Wochen mit FPGA-Anwendung und VHDL angefangen und 
habe ein SPI-Slave im FPGA (Lattice LFECP33E, Speed-Stufe 4) aufgebaut. 
Den Code dafür habe ich aus einem Lattice Reference Design. Die 
SPI-Taktfrequenz ist 50 MHz.

Nun tritt folgendes Problem auf:
Der Slave soll die Daten bei fallender SCK-Flanke an MISO legen, so dass 
sie bei der steigender SCK-Flanke vom Master eingelesen werden. Bei 50 
MHz ist der Abstand fallende zu steigende Flanke 10 ns. In der 
FPGA-Schaltung entsteht aber ein Delay von ca. 11 ns, das heißt der 
Slave legt Daten an MISO erst 11 ns nachdem er die fallende Clock-Flanke 
bekommen hat. Somit liest der Master ungültige Daten ein.

Und meine Fragen:

Ist das Delay von ca. 11 ns im Normalfall auch zu erwarten (aus eurer 
Erfahrung) oder sind bei richtiger Anwendung viel niedrigere Werte 
erreichbar?

Im Angehängten Datenblatt meine ich folgendes zu erkennen:

Seite 3-14: t_CO (Clock to Output - PIO Output Register)  max 6.11 ns
Seite 3-16: t_OUT_PIO (Output Buffer Delay) max 2.31 ns

Addiert man diese 2 Werte, kommt man schon auf über 8 ns Signal-Delay. 
Wenn man noch die Gatter-/FF-/Routing-/ Leiterbahn-Laufzeiten 
berücksichtigt kommt man schnell an 11 ns. Die Angaben sind allerdings 
Maximal-Werte und ich habe leider noch keine Erfahrung wie weit unter 
den max. Werten die Normalwerte so liegen.

Lässt sich das Delay durch irgend welche Optimierungen verbessern?

Danke schon mal für jeden Hinweis/Antwort!!!!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Somit liest der Master ungültige Daten ein.
Falscher SPI-Mode? Schlechtes Layout? Leitung nicht terminiert? Hast du 
die Signale mal mit einem (ausreichend schnellen) Oszilloskop gemessen?

> Der Slave soll die Daten bei fallender SCK-Flanke an MISO legen,
Was spricht dagegen, die Daten mit der steigenden Flanke an MISO 
auszugeben? So wie es aussieht hältst du die Hold-Zeit beim Master 
garantiert ein...

> Ist das Delay von ca. 11 ns im Normalfall auch zu erwarten (aus eurer
> Erfahrung) oder sind bei richtiger Anwendung viel niedrigere Werte
> erreichbar?
Du mußt ganz einfach mit dem schlechtesten Wert rechnen. Alles andere 
ist auf dem Niveau von Handauflegen und Gesundbeten...

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!!!

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.
Diese Definition wurde erst später eingeführt. Denn SPI ist ursprünglich 
ja nichts anderes als gekoppelte Schieberegister. Die ersten SPI waren 
einfach nur Schieberegister mit 1 Takt, der schiebt. Und die 
Datenübernahme erfolgte dann durch den Slave-Select. Viele SPI-Slaves 
arbeiten auch heute noch so. Es müssen ja "nur" die Datenleitungen 
rechtzeitig (Setupzeit) vor der aktiven Taktflanke stabil anliegen...

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/messagevie...

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

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was meint ihr, wenn ich die Frage an Lattice schreibe, kann ich mit
>einer Antwort rechnen?
Ich kann mich über die Arbeit des Supports bei Lattice nicht beschweren.

>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.

Zu dieser Zeit kommt noch eine zusätzliche Zeit dazu, die vom gewählten 
Ausgangstreiber-Standard abhängt (wie Klaus schon geschrieben hat).

Zu beachten ist, dass diese Rechnung nur stimmt, wenn wirklich ein IO-FF 
verwendet wird. Liegt das letzte FF auf dem Signal in der Logik des 
FPGAs, so kann eine erheblich längere Laufzeit dabei herauskommen.

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> Bei 50
> MHz ist der Abstand fallende zu steigende Flanke 10 ns. In der
> FPGA-Schaltung entsteht aber ein Delay von ca. 11 ns, das heißt der
> Slave legt Daten an MISO erst 11 ns nachdem er die fallende Clock-Flanke
> bekommen hat. Somit liest der Master ungültige Daten ein.

Nur wenn du den internen SCK verwendest. Du kannst den externen SCK 
wieder an ein Pin des FPGAs legen und damit dein Schieberegister takten. 
Dann musst du nur noch das Problem lösen, deine Daten wieder in deine 
allgemeine Clock-Domän zu bekommen, z.B. mit einem EBR. Der kann zwei 
verschiedene Takte verarbeiten.

Tom

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Und üblicherweise bezieht sich dies auf den INTERNEN Takt, also der Takt 
der am Clockeingang des IO-FFs anliegt.
Wenn nun der Takt SCLK von außen kommt, dann kommen die Laufzeiten von 
Pin SCLK zur internen Taktleitung, sowie die Laufzeiten zum IO-FF dazu, 
bis sich aufgrund einer Flanke am SCLK eine Änderung am getakteten 
Ausgangspin einstellt.

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/messagevie...

Ü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!

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> Thomas Reinemann schrieb:
MÜLL, es war wohl etwas spät.

>> 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?

Ich habe gedacht, der FPGA ist Master und erzeugt den Takt.

Thomas

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> 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.

Wenn du sowohl auf den Master als auch den Slave Einfluss nehmen kannst, 
dann hast du u.U. die Möglichkeit einen differentiellen Takt zu 
benutzen. Der hat eine bessere Flankensteilheit. Diesen gibt der Master 
aus und liest ihn wieder ein, der Slave sowieso. Im Slave muss das FF 
dan in den IOB. Die Laufzeiten auf der Platine sind dann nicht mehr so 
tragisch.

Zu solchen Probleme kannst du auch einen Lattice-FAE fragen.

Tom

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Reinemann schrieb:
> Im Slave muss das FF
> dan in den IOB.

Was ist IOB?

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
>> Im Slave muss das FF
>> dan in den IOB.
>
> Was ist IOB?

IO-Buffer

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> 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:

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

Tom

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> 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.

Natürlich ist sie da, diese Zeit beträgt eine Taktperiode, die du kennst 
und mit simuliert wird. Wenn du angibst, dass das FF im IOB genutzt 
werden soll, wird dein letztes FF in den IOB verschoben. Es wird kein 
zusätzliches eingefügt. In dem Fall käme das Signal ja einen Takt 
später.

Tom

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noips schrieb:
> 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.

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.

Die Laufzeiten addieren sich nicht über die Grenzen von FFs. Das ist 
dann Latenz.

Tom

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Falser schrieb:
> 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.
>
> Und üblicherweise bezieht sich dies auf den INTERNEN Takt, also der Takt
> der am Clockeingang des IO-FFs anliegt.
> Wenn nun der Takt SCLK von außen kommt, dann kommen die Laufzeiten von
> Pin SCLK zur internen Taktleitung, sowie die Laufzeiten zum IO-FF dazu,
> bis sich aufgrund einer Flanke am SCLK eine Änderung am getakteten
> Ausgangspin einstellt.

Wenn ich die Zeiten mit einem Xilinx FPGA Spartan 3 vergleiche, dann 
kommen mir die 7 ns doch zu hoch für um auf den internen Takt bezogen zu 
sein.
Bei einem Xilinx XCS3 z.B. ist die TICKOF Zeit folgendermaßen definiert:

When reading from OFF, the time from the active transition on the Global 
Clock pin to data appearing at the Output pin. The DCM is not in use.

Die Zeiten sind in der Größenordnung von 4-5 ns, also müsste so etwas 
mit einem Lattice wahrscheinlich auch zu erreichen sein. Die Zeiten 
werden aber bei den größeren Bausteinen aber größer, kann sein, kann 
sein, dass dein großer Lattice es zu langsam macht.

Wie ich aber vorher schon geschrieben habe, kommt mir das ganze bei 50 
MHz zu grenzwertig vor.
Du hast verschiedene Laufzeiten, die eine Rolle sich addieren, und Du 
hast nur 10 ns Zeit:
- Laufzeit aussteigende Flanke SCK Master SPI - Slave SPI (1 ns/30 cm)
- Reaktionszeit des SPI Slave auf SCK (dein momentanes Problem, sicher 
nicht unter 4-5 ns zu schaffen)
- Laufzeit SDO Slave -> SDI Master
- Setup Zeit Master vor fallender Flanke SCK (wird auch in der 
Größenordung von 4-5 ns liegen)

In Summe kommen diese Zeiten sehr nahe an die 10 ns heran, und ein 
bischen Sicherheit sollte auch noch drinnen sein.
Das heißt nicht, dass es nicht möglich ist mir 50 MBd zu übertragen, 
aber halt nicht genau mit SPI.

Ob Du bei deine Versuchen mit der Verwendung des internen Taktnetzes 
etwas falsch gemacht hast, weiss ich nicht, wahrscheinlich nicht.
Bei den meisten Applikationen kann man die interne PLL (oder DLL) 
verwenden, die solche Verzögerungen kompensiert.
Dann spielen die direkten Laufzeiten vom Pin zum Taktverteilernetz keine 
große Rolle.

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: noips (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.