Folgende Situation.. die Frage ist: Kann man das Board noch retten? FPGA hat 16bit Bus als Ausgang (LVCMOS33) und einen Clock-Eingang (LVCMOS33). Bei jeder steigenden Clock-Flanke soll der FPGA neue Werte am Bus ausgeben. Das Clock-Signal is variabel von DC bis 250 MHz. Alles intern im FPGA funktioniert mit dieser Rate nur leider bekomm ich die Verzögerung zwischen Clock und Signalausgabe nur auf Werte um die 6ns (Simulation: slew=fast, drive=12, OFD), benötige aber max. 4ns (1/250MHz). Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen" (bei 10ns also 100 MHz und 200 MHz). Irgendwelche Ideen? DCM, wenn ja wie? Es wäre akzeptabel, wenn beim Ändern der Frequenz 1 oder 2 Clocks verloren gehen.
Da de Ideen suchst: an den Datenausgang einen asynchronen Fifo hängen und mit dem asynchronen Takt wieder "synchronisieren". Wenn du einen internen Fifo nimmst, dann ist die Taktverzögerung geringer als an dem Pin.
Clock ebenfalls durchs FPGA führen. Also an einem Pin wieder ausgeben und die nachfolgende Schaltung mit dem verzögerten Takt betreiben.
> dose Jup an diese Idee hatte ich auch schon gedacht. Aber kennst du einen async FIFO, der noch bei 250MHz clock arbeitet? > Harald Flügel Klar, das würde helfen, ist aber leider nicht möglich. Die Clock kommt von außen und nicht aus dem FPGA. Also danke für die Ideen... aber hat noch jemand eine bessere?
Wie breit sind deine Daten? Ich habe mal einen Fifo in VHDL geschrieben. Da muss ich mal schauen ob dieser adaptierbar ist.
Mal rekapitulieren: Der Takt geht von DC bis 250 MHz. Eine DLL, mit der man den FPGA-internen Takt um eine feste Zeit vorverlegen könnte, scheidet damit aus. Der Takt kommt von außen und vesorgt sowohl FPGA als auch nachgeschaltete Logik. Somit ist das Ganze ein synchrones Design und hat damit eine Grenzfrequenz, die sich aus der Verzögerungszeit der Schaltelemente zwischen zwei Flipflops mit gleicher Taktquelle berechnet. Da ist nix zu machen. Punkt. Du kannst versuchen, die Clock-to-Output-zeit des FPGAs so gering wie möglich zu halten, aber das ist auch schon alles. Im übrigen stimme ich deiner Aussage unten nicht zu. Zitat: =====8<----- Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen" (bei 10ns also 100 MHz und 200 MHz). =====8<----- Wenn die Frequenz dumm liegt, dann ändern sich die Datenausgänge des FPGA just zu dem Zeitpunkt, zu dem die nachgeschaltete Logik die Daten einliest. Und selbst wenn diese nachgeschaltete Logik gegen Metastabilität gefeit sein sollte, kann es sein, dass sie Daten sieht, die das FPGA nie ausgegeben hat. So etwas kann vorkommen, weil durch unterschiedliche Verzögerungszeiten bei dem einen Bit schon der neue Wert gelesen wird und bei einem anden Bit noch der alte.
Mad Physicist schrieb: > Verzögerung > zwischen Clock und Signalausgabe nur auf Werte um die 6ns (Simulation: > slew=fast, drive=12, OFD), benötige aber max. 4ns (1/250MHz). 4 ns zwischen Ankunft der Taktflanke draußen am FPGA Pin und gültig stabilen Daten an den Ausgangsleitungen? Oder woanders? Falls ersteres sollte sich mit Datenblatt ermitteln lassen, ob das Signal überhaupt den Weg Pad zu Register bzw umgekehrt in unter 2 ns erledigen kann. Und da bin ich ziemlich skeptisch. Und wie hfl geschrieben hat gibt es dann Frequenzen, bei denen Müll heraus kommt. Ehrlich gesagt frage ich mich, ob da nicht das Konzept mal überdacht gehört. lg m
@Mad Physicist (Gast) >Das Clock-Signal is variabel von DC bis 250 MHz. Sowas ist immer sehr sinnvoll . . . > Alles intern im FPGA >funktioniert mit dieser Rate nur leider bekomm ich die Verzögerung >zwischen Clock und Signalausgabe nur auf Werte um die 6ns (Simulation: >slew=fast, drive=12, OFD), benötige aber max. 4ns (1/250MHz). Du brauchst ein paar Grundlagen und eingescheites Konzept. >Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung Und einen Deutschkurs. Das heißt Takt. >OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann >Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen" >(bei 10ns also 100 MHz und 200 MHz). Womit wir wieder beim Thema Murks wären . . . >DCM, wenn ja wie? Gar nicht bei so dermassen sinnlos, endlos schwankenden Taktfreqeunzen.
Vielen Dank für Eure Antworten! > dose 16 bit.. aber FPGA-Design hilft nicht, Clock-to-Output-Delay im FPGA ist einfach nicht unter 6ns zu bekommen. > Harald Flügel ("Im übrigen stimme ich deiner Aussage unten nicht zu. Zitat:") Im Gegenteil - den Sachverhalt den Du da beschreibst ist genau das was ich meine mit "überholen": Dass "wenn die Frequenz dumm liegt, dann ändern sich die Datenausgänge des FPGA just zu dem Zeitpunkt, zu dem die nachgeschaltete Logik die Daten einliest." Ich hab das nur nicht so gekonnt ausgedrückt und wollte im Eingangspost alles möglichst kurz halten. Bzw. das Problem ist nicht nur die Metastabilität, sondern auch eine leicht unterschiedliche Laufzeit der einzelnen Datenbits, so dass einige Bits vom alten und einige vom neuen Zustand erfasst werden. Ansonsten fürchte ich, dass Du recht hast, dass man nichts tun kann. Das dachte ich auch, wollte nur sicher gehen, dass ich nicht einfach zu doof bin mit dieser Einschätzung. > Matthias Woran das Problem liegt (wie Du und Harald Flügel es beschreiben) ist mir durchaus klar. Nur nicht worin die Lösung liegt falls es eine gibt... Datenblatt hab ich gewälzt, allerdings muss man da wohl mehrere spezifizierte Einzel-Timigs zusammenzählen. > Falk Brunner > Sowas ist immer sehr sinnvoll . . . ...genauso wie diese Zeile der Antwort... Es gibt nun mal gewisse Erfordernisse, die sich aus der zu erledigenden Aufgabe ableiten. > Du brauchst ein paar Grundlagen und eingescheites Konzept. ...ja, aber nicht die Basic-Grundlagen auf MK.net, sondern weiterführende. Wenn Du gute Links weißt - ich les gerne zum Thema FPGA! Wobei ich denke, bis auf diesen Punkt ist das Konzept sehr gut. Leider ist mir vorher nicht klar gewesen, dass die entsprechende Verzögerung im FPGA so groß wird. Genau genommen hab ich das ganze sowieso nur für 150 MHz geplant, aber da jetzt der FPGA intern noch bis 250 MHz ohne Probleme mitkommt und die nachgeschaltete Elektronik auf 250 MHz spezifiziert ist, ist es ärgerlich, dass es an der Schnittstelle hapert. Für eine Revision Null und dem ersten Spartan-3A-Projekt allerdings akzeptable Performance. > Und einen Deutschkurs. Das heißt Takt. Danke!!!!! Es gibt keinen hier im Forum, der "clock" nicht versteht. <switch-to-Falk-Brunner-Troll-Modus> Außerdem schreibt man "eingescheites" nicht zusammen, also offenbar brauchst Du einen Lücken-Setz-Kurs. </switch-to-Falk-Brunner-Troll-Modus> > Gar nicht bei so dermassen sinnlos, endlos schwankenden Taktfreqeunzen. Hatt's befürchtet. Wobei das Schwanken des Taktes nicht sinnlos ist. (Außerdem schreibt man "dermaßen" mit scharfem "ß" - wir treffen uns dann im Deutschkurs!) - Mad Physicist
250 MHz sind bei diesem synchronen systemansatz ausgeschlossen. 150 MHz kritisch. Wenn 6,66 ns periodenzeit hast und 6 ns c2o dann hast du rechnerisch noch 0,66 ns für die delays durch verdrahtung der chips und setup zeit des empfängers. Bedenke 10 cm draht sind ca. 0,5 ns. Wie ist das timing des empfängers überhaupt spezifiziert? Vorsicht folgender vorschlag erfordert sehr gute kenntnisse der STA!!! Bei manchen FPGA's lässt sich die c2o duch umgehen des globalen clock trees für die output register optimieren. Das würde so funktionieren: - der clock eingang wird direkt bei den daten ausgängen plaziert (mittig) - das clock signal wird zunächst direkt mit den output FF's verbunden - danach geht der clock auf das globale clock net und versorgt den rest Ob dies für deinen FPGA zielführend ist, kann ich dir nicht sagen. Ottmar
@Ottmar (Gast) Danke für Deine Einschätzung! Den fortgeschrittenen Ansatz mit (wie ich das verstehe) womöglich manuellem Routing auf dem FPGA werde ich mal im Hinterkopf behalten, erscheint mir mit meinem derzeitigen Kenntnisstand unrealistisch. Dennoch eine sehr interessante Idee! Eine murksige Lösung, die mir eingefallen ist, wäre folgende: In der Anwendung ändert sich der Takt andauernd um wenige Hz aufgrund einer Regelschleife und gelegentlich um große Schritte bei Wechsel des Betriebsmodus. Man baut also auf dem FPGA einen Frequenzzähler. Je nach Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY und/oder invertiert das Clock-Signal um setup/hold time im Empfänger einzuhalten. Muss man natürlich Hysterese vorsehen und ist evtl. nicht über den ganzen Temperaturbereich funktionell, aber für mich reicht's notfalls, wenn es bei Zimmertemperatur läuft. Ist ja kein kommertielles Produkt. - Mad Physicist
> wir treffen uns dann im Deutschkurs! - Mad Physicist Ja, wird wohl so sein... > Ist ja kein kommertielles Produkt. Sowas gibt es potenziell auch gar nicht... ;-) > Je nach Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY Funktioniert das bei einem Takteingang überhaupt? Oder: hast du den Lese-Takt überhaupt an einen Taktpin angeschlossen? > Es wäre akzeptabel, wenn beim Ändern der Frequenz 1 oder 2 Clocks > verloren gehen. Du könntest also mit einem konstanten Datenversatz um 1 oder 2 Takte leben?
Hab nochmal darüber nachgedacht. Es ist nicht ganz so aussichtslos. Du brauchst zwei clock modes und einen clock switch. In einem low frequency (LF) mode gehst du dierkt auf das interne clock netzwerk und somit auf die IO FF's. Timing wie gehabt. Im high frequency (HF) mode gehst du über die DCM und kompensierst damit die internen delays des clocktrees. Bzw. es wäre auch denkbar den feedback pfad der DCM über einen bidirectionalen buffer nach außen zu legen um auch die delay schwankungen der output buffer zu kompensieren. Umschalten zwischen LF und HF mode kannst du ab der min. arbeitsfrequenz der DCM's Wenn deine 6ns c2o bisher aus 2ns clocktree und 4ns output buffer bestanden dann kommst du so auf 4 ns. Wenn deine zahlen worst case waren, dann werden sie bei zimmertemperatur noch besser sein. Ottmar
> gehst du über die DCM
So ein DCM ist aber recht allergisch gegen variable Takte. Der wird
nicht schon nach 1-2 Takten wieder eingeschwungen sein...
Lothar Miller schrieb: >> gehst du über die DCM > So ein DCM ist aber recht allergisch gegen variable Takte. Der wird > nicht schon nach 1-2 Takten wieder eingeschwungen sein... Und Taktfrequenz bis 0 Hz mag die DCM auch nicht !
Lothar Miller schrieb: >> gehst du über die DCM > So ein DCM ist aber recht allergisch gegen variable Takte. Der wird > nicht schon nach 1-2 Takten wieder eingeschwungen sein... Für frequenzsprünge absolut richtig. Aber eine gewisse "langsame" frequenzänderung können sie ab. Was die DCM's hier mitmachen kann der TO ja mal analysieren. :-)
@ Lothar Miller & Ottmar Vielen Dank für die Ideen! > Du könntest also mit einem konstanten Datenversatz um 1 oder 2 Takte > leben? Ja. Und der darf sich bei Frequenzwechsel auch gelegentlich um 1-2 Takte verschieben (solange Hysterese vorhanden, d.h. die Änderung der Freq um einen kleinen Betrag hin und zurück darf nicht dazu führen, dass der Versatz sich vor und zurück ändert; das darf nur bei großen Änderungen passieren). >> Je nach Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY >Funktioniert das bei einem Takteingang überhaupt? > Technisch kein Problem. Ich kann entweder einen IBUFG oder einen IBUF_DLY_ADJ an einem GCLK-Input verwenden. Mit anpassparer delay kann mann dann einen BUFG nachschalten um wieder aufs globale clock netz zu kommen. Verlängert natürlich die Zeit; insgesamt clock-to-output ca. 10ns laut Simulation. > Für frequenzsprünge absolut richtig. Aber eine gewisse "langsame" > frequenzänderung können sie ab. ...genau das ist meine Angst: Dass mir die DLL bei den durch die Regelschleife verursachten kleinen Taktänderungen raus fliegt und das wäre nicht akzeptabel. Und die schwingt dann auch nicht schnell ein sondern muss laut Datenblatt vollständig zurückgesetzt werden. > Und Taktfrequenz bis 0 Hz mag die DCM auch nicht ! Genau, allerdings für Frequenzen unterhalb der DCM-Minimalfrequenz (5 MHz) kann das Design locker ohne irgendwelche zusätzlichen Vorkehrungen arbeiten. @Ottmar > Du brauchst zwei clock modes und einen clock switch. In einem low > frequency (LF) mode gehst du dierkt auf das interne clock netzwerk und > somit auf die IO FF's. Timing wie gehabt. > Im high frequency (HF) mode gehst du über die DCM und kompensierst damit > die internen delays des clocktrees. > Das ist ein ganz interessanter Ansatz... kombiniert Frequenzzähler und DLL. Nicht ganz so "murksig" wie der ursprüngliche Freqzähler-Ansatz. Wie gesagt, kann aber sein, dass die DLL öfters rausfliegt und das wäre nicht gut. Aber vielleicht kann man durch manuelles Anpassen der Verzögerung in der DLL was erreichen. - Mad Physicist
Leute, ihr seid ganz schön abgefahren! Gut, das war in diesem Thead auch die Forderung, aber trotzdem. @ Mad Physicist Auch wenn Du eine Lösung hinbekommst: Verhindere bitte nicht, dass derjenige, der das Problem verursacht hat, etwas daraus lernt. Wer auch immer das ist. Wie sagen doch die Briten so treffend: garbage in garbage out.
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.