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
>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?
>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
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...
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
;-)
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 ;-)
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
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.
@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.
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
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.
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.
> 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,...
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
> 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.
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
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
>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 ?
>>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 (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
>> 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?
> 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
@ Christian H.
die Initial-/oder Default-Werte legst du bei der Deklaration fest.
z.B.
1
signalmy_signal:std_logic:='1';
oder
1
process(...)
2
variablemy_variable:std_logic:='1';
3
begin
4
...
5
endprocess;
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
initial data=0;
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€.
@ 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
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
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
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.
@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
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.
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
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
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
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
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
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.
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?
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
>>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
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.
@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.
>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).
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
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.
CLK2X* Clock at 2x CLK0 frequency, in phase with CLK0
2
CLK2X180* Clock at 2x CLK0 frequency shifted 180o with regards to CLK2X
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
>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?
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.
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
The duty cycle of the CLK0 output is 50-50 unless the
2
DUTY_CYCLE_CORRECTION attribute is set to FALSE, in which case the duty
3
cycle is the same as that of the CLKIN input. The duty cycle of the phase
4
shifted outputs (CLK90, CLK180, and CLK270) is the same as that of the CLK0
5
output. The duty cycle of the CLK2X, CLK2X180, and CLKDV outputs is 50-50
6
unless CLKDV_DIVIDE is a non-integer and the DLL_FREQUENCY_MODE is High
7
(see “CLKDV_DIVIDE,” in the Constraints Guide for details).
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...
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?
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.
Thread beobachten
Seitenaufteilung abschalten