Hallo, Ich stehe davor demnächst ein größeres FPGA Projekt zu beginnen. Mit groß meine ich jetzt für meine Verhältnisse groß. D.h. externe Komponenten wie mehrere ADCs, SDRAM, FX2,... Das ist jetzt nicht so extrem groß, aber größer als alles was ich bisher gemacht habe. Daher meine Frage: Gibt es Richtlinien für größere Projekte? Ich meine jetzt nicht unbedingt wie man das Projekt strukturiert bekommt. Vorher werde ich sicher genau definieren, was die FPGA am Ende machen soll und nicht drauf los designen. Das ich im Projekt den Überblick verliere ist auch nicht meine Befürchtung. Mit Instantiierungen sollte das ganze übersichtlich machbar sein. Meine Frage ist ehr: Was ändert sich, wenn das Design größer wird? Beispiel Zustandsmaschine: Es ist klar, dass die nicht beliebig viele Zustände haben kann, aber was ist maximal möglich/sinnvoll? Gibt es andere Dinge über die man sich da Gedanken machen muss? Was sind die schlimmsten Fehler mit denen man sich ein Design langsam machen kann? Oder ist das ganze gar nicht so wild wie ich es mir vorstelle und es ist nicht mehr oder weniger zu beachten als bei einem "ordentlichen" kleineren design? Viele Grüße, Christian
Gast
#917251
>Ich stehe davor demnächst ein größeres FPGA Projekt zu beginnen. Benutzt Du eine fertige Platine für den FPGA, oder machst Du sie selbst? Beim selber machen kann man natürlich einiges falsch oder zumindest ungünstig machen. Leider.
Die Platine mache ich selbst. Damit habe ich aber auch ein wenig mehr Erfahrung (Betonung auf wenig). Sicher wird sich im nachhinein herausstellen, dass ich den einen oder anderen Fehler gemacht habe. Für das Projekt eine Platine zu machen ist für mich aber auf jeden Fall der nächste Schritt. Für fast jeden Teil der Schaltung habe ich etliche Prototypen gebaut und getestet, die natürlich nur die Teilfunktion erfüllen. Ich wüsste keinen sinnvollen Schritt, den ich noch vor dem erstellen der großen Platine machen könnte. Was für typische Fehler wüsstest du denn?
Gast
#917277
>Was für typische Fehler wüsstest du denn? Ich habe bisher noch keine Platine mit einem FPGA selbst gemacht, kommt aber wahrscheinlich in den nächsten Monaten. Ich gehe eigentlich fest davon aus, dass mein erster Prototyp nicht funktionieren wird: Vertauschte Leitungen, insbesondere die zur Konfiguration des FPGA. Probleme durch Signallaufzeiten, Reflexionen... Da können Dir Andere sicher mehr sagen, vielleicht der derzeit so schweigsame Herr Brunner.
Mein großer Vorteil ist, dass ich nicht unter Zeitdruck stehe. D.h. ich kann alles 10 mal Kontrollieren. Reflektionen sind nicht meine größte Sorge. Bei Frequenzen von 50 bzw 133 MHz und Leitungslängen von wenigen cm rechne ich nicht mit großen Schwierigkeiten. Aber das kann man ja in IBIS mal testen.
@ Stefan Salewski (Gast) >Ich gehe eigentlich fest davon aus, dass mein erster Prototyp nicht >funktionieren wird: Vertauschte Leitungen, insbesondere die zur >Konfiguration des FPGA. Probleme durch Signallaufzeiten, Reflexionen... Warum sooo pessimistisch? Aller Wahrcheinlichkeit werden Fehler drauf sein, ja. Aber meist läuft der Prototyp, wenn auch mit kleineren oder grösseren Korrekturen. >Da können Dir Andere sicher mehr sagen, vielleicht der derzeit so >schweigsame Herr Brunner. Die Wissenden reden nicht. Die Redenden wissen nicht. Laotse @ Christian H. (cavorca) >Reflektionen sind nicht meine größte Sorge. Bei Frequenzen von 50 bzw >133 MHz und Leitungslängen von wenigen cm rechne ich nicht mit großen >Schwierigkeiten. Aber das kann man ja in IBIS mal testen. Lass das mal nicht MC Murphy hören . . . . 133 MHz SDRAM hat so Pi mal Dauem 1ns Anstiegszeit. -> 20cm Laufzeit -> ab 3cm Reflexionen etc. Siehe Wellenwiderstand Was sollte man beachten? Hmmm Grübel Hardware: - Solide Spannungsversorgung - Prüfen, ob eine Einschaltreihenfolge der verschiedenen Spannungen nötig ist - Prüfen, ob beim Einschalten ein hoher Strompuls benötigt wird - Prüfen, elche verschiedenen IO-Spannungen benötigt werden - Bei schnellen Signalen, den Wellenwiderstand beim Layout beachten - Ein paar frei Pins auf in Stecker legen, zum Testen - JTAG/Programmieranschluss auf einen Stecker legen (keine Einzelpins!) Software: - Design sinnvoll in Module gliedern, eher ein bisschen mehr als zu wenig - Ein SOLIDES Konzept erstellen und durchdenken - Taktkonzep , sehr wichtig. Mit so wenig wie möglich verschiedenen Takten arbeiten - Voll synchrones Design, keine asynchronen Tricks, Siehe auch Taktung FPGA/CPLD - Taktverteilung für IO solide planen. Takte kann man nicht einfach mal auf ein beliebiges IO Pin geben und zu nem IC routen. Das geht in den meisten Fällen NICHT, Siehe SDRAM-Timing - Pinbelegung sinnvoll strukturieren, dabei auf einfaches Layout achten und die verschieden IO-Bänke mit möglicherweise verschiedenen IO-Spannungen beachten; IO Pins kann man immer noch ein wenig per Software tauschen, bei Takten geht das meistens NICHT - IO-Treiber so langsam und schwach wie möglich einstellen, um Probleme mit Reflexionen und EMV zu minimieren - Wenn asynchrone Takte/Signale vorhanden sind, diese sehr solide und vorsichtig behandeln (Asynchrone FIFOs, doppeltes Abtasten vor der Nutzung in State-Machines etc.) - Ausgangssignale möglichst über FlipFlops treiben, das macht das IO-timig schneller, selbes für Eingangssignale Simulation - Verhaltensimulation reicht im allgemeinen aus. Post Place & Route Simulation ist aufwändig und langsam. In einem soliden synchronen Design reicht eine automatische Timinganalyse Und noch viele Dinge mehr, die mir spontan nicht einfallen MFG Falk
Gast
#917466
Ein schnell gemachter Fehler ist eine zu mickrige Speisung. Altera zB hat als Fussnote fuer den Stromverbrauch 15% Auslastung der Gatter. Dh wenn's langsam voll wird, kann der Strom der siebenfache sein. Wer hat die Speisung denn schon siebenfach ueberdimensioniert ....
Da du keinen Zeitdruck hast, empfehle ich, das FPGA-Design VOR dem endgültigen Routing der Platine komplett zu erstellen und zu simulieren. Auch immer mal eine Timing-Simulation laufen lassen, gerade bei vollen FPGA mit einigen schnellen Pfaden kommt´s da gerne mal zu Setup- und Hold-zeit-Verletzungen. Ansonsten auf jeden Fall vorher das gesamte Konzept aufstellen, und alles simulieren. Ohne Simulation wird das nur Harakiri im Blindflug. Ich kenn da einen Kollegen....5 Bit Logic-analyser an 5 Testpins und dann los....naja.
Falk Brunner wrote: > Lass das mal nicht MC Murphy hören . . . . > > 133 MHz SDRAM hat so Pi mal Dauem 1ns Anstiegszeit. -> 20cm Laufzeit -> > ab 3cm Reflexionen etc. Ich hoffe unter 3 cm bleiben zu können. Ich hoffe auch durch die kurzen Leitungen die timing Probleme weitgehend umschiffen zu können. > Siehe Wellenwiderstand > > Was sollte man beachten? Hmmm *Grübel* > > Hardware: OK Wie sieht es eigentlich mit der Taktverteilung aus? Also insb. die Versorgung der 4 ADCs. Es heißt ja, dass man keinesfalls einen vom FPGA generierten Takt für high speed ADCs nehmen soll. Aber gilt das auch, wenn man den Ausgang eines DCMs auf einen Pin legt? In den App-notes steht ja, dass die dinger den Takt aufarbeiten. Also was ist besser: Quarzoszillator direkt an alle ADCs und den FPGA (sofern der Oszillator so viele Eingänge Treiben kann) oder nur in den FPGA und von da aus über einen DCM an die ADCs? > Software: Das einzige was bei mir Asynchron sein wird sind externe Trigger-Signale. Aber die kann ich ja synchron abtasten. Takte werde ich 2 oder 3 verwenden. Nur einer wäre mir viel lieber, aber das geht nicht. Die Daten kommen mit 50MHz. > Simulation > > - Verhaltensimulation reicht im allgemeinen aus. Post Place & Route > Simulation ist aufwändig und langsam. In einem soliden synchronen Design > reicht eine automatische Timinganalyse OK. 3363 wrote: > Ein schnell gemachter Fehler ist eine zu mickrige Speisung. Altera zB > hat als Fussnote fuer den Stromverbrauch 15% Auslastung der Gatter. Dh > wenn's langsam voll wird, kann der Strom der siebenfache sein. Wer hat > die Speisung denn schon siebenfach ueberdimensioniert .... Ich werde dann die Maximalwerte aller ICs zu addieren. Dann sollte ja nichts schief gehen. Für die Versorgung +-5V werde ich auch erst mal ein externes Netzteil verwenden. Sowas zu bauen ist ja ein Thema für sich. Christian R. wrote: > Da du keinen Zeitdruck hast, empfehle ich, das FPGA-Design VOR dem > endgültigen Routing der Platine komplett zu erstellen und zu simulieren. > Auch immer mal eine Timing-Simulation laufen lassen, gerade bei vollen > FPGA mit einigen schnellen Pfaden kommt´s da gerne mal zu Setup- und > Hold-zeit-Verletzungen. Ansonsten auf jeden Fall vorher das gesamte > Konzept aufstellen, und alles simulieren. Ohne Simulation wird das nur > Harakiri im Blindflug. Ich kenn da einen Kollegen....5 Bit > Logic-analyser an 5 Testpins und dann los....naja. Das erfordert natürlich viel Disziplin. Aber es ist schon der richtige Weg. Geplant hatte ich es Anfangs so, jetzt bin ich mir auch wieder sicher, dass ich es so mache. Ich plane einen Spartan 3(E) Speedgrade 4 einzusetzen. (Bestellungen bei Digikey sind ja viel billiger geworten :-) ) Sind da Taktraten von 133 MHZ realistisch? Oder vielleicht auch ein bisschen mehr? Hat die Sache Chancen auf einer 2 Layer Platine zu funktionieren? 4 Layer sind so teuer. Bevor ich in den Sauren Apfel beiße frage ich mal lieber...
Gast
#917764
Autsch... Du machst Dir so viel Mühe mit der Simulation, Aufbau der Platine und co und dann möchstest Du nur 2 Layerplatine mache? :-o Das finde ich, ehrlich gesagt, sehr gewagt. Es mag funktionieren, doch habe ich da meine Zweifel. Zu anderen Sachen: für die Clocks würde ich einen Clockmultiplexer nehmen. Also zunächst mal aus dem FPGA raus -> Clock Mux -> ADCs und zurück zum FPGA. Die Vorteile liegen auf der Hand -- Du kannst die Phase drehen, wie Du lustig bist. Die Clock, die z.B. beim ADC ankommt ist vollkommen synchron zu der Clock, die dann am FPGA zurückkommt. Damit vermeidest Du diverse Probleme mit der Phase. Was soll das Ganze werden? Grüße, Kest
Kest wrote: > Platine und co und dann möchstest Du nur 2 Layerplatine mache? :-o Ich würde lieber, wenn es aber nicht viele Aussichten auf Erfolg hat nehme ich 4 Layer > > Zu anderen Sachen: für die Clocks würde ich einen Clockmultiplexer > nehmen. Also zunächst mal aus dem FPGA raus -> Clock Mux -> ADCs und > zurück zum FPGA. Die Vorteile liegen auf der Hand -- Du kannst die Phase > drehen, wie Du lustig bist. Die Clock, die z.B. beim ADC ankommt ist > vollkommen synchron zu der Clock, die dann am FPGA zurückkommt. Damit > vermeidest Du diverse Probleme mit der Phase. > Kann man das gleiche aber nicht auch mit DCMs erreichen? Ich meine Takt an die ADCs von da aus an den FPGA in einen DCM. In dem kann ich doch auch beliebig die Phase verschieben. > Was soll das Ganze werden? Ein kleines USB-Oszilloskop mit Logic Analyzer. Klar davon gibts sicher Fertige mehr als genug, ich will aber basteln ;-)
Gast
#917812
4 Layers... hast du das pinout vom FPGA schon gemacht? Nimm lieber ein ordentlich schnelles Speedgrade, wochenlang zu optimieren ist viel schlimmer als ein paar euro mehr ausgeben. Falls du mehr baust und das timing stimmt dann kannst du dann ja immernoch einen billigeren nehmen.
ijuz wrote: > 4 Layers... hast du das pinout vom FPGA schon gemacht? > Nein. Glaubst du 4 sind auch zu wenig? Ich bin bisher davon ausgegangen, dass ich die Leitungen weitgehend entflechtet bekomme. Ist das unrealistisch? > Nimm lieber ein ordentlich schnelles Speedgrade, wochenlang zu > optimieren ist viel schlimmer als ein paar euro mehr ausgeben. > Falls du mehr baust und das timing stimmt dann kannst du dann ja > immernoch einen billigeren nehmen. Und wo kauft man sowas? Bei Digikey finde ich Spartan 3E im passenden Gehäuse nur im Speedgrade 4. Höchstwahrscheinlich bleibt es ein Einzelexemplar.
Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje. Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der ist zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade so. Da sind aber recht viele Multiplexer im High-Speed-Pfad. Lässt sich leider nicht anders machen. ich bin da eher skeptisch, dass die die 133Mhz für den SDRAm schafft. Wozu eigentlich? Bei 50MHz Sampling-Rate? Müssen die alle permanent in den Speicher schreiben? Kannst du das nicht erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder gleich an den USB-Chip? Ahso, ADC-Takt sollte natürlich jitter-arm sein, sonst bekommst du digitales Rauschen ins Signal. DCM ist keine gute Idee. Wir machen das so: Quarz-Oszillator (jauch) in den FPGA an einen GCK Eingang, und für die ADCs wieder ausgeben, ohne FFs oder sonstiges dazwischen, also nur über die Clock-Buffer. Jitter liegt dann bei 28ps bei 80MHz. Noch besser wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt an die ADCs und an den Spartan parallel. Simulier das mit dem SDRAM mal durch, ich bezweifle, dass der Spartan das schafft. Erst recht der 4er und wenn noch viel logik im Chip ist. Ahja, und viel Spaß mit dem FX2-Timing. Aber das hatten wir ja in einem anderen Thread schon mal ;) Mit einer 2-Lagen-Platine brauchste da gar nicht anzufangen, wie willst du da auf die Impedanzen für die Leitungen des SDRAM kommen? 4 Lagen sind Minimum.
Christian R. wrote: > 133Mhz für den SDRAm schafft. Wozu eigentlich? Bei 50MHz Sampling-Rate 8 Bit * (4 ADC + 1 Logic), sind bei 16 Bit Datenbus des SDRAMS 125MHz Dann muss es ein Bisschen mehr sein für Refreshs. Aber Vielleicht kann ich ja einen SDRAM nehmen der einen breiteren Bus hat? Das würde die Sache ziemlich entspannen. Oder bekomme ich dann andere Probleme? Vielleicht sollte ich auch lieber nur 3 Kanäle nehmen. > Müssen die alle permanent in den Speicher schreiben? Kannst du das nicht > erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder > gleich an den USB-Chip? In ein Fifo muss ich sowieso zuerst, da SDRAM und ADCs wegen der Refreshs leider nicht Synchron laufen können. Ich will nur mehr Daten zwischenspeichern als in den Spartan passen. Außerdem will ich lernen wie man SDRAM anspricht. Das kann ich bestimmt irgendwann mal gebrauchen. > über die Clock-Buffer. Jitter liegt dann bei 28ps bei 80MHz. Noch besser hui, nicht schlecht. > wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt > an die ADCs und an den Spartan parallel. > > Simulier das mit dem SDRAM mal durch, ich bezweifle, dass der Spartan > das schafft. Erst recht der 4er und wenn noch viel logik im Chip ist. mach ich. Ich würde ja auch gerne einen 5er nehmen. Die sind nun mal nur nicht so leicht zu bekommen. > Ahja, und viel Spaß mit dem FX2-Timing. Aber das hatten wir ja in einem > anderen Thread schon mal ;) > Ich weiß ehrlich nicht gesagt was daran so schwierig sein soll. Damals habe ich mein FX2 Modul mit einem Nexys2 verbunden. Der Spartan auf dem Board hat Daten in das FIFO vom FX2 geschrieben, gewartet, wenn das FIFO grade voll ist. Das hat ohne große Komplikationen funktioniert. Klar musste ich mir überlegen wie und bei welcher Flanke, aber das muss man doch bei jedem Logik-Chip. In der Übertragung gab es jedenfalls keine Fehler. Oder hatte ich einfach nur Glück? ;-) > Mit einer 2-Lagen-Platine brauchste da gar nicht anzufangen, wie willst > du da auf die Impedanzen für die Leitungen des SDRAM kommen? 4 Lagen > sind Minimum. Die Chips sollen ja alle ganz dicht am FPGA sitzen. Meinst du die Impedanzen sind auch bei 2-3cm langen Leitungen so wichtig? Klar, es ist ein wichtiges Thema und man sollte es auf keinen Fall ignorieren, aber ich will ja auch nicht die Signale über 10 cm oder noch längere Leitungen schicken. Aber ich habe mich schon auf den Gedanken eingestellt tief in die Tasche greifen zu müssen. Die Leitungen zum FX2 bei dem Aufbau mit Nexys2 sind die Leitungen außerhalb des Nexys-Boards auch noch ein paar cm und die Masserückleitungen sind wegen der schlechten Ansteckmöglichkeit leider extrem ungünstig. Aber es hat funktioniert. Und der Aufbau kann doch eigentlich nur besser laufen, wenn ich alles auf eine Platine mache und nicht über 2 Stecker muss. Als ich mit der Elektronikbastelei angefangen habe habe ich mir um Leitungsimpedanzen und Signalreflektionen noch gar keine Gedanken gemacht. Damals hatte ich einen Aufbau mit 30-40cm langen frei laufenden Kabeln (d.h. ohne ordentliche Masseleitung in der Nähe) das dann noch auf Breadboards mit den parasitären Kapazitäten. Es lief Tatsächlich bei 50MHz. Das hätte ich vorher nicht für möglich gehalten. Aber sowas will ich auch nicht nochmal versuchen ;-)
Gast
#917943
125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive Transferrate (Im Page-modus bekommst Du zwar mehr, bist aber auf eine SDRAM-Page beschränkt). Na ja, da musst Du noch rechnen. Nimm lieber irgendein SDRAM mit 32 Bit, oder mehrere Chips nebeneinander. 16 Bit limitiert ganz schön. Außerdem gehen 32 Bit gut durch 8 Bit Auflösung, wo Du auf Deine 4 Kanäle kommst. Grüße, Kest
Kest wrote: > 125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im > Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive > Transferrate > (Im Page-modus bekommst Du zwar mehr, bist aber auf eine SDRAM-Page > beschränkt). Na ja, da musst Du noch rechnen. 40%? ich hätte gedacht, dass man während man Daten in den Ram schreibt die nächste auf der nächsten Bank schon zum beschreiben vorbereiten kann. Grade wenn man immer Pageweise die Daten reinschreibt hätte ich ehr mit >95% gerechnet. Aber wenn das nicht stimmt muss ich wohl noch mal in ein SDRAM Datenblatt schauen. > Nimm lieber irgendein SDRAM mit 32 Bit, oder mehrere Chips > nebeneinander. 16 Bit limitiert ganz schön. Außerdem gehen 32 Bit gut > durch 8 Bit Auflösung, wo Du auf Deine 4 Kanäle kommst. OK. Mache ich. Viele Grüße, Christian
@ Christian R. (supachris) >Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje. ??? Das schaffen sogar "alte" Spartan II. @>Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der ist >zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade >so. UND? Es ommt immer darauf an, wie lang die kominatorischen Pfade sind. Pipelinig ist das Stichwort. >133Mhz für den SDRAm schafft. Problemlos. Wozu eigentlich? Bei 50MHz Sampling-Rate? >erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder >gleich an den USB-Chip? Dannbraucht er ja keinen SDRAM. Der ist wesentlich grösser als die BRAMS, und das will er wahscheinlich. >wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt >an die ADCs und an den Spartan parallel. Eben. @ Christian H. (cavorca) >Die Chips sollen ja alle ganz dicht am FPGA sitzen. Meinst du die >Impedanzen sind auch bei 2-3cm langen Leitungen so wichtig? Naja, die Impedanz allein ist es nicht. Es ist auch die Masseverteilung. Das wird eng auf zwei Lagen. Nimm besser 4. @ Kest (Gast) >125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im >Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive >Transferrate Das halte ich für ein Gerücht! MfG Falk
Gast
#918043
Autor: Christian R. (supachris) schrieb: >Noch besser wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) >direkt an die ADCs und an den Spartan parallel. Ich wollte eigentlich das Taktsignal vom Taktgenerator direkt dem ADC zuführen und vom Taktausgang des ADC zum Takteingang des FPGA. Ich denke bezüglich Jitter ist das das beste. Soweit ich weiß ist alles, was irgendwie durch den FPGA geschleust wird vom Jitter deutlich schlechter, als das was von einem guten Taktgenerator kommt. Nachteil ist natürlich, dass man den Takt dann nicht beliebig runterteilen kann. (Meine Anwendung wäre: 12 bit ADC mit 100 MSPS, da sollte der Jitter nicht wesentlich größer als 1ps rms sein -- denke ich zumindest.) Später kann ich bei Bedarf ja statt eines einfachen Taktgenerators einen Clock-Synthesizer wie etwa den MAX3674 verwenden.
Gast
#918054
@Falk Brunner (falk): das ist kein Gerücht, das steht im Datenblatt: Im Burstmodus (wo nur 8 Werte gelesen werden), braucht man ca. 20 Takte. Wie der SDRAM-Controller dann implementiert ist, ist eine andere Frage. Damit kann man mit jedem Burst unterschiedliche Adressen anlegen und man bekommt seine Sachen nach 20 Takten. Liest oder schreibt man aber kontinuierlich (von mir aus 1024 Werte, es kommt natürlich auf die Größe der Page an), dann bekommt man schon eine Auslastung von 95 %. Grüße, Kest
Falk Brunner wrote: > @ Christian R. (supachris) > >>Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje. > > ??? > Das schaffen sogar "alte" Spartan II. > > @>Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der > ist >>zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade >>so. > > UND? Es ommt immer darauf an, wie lang die kominatorischen Pfade sind. > Pipelinig ist das Stichwort. Jo, ohne kombinatorische Logik gerade durch als Datenschaufel ist das kein Thema. Ich meinte oben irgendwas gelesen zu haben, dass er die Maxima raussuchen und abspeichern will.
Gast
#918096
Refresh ? Vergiss den. Refreshen muss man nur wenn was drin ist. Also zuerst sampeln und in einem Rutsch synchron reinschreiben. Nachher kann man dann ja refreshen.
3363 wrote: > Refresh ? Vergiss den. Refreshen muss man nur wenn was drin ist. Also > zuerst sampeln und in einem Rutsch synchron reinschreiben. Nachher kann > man dann ja refreshen. Das geht nicht beliebig. Wenn man einen größeren RAM hat muss man refreshen bevor der RAM voll ist. Auch wenn man mit maximaler Rate reinschreibt. Beispiel: 64MB reinschreiben mit 200MB/s dann ist das Ding nach 0,32 Sekunden voll. Refreshen muss man aber laut Datenblatt mindestens alle 64 ms. Oder kann man das in der Praxis was strecken? Oder meinst du ganz was anderes? Viele Grüße, Christian
Gast
#918167
Kriegt man eigentlich aus dem MIG von Xilinx einen tauglichen SDRAM-controller raus? Oder muss ich mir den selber schreiben? Ich stehe auch vor der Aufgabe, mir ein RAM ins Design ziehen zu müssen und überlege, ob ich es nicht statisch machen soll: Wenn ich "nur" 125MHz hinbekomme, sei es druch das RAM oder den FPGA, kann ich ja auch ein SRAM nehmen mit 10ns und 2 paralle schalten. Dann kriege ich meine Daten auch weg.
Gast
#918177
Der Standardtrick ist die Zeilen und Spalten zu vertauschen. Man muss fuer einen Refresh ja nur die Adresse anlegen, ob lesen oder schreiben ist egal. In diesem Fall ist ein lineares Schreiben genugend. Zumindest war das frueher so, als die dynamischen RAMs noch kleiner waren.
Gast
#918191
War das jetzt eine Antwort aif meine Frage? Ich habe es aber in keinen Fall kapiert. :-(
Gast
#918192
> Der Standardtrick ist die Zeilen und Spalten zu vertauschen. Man muss > fuer einen Refresh ja nur die Adresse anlegen, ob lesen oder schreiben > ist egal. Erstens musst du für einen Refresh die entsprechende Zeile öffnen und wieder schließen. Ob du dazwischen liest oder schreibst ist egal. Zweitens dauert genau deshalb der Zugriff viel länger, als wenn man eine Zeile "offenhält" und verschiedene Zellen darin schreibt/liest. Soll heißen: Mit dem "Vertauschen" verschlechterst du ziemlich den Durchsatz. Wenn das kein Problem ist: optimal, denn dann werden die Zeilen tatsächlich alle refreshed.
Mensch, genau das mit diesem "Refresh-Trick" habe ich hier vor Monaten mal gefragt. Da wollte mir keiner Antworten. Sollte es nicht auch so gehen: Bank1 präparieren, sodass eine ganze Page im Burst-Mode beschrieben wird. Auf Bank2 ein Activate Kommando, aber nichts reinschreiben sondern direkt wieder Precharge. Dann das gleiche mit einer anderen Bank/Spalte bis der Writeburst zu Ende ist. Der ist ja 256 Takte lang. Da hat man allerlei Zeit was anderes zu machen. Was ich aber mittlerweile vielleicht für einfacher halte wäre den RAM einfach mit einem schnelleren Takt laufen zu lassen und die Daten in einem Fifo oder Dualportram im FPGA zwischenspeichern. In meiner Anwendung brauche ich ja auch den Durchsatz. Zum MIG: So weit ich weiß kann der keinen SDRAM sondern nur DDR, DDR2 RLDDR,...
Gast
#918318
SDRAM Controller gibt es wie Sand am Meer. Ich habe allerdings damals selber nach der Vorlage gemacht und ich muss sagen, es war auch gut so -- da weis man, was so intern paassiert. Mittlerweile verwende ich den von Altera aus dem SOPC-Builder und es funktioniert wunderbar, man muss sich um nichts kümmern. Auch von Altera gibt es SDRAM Controller (aus dem Megawizard) mit VHDL Dateien, die kann man sogar ohne Änderung für Xilinx verwenden. Grüße, Kest p.s.: such mal bei Altera nach dem SDRAM-Controller, wenn Du nichts findest, dann kann ich den hier hochladen
Gast
#918449
> Was sind die schlimmsten Fehler mit denen man sich ein Design langsam > machen kann? - Mangelhafte Programmier-Kenntnisse in VHDL - Keine/wenig Erfahrung mit dem eingesetzten FPGA - Unterschiedlichen Leiterbahnlängen bei schnellen, parallelen Leitungen.
Gast
#918476
Unbedingt kalkulieren: Benötigter Speicher im FPGA. Gerade bei Fifo-lastigen Designs unbedingt darauf achten. Nicht zu vergessen: Beim Einsatz eines Embedded Analyzers kann man nie genug Speicher haben. Auch nicht zu vergessen: Lieber einen höheren Speedgrade ansetzen, kann man nachher immer noch durch einen langsameren ersetzen. Gruß Willy
Gast
#918480
Weiterer Punkt: Vernünftigen (bspw. durch Watchdog getriggerten) externen Reset vorsehen. Würde mich nicht bei allen Herstellern auf saubere Initialwerte der Register verlassen.
Willy wrote: > Vernünftigen (bspw. durch Watchdog getriggerten) externen Reset > vorsehen. Würde mich nicht bei allen Herstellern auf saubere > Initialwerte der Register verlassen. Spartan 3 ist das Thema, der hat nach der Konfiguration sehr wohl verlaessliche Initalwerte, wie jedes andere SRAM basierte FPGA auch! Ein zusaetzlicher Reset ist meistens Ueberfluessig! Ein Supervisor fuer z.B. die I/O Spannung(en) kann durchaus Sinn machen, dann kann man das FPGA aber auch gleich damit in den config mode schicken. Cheers, Roger
Gast
#918526
>Ein zusaetzlicher Reset ist meistens Ueberfluessig! ja,ja, das sagt Xilinx, unterschlägt aber, aber es nicht nur System-Resets gibt sondern druchaus unterschiedliche Schaltungsteile mit unterschiedlichen Aufgaben. Hat man in einem FPGA einen watch dog, ein BSP-bios und noch die eigentliche Applikation, dann darf da nur die APP resettet werden und sonst nichts, wenns weiterlaufen soll. Also ohne einen logischen Reset kommt man in der Regel nicht aus und warum soll man den immer synchron machen ?
Gast
#918546
>>Spartan 3 ist das Thema, der hat nach der Konfiguration sehr wohl >>verlaessliche Initalwerte, wie jedes andere SRAM basierte FPGA auch! >>Ein zusaetzlicher Reset ist meistens Ueberfluessig! Kann mich da jemand aufklären? Ich verwende einen Vitrex-2 und je nach Lust und Laune läuft das geladene Programm nach dem Upload der Konfiguration nicht richtig an, trotz einem asynchronem Reset nach dem Programmstart. Mal läuft das Programm 40 Mal hintereinander an, mal muss ich den 2/10 Mal zusätzlich resetten, damit das Programm startet. Bin immer noch nicht drauf gekommen, warum es so ist.
Hells Angel wrote: > Also ohne > einen logischen Reset kommt man in der Regel nicht aus und warum soll > man den immer synchron machen ? Das mag vielleicht in der Biker Szene so sein. Zu asynchron/synchron resets findest du genuegend Info im Netz. Cheers, Roger
Gast
#918615
Gast (Gast): Hast Du mal darüber nachgedacht, dass es an der Clock liegen könnte, dass das Program nicht anläuft? Hast Du DCMs drin? Hatte auch was ähnliches, wo DCM nicht richtig konfiguriert wurde (ab und zu) und die Clock falsche Frequenz hatte. Grüße, Kest
@ Kest (Gast) >kontinuierlich (von mir aus 1024 Werte, es kommt natürlich auf die Größe >der Page an), dann bekommt man schon eine Auslastung von 95 %. Das meinte ich impizit. Was anderes macht bei dieser Anwendung wenig Sinn. Und das mit dem Vertauschen der Adressen an einem SDRAM würde ich mir fix verkneifen. Nehmt einen ordentlichen SDRAM-Controller mit Refresh, pappt davor im FPGA einen FIFO und gut. MFG Falk
Gast
#919158
>> einen logischen Reset kommt man in der Regel nicht aus und warum soll >> man den immer synchron machen ? >Das mag vielleicht in der Biker Szene so sein. >Zu asynchron/synchron resets findest du genuegend Info im Netz. Der resettende Takt muss immer synchron zum taktenden sein, auch wenn man den asynchronen Eingang des FF nutzen will. Dazu muss es externe Reset eben in einen internen verwandelt werden. >Mal läuft das Programm 40 Mal hintereinander an, mal muss >ich den 2/10 Mal zusätzlich resetten Das hört sich genau nach sowas an: Dein Reset startet unterschiedliche design paritions unterschiedlich. Entweder ist nichts alles verdrahtet, oder es gibt ein logistisches Problem, oder der REset ist nicht stabil, weil nicht ordentlich eingetaktet oder in einer Clock domain verschluckt oder insgesamt einfach zu kurz zum Eintakten.
Berater wrote: > Der resettende Takt muss immer synchron zum taktenden sein, auch wenn > man den asynchronen Eingang des FF nutzen will. Dazu muss es externe > Reset eben in einen internen verwandelt werden. Wieso antwortest du auf meinen Text mit diesem geblabber?
Gast
#919256
> Sollte es nicht auch so gehen: > Bank1 präparieren, sodass eine ganze Page im Burst-Mode beschrieben > wird. > Auf Bank2 ein Activate Kommando, aber nichts reinschreiben sondern > direkt wieder Precharge. Dann das gleiche mit einer anderen Bank/Spalte > bis der Writeburst zu Ende ist. Der ist ja 256 Takte lang. Da hat man > allerlei Zeit was anderes zu machen. Klingt nicht schlecht. Ich bin grad nicht 100 pro sicher, dass ein activate auf einer anderen Bank den Burst-Write nicht unterbricht, aber ich glaub das geht. ABER: Bedenke bei allen Tricks, um Refresh-Zyklen zu sparen, um wieviel der Speichercontroller dadurch komplizierter wird. Insbesondere wieviel inneren Zustand er über den Refresh-Zustand der Zeilen halten muss (sind ja schnell mehrere K Zeilen).
@Kest: Vielleicht wäre ein fertiger Controller auch was für mich. Aber klar hat es auch Vorteile den selbst zu schreiben. @Gast: Ich programmiere zwar in Verilog, aber da sind magelhafte Kenntnisse sicher genau so schlimm. Profi bin ich sicher nicht, aber die ganz brutalen Anfängerfehler mache ich immerhin nicht mehr. @Willy: Wo bekomme ich denn einen höheren Speedgrade? Kann ich bei den distributoren auf xilinx.com auch einzelne bestellen? Sonst hätte ich keine Idee. Es soll ein 250E PQ208 werden. @Roger Steiner: Wie lege ich die Initialwerte fest? Geschieht das im "nicht synthetisierbaren" Initial Block? (Oder wie der in VHDL auch heißen mag) Über den Unterschied synchrone / asynchrone Resets muss ich mich noch etwas einlesen. @Morin: Aus dem Datenblatt hatte ich mir damals erarbeitet dass es funktionieren müsste. Ein writeburst wird nur von einem anderen Write, einem Read oder einem Burst Terminate unterbrochen. Wenn ich mich richtig erinnere und es damals nicht falsch verstanden habe. Ich hatte mir auch schon eine kleine Platine mit SDRAM gemacht mit der ich das mal ausprobieren kann. Habe ich aber bisher nicht gemacht. In neueren RAM Sorten ist das alles viel besser geregelt. Da kann man auf einer Bank lesen/schreiben und WÄHREND eines Bursts auf den anderen Banks refresh-Kommandos ausführen. Ich will wirklich mal wissen welcher Teufel die Leute damals geritten hat die den refresh-Teil nur einmal für alle 4 Banks vorgesehen haben. Für so einen Ram würde ich auch den doppelten Preis zahlen. Aber RLDDR-RAM ist mir dann doch was komplex. Die Refresh-"Tricks" mögen den Controller aufwändiger machen aber bedenke dass der ganze Teil davor dann synchron mit einem einzigen Takt läuft. Das ist doch auch was wert. Man spart auch den ganzen Fifo davor. Allerdings bin ich auch ehr von der Idee runter. In meiner Anwendung will ich auch die Möglichkeit haben mit der halben, 1/5, 1/10,... Rate zu Samplen. Und den RAM Takt will ich nicht unbedingt im Betireb umschalten. Aber nochmal eine allgemeine Frage wie komplex etwas werden kann/darf: Gibt es eine Beschränkung wie viele Eingänge ein Multiplexer haben kann? Gibt es eine Beschränkung auf Sinnvolle Werte die kleiner ist? Gleiche Fragen zu den Anzahl Zuständen in einer Zustandsmaschine. Ist es irgendwann einfach nicht mehr synthetisierbar? Viele Grüße, Christian
Die FPGAs gibts eigentlich alle bei Silica/AVNet. Spoerle hat auch jede Menge. NuHorizons auch.
@ Christian H. die Initial-/oder Default-Werte legst du bei der Deklaration fest. z.B.
1 | |
oder
1 | |
2 | |
3 | |
4 | |
5 | |
und die sind auch synthetisierbar. Du kannst locker FSMs mit mehreren hundert Zustaenden bauen, synthetisieren ist nicht das Problem, sondern eher Latenz und ueberschaubarkeit des designs. Cheers, Roger
@ Christian R.: bei spoerle kann ich nichts finden. Bei NuHorizons und Avnet schon. Da hat doch sicher schon mal jemand was bestellt. Wie teuer ist das im Endeffekt? Also mit Versand und Zoll. Die verfügbarkeiten sehen aber auch nicht so toll aus. Nuhorizons hat 2 Stück, avnet keine auf lager. Ich glaube nicht dass die extra welche einkaufen, wenn ich einen haben will. @Roger: Weißt du auch wie es mit Verilog aussieht? Vielleicht so:
1 | |
Ich könnte mir vorstellen das auch mehrere hundert Zustände bei entsprechend sorgfältiger Vorbereitung noch übersichtlich sein können. Es ist aber so, dass auch dann noch in ein Flipflop in jedem Zustand etwas anderes reingeschireben werden kann? Da muss es dann doch einen Multiplexer geben der genau so viele Eingänge hat wie es Zustände gibt. Entstehen da durch die langen Latenzen? Ich frage anders: Muss ich mir darum Gedanken machen?
Christian H. wrote: > @ Christian R.: > bei spoerle kann ich nichts finden. > Bei NuHorizons und Avnet schon. Da hat doch sicher schon mal jemand was > bestellt. Wie teuer ist das im Endeffekt? Also mit Versand und Zoll. Die haben doch Vertretungen in Deutschland. Nix Zoll und so....Wir bestellen immer bei Avnet/Silica in Poing bei München. Lass dir halt ein Angebot schicken.....oder willst du die Privat kaufen? Versand kostet bei Silica 4,50€.
Ich habe ein Gewerbe, das ich angeben kann. Das sollte denen ja reichen?
Jo klar. Privat geht halt nur nicht. Einfach Angebot anfordern, kommt meist am gleichen Tag.
Gast
#919864
@ Roger >die Initial-/oder Default-Werte legst du bei der Deklaration fest. >z.B. >signal my_signal : std_logic := '1'; Das halte ich aber bei der Synthese für ein Gerücht. Für Simulationszwecke stimmt das, aber für die Synthese spielt man auf diese Weise Roulette ... Gruß, Willy
Gast
#919872
>>z.B. >>signal my_signal : std_logic := '1'; > >Das halte ich aber bei der Synthese für ein Gerücht. Das funktionier 100% mit Altera Grüße, Kest
Gast
#919876
Aber die Welt besteht nicht nur aus "A" und "X" Gruß, Willy
Willy wrote: > @ Roger > >>die Initial-/oder Default-Werte legst du bei der Deklaration fest. >>z.B. >>signal my_signal : std_logic := '1'; > > > Das halte ich aber bei der Synthese für ein Gerücht. Für > Simulationszwecke > stimmt das, aber für die Synthese spielt man auf diese Weise Roulette > ... > > Gruß, > Willy Bei Mentor Precision muss man es zwar extra aktivieren, aber dann werden die init Werte auch mit synthetisiert. Gruß Little Chip
Gast
#919918
IEEE-1076.6 (Standard for VHDL Register Transfer Level (RTL) Synthesis) sagt aus das ein Initialwert bei der Deklaration eines Signals oder einer Variablen ignoriert werden. D.h. man sollte sich nicht darauf verlassen das das bei jedem Tool und jeder Version eines Tools umgesetzt wird. Gruß, Mathi
Gast
#919924
Mag ja alles sein, aber man darf doch nicht davon ausgehen, dass ein globaler Fpga-Reset gleichbedeutend mit einem Power-Up-Reset ist ! Initial-Registerwerte bei Signal-Deklarationen erleichtern mir nur Schreibarbeit bei Testbench-Geschichten. Gruß, Willy
@ Christian R.: > Weißt du auch wie es mit Verilog aussieht? leider nein. > Ich könnte mir vorstellen das auch mehrere hundert Zustände bei > entsprechend sorgfältiger Vorbereitung noch übersichtlich sein können. Das ist Ansichtssache, aber wie gesagt, wenn du willst, dann kannst du das machen. > Es ist aber so, dass auch dann noch in ein Flipflop in jedem Zustand > etwas anderes reingeschireben werden kann? Da muss es dann doch einen > Multiplexer geben der genau so viele Eingänge hat wie es Zustände gibt. > Entstehen da durch die langen Latenzen? Kommt auf die Art der Codierung draufan, bei one-hot z.B. brauchts zwar soviel Flipflops wie states, dafuer ist die decodierung recht simpel. > Ich frage anders: Muss ich mir darum Gedanken machen? Nein, all das nimmt dir die Synthese ab. @ Willy > Das halte ich aber bei der Synthese für ein Gerücht. > Für Simulationszwecke stimmt das, aber für die Synthese spielt man > auf diese Weise Roulette Dann musst du aber dein Kentnissstand etwas auffrischen! > Aber die Welt besteht nicht nur aus "A" und "X" Nein, aber es ist doch der groesste Brocken davon, schau dir nur mal die posts in diesem Forum an. Zuerst Xilinx dann Altera und once in a blue moon was anderes. > Mag ja alles sein, aber man darf doch nicht davon ausgehen, > dass ein globaler Fpga-Reset gleichbedeutend mit einem > Power-Up-Reset ist ! Bei den SRAM basierten FPGAs sind die Initialwerte implizit im Bitstream. Ausser fuer einen brown-out gibt es meistens keinen Anlass fuer einen globalen Reset.
Gast
#919970
Roger, 95% meiner REALEN Designs hätten mit deiner Reset-Strategie nichts getaugt. Schöne Grüße, Willy
Gast
#919984
@Willy (Gast): Ich möchte Dir nicht zu nahe treten, aber denkst Du nicht, dass das nicht am Reset lag, sondern wie Du programmiert hast? ;-) Grüße, Kest
Gast
#919987
Fakt ist, Willy hat nach IEEE recht. Wenn ein Tool solche Initialwerte übernimmt, macht es mehr als es muss/sollte. Wenn man sich darauf verlassen will, kann man das tun, sich Schreibarbeit sparen und unter Umständen bei Toolwechsel auf die Nase fallen. Man kann aber auch dem Standard glauben und unter Umständen mehr schreiben als überhaupt notwendig ist.
Willy, du hast ein Konzeptionelles oder Verstaendnis Problem. Cheers, Roger
Gast
#919991
Ach Herr Kest ist auch wieder da, ich programmiere meine Designs nicht, ich beschreibe sie ;O) Konntest du eigentlich in der Zwischenzeit "dein" bmp-Package etwas verfeinern ? Gruß, Willy
Gast
#920014
@Willy (Gast): nein, BMP Zeug habe ich nicht mehr angefasst -- keine Zeit gehabt. Grüße, Kest
Gast
#920021
Roger, kann man denn auch Zustandsmaschinen mit einer Initial-Deklaration in einen Quasi-Reset-Zustand bringen ? Bsp.: type state_type is (s_config_up, s_idle, s_running ...); signal ls_state : state_type := s_config_up; Kann man hier sicher gehen, dass der Automat im "s_config_up"-Zustand losläuft ? Gruß, Willy
Gast
#920027
Auch das funktioniert (zumindest für Altera) zuverlässig. Mal stelle sich nur ein BlockRam vor, den man mit bestimmten Werten initialisiertz haben möchte :-o Grüße, Kest
Willy, > kann man denn auch Zustandsmaschinen mit einer Initial-Deklaration > in einen Quasi-Reset-Zustand bringen ? Ja, das geht natuerlich auch fuer selbst definierte types, wie man sie eben fuer state machines verwendet. > type state_type is (s_config_up, s_idle, s_running ...); > signal ls_state : state_type := s_config_up; > > Kann man hier sicher gehen, dass der Automat im "s_config_up"-Zustand > losläuft ? Wie du kann ich hier sagen dass alle meine REALEN designs diesen Ansatz erfolgreich implementieren. Cheers, Roger
Gast
#920078
Roger, eine kritische Situation für deine Initialwert-Strategie ist bspw. ein Prozessor-FPGA-System, in dem der Prozessor dem FPGA einen globalen Reset verpassen möchte. Was machst Du denn dann ? Gruß, Willy
Willy, Altera StratixII + und CycloneIII -> Remote System Upgrade. Cheers, Roger
Gast
#920122
Ach ja, aber nur für zwei B'A'usteine und mit entsprechendem Update-Controller-Aufwand. Schade, dass noch nicht jeder einen CycloneIII auf dem Board hat. Wie auch immer ... Gruß, Willy
Nochmal zu der Aussage möglichst wenig unterschiedliche Takte im Design haben. Wie viele sind denn noch OK? Und warum sollte man Möglichst wenige haben? Übersichtlichkeit oder Ressourcen? Um Asynchronität muss man sich bei einem neuen Takt ja nicht unbedingt so viele Gedanken machen. Ich meine, wenn man den Takt mit einer DCM verdoppelt ist es ja nicht so kompliziert, wie es ist, wenn man einmal 100MHz und einmal 133MHz hat. Oder noch schlimmer 2 Oszillatoren die vollkommen unabhängig laufen. Wenn ich jetzt Folgende Situation habe: Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz abgetastet werden. Dann brauche ich im Eingangsteil ja auf jeden Fall einen 100MHz Takt. Dann brauche ich aber auch auf jeden Fall eine Möglichkeit die Information weiter zu geben, bei welchen Taktflanken des 100MHz Taktes die Ausgänge der ADCs valide sind (bei 1,3,5,... oder bei 2,4,6,...). Also brauche ich entweder nochmal den 50MHz Takt, der auch an die ADCs geht oder ein Signal, das mir sagt ob bei der nächsten pos Flanke des 100MHz Taktes auch bei den 50MHz eine positive Flanke ist. Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung? Andere Frage: Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man sich bei FPGAs für eine Sorte entscheiden. Ist das richtig? Viele Grüße, Christian
Gast
#921673
Du solltest in eimem Design je Clock nur eine Taktsorte verwenden, weil am Ende dadruch am meisten Zeitresource für das Routen besteht. Wenn der Ausgang eines FF, das mit falling getrieben wurde, über Kombinatorik an den Eingang eines FFs geht, der mit risign getrieben wird, besteh nur die halbe Zeit (ungefähr). Das limitiert das gedamte Design. Es gibt auch keinen Grund, beide Takte zu verwenden, es sei denn im IO Bereich zum Eintakten! Bei Deinem Design verwendest du einen 100er Takt (wird schwer genug, je nach FPGA) und taktest damit ein FF -> das macht dann die benötigten 50 und Du kannst schon damit 50% Phase einstellen. Ansonsten DDR-Zelle mit 100 Takten und einen verschobenen 50er als Eingang. MAcht 25% Genaugikeit. So brauchst du nur e9in Taktnetz -> weniger Strom.
Gast
#921723
Die Anzahl der Taktnetze in einem FPGA ist beschränkt, abhängig vom FPGA. Es gibt globale Taktnetze und lokale Taktnetze, die sich über einen Quadranten eines FPGA beschränken. Taktübergänge sind manchmal nicht ganz unproblematisch, man muss schon wissen was man tut. Stichwort Metastabilität. Wenige Taktnetze sind daher nur ein Vorteil. Wo ist das Problem Daten von einem 50 MHz Signal auf 100 MHz zu übernehmen, wenn beide Clocks phasenstarr sind? Dein Design muss dann aber mit 100 MHz laufen können (bzw. du arbeitest mit Chip Enables alle 2 Cycles). FF auf beide Flanken zu triggern ist nur für DDR-Ausgangsregister zu empfehlen. Was das PCB-Layout betrifft: FPGA mit ADCs, externer PLL usw.. 4 Lagen ist da das absolute Minimum. Du willst schließlich mit deinem ADC ein paar gültige Bits haben und nicht nur Einstreuungen von den ganzen digitalen Bausteinen. Je nach sonstigen Bauteilen wären 6 Lagen durchaus angebracht. P.S.: Wir basteln auch grad einen ADC Board: 250 MS/s 12bit ADC, 600 MS/s 12 bit DAC auf 8 Lagen. Das ganze steckt auf einem 16 lagigem FPGA-Board.
Das Problem die ADC Daten mit 100MHz abzutasten ist meiner Meinung nach folgendes: Wenn ich jeden 2. Takt etwas mache ist es - sofern ich im Design nur den 100MHz Takt habe - vollkommen zufällig ob ich das dann jeweils zur fallenden oder steigenden Flanke der 50MHz mache. Im Datasheet des ADCs steht jetzt über das Timing: -neue Daten bei Rising Edge -Hold Time nach Rising Edge: min 3,9ns -Delay Time für neue Daten nach Rising Edge: max 12ns Wenn ich bei 50MHz ADC Takt also bei der fallenden Flanke Sample kommt evtl nur murks raus, da die neuen Daten noch nicht unbedingt anliegen, die alten aber nicht mehr. Also könnte alles dazwischen sein. Einzige Möglichkeit ist also bei der Rising Edge der 50MHz zu samplen. Ich sehe nicht wie ich das sicher stellen kann, wenn ich nur die 100MHz am Input habe. Oder ist irgendwo in meiner Argumentation ein Fehler?
Gast
#922567
Willy: > Das halte ich aber bei der Synthese für ein Gerücht. Für > Simulationszwecke > stimmt das, aber für die Synthese spielt man auf diese Weise Roulette Roulette spielst du nur, wenn du Sprachfeatures benutzt, von denen du nicht weißt, ob sie synthetisiert werden. Siehe (hoffentlich) die Anleitung des jeweiligen Synthesetools. Das gilt aber für alle Sprachfeatures, nicht nur für Register-Initialwerte. Insofern sehe ich hier keine besondere Situation. Ohne einen gemeinsamen Standard, an den sich alle Tools halten (Betonung auf dem letzten Halbsatz), programmierst du immer nach den Regeln des jeweiligen Tools. > Initial-Registerwerte bei > Signal-Deklarationen erleichtern mir nur Schreibarbeit bei > Testbench-Geschichten. Deine Entscheidung. Andere verwenden sie auch für die Synthese. Mathi: > Wenn man sich darauf verlassen will, kann man das tun, sich > Schreibarbeit sparen und unter Umständen bei Toolwechsel auf die Nase > fallen. Andersherum würde ich niemals davon ausgehen, dass bei 100%igem Einhalten des Standards keine Probleme bei Toolwechsel auftreten. Erst Recht nicht nach meiner Erfahrung mit den Xilinx-Tools.
@ Christian H. (cavorca) >wenige haben? Übersichtlichkeit oder Ressourcen? Probleme beim Datenüberganz zwischen den Taktnetzen (Clock domains). >Um Asynchronität muss man sich bei einem neuen Takt ja nicht unbedingt >so viele Gedanken machen. Ich meine, wenn man den Takt mit einer DCM >verdoppelt ist es ja nicht so kompliziert, wie es ist, wenn man einmal Das sind die Aussnahmen. Und auch die wollen SOLIDE gehandhabt sein. >100MHz und einmal 133MHz hat. Oder noch schlimmer 2 Oszillatoren die >vollkommen unabhängig laufen. Eben. >Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz >abgetastet werden. Warum? Sehe ich als relativ sinnfrei an. >Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein >Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung? Du bist gerade auf dem besten Weg, dein Taktkonzept an die Wand zu fahren. ;-) K.I.S.S.!!! Lass den Kuddelmuddel! EIN 50 MHz Takt für die ADCs und das FPGA zum Eintakten EIN 133 MHz Takt für den SDRAM und FPGA. Sonst nichts. Die 133 MHz kann man ggf. aus den 50 MHz per DCM erzeugen. Und selbst dann braucht man einen asynchronen FIFO. >Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative >Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man >sich bei FPGAs für eine Sorte entscheiden. Ist das richtig? Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen. MFG Falk
Gast
#922689
>>Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative >>Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man >>sich bei FPGAs für eine Sorte entscheiden. Ist das richtig? >Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen. >MFG Falk Deine Aussage ist sicher richtig -- worauf sie sich nun genau bezieht bleibt jedoch völlig offen.
Falk Brunner wrote: >>Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz >>abgetastet werden. > > Warum? Sehe ich als relativ sinnfrei an. Die ADCs sind bei 50MHz fast an ihrem Maximum. Es spricht aber nichts dagegen die Logic-Analyzer-Eingänge schneller abzutasten. Es könnte ja mal interessant sein sich schnellere digitale Signale anzugucken. Du hast mich nicht etwa so Missverstanden, dass ich die ADC Eingänge am FPGA mit 100MHz abtasten will? Das ist klar, dass das Quatsch ist. Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge. >>Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein >>Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung? > > Du bist gerade auf dem besten Weg, dein Taktkonzept an die Wand zu > fahren. ;-) > K.I.S.S.!!! > > Lass den Kuddelmuddel! EIN 50 MHz Takt für die ADCs und das FPGA zum > Eintakten > EIN 133 MHz Takt für den SDRAM und FPGA. Sonst nichts. Die 133 MHz kann > man ggf. aus den 50 MHz per DCM erzeugen. Leider brauche ich noch mindestens einen 3. Takt für die Komunikation mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich kann die 50MHz einfach durch 2 Teilen, aber Fifo brauche ich da ja trotzdem noch eins, da der RAM ja mit 133MHz läuft. Wäre es denn komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den 50MHz? Wenn ja wüsste ich nicht warum. > Und selbst dann braucht man > einen asynchronen FIFO. Warum asynchron? Macht es das nicht komplizierter? Reicht nicht auch ein Synchroner? Den hätte ich jetzt genommen. Hier sagen doch immer alle, dass man das Design Synchron halten soll ;-) > > Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen. > OK Viele Grüße, Christian
@ Christian H. (cavorca) >Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge. Das hast du vielleicht GEDACHT, aber mit nichten GESCHRIEBEN! >mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich Welches FIFO? Ein externer Baustein? Wozu? Du hast ein FPGA, da passen viel schnelle FIFOs rein. >komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den >50MHz? Wenn ja wüsste ich nicht warum. Kann man manchen. >Warum asynchron? Wenn ich zwei verschieden Takte habe, egal ob unabhängig oder per PLL/DCM gekoppelt, ich einfach ZWEI Takteingänge am FIFO brauche. UNd die haben nun mal nur Asynchrone FIFOs. > Macht es das nicht komplizierter? Nicht wirklich. > Reicht nicht auch ein >Synchroner? Siehe oben. >Den hätte ich jetzt genommen. Hier sagen doch immer alle, >dass man das Design Synchron halten soll ;-) Was bei einer Taktgrenze schlecht geht. MfG Falk
Gast
#922724
Christian H. hat viele Fragen: >Warum asynchron? Macht es das nicht komplizierter? Reicht nicht auch ein >Synchroner? Den hätte ich jetzt genommen. Hier sagen doch immer alle, >dass man das Design Synchron halten soll Wenn die Bemerkung von einem Beckenrandschwimmer gestattet ist: Wenn Du etwas kommerzielles baust solltest Du vielleicht etwas mehr Erfahrung haben -- oder Mitarbeiter die Dir helfen. Wenn es nicht kommerziell ist, würde ich zunächst den VHDL-Code schreiben, irgendwo verfügbar machen und zur Diskussion stellen. So ist das einfach alles zu wage. "Hier sagen doch immer alle" usw hat doch keinen Wert, wenn man nicht verstanden hat warum.
Falk Brunner wrote: > @ Christian H. (cavorca) > >>Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge. > > Das hast du vielleicht GEDACHT, aber mit nichten GESCHRIEBEN! > Ok, das in dem Post musste man wirklich missverstehen. Geschrieben habe ich es ganz oben schon mal. Aber dass man bei so einem langen Thread mal den Überblick verliert ist ja schon fast zu erwarten ;-) >>mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich > > Welches FIFO? Ein externer Baustein? Wozu? Du hast ein FPGA, da passen > viel schnelle FIFOs rein. Ich meine die Fifos im FX2. Es soll ja etwa so aussehen: ADC ---(50MHz)---> Fifo im FPGA ---(133MHz)---> SDRAM ---(133MHz)--->Fifo im FPGA ---(48 oder 30 MHz)---> Fifo im FX2 ---USB---> PC Und der Fifo im FX2 läuft nunmal nicht schneller als 48MHz. >>komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den >>50MHz? Wenn ja wüsste ich nicht warum. > > Kann man manchen. > >>Warum asynchron? > > Wenn ich zwei verschieden Takte habe, egal ob unabhängig oder per > PLL/DCM gekoppelt, ich einfach ZWEI Takteingänge am FIFO brauche. UNd > die haben nun mal nur Asynchrone FIFOs. > Hm. Ergibt Sinn. Ich habe mir den Fifo aus dem Xilinx Core Generator nochmal angesehen. Der hat 2 Takteingänge. Ob synchron oder asynchron steht gar nicht dabei. Wie auch immer, den sollte ich ja nehmen können für diese Anwendung. > Was bei einer Taktgrenze schlecht geht. ok. wenn er nur einen Takt hat klar. Ich dachte Synchron= 2 Takteingänge + WE und OE. Asynchron= nur WE und OE. Aber wie gesagt, mit dem aus dem Core Generator sollte es ja gehen.
Stefan Salewski wrote: > Wenn es nicht kommerziell ist, würde ich zunächst den VHDL-Code > schreiben, irgendwo verfügbar machen und zur Diskussion stellen. > Es ist nicht kommerziell. Dass mir die Erfahrung zu einem kommerziellen Produkt fehlt weiß ich. > "Hier sagen doch immer alle" usw hat doch keinen Wert, wenn man nicht > verstanden hat warum. Ich denke es war oben ja hauptsächlich das Missverständnis über Fifos oder ehr mein Unwissen wie man ein Fifo mit 2 Takteingängen nennt. Dass ich 2 Takte an der Stelle brauche ist mir absolut klar und dass ich ein evtl vorhandenes Modul, das nur einen Takt hat, nicht nehmen kann wäre mir sicher beim umsetzen des Designs aufgefallen, wenn ich versuche den 2. Takt anzuschließen. Gründe warum man hauptsächlich synchrone Desings verwenden soll kenne ich hier aus dem Forum einige, aber wann ein asynchrones - und damit meine ich jetzt das kein Takt vorhanden ist - Design Vorteile hat weiß ich nicht, bzw in welchen Situationen man eins braucht.
Gast
#922778
@Christian H. >Ich denke es war oben ja hauptsächlich das Missverständnis Also ich habe jedenfalls etwas den Überblick verloren, insbesondere auch durch Falks doch oft recht knappe Antworten. Das liegt sicher daran, dass ich bezüglich FPGA/VHDL immer noch Anfänger bin, aber gerade Anfänger möchten hier ja etwas lernen. Ich werde den Thread bei Gelegenheit nochmals in Ruhe lesen... Aber trotzdem verwundert es mich immer wieder, dass auch bei nichtkommerziellen Projekten von vielen aus Hard- und Software so ein großes Geheimnis gemacht wird. So nach dem Motto: Ich habe zwar tausend Fragen, aber das was ich bauen will ist so genial, dass ich möglichst nichts verraten möchte. (Es gibt natürlich auch das umgekehrte -- da wird wegen einer trivialen Frage ein riesiger Quelltext gepostet...) Diese Anmerkung ist eigentlich gar nicht so sehr auf diesen Thread bezogen -- es fällt mir bloß gerade in diesem Forum des öfteren auf.
Stefan Salewski wrote: > @Christian H. >>Ich denke es war oben ja hauptsächlich das Missverständnis > Ich sehe mich auch als Anfänger, wenn auch nicht mehr als Einsteiger. > Ich werde den Thread bei Gelegenheit nochmals in Ruhe lesen... > > Aber trotzdem verwundert es mich immer wieder, dass auch bei > nichtkommerziellen Projekten von vielen aus Hard- und Software so ein > großes Geheimnis gemacht wird. So nach dem Motto: Ich habe zwar tausend > Fragen, aber das was ich bauen will ist so genial, dass ich möglichst > nichts verraten möchte. (Es gibt natürlich auch das umgekehrte -- da > wird wegen einer trivialen Frage ein riesiger Quelltext gepostet...) Ja. Manche Leute wollen das Rad neu erfinden aber nicht verraten was das Geheimnis dahinter ist. Naja. Ich kenne auch jemanden der eine "Erfindung" "gemacht" hat, die alle Energieprobleme löst. Er will aber nicht verraten wie. Ich soll ihm die Thermodynamik dazu erklären. Passende Werte für seine Maschine soll auch jemand anders ausrechnen. Ich bin mal gespannt ob es überhaupt jemals einen Prototyp geben wird. Diese Leute wie Dr. Nobel Preis (Sesamstraße) sind halt eine eigene Kategorie. ;-) > Diese Anmerkung ist eigentlich gar nicht so sehr auf diesen Thread > bezogen -- es fällt mir bloß gerade in diesem Forum des öfteren auf. Ok. Aber findest du ich hätte an einer Stelle ausführlicher schreiben sollen was ich bauen will? Wenn ich es nicht ausführlich genug erzählt habe war es nicht mit Absicht.
Nochmal zu dem Taktkonzept. Ich habe 4 ADCs mit 8 Bit, die mit 50MHz abgefragt werden sollen. Dann habe ich 16 Bit digitale Eingänge die mit 100MHz abgefragt werden sollen. Würde Folgendes funktionieren: An jedem Eingang befindet sich erst mal ein Buffer (Wurde mir hier ja auch empfohlen, um das Design möglichst schnell zu machen). Die Buffer für die ADCs laufen mit den 50MHz die auch die ADCs bekommen. Bei der steigenden Flanke werden die Daten übernommen. (Bei der Fallenden wären sie ja nicht Valide.) Die 50MHz werden per DCM auf 100MHz multipliziert. Dabei nehme ich denjenigen Taktausgang des DCM, dass auf jede Flanke des 50MHz Signals eine Steigende 100MHz Flanke kommt. Ob das der CLK2x oder der CLK2X180 Ausgang des DCMs ist weiß ich jetzt noch nicht, aber einer von beiden MUSS es ja sein. Da die Taktflanken in diesem Fall synchron sind sollte ich doch einfach die Ausgänge der 50MHz Flipflops mit Logik verarbeiten können die mit diesen 100MHz getaktet werden. Im Prinzip ist es ja als ob die auch mit den 100MHz laufen, jedoch nur bei jedem 2. Takt ihren Wert ändern können. Soweit korrekt? Sollte es nicht sogar funktionieren, wenn ich weitere Logik mit 50 MHz betreibe und die Ergebnisse mit den 100MHz abfrage? Beispiel: Ich möchte wissen ob der Wert von einem ADC größer oder kleiner als 128 ist. Da digitale Vergleicher durch die lange Logik langsam sind bietet es sich an diesen Vorgang in einem langsamen Takt arbeiten zu lassen und selbst dann evtl. noch mit Pipeline. Vorausetzung ist dass ich hier am Ende des Vergleichers wieder ein Flipflop habe das mit den 50MHz getaktet wird. Dieser Ausgang sollte dann doch wieder ohne Probleme von Logik verarbeitet werden können, die mit 100MHz läuft? Ich meine es ist ja wieder genau das gleiche: Die Setup-, Hold- und Durchlaufzeiten eines Flipflops sind im FPGA ja so kurz, dass sie bei >>100MHz funktionieren. Also sollte es doch auch gehen, wenn ein Teil nur mit 50MHz läuft. Mit anderen Worten: Ob man jetzt ein Fipflop hat, dass mit 100MHz läuft und einen Enable Eingang hat, der jeden 2. Takt das Flipflop deaktiviert oder ob man gleich das Flipflop mit 50MHz betreibt sollte doch keinen Unterschied machen. Oder doch? Wenn ja habe ich ein fundamentales Verständnisproblem und bitte um Erklärung. Den einzigen Unterschied den ich sehe ist dass die Möglichkeit mit den 50MHz einfacher ist. Wenn ich ein Enable Signal habe muss ich noch irgendwie rausfinden ob ich die "graden" oder die "ungraden" Flanken ignoriere. (Denn die einen entsprechen den fallendan Flanken der 50MHz und die anderen den steigenden. Die Signale der ADCs sind aber nur bei den Steigenden valide.) Das entfällt beim direkten betreiben mit 50MHz. Ich hoffe das habe ich jetzt so geschrieben, dass man nicht den ganzen Thread lesen muss um zu verstehen worum es geht.
Gast
#925047
>Ich hoffe das habe ich jetzt so geschrieben, dass man nicht den ganzen >Thread lesen muss um zu verstehen worum es geht. Im Prinzip ist das doch ein ganz allgemeines Problem? Du willst einige Eingänge des FPGA mit einfacher Taktfrequenz (100MHz) abfragen, und andere mit halber (50MHz).
Gast
#925062
Noch eine Anmerkung vom Beckenrandschwimmer: Grundsätzlich sollte es doch einfacher sein, wenn Du als allgemeinen Takt 100 MHz verwendest, und ihn einfach zum Einlesen der ADC-Daten teilst (Flip-Flop oder wie auch immer.) Dann kannst Du auf den DCM verzichten -- das Einlesen bei jeden zweiten Takt sollte Standard sein. Der Nachteil wäre, dass der Takt für den ADC im FPGA halbiert werden muss, dadurch bekommst Du mehr Jitter. Aber bei 8 Bit und 50 MHz ist das nicht tragisch.
Stefan Salewski wrote: > Noch eine Anmerkung vom Beckenrandschwimmer: > > Grundsätzlich sollte es doch einfacher sein, wenn Du als allgemeinen > Takt 100 MHz verwendest, und ihn einfach zum Einlesen der ADC-Daten > teilst (Flip-Flop oder wie auch immer.) Dann kannst Du auf den DCM > verzichten -- das Einlesen bei jeden zweiten Takt sollte Standard sein. > > Der Nachteil wäre, dass der Takt für den ADC im FPGA halbiert werden > muss, dadurch bekommst Du mehr Jitter. Aber bei 8 Bit und 50 MHz ist das > nicht tragisch. Trotzdem würde ich lieber darauf verzichten. Außerdem muss ich dann die Laufzeiten zusätzlich berücksichtigen. Aber die sollten bei mir je recht übersichtlich sein. Aber mal prinzipiell: Sind meine Überlegungen richtig? Wenn nicht würde mich interessieren wo der Fehler liegt, wenn ja wäre es auch wichtig das zu wissen. Irgendwo geht es mir ja schon darum die Sachen mal zu verstehen. Sonst lerne ich es ja nie.
@ Christian H. (cavorca) >Die 50MHz werden per DCM auf 100MHz multipliziert. >Dabei nehme ich denjenigen Taktausgang des DCM, dass auf jede Flanke des >50MHz Signals eine Steigende 100MHz Flanke kommt. Ob das der CLK2x oder >der CLK2X180 Ausgang des DCMs ist weiß ich jetzt noch nicht, aber einer >von beiden MUSS es ja sein. ;-) Das kann man so gar nicht genau sagen, weil das nämlich beim Taktverdopplen zweiduetig ist. Du musst die Phasenausrichtung der beiden Takte mit Logik machen. Und zwar musst du mit dem 50 MHz Takt ein FF toggeln lassen. mit dem 100 MHz Takt tastest du dieses ab. Mit bissel Logik bekommt man daraus die richtige Phase des 100 MHz Taktes, welcher mit steigenden Flanke des 50 MHz Taktes übereinstimmt. >Da die Taktflanken in diesem Fall synchron sind sollte ich doch einfach >die Ausgänge der 50MHz Flipflops mit Logik verarbeiten können die mit >diesen 100MHz getaktet werden. Im Prinzip ist es ja als ob die auch mit >den 100MHz laufen, jedoch nur bei jedem 2. Takt ihren Wert ändern >können. >Soweit korrekt? Ja. Du kannst aber auch alles mit dem 50 MHz Takt machen. Die 100 MHz Digitaleingänge machst du über DDR FlipFlops, das ergibt dann auch 100 MHz Abtastfrequenenz. MFG Falk
Gast
#925114
Wenn er hinterher nicht in 100 MHz wieterarbeitet, beadrf es auch nicht der Abtastung ( interfacing mit 100 MHz ;-) Dann sollte man mal über das Systemdesign nachdenken. >Mit anderen Worten: Ob man jetzt ein Fipflop hat, dass mit 100MHz läuft >und einen Enable Eingang hat, der jeden 2. Takt das Flipflop deaktiviert >oder ob man gleich das Flipflop mit 50MHz betreibt sollte doch keinen >Unterschied machen. Doch : 2 Takte -> 2 Taktnetze die Strom ziehen.
Falk Brunner wrote: > ;-) > Das kann man so gar nicht genau sagen, weil das nämlich beim > Taktverdopplen zweiduetig ist. > mit steigenden Flanke des 50 MHz Taktes übereinstimmt. Hm. Ich hatte das hier gelesen: http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/s3edl/s3edl0021_13.html
1 | |
2 | |
Das "in phase with CLK0" hätte ich jetzt interpretiert ob das jedes mal gleich ist. Wie ich dich verstehe entscheidet es sich zufällig beim einschalten welcher der 2X Clocks die steigende Flanke Synchon zu den 50MHz hat. Also ist das bei Xilinx etwas missverständlich geschieben? Wie an der Stelle "in phase" definiert ist, konnte ich auch nicht finden. In anderen Dokumenten stand gar nichts dazu. > Du musst die Phasenausrichtung der beiden > Takte mit Logik machen. Und zwar musst du mit dem 50 MHz Takt ein FF > toggeln lassen. mit dem 100 MHz Takt tastest du dieses ab. Mit bissel > Logik bekommt man daraus die richtige Phase des 100 MHz Taktes, welcher Mir ist nicht ganz klar, wie ich die richtige Phase anschließend verwenden soll. Eine kombinatorische Clock soll ich ja sicher nicht basteln. Aber rausfinden welcher der richtige ist kann ich -wie ich dich verstehe- erst zur Laufzeit. Dann sind die Flipflops ja aber schon an das Taktnetz angeschlossen, was ich ja beim Designen festlege. Was soll ich also machen? Vielleicht alles doppelt vorsehen und die Daten zur falschen Flanke einfach verwerfen? Wäre dann ziemlich viel Zeug, was doppelt vorhanden ist... Oder wie geht es richtig? > Du kannst aber auch alles mit dem 50 MHz Takt machen. Die 100 MHz > Digitaleingänge machst du über DDR FlipFlops, das ergibt dann auch 100 > MHz Abtastfrequenenz. OK, damit habe ich noch nie gearbeitet. Die DDR-FFs muss man instanzieren und kann sie nicht mit "normalem" Code beschreiben? In der Beschreibung von Xilinx steht, dass das DDR-FF 2 Takteingänge hat. Der zweite sollte dann also der erste invertiert sein. Das mache ich aber sicher besser mit einem DCM als mit einem Inverter, da ich sonst die Verzögerungszeit des Inverters in den Pfad bekomme. Richtig? Thomas Ulrich wrote: > Wenn er hinterher nicht in 100 MHz wieterarbeitet, beadrf es auch nicht > der Abtastung ( interfacing mit 100 MHz ;-) Dann sollte man mal über das > Systemdesign nachdenken. Die Daten will ich schon alle verwenden. Eigentlich soll es nachher mit 100MHz laufen, vielleicht kann ich aber durch die DDR-FFs das ganze parallelisieren und das gleiche mit 50MHz erreichen. In die Richtung habe ich bisher noch nicht überlegt. Das werde ich aber mal tun. > Doch : 2 Takte -> 2 Taktnetze die Strom ziehen. OK. Von wie viel Strom reden wir denn? Finde ich das im Datasheet oder ist das realistisch betrachtet ehr Erfahrungssache?
@ Christian H. (cavorca) >> Das kann man so gar nicht genau sagen, weil das nämlich beim >> Taktverdopplen zweiduetig ist. >> mit steigenden Flanke des 50 MHz Taktes übereinstimmt. >Hm. Ich hatte das hier gelesen: >http://toolbox.xilinx.com/docsan/xilinx7/books/dat... >CLK2X* Clock at 2x CLK0 frequency, in phase with CLK0 >CLK2X180* Clock at 2x CLK0 frequency shifted 180o with regards to CLK2X Stimmt schon, aber du kannst vom 100 MHz Takt aus NICHT sagen, welche von zwei aufeinanderfolgenden Flanken mit der steigenden Flanke des 50 MHz Taktes übereinstimmt. Mals mal auf. CLK2x180 ist quasi um ein 1/4 der 50 MHz verschoben, was komischerweise 1/2 des 100MHz Taktes ist. >Mir ist nicht ganz klar, wie ich die richtige Phase anschließend >verwenden soll. Zum Takten deiner 50 MHz ADC Daten. >Eine kombinatorische Clock soll ich ja sicher nicht basteln. Aber Besser ist das. ;-) >rausfinden welcher der richtige ist kann ich -wie ich dich verstehe- >erst zur Laufzeit. Genau. > Dann sind die Flipflops ja aber schon an das Taktnetz >angeschlossen, was ich ja beim Designen festlege. Was soll ich also >machen? Einen rücksetzbaren Zähler bauen, der dann alles richtig steuert. >Vielleicht alles doppelt vorsehen und die Daten zur falschen Flanke >einfach verwerfen? Nöö, das wäre Unsinn. Denn du must dann immer noch rausfinden, welche Daten die richtigen sind. >OK, damit habe ich noch nie gearbeitet. Die DDR-FFs muss man >instanzieren und kann sie nicht mit "normalem" Code beschreiben? Genau. >In der Beschreibung von Xilinx steht, dass das DDR-FF 2 Takteingänge >hat. Der zweite sollte dann also der erste invertiert sein. Das mache >ich aber sicher besser mit einem DCM als mit einem Inverter, da ich Bei deinen Frequenzen reicht der Inverter. >> Doch : 2 Takte -> 2 Taktnetze die Strom ziehen. >OK. Von wie viel Strom reden wir denn? Ja nach Grösse des FPGAs zwischen 10..200mA. MfG Falk
Gast
#925222
>Hast Du mal darüber nachgedacht, dass es an der Clock liegen könnte, >dass das Program nicht anläuft? Hast Du DCMs drin? Hatte auch was >ähnliches, wo DCM nicht richtig konfiguriert wurde (ab und zu) und die >Clock falsche Frequenz hatte. Ja, DCM's sind drin. Und woran könnte es liegen bzw. wie hast du dr dabei beholfen?
Falk Brunner wrote: > Stimmt schon, aber du kannst vom 100 MHz Takt aus NICHT sagen, welche > von zwei aufeinanderfolgenden Flanken mit der steigenden Flanke des 50 > MHz Taktes übereinstimmt. Mals mal auf. OK: 50 MHz: +-------+ +-------+ +-------+ + -+ +-------+ +-------+ +-------+ 100MHz: +---+ +---+ +---+ +---+ +---+ +---+ + -+ +---+ +---+ +---+ +---+ +---+ +---+ 100MHz ~180° -+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ + Habe ich das so richtig verstanden: die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist zufällt. Was Xilinx mit "in Phase" meint ist nicht die Zuordnung: Bei A (hier das obere) ist immer bei einer steigenden Flanke irgend eine Flanke vom ursprünglichen Takt und bei B immer eine fallende, _sondern_: Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar Grad) früher oder später. Richtig? >>Mir ist nicht ganz klar, wie ich die richtige Phase anschließend >>verwenden soll. > > Zum Takten deiner 50 MHz ADC Daten. Betonung auf wie ;-) > Einen rücksetzbaren Zähler bauen, der dann alles richtig steuert. OK. > Bei deinen Frequenzen reicht der Inverter. Die "ordentlichere" Lösung wäre aber der DCM? Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz. Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder doch? Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite. > Ja nach Grösse des FPGAs zwischen 10..200mA. ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs? Ich werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich noch ehr im unteren Bereich? Viele Grüße, Christian
Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50 runterteilen und die 100Mhz für das kurze Stückschen zwischen den Digital-Eingängen und den ohnehin nötigen FIFO benutzen. Mit den 50Mhz genau so. Du musst ja eh zwischenspeichern, also kannst du gleich mit der von dir gewollten Sample-Rate in die FIFOs schreiben und auf der Lese-Seite dann den Takt verwenden, der am ehesten zum RAM-Interface passt. Für den FX2 brauchst du eh noch einen extra Takt, wenn du nicht den internen verwenden willst. Bei Internen FX2-Takt hast du folgendes: die 48Mhz sind Harakiri, da muss man extrem mit dem Timing aufpassen, einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC übertragen. Kannst du dir dann aussuchen, was für dich das kleinere Übel ist. Der Mehr-Stromverbrauch für einen weiteren takt hält sich in Grenzen, die Spartan 3e sind recht genügsam.
@ Christian H. (cavorca) >die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist >zufällt. Zufällig? Nein. Aber die Zuordnung steigende Flanke 100 MHz und steigende Flanke 50 Mhz ist zweideutig. Mak kann auch die fallende Flanke vom 50 MHz Takt erwischen, ausserdem ist nicht gesagt, dass der 50MHz GENAU 50% Tastverhältnis hat. >Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei >den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar >Grad) früher oder später. >Richtig? Ja. Wobei die DCMs AFAIK immer auf die steigende Flanke ausregeln. Oder kann man das einstellen? >> Bei deinen Frequenzen reicht der Inverter. >Die "ordentlichere" Lösung wäre aber der DCM? Ja, laut Xilinx bringt das ein paar sub-Nanosekunden. >Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz. >Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe >oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder >doch? Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist aber streng genommen anspruchsvoller vom Timing her. >Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite. >> Ja nach Grösse des FPGAs zwischen 10..200mA. >ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs? Beides. http://www.geocities.com/Jacquesmartini/digital/pldpower/pld_power_measurement.html Das war ein 200K Spartan-II, bei 150MHz. Machte dort ~200mA. Mal so als Vergleich. > Ich >werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich >noch ehr im unteren Bereich? Keine Ahnung. Ich würde das eher oben ansiedeln, so 100mA, ggf mehr. @ Christian R. (supachris) >Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50 >runterteilen und die 100Mhz für das kurze Stückschen zwischen den Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder verdoppeln oder mit DDR FlipFlop arbeiten. hat den Vorteil dass - die ADCs einen möglichst jitterarmen Takt bekommen - die Taktverteilung sternförmig ist - man "nur" 50 MHz vetrteilen muss und nicht 100 MHz MFG Falk
Falk Brunner wrote: > @ Christian R. (supachris) > >>Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50 >>runterteilen und die 100Mhz für das kurze Stückschen zwischen den > > Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber > sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder > verdoppeln oder mit DDR FlipFlop arbeiten. > hat den Vorteil dass > > - die ADCs einen möglichst jitterarmen Takt bekommen > - die Taktverteilung sternförmig ist > - man "nur" 50 MHz vetrteilen muss und nicht 100 MHz Stimmt so ist es besser, hab ich gar nicht dran gedacht. Vom (guten) Quarzoszillator direkt per Clock-Treiber auf die ADCs und per DCM im Spartan auf 100 MHz. Hat man halt nur einen (sehr) geringen Jitter beim Logic-Analyser. Aber besser als auf dem ADC.
Christian R. wrote: > Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50 > runterteilen und die 100Mhz für das kurze Stückschen zwischen den > Digital-Eingängen und den ohnehin nötigen FIFO benutzen. Mit den 50Mhz > genau so. Du musst ja eh zwischenspeichern, also kannst du gleich mit > der von dir gewollten Sample-Rate in die FIFOs schreiben und auf der > Lese-Seite dann den Takt verwenden, der am ehesten zum RAM-Interface > passt. Meinst du dann auch die geteilten 50MHz an die ADCs rausgeben? Sonst bekomme ich ja Probleme mit den Timings. Irgendwann muss ich mich auch drum kümmern, wie ich die Daten sortiere. Das mache ich lieber vor dem Fifo als danach da vorher die Taktrate noch ein wenig niedriger ist. > Für den FX2 brauchst du eh noch einen extra Takt, wenn du nicht > den internen verwenden willst. Bei Internen FX2-Takt hast du folgendes: > die 48Mhz sind Harakiri, da muss man extrem mit dem Timing aufpassen, ok, kann gut sein, dass ich damals 30MHz hatte und daher so wenig Probleme. > einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im > Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC Moment. Der Bus ist doch 16 Bit Breit. Das wären dann doch 60 MByte/s. Oder kenne ich da einen Flaschenhals noch nicht? Ich meine im Datasheet steht ja auch an den FIFOs max burst rate=96MByte/s Andererseits wäre ich auch schon mit 10MByte/s zufrieden. Mehr wäre natürlich besser, aber Hauptsache erst mal was mehr als die ~1MByte/s von Full Speed. > übertragen. Kannst du dir dann aussuchen, was für dich das kleinere Übel > ist. Der Mehr-Stromverbrauch für einen weiteren takt hält sich in > Grenzen, die Spartan 3e sind recht genügsam. Falk Brunner wrote: > @ Christian H. (cavorca) > >>die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist >>zufällt. > > Zufällig? Nein. Aber die Zuordnung steigende Flanke 100 MHz und > steigende Flanke 50 Mhz ist zweideutig. Mak kann auch die fallende > Flanke vom 50 MHz Takt erwischen, ausserdem ist nicht gesagt, dass der > 50MHz GENAU 50% Tastverhältnis hat. > Nagut, jetzt bin ich noch verwirrter. Also ist eine Zuordung doch immer fest: steigende Flanke CLK2X-> Flanke von CLK fallende Flanke CLK2X180-> Flanke von CLK Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im 100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass die Daten valide sind stelle ich doch durch den FF sicher der mit 50MHz läuft. >>Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei >>den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar >>Grad) früher oder später. >>Richtig? > > Ja. Wobei die DCMs AFAIK immer auf die steigende Flanke ausregeln. Oder > kann man das einstellen? > >>> Bei deinen Frequenzen reicht der Inverter. >>Die "ordentlichere" Lösung wäre aber der DCM? > > Ja, laut Xilinx bringt das ein paar sub-Nanosekunden. > Immerhin ;-) >>Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz. >>Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe >>oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder >>doch? > > Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist > aber streng genommen anspruchsvoller vom Timing her. > Da sagt mir aber doch die Synthese ob es geht oder nicht? >>Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite. > >>> Ja nach Grösse des FPGAs zwischen 10..200mA. >>ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs? > > Beides. > > http://www.geocities.com/Jacquesmartini/digital/pldpower/pld_power_measurement.html > > Das war ein 200K Spartan-II, bei 150MHz. Machte dort ~200mA. Mal so als > Vergleich. > >> Ich >>werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich >>noch ehr im unteren Bereich? > > Keine Ahnung. Ich würde das eher oben ansiedeln, so 100mA, ggf mehr. > Das ist viel Strom. Hatte da AMD seine Finger im Spiel? ;-) > Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber > sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder Warum eigentlich sternförmig? ich würde es so anordnen: Taktquelle -- ADCs -- FPGA Dann werden die Signale der ADCs genau so viel verzögert, wie der Takt zwischen ADCs und FPGA verzögert wird. Dann könnte ich doch die Lufzeiten so gut wie ignorieren. Oder ist das eine Milchmädchen-Rechnung. Wenn ja: Wo und warum?
Gast
#925292
Was versteht man denn unter einer sternförmigen Taktverteilung ???
Sven wrote: > Was versteht man denn unter einer sternförmigen Taktverteilung ??? So weit ich weiß: Alle Taktleitungen von der Takquelle zu den ICs die den Takt verwenden sind gleich lang. siehe: http://www.mikrocontroller.net/articles/SDRAM-Timing Ich fände es bei mir praktischer, wenn die Taktleitung zum FPGA um die Länge der Datenleitungen von ADCs zu FPGA, läger ist als die Taktleitung von Quelle zu ADCs. Ich bitte um Widerspruch, wenn das Quatsch ist.
@ Christian H. (cavorca) >Nagut, jetzt bin ich noch verwirrter. ;-) >Also ist eine Zuordung doch immer fest: >steigende Flanke CLK2X-> Flanke von CLK >fallende Flanke CLK2X180-> Flanke von CLK Nöö, eher so. steigende Flanke CLK2X-> steigende Flanke von CLK fallende Flanke CLK2X180-> steigende Flanke von CLK >Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die >auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im >100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass Das glaube ich kaum. >die Daten valide sind stelle ich doch durch den FF sicher der mit 50MHz >läuft. Nein, dann auch nicht. Denn dann reduziert sich im schlimmsten Fall ds Timing vom 50 MHz FlipFlop zum 100MHz FlipFlop. >> Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist >> aber streng genommen anspruchsvoller vom Timing her. >Da sagt mir aber doch die Synthese ob es geht oder nicht? Nein, das sagt dir der Timinganalyzer nach dem Place & Route. Die Angaben nach der Synthese sind ziemlich unbrauchbare Schätzwerte. >Das ist viel Strom. Hatte da AMD seine Finger im Spiel? ;-) AKAIF nein. Wenn dann eher Intel, die haben solche dreckigen Trick öfter genutzt. >Warum eigentlich sternförmig? Weils besser ist ;-) Fürs Timing und den Jitter. >Milchmädchen-Rechnung. Wenn ja: Wo und warum? Weil die ADCs einen gewissen Abstand zueinander haben, da kommt mal fix ne halbe Nanosekunde und mehr raus. Und Taktleitungen sollte man sehr konservativ behandeln, auch der Welenwiderstand ist hier ein zentrales Thema. >Ich fände es bei mir praktischer, wenn die Taktleitung zum FPGA um die >Länge der Datenleitungen von ADCs zu FPGA, läger ist als die Taktleitung >von Quelle zu ADCs. Ich bitte um Widerspruch, wenn das Quatsch ist. Ist Quatsch. Siehe Artikel zum SDRAM-Timing. Dein "Trick" verschiebt dir die Hold-Zeit, auch nicht gut. MfG Falk
Christian H. wrote: >> einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im >> Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC > > Moment. Der Bus ist doch 16 Bit Breit. Das wären dann doch 60 MByte/s. > Oder kenne ich da einen Flaschenhals noch nicht? > Ich meine im Datasheet steht ja auch an den FIFOs max burst > rate=96MByte/s > Andererseits wäre ich auch schon mit 10MByte/s zufrieden. Mehr wäre > natürlich besser, aber Hauptsache erst mal was mehr als die ~1MByte/s > von Full Speed. Der FX2 übernimmt die Daten nur bei jeder 2. Taktflanke. Bei 48Mhz IFCLK also 48 Mbyte/s. Mehr als 40 Mbyte/s wirst du eh nicht los, schneller ist USB nun mal nicht. Die 96 MByte/s Burst sind ein webegag. ich weiß nicht, woher die diesen fantasiewert nehmen.
Gast
#925479
Nur kurz zum "Phantasiewert 96 MByte/s": habe ein Design gehabt (USB hat jemand anders gemacht), da waren mit 8 Bit 40 MByte/s drin :-o Und das ist sehr wohl wahr. Ich vermute also, dass mit 16 Bit schon 80 MB/s drin gewesen wären. Wie USB-Teil programmiert wurde, keine Ahnung. Ich weis noch, dass ich sowohl Clock (48 MHz), als auch die clock um 135 Grad geschoben zum USB-Controller auf eine RDY4 Leitung legen sollte. Grüße, Kest
Laut Datenblatt muss das SLWR immer togglen und ist nur zu jeder 2. Flanke aktiv. Ich hatte auch probiert, das dauerhaft aktiv zu lassen um bei jeder Flanke zu schreiben, ging aber nicht, dann hat der FX2 jedes 2. Wort vergessen. Eventuell klappt das im GPIF Modus, weiß ich nicht, ich benutze den Slave FIFO Modus, da sind alle Timing-Diagramme im Datenblatt so, dass nur bei jeder 2. Flanke geschrieben wird.
Falk Brunner wrote: > @ Christian H. (cavorca) > >>Nagut, jetzt bin ich noch verwirrter. > > ;-) > >>Also ist eine Zuordung doch immer fest: >>steigende Flanke CLK2X-> Flanke von CLK >>fallende Flanke CLK2X180-> Flanke von CLK > > Nöö, eher so. > steigende Flanke CLK2X-> steigende Flanke von CLK > fallende Flanke CLK2X180-> steigende Flanke von CLK > Warum nur steigende Flanke von CLK? auf die fallende Flanke von CLK0 sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die steigende? Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich auflöst: Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke CLK2X180 oder kann es auch andersherum sein: fallende Flanke CLK2X, steigende CLK2X180->steignde Flanke von CLK? Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180 das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke. >>Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die >>auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im >>100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass > > Das glaube ich kaum. > Ich verstehe nicht warum. Dass ich synchron zu den Flanken des 50MHz FFs sein muss ist klar. Damit - so habe ich es verstanden - ergibt sich aber nur die Bedingung, dass ich den richtigen Takt aussuchen muss. CLK2X ODER CLK2X180. Das alles steht bei mir auf der Annahme: Alle Flipflops im FPGA sind etwa gleich schnell. Ist das richtig? Vielleicht ist das ja schon der Knackpunkt, dass das falsch ist. Ich meine: Was man beachten muss bei den Timings sind ja im Prinzip die Setup und Hold Zeiten. Beispiel der Ausgang von Flipflop A ist an den Eingang von Flipflop B angschlossen. B wird mit 100MHz getaktet. Daten sollen bei steigenden Flanken übernommen werden. Im ersten Fall soll A auch mit den gleichen 100MHz getaktet werden. Das sollte ja funktionieren. Jetzt betrachten wir den Fall, dass A mit 50MHz getaktet wird, undzwar so, dass die Flanken der 50 MHz Synchron mit den steigenden 100MHz Flanken sind. Dann gibt es 2 Fälle: 1) Steigende bei 50 und bei 100. Das ist eigentlich das gleiche als ob man beides mit 100MHz betreibt. Dadurch dass der letzte Flanke von A aber doppelt so lange her ist verlängert sich die Zeit die die Daten an B anliegen. Aber das macht ja nichts aus. 2) Fallende bei 50, Steigende bei 100. Da das FF A bei 100MHz laufen würde (es ist ja ganau so schnell wie B) sind bei der Flanke die Daten des letzten Taktes schon valide. Die Setup und Hold Zeiten müssen also erfüllt sein (sofern es im reinen 100MHz betrieb läuft.) Versteh mich nicht falsch: Ich glaube dir ja, dass du Recht hast. Du hast sicher mehr Erfahrung und Wissen darüber als ich. Aber: Wo ist der Fehler in meiner Argumentation? > Nein, das sagt dir der Timinganalyzer nach dem Place & Route. Die > Angaben nach der Synthese sind ziemlich unbrauchbare Schätzwerte. > Aber ich erfahre es und kann mich auf die Werte verlassen? > AKAIF nein. Wenn dann eher Intel, die haben solche dreckigen Trick öfter > genutzt. War ja eigentlich nur ein Spaß. Aber warum war es denn lange so, dass AMD so extrem viel Strom verbraucht hat? Vor einigen Jahren brauchten die doch > Weils besser ist ;-) > Fürs Timing und den Jitter. Wie wirkt sich die Leitungslänge auf Jitter aus? Oder nennt man Jitter auch den Zeitunterschied der Flanken zweier verschiedener Signale? > >>Milchmädchen-Rechnung. Wenn ja: Wo und warum? > > Weil die ADCs einen gewissen Abstand zueinander haben, da kommt mal fix > ne halbe Nanosekunde und mehr raus. Und Taktleitungen sollte man sehr halbe Nanosekunde wären 10 cm. Ich denke nicht, dass ich über 3 cm komme. Aber das wird sich ja beim erstellen der Platine zeigen. > Ist Quatsch. Siehe Artikel zum SDRAM-Timing. Dein "Trick" verschiebt dir > die Hold-Zeit, auch nicht gut. Wie schon oben geschrieben: An den ADC Ausgängen liegen bei 50MHz Betrieb die Daten seit mindestens 8 ns an, nach der Flanke noch mindestens 3,9 ns. Ich habe jetzt nicht nachgesehen was die FFs im Spartan für Setup und Hold werte fordern, aber ich denke mit diesen Werten leige ich weit im grünen bereich. Wenn jetzt aber die Taktverteilung sternförmig mache dann liegen die Daten noch etwas länger an. Hm ok. Du hast recht. Das macht die Sache ehr einfacher. Aber bei den Zeiten und kurzen Leitungen sollte das ja auch nicht soo kritisch sein. Den Artikel über SDRAM-Timing werde ich sicher nochmal lesen. Aber frühestens nächste Woche. Eigentlich habe ich momentan nicht mal Zeit hier zu antworten. @Christian R. und Kest: Das nur jede 2. Flanke die Daten aufgenommen werden hat mir gestern echt den Rest gegeben. Ich will echt mal wissen, was ich damals gemacht habe als ich den FX2 an meinem Spartan Board getestet habe. Wahrscheinlich habe ich es einfach übersehen, dass die Hälfte nicht ankommt. Kann es vielleicht sein, dass es nur bei 16 Bit Betrieb der Fall ist, dass nur bei jeder 2. Flanke Daten genommen werden und bei 8 Bit bei jeder Flanke? Das würde ja zu eurer beider Erfahrungen passen. Warum tut Cypress so etwas?? Das macht doch alles unnötig komplizierter. Ich meine warum nehmen die dann nicht gleich den halben Takt? Viele Grüße, Christian P.S. Die 96MByte/s Burst Rate kann man haben. Zumindest, wenn man nur 16 Bit überträgt ;-)
@ Christian H. (cavorca) >Warum nur steigende Flanke von CLK? Weil DCMs bzw. PLLs etc. so funktionieren. Sie werten nur ein Flanke aus. > auf die fallende Flanke von CLK0 >sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die >steigende? Nöö, das klappt nur, wenn CLK ziemlich genau 50% Tastverhältnis hat. Und das ist in der Realität selten der Fall. Deshalb gibt es ja den Duty Cycle Corretion Modus, wo der DCM ein sauberes 50% Tastverhältnis generiert. >Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich >auflöst: ;-) >Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke >CLK2X180 AFAIK ja. oder kann es auch andersherum sein: fallende Flanke CLK2X, >steigende CLK2X180->steignde Flanke von CLK? AFAK nein, es sei denn, man kann das irgendwo noch einstellen. >Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180 >das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke. Meistens ja, immer nein. Wenn CLK0 genau 50% Tastverhältnis hat, fallen auch diese Flanken aufeinander. Vorsicht Falle. >>Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die >>auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im >>100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass > > Das glaube ich kaum. > >Ich verstehe nicht warum. Dass ich synchron zu den Flanken des 50MHz FFs >sein muss ist klar. Damit - so habe ich es verstanden - ergibt sich aber >nur die Bedingung, dass ich den richtigen Takt aussuchen muss. CLK2X >ODER CLK2X180. Nöö, du musst auch die richtige Phase erwischen, sonst werden dein Timingreserven unnötig vermindert. >Das alles steht bei mir auf der Annahme: Alle Flipflops im FPGA sind >etwa gleich schnell. Ist das richtig? Ja, tut hier aber nix zur Sache. Schau nochmal in dein Timingdiagramm und frage dich was passiert, wenn du eine CLK2x Flanke nach links oder Rechts rückst. Wie ändert sich der zeitliche Abstand? Das sind deine Timingreserven. >Flanken sind. Dann gibt es 2 Fälle: >1) Steigende bei 50 und bei 100. Genau. >Das ist eigentlich das gleiche als ob man beides mit 100MHz betreibt. Eben. >Versteh mich nicht falsch: Ich glaube dir ja, dass du Recht hast. Du >hast sicher mehr Erfahrung und Wissen darüber als ich. Aber: Wo ist der >Fehler in meiner Argumentation? Die stimmt wahrscheinlich im Grossen und Ganzen in deinem Kopf, allerding sind deine Formulierungen etwas schwammig und bisweilen zu allgemein. >Aber ich erfahre es und kann mich auf die Werte verlassen? Ja. >War ja eigentlich nur ein Spaß. Aber warum war es denn lange so, dass >AMD so extrem viel Strom verbraucht hat? Und Intel baut seit Äonen von Jahren Stromsparwunder? Hab ich was verpasst? >Wie wirkt sich die Leitungslänge auf Jitter aus? Lange Leitungen auf dem Board können mehr Störungen oder Reflexionen einfangen, das macht Jitter. > Oder nennt man Jitter >auch den Zeitunterschied der Flanken zweier verschiedener Signale? Nöö, das ist Skew. Jitter ist die zeitliche Veränderung des Auftretens einer Flanke, praktisch das zeitliche Zappeln einer Flanke um einen idealen zeitpunkt. Mal bissel früher, mal bissel später. >macht die Sache ehr einfacher. Aber bei den Zeiten und kurzen Leitungen >sollte das ja auch nicht soo kritisch sein. Nein, ist aber dennoch besser. Wieviel wird sich zeigen. MFG Falk
Falk Brunner wrote: >> auf die fallende Flanke von CLK0 >>sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die >>steigende? > > Nöö, das klappt nur, wenn CLK ziemlich genau 50% Tastverhältnis hat. Und > das ist in der Realität selten der Fall. Deshalb gibt es ja den Duty > Cycle Corretion Modus, wo der DCM ein sauberes 50% Tastverhältnis > generiert. > Ah, das klärt so einiges. Sag mit doch gleich, dass mein Bild oben falsch ist ;-) Bei Xilinx steht aber, dass CLK(0/2X/2X180) alle 50-50 Duty Cycle haben (Wenn man den DCM so einstellt)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
quelle: http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/s3edl/s3edl0021_13.html >>Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich >>auflöst: > > ;-) > >>Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke >>CLK2X180 > > AFAIK ja. OK :-) >>Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180 >>das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke. > > Meistens ja, immer nein. Wenn CLK0 genau 50% Tastverhältnis hat, fallen > auch diese Flanken aufeinander. Vorsicht Falle. > Jetzt wiedersprichst du dir. Sagen wir bei 0° hat CLK0 die Rising Edge. Oben sagst du jetzt, dass bei 0° auch die steigende von CLK2X und die Fallende von CLK2x180. Bei 180° haben CLK2X und CLK2X180 nochmal die gleichen flanken. Bei 50-50 DC von CLK0 ist hier noch eine Steigende Flanke von CLK0. Die fallende Flanke von CLK2X und die Steigende von CLK2X180 sind (bei 50-50 DC) bei 90° und bei 270°. Da sollte doch in der Regel nichts passieren. Erst recht nicht bei CLK0 ist 50-50. Wenn dann doch ehr bei so extremen fällen wie 25-75 oder 75-25. Oder nein? > allerding sind deine Formulierungen etwas schwammig und bisweilen zu > allgemein. Ja, das Problem bemerke ich auch. Ich glaube an manchen Stellen fehlen mir ein wenig die Fachausdrücke um das was ich meine klar und knapp in einem Satz zu sagen. > Und Intel baut seit Äonen von Jahren Stromsparwunder? Hab ich was > verpasst? Das nicht. Wenn ich mich richtig erinnere hatte Intel aber vor AMD die Idee, dass man einen Prozessor, wenn er nicht gebraucht wird, auch mal mit einer kleineren Frequenz Takten kann und damit die Versorgungsspannung reduzueren kann. Aber egal, darum geht es hier ja eigentlich nich. > Lange Leitungen auf dem Board können mehr Störungen oder Reflexionen > einfangen, das macht Jitter. OK, Akzeptiert. > Nein, ist aber dennoch besser. Wieviel wird sich zeigen. OK Viele Grüße, Christian
@ Christian H. (cavorca) >Die fallende Flanke von CLK2X und die Steigende von CLK2X180 sind (bei >50-50 DC) bei 90° und bei 270°. Da sollte doch in der Regel nichts >passieren. Erst recht nicht bei CLK0 ist 50-50. Wenn dann doch ehr bei >so extremen fällen wie 25-75 oder 75-25. Stimmt. MFG Falk
Christian R. wrote: > Laut Datenblatt muss das SLWR immer togglen und ist nur zu jeder 2. > Flanke aktiv. Ich hatte auch probiert, das dauerhaft aktiv zu lassen um > bei jeder Flanke zu schreiben, ging aber nicht, dann hat der FX2 jedes > 2. Wort vergessen. Eventuell klappt das im GPIF Modus, weiß ich nicht, > ich benutze den Slave FIFO Modus, da sind alle Timing-Diagramme im > Datenblatt so, dass nur bei jeder 2. Flanke geschrieben wird. Wo steht dass man SLWR immer togglen muss? Ich kann das beim besten willen nicht finden. Ehr im Gegenteil: Aus dem TRM: Slave Write — SLWR In synchronous mode (IFCONFIG.3 = 0), data on the FD bus is written to the FIFO (and the FIFO pointer is incremented) on each rising edge of IFCLK while SLWR is asserted. In asynchronous mode (IFCONFIG.3 = 1), data on the FD bus is written to the FIFO (and the FIFO pointer is incremented) on each asserted-to-deasserted transition of SLWR. By default, SLWR is active-low; its polarity can be changed via the FIFOPINPOLAR register. Auch im Datasheet sieht es anders aus: Abbildung 31 auf Seite 51 und Abb. 23 auf S. 47 (Beide Papiere gibts auf http://www.cypress.com/products/index.jsp?gid=9&fid=14&category=All&; ) Reden wir evtl. von verschiedenen chips? Wobei ich aber auch nicht glaube, dass es beim FX2 anders ist als beim FX2LP
Stimmt, es geht offensichtlich auch bei jeder Flanke ohne Tooggeln. Ich bin nach den Bildern 9-12 und 9-13 auf Seite 121 des TRM gegangen. Müsste man mal probieren, dann würde ja auch der 30MHz interne Takt reichen. Bei unserer Anwendung ist es egal, ich arbeite mit 40Mhz externem Takt und kann somit 40MByte/s übertragen, da ich bei jeder 2. Flanke 16 Bit schreibe. Klappt bestens. Ich werd aber mal ausprobieren, wie es mit SLWR und SLRD dauerhaft auf Low klappt.
OK. Ich hoffe ich schaffe es das heute mal auszuprobieren. In meinem Projekt werde ich auf jeden Fall 30MHz extern nehmen, da ich dann im FPGA mit 2 verschiedenen Takten auskomme. Sonst brauche ich 3. Aber Geschwindigkeit ist bei mir eh nicht so wichtig, so lange es wenigstens etwas schneller als Full-Speed ist. Wenn man SLWR nicht togglen muss entspannt das doch auch das Timing. Sehe ich das richtig? Ich meine die Setup und Hold Zeiten der Daten sind ja wesentlich kürzer als die von SLWR. Evtl muss man durchzählen, wann der Buffer voll ist, aber man kann ja auch einstellen, dass der Full-Flag schon gesetzt wird, wenn noch genau ein mal geschrieben werden kann. Viele Grüße, Christian
Hatte erst heute Gelegenheit. Ergebnis: Daten werden auch bei SLWR permanent LOW alle übertragen. Ob in der Datenübertragung Fehler sind habe ich noch nicht überprüft. Aber ich bin recht sicher, dass zumindest keine Words verschluckt werden. Am FX2 hängt ein FPGA in dem ein Zähler implementiert ist. Bei jedem Takt bei aktivem SLWR wird der Zähler inkrementiert. Wenn ich in der CyConsole 1024 Bytes übertrage ist das letzte Byte jedes mal gleich. Auch nachdem ich x mal 1024 Bytes übertrage. Es könnte natürlich auch noch sein, dass aus irgendwelchen Gründen auch immer ein Word verdoppelt wird, wenn eins verschwindet. Bei nächster Gelegenheit werde ich mal ein Programm schreiben, dass Checkt ob alle Daten stimmen. Ich bin auch sehr gespannt auf welche Datenrate ich jetzt komme.
Ich habe jetzt einige 100MB Daten übertragen und sie kommen so weit ohne Aussetzer an. Bevor ich wirklich behaupten würde, dass es einwandfrei läuft würde ich noch eine GB übertragen. Allerdings läuft die Übertragung nur mit 2,5 bis 3,5MByte/s. Auf dem PC läuft kaum was. Die CPU Nutzung schwankt irgendwo bei 10%. Das einzige was ich hier im Forum dazu finden konnte ist dass man IOCTL_ADAPT_SET_TRANSFER_SIZE auf einen großen Wert setzen soll. Diese Funktion kann ich aber weder bei Google noch im PDF zur CyAPI finden. Die Daten schreibe ich mit einem FPGA in den FX2. Konfiguration: EP2 1024kByte, 4fach buffered. Am USB-Port hängt sonst noch das FPGA Board. USB wird da aber nur als Stromversorgung genutzt. Ob intern im Notebook noch Geräte existieren die USB nuten weiß ich nicht. Hat jemand einen Vorschlag was ich noch probieren kann? Viele Grüße, Christian
Ahja, naja, laut Datenblatt soll es ja wohl auch mit permanentem Low klappen. Gut zu wissen, die bestehende Schaltung bau ich jetzt nicht mehr um, aber das nächste mal dann. Im CyAPI musst du SetXFerSize aufrufen, und am besten auf 64k setzen, dann erreicht man ungefähr 40 MByte/s.
Ich habe schon 8k, 64k und 2M ausprobiert. Nach einem neustart des Systems komme ich auch nicht über 4MByte/s. Ob ein anderes Gerät den Bus blockiert? Allerdings ist es auf einem anderen System das gleiche...
vielleicht ist mein Code falsch?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
Wenn ich den Teil der prüft ob die Daten stimmen rausnehme, ist es auch nicht bedeutend Schneller.
Jo, wenn du jedes Paket einzeln abholst, ist das klar. Musst gleich mit einem XFer 64k oder sowas die Daten holen. So packt der nur 1024 byte in einen MicroFrame. Damit kommst du rechnerisch auf max. 8.000.000 Bytes/s. Ein Microframe ist 128µs lang, bei einer Füllung von lediglich 1024 Byte geht da nicht mehr. Der FX2 kann aber bis zu 11 Pakete á 512 byte in einen MicroFrame stecken. Bei 10 Paketen, also 5120 byte pr Frame kommt man auf 40.000.000 Byte/s. 11 ist das Maximum, mehr passt einfach nicht rein. Damit kommt man auf max. 41,96 MByte/s. Kann man sich schön auf dem Oszi direkt an D+ oder D- angucken, wie voll die Frames dann sind.
Ah! Super! Vielen Dank!! Jetzt läuft es auch bei mir mit 37,5 - 39 MiB/s (ohne die Kontrolle ob die Daten stimmen. Mit bin ich bei ca 30MiByte/s. Jetzt muss ich mir wohl mal ansehen wie man Programme mit mehreren Threads schreibt.) Ich habe jetzt mal 4,5GiB übertragen. War kein Fehler dabei. Vielleicht lasse ich es irgendwann mal eine Nacht durchlaufen. Gibt es eine maximale Größe für die Länge die ich bei XferData angebe? Im PDF steht ja nur was zu isochronous transfers. Was ich an der Doku auch sehr eigenartig finde ist, das bei den Funktionen nicht explizit dabei steht welche Parameter sie haben und von welchem Typ die sind.
Jo, verloren geht bei BULK nix, alles was in den Chip rein kommt, bekommt man auch am Host. Die Doku ist wirklich sinnlos, hab das auch alles durch probieren rausgefunden. Maximale TransferSize ist wohl 3MB, hatte mal einer rausgefunden hier. Bringt aber nix. Das Optimum liegt je nach hostcontroller bei 64 oder 128 k. Multithreading ist da wirklich angesagt, Daten abholen und Daten auswerten in verschiedenen Threads. Du hattest jetzt 30MHz IFCLK, und Schreiben bei jeder Flanke, oder? Wenn da auch nicht mehr als 40MB/s rauskommen, brauch ich ja erst ma nix an der Schaltung im FPGA zu ändern.
Christian R. wrote: > Jo, verloren geht bei BULK nix, alles was in den Chip rein kommt, > bekommt man auch am Host. Meine Sorge war nicht, dass durch den Bulktransfer Daten verloren gehen oder verfälscht werden, sondern auf dem Weg zum FX2. Das geht über 2 Stecker, verschiedene Leitungsimpedanzen, katastrophale Masserückleitung,... Aber wenn es hier Funktioniert funktioniert es mit einem Ordentlichen Design garantiert. Und das Timing sollte ja auch in Ordnung sein, wenn die Übertragung Fehlerfrei läuft. > Die Doku ist wirklich sinnlos, hab das auch > alles durch probieren rausgefunden. Maximale TransferSize ist wohl 3MB, > hatte mal einer rausgefunden hier. Bringt aber nix. Das Optimum liegt je > nach hostcontroller bei 64 oder 128 k. OK. >Multithreading ist da wirklich > angesagt, Daten abholen und Daten auswerten in verschiedenen Threads. Ja. > > Du hattest jetzt 30MHz IFCLK, und Schreiben bei jeder Flanke, oder? Wenn Sogar 48MHz IFCLK. (IFCONFIG=0xE3) Und ja, schreiben bei jeder Flanke. Mein Rekord war 39,4 MiB/s. Wenn man über längere Zeiten mittelt geht es ehr Richtung 38, sofern der PC nix anderes macht. > da auch nicht mehr als 40MB/s rauskommen, brauch ich ja erst ma nix an > der Schaltung im FPGA zu ändern. Mich würde ja schon interessieren was du da baust. Oder darfst du das nicht erzählen?
Christian H. wrote: > Mich würde ja schon interessieren was du da baust. Oder darfst du das > nicht erzählen? Den Nachfolger dieses Geräts: http://www.izfp-d.fraunhofer.de/download/micro-use.pdf
Sieht interessant aus. Und ich dachte in der Industrie verwendet man ehr CAMAC, VME oder PCI oder etwas in der Richtung oder soll das Produkt mobiler sein?
PCI Karte haben wir ja auch. Aber für 16 Ultraschallkanäle braucht man 16 Full-Size PCI-Karten mit jeweils 35 Watt Leistungsaufnahme. Dazu ein riesen 19" Industrie-PC mit einer 16 PCI-Slot Backplane. Gesamt-Leistungsaufnahme etwa 900 Watt. Und die ganze Sache mit dem PC ist dann ortsfest und erschütterungsempfindlich. Um aber ordentliche Signale von den Ultraschall-Sensoren zu erhalten müssen die Kabel kurz sein. In den meisten Fällen ist der Prüfling aber einige Meter entfernt, riesengroß, tonnenschwer und muss durch ein Portal o.ä. abgescannt werden. Eine solche USB-Kiste ersetzt 16 Full-Size PCI Karten und ist dazu da, um auf einem beweglichen Portal zusammen mit einem kleinen Wall-Mount-PC (und evtl weiteren USB-Geräten) zur Datenaufnahme montiert zu werden. Zum Host-Rechner gehen dann die Daten per Ethernet.
So, ich hab jetzt die Ansteuerung des FX2LP auch mal auf Lesen/Schreiben bei jeder Flanke des IFCLK und durchgehend aktiven SLWR und SLRD umgebaut. Klappt prima. Der FPGA schreibt/liest jetzt mit 80 MB/s, bei 40 MHz externem IFCLK. Weiß gar nicht, wieso ich das anfangs im Datenblatt nicht so gesehn hatte. Erwartungsgemäß ist die Kommunikation zum PC aber auch nicht schneller, viel mehr als 40 MByte/s geht ja nicht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.