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!!!!
> 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...
> 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.
> 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...
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?
>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.
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
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.
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!
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
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.
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
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!
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
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?
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
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.
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
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.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.