Hallo zusammen. Mein Problem ist etwas schwer zu beschreiben. Ich bitte daher um Nachsicht. Ich schreibe ein VHDL-Code für eine Controlleranbindung (diverse Adressleitungen, 16-Bit Datenbus + diverse Steuerleitungen, CS, RW, RD, RAS, CAS usw.) Die Anbindung zw. Controller unf FPGA (der Adress- und Datenbus) läuft mit 50 Mhz. Genauer gesagt ist es sogar eine SDRAM-Anbindung zw. Controller und FPGA. Der interne Takt des FPGA beträgt 625 Mhz. Nun kommt es immer wieder vor, dass beim hinzufügen von Componenten (z.B: neue Register oder Timer im FPGA), mein Design nicht mehr "läuft". Ich habe die Vermutung, dass das Timing im FPGA plötzlich "futsch" ist. Place&Route versucht ja die einzelnen Slices optimal zu platzieren und das ganze Design optimal zu routen. Da dies aber bei hinzufügen / entfernen von Componenten immer wieder anders geroutet / platziert wird, vermute ich dass es daher kommt. Ich habe so gut wie keine Constraints mit Timingwerten hinterlegt. Jetzt meine Frage: Muss ich für jedes Signal, welches von "Aussen" kommt ein Constraint anlegen, oder muss ich ein einmal funktionierendes Design "festsetzen", so dass die schon funktionierenden Blöcke immer wieder von Place & Route an die gleiche Stelle geroutet werden? Wenn Timingcontraint: Wie lege ich dies an? Ein einzeiliges Beispiel wäre Super. Oder vielleicht doch ganz anders ? Danke schon mal für euere Hilfe. noeppkes ...
Gast
#2243601
Christian Armbruster schrieb: > Der interne Takt des FPGA beträgt 625 Mhz. Oha. Da fühle ich mich gleich als Amateur, weil meine Designs selten über 100 MHz gehen... Christian Armbruster schrieb: > Ich habe so gut wie keine Constraints mit Timingwerten hinterlegt. Das solltest Du aber. 1 Takt (wenn möglich), synchrones Design (wichtig!) und ein Clock constrain, z.B.:
1 | |
2 | |
Und irgendwie habe ich das Gefühl, das Du bisher keine Simulation durchgeführt hast... Christian Armbruster schrieb: > so dass die schon funktionierenden Blöcke immer wieder von > Place & Route an die gleiche Stelle geroutet werden? Nein. Dafür sorgen die Constraints. Duke
Die OFFSET IN Constraints für die Bus-Seite sind auch sehr hilfreich, denn da krachts am ehesten mal bei solchen Sachen. Dass man den Takt als Constraint angibt, ist ja das mindeste.
Christian Armbruster schrieb: > Place&Route versucht ja die einzelnen Slices optimal zu platzieren und > das ganze Design optimal zu routen. Nein. Das tut P&R leider nicht! Sondern es platziert das Design nur irgendwie, so dass es im FPGA Platz hat. Wenn du spezielle Wünsche hast (und die hast du mit eine Taktfrequenz von einem halben GHz!) dann MUSST du der Toolchain UNBEDINGT sagen, wie schnell dein Design laufen soll. BTW: was ist das für ein FPGA? Welche maximale Taktfrequenz spukt dir die Synthese aus? Ich habe den Verdacht, dass dein Design nicht mehr implementiert wird, wenn du ein Timing-Constraint angibst... > ... kommt es immer wieder vor ... > Ich habe die Vermutung ... > Und irgendwie habe ich das Gefühl ... Irgendwie esoterisch, das hier... ;-)
Das müsste dann ja schon fast ein Virtex 7 sein. Der Virtex 6 schafft intern 600MHz an BlockRAM und DSP48 Modulen. Viel mehr ist eigentlich schon nicht machbar intern....
Hallo Duke. Danke für deine Antwort. > Das solltest Du aber. 1 Takt (wenn möglich), synchrones Design > (wichtig!) und ein Clock constrain, z.B.: >
1 | |
2 | |
3 | |
Na ja. Das habe ich angelegt. Ist automatisch drin. Habe noch ein DDR3-RAM implementiert. > Und irgendwie habe ich das Gefühl, das Du bisher keine Simulation > durchgeführt hast... Teilweise schon. Nur das mit der Simulation ist so ne Sache. Steig da noch nicht ganz durch. > Christian Armbruster schrieb: >> so dass die schon funktionierenden Blöcke immer wieder von >> Place & Route an die gleiche Stelle geroutet werden? > Nein. Dafür sorgen die Constraints. > > Duke O.K. D.h. wenn ich obiges Constraints angelegt habe, kann es trotzdem sein, dass mein Design nicht läuft? Ich meine natürlich nur von den Timings her. Genau diese Befürchtung hatte ich nämlich. Muss ich denn nun die restlichen Signale auch noch mit Timingwerten versehen? noeppkes ...
HalloChristian R. Um das ganz mal mit dem Board aufzuklären. Christian R. schrieb: > Das müsste dann ja schon fast ein Virtex 7 sein. Der Virtex 6 schafft > intern 600MHz an BlockRAM und DSP48 Modulen. Viel mehr ist eigentlich > schon nicht machbar intern.... Es ist Board von Trnez electronic. GigaBee XC6SLX (Spartan-6LX) Industrie-Mikromodul (XC6SLX45-2FGG484C = 43 k logic cells, commercial grade) Das Ding hat gleich noch ein paar MB DDR3-RAM drauf. Und man bekommt dafür ein DDR3-Referenzdesign (Kommt aber von der MIG). Das DDR3-RAM ist sogar schon mal gelaufen. Das DDR3-Ram wird per FPGA an den Controller angeschlosssen. Dazu noch ein paar Register / Timer und ein TFT als 16-Bit RGB am FPGA. Dabei stellt der FPGA gleich noch 2 Hardwarefenster zur Verfügung die ich über X-Y Koordinaten über das eigentliche Fenster wandern lassen kann. Das ganze funktioniert sogar. Eben nur mit den Einschränkungen, dass wenn ich was ändere / hinzufüge am Design, es teilweise nicht mehr läuft. Ich bastle dann ewig lange bis es wieder geht. Aber nun wieder zurück zu meiner Frage. Muss ich nun ALLE externen Leitungen per Timing angeben / eingrenzen oder wie? Wie gesagt, ab und zu zerschiesst es mir die Anbindung an meinen Controller. Dabei auch nicht alles, sondern nur Teile davon. Vermute eben, dass intern dann zum Teil längere Laufzeiten "geroutet" werden. noeppkes ... noeppkes ...
Hallo Lothar. Wird die max. Taktfrequenz irgendwo innerhalb der zig Tausend Ausgaben ausgegeben? noeppkes ...
Hallo Duke. > Christian Armbruster schrieb: >> Ich habe so gut wie keine Constraints mit Timingwerten hinterlegt. > Das solltest Du aber. 1 Takt (wenn möglich), synchrones Design > (wichtig!) und ein Clock constrain, z.B.: >
1 | |
2 | |
3 | |
>
Habe nur 1 Takt, (mit ner PLL ochgejubelt), synchrones Design und eben
auch die TIMESPEC angegeben.
noeppkes ...
Hui, ein Spartan 6 mit 625Mhz intern? Das ist ja recht sportlich. Der BlockRAM schafft da gerade mal 250Mhz, wenn ich mich recht erinnere. ALLE Leitungen musst du ntürlich nicht mit Constraints belegen, aber gerade am Bus zu deinem µC solltest du die OFFSET IN Constraints setzen. Denn meist reichen dann irgendwelche Setup- oder Hold-Zeiten nicht aus. Wir haben hier ein Spartan 6 Design mit vielen Kanälen mit FIR-Filtern usw. und auch einer Anbindung an TI EMIF, der EMIF läuft mit 100MHz, und der schafft das Timing gerade so, wenn man 2 zusätzliche Zyklen Strobe bei Read und Write einfügt. Füllgrad des 45er S6 ist gerade mal 30% etwa.
Gast
#2244208
Christian R. schrieb: > Hui, ein Spartan 6 mit 625Mhz intern? Das ist ja recht sportlich Sportlich ist untertrieben, geht wenn überhaupt nur bei bestimmten Mondphasen. Laut Datasheet (ds162) ist die maximale Frequenz des global clock trees 375-400 MHz (je nach speed grade)
Gast
#2244444
Christian Armbruster schrieb: > Der interne Takt des FPGA beträgt 625 Mhz. Christian Armbruster schrieb: > GigaBee XC6SLX (Spartan-6LX) Industrie-Mikromodul > (XC6SLX45-2FGG484C = 43 k logic cells, commercial grade) Ich kann zwar nix zur Lösung beitragen, jedoch beeindrucken mich die Daten schon. Bei dem Takt bekomme ich ein AND hin ... ;-)
Lattice User schrieb: > Laut Datasheet (ds162) ist die maximale Frequenz des global clock trees > 375-400 MHz (je nach speed grade) Dann darf man die globalen Taktnetze nicht nehmen und muß alles mit lokal verteilten und verdrahteten Takten machen... ;-)
Gast
#2244554
Lothar Miller schrieb: > Lattice User schrieb: >> Laut Datasheet (ds162) ist die maximale Frequenz des global clock trees >> 375-400 MHz (je nach speed grade) > Dann darf man die globalen Taktnetze nicht nehmen und muß alles mit > lokal verteilten und verdrahteten Takten machen... ;-) Möchtest du ihn dabei supporten evil grin Jetzt mal etwas konstruktiver. Um einen DDR3 Speicher mit einer Datenrate von 625 MHz zu betreiben muss man den FPGA intern keineswegs mit 625 takten. In den IO Banks ist fest verdrahtete Logic entahlten, um das zu ermöglichen. Intern hat man dann den halben Takt und die doppelte Datenbreite. 4 zu 1 Untersetzung ist auch möglich. Manche Hersteller bezeichnen das als 2:1 bzw 4:1 Gearbox.
Lattice User schrieb: >> muß alles mit lokal verteilten und verdrahteten Takten machen... ;-) > Möchtest du ihn dabei supporten *evil grin* Es hätte einen gewissen morbiden Reiz... ;-) > Manche Hersteller bezeichnen das als 2:1 bzw 4:1 Gearbox. Das Getriebe ist hier offenbar andersrum angeflanscht... Zur Erinnerung das, was Christian Armbruster schrieb: >>> Die Anbindung zw. Controller unf FPGA (der Adress- und Datenbus) läuft >>> mit 50 Mhz. Genauer gesagt ist es sogar eine SDRAM-Anbindung zw. >>> Controller und FPGA. >>> Der interne Takt des FPGA beträgt 625 Mhz.
Hallo Lathar. Danke für deine Nachricht. Es ist genauso wie du es beschrieben hast. Der Spartan 6 hat schon 2 Anbindungen für DDR2/3 auf dem Chip. Mit dem Eingangstakt muss ich mich allerdings etwas korrigieren. Lt. Hersteller sind schon 625 Mhz möglich, bin jedoch "erst" bei 500 Mhz. Das DDR3 läuft dann mit doppelter Geschwindigkeit. Das mal nur nebenbei erwähnt. Aber ich will wieder zurückkehren auf meine Ursprüngliche Frage. Timingprobleme bei hinzufügen / entfernen von Blöcken. So wie ich die ganzen Antworten verstanden habe, muss ich jedes Signal mit Timingwerten definieren. (Constraint) Kann mir dafür jemand mal ein einzeiliges Beispiel schreiben. Auch wie ich den "Offset IN" angebe. Das würde mir unheimlich weiterhelfen. Weiter denke ich auch, dass ich mit "PlanAhead" (soll ja jetzt in der ISE 13 mit drin sein), die Blöcke festtackern muss. Wäre das auch ein Ansatz? noeppkes ...
Hallo Lattice User. Wie schon im letzen Post geschrieben, muss ich mich mit dem Takt von 625 Mhz auf 500 Mhz korrigieren. 625 Mhz sollen aber auch möglich sein. Habe es aber bisher noch nicht geschafft. > Sportlich ist untertrieben, geht wenn überhaupt nur bei bestimmten > Mondphasen. > > Laut Datasheet (ds162) ist die maximale Frequenz des global clock trees > 375-400 MHz (je nach speed grade) Warum kann ich dann mit dem Core Generator (V13.1) genau für diesen Chip bei einem Eingangstakt von 125 Mhz einen Takt bis 1080 Mhz erzeugen? Falls das nicht gehen sollte, müsste doch der Core Generator schon meckern? (Tut er auch. Allerdings erst ab 1080 Mhz!) Ab 400 Mhz kommt dann die Meldung: "CLK_OUT1 frequency requires that this output clock must drive a BUFFPLL" Bis 400 Mhz kommt diese Meldung nicht. (Kann natürlich höchstens sein, dass man dies nicht als "Global Takt" verwenden kann/darf. Das weiss ich allerdings noch nicht.) noeppkes ...
Gast
#2244876
Christian Armbruster schrieb: > (Kann natürlich höchstens sein, dass man dies nicht als "Global Takt" > verwenden kann/darf. Das weiss ich allerdings noch nicht.) So isses. Die 1080 MHz kannst Du in der DCM/PLL erzeugen um sie dort auch gleich wieder auf ein verträgliches Maß (~50-100 MHz) zu teilen. Für die Takterzeugen verwende ich den Core Generator nicht, sonder instanziiere mir die DCM per Hand. Alle überflüssigen Signale werden einfach nicht angeschlosse und ich verwende nur die generics, die ich brauche. Da bleibt das alles recht übersichtlich:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
Duke
Die 1080MHz sind für die ISERDES/OSERDES Anbindungen und dann lokal begrenzt auf diese IO Blöcke. Im Datenblatt steht ja die maximal Frequenz des internen BUFG Taktnetzwerkes, und die ist 375 bis 400MHz je nach Speedgrade. Ist es denn überhaupt nötig, den intern mit einer so extremen Frequenz zu betreiben? Du kannst ja dann nichtmal BlockRAMs oder DSP Einheiten mit dem Takt versorgen. Wird denn dein Clock Constraint eingehalten nach dem Routen?
Hallo Christian R. Danke für deine Antwort. Ich benötige den takt auf jeden Fall für das DDR3-RAM. Intern muss ich mal sehen, ob ich auf max. 375/400 Mhz gehen kann. D.h. Ich nehme die DCM und erzeuge den Takt für das DDR3 (625 Mhz) Teile den dann durch 2 und nehme diesen als global Takt. Habe ich das richtig verstanden? Wenn ja, schreibe ich einfach ein VHDL-Modul, das mir den Takt durch 2 teilt oder muss ich hier auch noch etwas beachten? noeppkes ...
Ein Blick in den User Guide des Spartan 6 Memory Controllers ( http://www.xilinx.com/support/documentation/user_guides/ug388.pdf ) hätte dir das hier gesagt:
1 | |
625MHz geht also schon mal überhaupt nicht. So einfach, wie du dir das vorstellst, ist das nicht. Man kann nicht beliebig schnell takten. Du musst deinen DDR3 RAM mit 400MHz laufen lassen. Das ist an einem Spartan schon sportlich genug, wird aber klappen. Intern dann noch weniger, dafür mehr Busbreite...
Hallo Christian R. Naochmals danke dafür. Christian R. schrieb: > Ein Blick in den User Guide des Spartan 6 Memory Controllers ( > http://www.xilinx.com/support/documentation/user_guides/ug388.pdf ) > hätte dir das hier gesagt: > >
1 | |
> > 625MHz geht also schon mal überhaupt nicht. So einfach, wie du dir das > vorstellst, ist das nicht. Man kann nicht beliebig schnell takten. Du > musst deinen DDR3 RAM mit 400MHz laufen lassen. Das ist an einem Spartan > schon sportlich genug, wird aber klappen. Intern dann noch weniger, > dafür mehr Busbreite... 1. Komisch nur dass mir das mit: "625 Mhz geht auch noch" erklärt wurde. Ich reduziere mal die Taktrate auf 400 Mhz. 2. Du hattest recht. Ich habe Constraintverletzungen und zwar genau in diesen Taktleitungen. Wie kann ich das lösen. Muss ich den Takt dann soweit reduzieren, dass es passt oder kann ich irgendwie "manuell" eingreifen? noeppkes ...
Gast
#2245119
Christian Armbruster schrieb: > Wenn ja, schreibe ich einfach ein VHDL-Modul, das mir den Takt durch 2 > teilt oder muss ich hier auch noch etwas beachten? Ja. Abgeleitete Takte gehen über lokales Routing und damit relativ lange Laufzeiten zu den FFs. Das mag für eine Handvoll FFs oder um damit VGA-Timings zu erzeugen noch gehen, ist aber nicht schön. Bei Xilinx kannst Du Dir aus der DCM auch verschiedene Takte generieren --> CLKFX, CLKDV und CLK0. Außerdem gibt es einige davon auch noch mit verschiedenen Phasen. Hast Du schonmal ins Datenblatt geschaut? Duke
Hallo Duke. Ja, ich habe schon ins Datenblatt gesehen. Es ist dort ja schön beschrieben, wie man mehrere Takte erzeugt. Das ist mir soweit klar. Ich wusste nur nicht, dass wenn ich den Takt per VHDL in einem Modul erzeuge, dies wesentlich länger dauert. Diese Hintergrundwissen findet man nur schwer in Handbüchern. noeppkes ...
Christian Armbruster schrieb: > dass wenn ich den Takt per VHDL in einem Modul erzeuge, dies wesentlich > länger dauert. Es dauert nicht länger. Der Takt wird auch nicht per VHDL erzeugt, sondern dieser VHDL-Code wird in Flipflops umgesetzt, und der Ausgang eines dieser FFs ist dann dein neuer Takt. Der Knackpunkt daran: der so erzeugte Takt ist von schlechter Qualität (z.B. Jitter) und zudem muss er nach dem Teilerflipflop erst wieder auf ein Taktnetz. Und dieser Pfad dorthin ist nur schwer beherrschbar. BTW: Sagtest du nicht, du hättest nur 1 Takt im FPGA... Christian Armbruster schrieb: > Der interne Takt des FPGA beträgt 625 Mhz.
Christian Armbruster schrieb: > Komisch nur dass mir das mit: "625 Mhz geht auch noch" erklärt wurde. Wer sagte dir das?
Hallo christian R. Christian R. schrieb: > Christian Armbruster schrieb: >> Komisch nur dass mir das mit: "625 Mhz geht auch noch" erklärt wurde. > > Wer sagte dir das? Na ja. Es ist ja ein öffentliches Formun. Diesen Beitrag kann somit jeder lesen. Ich möchte hier keinen in die Pfanne hauen. Ich kann nur sagen, (habe vorhin erst noch einmal nachgesehen) ich habe eine eMail von vertrauenswürdiger Quelle erhalten in dem dies Stand. noeppkes ...
Hallo Lothar. Lothar Miller schrieb: > Christian Armbruster schrieb: >> dass wenn ich den Takt per VHDL in einem Modul erzeuge, dies wesentlich >> länger dauert. > Es dauert nicht länger. Der Takt wird auch nicht per VHDL erzeugt, > sondern dieser VHDL-Code wird in Flipflops umgesetzt, und der Ausgang > eines dieser FFs ist dann dein neuer Takt. > Der Knackpunkt daran: der so erzeugte Takt ist von schlechter Qualität > (z.B. Jitter) und zudem muss er nach dem Teilerflipflop erst wieder auf > ein Taktnetz. Und dieser Pfad dorthin ist nur schwer beherrschbar. > Das mit dem VHDL und FF ist mir klar. (Wäre wahrscheinlcih sonst nie soweit gekommen). Was mir nicht klar war ist, dass ein Teiler mit FF einen Jitter erzeugt der mir Probleme bereitet. Aber es muss doch(mit relativ geringem Aufwand) möglich sein, solche Signale zu erzeugen. Dann hätte man ja auf vielen Signalen (sehr oft wird ja die Logik, FF mit dem Systemclock gespeist) einen Jitter. Denke nur daran man baut einen Timer. D.h. FF laden mit dem Wert, gegen 0 zählen lassen mit den Systemclock, bei 0 Signal für einen z.B. Interrupt erzeugen oder das Signal dann intern weiterverwenden. Wenn da ein Jitter drauf ist, gibt es ja auch undefinierte Zustände oder? Wie bekommt man diese Jitter denn überhaupt weg. Angenommen ich hätte (habe ich ja auch) einen Timer, welcher mir ein Signal erzeugt? > > BTW: Sagtest du nicht, du hättest nur 1 Takt im FPGA... > Christian Armbruster schrieb: >> Der interne Takt des FPGA beträgt 625 Mhz. Ja, das hatte ich. Jetzt möchte ich es aber ändern auf: 1 Takt für DDR3 und einen für die Logik (welcher dann langsamer läuft) noeppkes...
Christian Armbruster schrieb: > Wenn da ein Jitter drauf ist, gibt es ja auch undefinierte Zustände oder? Der Jitter muß nur klein genug sein, dass das Signal noch rechtzeitig zum nächsten Takt fertig gezittert hat... > Wie bekommt man diese Jitter denn überhaupt weg. Angenommen ich hätte > (habe ich ja auch) einen Timer, welcher mir ein Signal erzeugt? Gar nicht. Denn da spielt z.B. auch die Spannungsversorgung rein, wieviele andere FFs in der Nähe gerade umschalten usw. usf. > Aber es muss doch(mit relativ geringem Aufwand) möglich sein, solche > Signale zu erzeugen. Takte werden mit Takt-Managern erzeugt. Die haben eine optimale Anbindung an die Taktnetze. Besser gehts einfach nicht, und trotzdem hast du da (natürlich) auch noch Jitter...
Gast
#2245477
Was sollen die 625 MHz bezogen auf den DDR3 denn sein? 1. Bitrate (625 Mb/s pro Datenleitung natürlich) oder 2. Taktrate. Das wäre dann eine Bitrate von 1250 Mb7s. Wenn 2) dann wird es endlos Probleme geben: Aus dem Spartan6 Datasheet: • Integrated Memory Controller blocks • DDR, DDR2, DDR3, and LPDDR support • Data rates up to 800 Mb/s (12.8 Gb/s peak bandwidth) Der auf dem Board verbaute Speicher ist für 533 MHz spezifiziert (1066 Mb/s) Die schnellsten Pins des Spartan6 können differentiell 1080 Mb/s. DDR3 ist jedoch single ended. (ausser für die Clock)
Hallo Lattice USer. Lattice User schrieb: > Was sollen die 625 MHz bezogen auf den DDR3 denn sein? > > 1. Bitrate (625 Mb/s pro Datenleitung natürlich) > > oder > > 2. Taktrate. Das wäre dann eine Bitrate von 1250 Mb7s. > die Taktrate. Habe sie jetzt aber auf 400 Mhz. geändert. Das ganze wird ja dann noch mal *2 genommen. > Wenn 2) dann wird es endlos Probleme geben: > > Aus dem Spartan6 Datasheet: > • Integrated Memory Controller blocks > • DDR, DDR2, DDR3, and LPDDR support > • Data rates up to 800 Mb/s (12.8 Gb/s peak bandwidth) > > Der auf dem Board verbaute Speicher ist für 533 MHz spezifiziert (1066 > Mb/s) > Ähhh, auf welchem Board denn? Ich habe ein Board von Trenz Elektronik. Damit sollte (Lt. Angaben von Trenz) es keine Probleme geben. Schon mehrfach verkauft und zig Male eingesetzt. > Die schnellsten Pins des Spartan6 können differentiell 1080 Mb/s. DDR3 > ist jedoch single ended. (ausser für die Clock) noeppkes ...
Gast
#2245558
Christian Armbruster schrieb: > Ähhh, auf welchem Board denn? Ich habe ein Board von Trenz Elektronik. > Damit sollte (Lt. Angaben von Trenz) es keine Probleme geben. Schon > mehrfach verkauft und zig Male eingesetzt. Auf dem oben von dir genannten "GigaBee XC6SLX". Man kann sich ja die Schaltpläne bei Trenz herunterladen.
Hallo Lattice USer. Danke für die Info. Hat sich zuerst so angehört als würdest du ein anderes Board meinen. Nachmals zusammengefasst: Ich HATTE Constraint/Timing-Verletzungen. Durch herabsetzen des Taktes sind diese nun weg. Habe es bisher aber auf dem Board noch icht getestet. Kommt in den nächsten Tagen. Trotzdem möchte ich die Frage noch einmal aufgreifen: Wie kann ich Signale im FPGA "schneller" machen, sofern ich eine Timing-Verletzung habe. Geht das dann mit PlanAhead, indem ich die Platzierung verschiebe? Wenn ja, gibt es noch andere Möglichkeiten? Im Moment habe ich den Takt von 500 Mhz auf 250 Mhz reduziert. Dann gibt es, wie schon gesagt, keine Timingfehler mehr. 250 Mhz reichen mir aber nicht aus, sollte schon auf die max. Frequenz von 375 Mhz kommen. noeppkes ...
Gast
#2246323
Christian Armbruster schrieb: > Trotzdem möchte ich die Frage noch einmal aufgreifen: Wie kann ich > Signale im FPGA "schneller" machen, sofern ich eine Timing-Verletzung > habe. Mit viel Erfahrung. Durch das Einfügen von Pipelinestufen kann man üblicherweise die Taktfrequenz erhöhen. > Geht das dann mit PlanAhead, indem ich die Platzierung verschiebe? Möglicherweise wird es durch eine Handplatzierung besser, das mußt Du aber unter Umständen bei jeder Designänderung prüfen. Das macht keinen Spaß, wenn sich noch viel am Design ändert. > Wenn ja, gibt es noch andere Möglichkeiten? Einen Chip mit höherem Speedgrade wählen, oder auf die Virtex-Familie umsteigen. Duke
Hallo Duke. Das hat mich schon mal einen Schritt weitergebracht. > Christian Armbruster schrieb: >> Trotzdem möchte ich die Frage noch einmal aufgreifen: Wie kann ich >> Signale im FPGA "schneller" machen, sofern ich eine Timing-Verletzung >> habe. > Mit viel Erfahrung. Durch das Einfügen von Pipelinestufen kann man > üblicherweise die Taktfrequenz erhöhen. Wie in etwa kann man sich das einfügen von Pipelinestufen vorstellen? Kann man das mit ein paar Worten beschreiben oder irgendwo nachlesen? Ich kann nicht so einfach auf einen anderen FPGA wechseln. Der Spartan6 ist eben auf dem Board drauf. Habe eh schon lange nach einenm Board gesucht, welches DDR2/3-RAM drauf hat, wenig kostet, funktioniert und für mich einsetzbar ist. So bin ich bei dem Trenz-Board "gelandet". Bezahlbar, klein, DDR2/3 RAM und auf das wesentliche (für meine Anwendung) begrenzt. Ich sollte es demnach auch mit diesem Board hinbekommen. Das haben ja andere auch schon geschafft. Lt. Hersteller sind diese Board zig Male verkauft worden und etliche Male auch mit DDR3-RAM in Benutzung. noeppkes ...
Gast
#2246673
Christian Armbruster schrieb: > Ich sollte es demnach auch mit diesem Board hinbekommen. Das haben ja > andere auch schon geschafft. Lt. Hersteller sind diese Board zig Male > verkauft worden und etliche Male auch mit DDR3-RAM in Benutzung. Hast Du Dir mal überlegt, welche Speicherbandbreite Du überhaupt in Deiner Anwendung brauchst? Was willst Du mit dem Ding machen? Duke
Hallo Duke. Duke Scarring schrieb: > Christian Armbruster schrieb: >> Ich sollte es demnach auch mit diesem Board hinbekommen. Das haben ja >> andere auch schon geschafft. Lt. Hersteller sind diese Board zig Male >> verkauft worden und etliche Male auch mit DDR3-RAM in Benutzung. > Hast Du Dir mal überlegt, welche Speicherbandbreite Du überhaupt in > Deiner Anwendung brauchst? Was willst Du mit dem Ding machen? TFT-Ansteuerung (800 * 480), incl. Oszi-Funktion. D.h. die gemssenen Werte vom Wandler werden mit dem FPGA umgerechnet und direkt ins DDR3-RAM an die richtige Speicherzelle geschrieben. Die TFT-Logik stellt das "Bild" dann dar. Frequenz knapp 50 Hz. Schneller macht es das Display nicht mit (18-Bit RGB, reduziert auf 16 Bit). Natürlich schreibt der Controller auch noch Daten auf's Display, genauer gesagt ins DDR3-RAM. Daher mindestens 2 Ports' für den DDR3-Controller. Weiter soll der DDR3-Speicher auch als Controllerspeicher verwendet werden. (50 Mhz SDRAM-Anbindung). Du siehst, es wird von mehreren Seiten auf den DDR3-Speicher zugegriffen. Daher die hohe Zugriffszeit. Aber die Frege nach dem "was willst du eigentlich damit machen" ist ja eher nebensächlich. Ich würde gerne wissen was man unter Pipelining vertseht und wie man das macht. Bzw. wie ich im FPGA die Signale etwas flotter machen kann. Lt. Datenblatt kann er 375 Mhz, da bekomme ich allerdings schon Timing Constraint-Warnungen. 250 Mhz sollte noch gehen (praktisch noch nicht getestet). noeppkes ...
Gast
#2246798
Christian Armbruster schrieb: > (praktisch noch nicht > getestet). Bevor Dein Design nicht grundsätzlich läuft, brauchst Du Dir über Pipelining und einen höheren Takt überhaupt keine Gedanken zu machen. Christian Armbruster schrieb: > Du siehst, es wird von mehreren Seiten auf den > DDR3-Speicher zugegriffen. Das geht letztendlich nur sequenziell. Diesbezüglich addieren sich die benötigten Datenraten. Das Auslesen benötigt 800*480 Pixel * 2 Byte/Pixel * 50 Hz = 38.4 MByte/s. Das Füllen des Speichers läuft mit 0 bis 38.4 MByte/s und Dein Controller braucht auch noch was. D.h. Du benötigst ca. 80 bis 100 MByte/s Speicherbandbreite. Der Speicher auf Deinem Board ist 2x16 = 32 Bit breit. Wenn Du den mit 100 MHz taktest und er mit jeder Flanke Daten bringt, hast Du eine Datenrate von 800 MByte/s. Was willst Du denn da jetzt am Speichertakt drehen, obwohl gar keine Notwendigkeit besteht? Christian Armbruster schrieb: > Aber die Frege nach dem "was willst du eigentlich damit machen" ist ja > eher nebensächlich. Nein. Die ist genau dafür wichtig. Duke P.S.: > Ich würde gerne wissen was man unter Pipelining > vertseht und wie man das macht. Kannst Du google bedienen?
Hallo Duke. Danke für deine Hilfe. > Christian Armbruster schrieb: >> (praktisch noch nicht >> getestet). > Bevor Dein Design nicht grundsätzlich läuft, brauchst Du Dir über > Pipelining und einen höheren Takt überhaupt keine Gedanken zu machen. > Mein Timing lief bis zur Erhöhung des Taktes. Das steht jetzt mal fest. > Christian Armbruster schrieb: >> Du siehst, es wird von mehreren Seiten auf den >> DDR3-Speicher zugegriffen. > Das geht letztendlich nur sequenziell. Diesbezüglich addieren sich die > benötigten Datenraten. Das Auslesen benötigt 800*480 Pixel * 2 > Byte/Pixel * 50 Hz = 38.4 MByte/s. Das Füllen des Speichers läuft mit 0 > bis 38.4 MByte/s und Dein Controller braucht auch noch was. D.h. Du > benötigst ca. 80 bis 100 MByte/s Speicherbandbreite. > > Der Speicher auf Deinem Board ist 2x16 = 32 Bit breit. Wenn Du den mit > 100 MHz taktest und er mit jeder Flanke Daten bringt, hast Du eine > Datenrate von 800 MByte/s. Was willst Du denn da jetzt am Speichertakt > drehen, obwohl gar keine Notwendigkeit besteht? Das ist ja theoretisch in Ordnung. Du hast es schön 1:1 gerechnet. Ich habe hier aber kein SRAM, sondern ein DDR3! Wie sieht es aber aus, wenn ständig die Adressleitungen des DDR3-Ram gewechselt werden. Dann läuft es nicht mehr in einem Takt. Und das ist doch genau das Problem das ich habe? Die Displayansteuerung kann man zwar mit Burst "laufen" lassen, jedoch nicht die Controllerseite oder sehe ich da was falsch? Ausserdem hat man ja auch noch einen maximalen Busrt-Lenght von 4 oder 8. Dann braucht man zwischendurch auch wieder mehrere Takte für den DDR3-Controller. (Den Refresh für das DDR3 habe ich jetzt nicht einmal berücksichtigt). Selbst mit einer FiFo (welche ich für alle 3 Ports habe) und dem Worst-Case-Fall reichen 100 Mhz nicht aus. Es sind übrigens 3 Zugriffe sequentiell die ich habe. Ich habe oben 2 Ports geschrieben. TFT-Ansteuerung, Controller-Speicher und die Istwertmessung die den Displayspeicher füllt. > > Christian Armbruster schrieb: >> Aber die Frege nach dem "was willst du eigentlich damit machen" ist ja >> eher nebensächlich. > Nein. Die ist genau dafür wichtig. Danke für die Info. Werde es mal bei google probleiren. Tsssssss. Dass ich da nicht selbst draufgekommen bin... noepppkes...
Pipelining für Dummies. Ich habe google bedient. http://coe.uncc.edu/~amukherj/INTRO2VHDL/L08-Pipelining.pdf noeppkes ...
Und hier noch ein interessantes Dokument über Pipelining. http://www.eecg.toronto.edu/~moshovos/ACA06/lecturenotes/004-pipelining.pdf noeppkes ...
Gast
#2246969
Christian Armbruster schrieb: > Dann läuft es nicht mehr in einem Takt. Und das ist > doch genau das Problem das ich habe? Die Displayansteuerung kann man > zwar mit Burst "laufen" lassen, jedoch nicht die Controllerseite oder > sehe ich da was falsch? Was verwendest Du den für einen Controller? Die meisten haben heutzutage einen Cache. Wenn Du was fertiges für Dein Display suchst: Der SVGA-Core aus der grlib verwendet einen FIFO um sich die Displaydaten schonmal zurechtzulegen. Christian Armbruster schrieb: > Du hast es schön 1:1 gerechnet. Ich > habe hier aber kein SRAM, sondern ein DDR3 Trotzdem bist Du bei einer Transferrate von 1:8 (benötigt/theoretisch nutzbar) Deine Istwertmessung könnte ihre Schreibzugriffe in einem FIFO vorbereiten und dann während des Refresh die Daten am Stück in den Speicher schieben. Ich sehe da also drei Module die per Burst Ihre Daten mit den Speicher austauschen können. Duke
Gast
#2247009
Christian Armbruster schrieb: > Wie sieht es aber aus, wenn ständig die Adressleitungen des DDR3-Ram > gewechselt werden. Dann läuft es nicht mehr in einem Takt. Und das ist > doch genau das Problem das ich habe? Die Displayansteuerung kann man > zwar mit Burst "laufen" lassen, jedoch nicht die Controllerseite oder > sehe ich da was falsch? Dem Controller kann man einem Cache verapssen, das macht ihn auch burst fähig. > Ausserdem hat man ja auch noch einen maximalen > Busrt-Lenght von 4 oder 8. Dann braucht man zwischendurch auch wieder > mehrere Takte für den DDR3-Controller. Der DDR3 kann Pipelining, wie viel Stufen muss man dem datenblatt entnehmen. Würde mich überraschen wenn der Memorycontroller das nicht kann. > (Den Refresh für das DDR3 habe > ich jetzt nicht einmal berücksichtigt). Selbst mit einer FiFo (welche > ich für alle 3 Ports habe) und dem Worst-Case-Fall reichen 100 Mhz nicht > aus. > > Es sind übrigens 3 Zugriffe sequentiell die ich habe. Ich habe oben 2 > Ports geschrieben. > TFT-Ansteuerung, Controller-Speicher und die Istwertmessung die den > Displayspeicher füllt. Wenn ich es richtig sehe sind doch die beiden Rams auf dem Board an getrennten Memorycontrollern des S6 angeschlossen. Warum die beiden nicht unabhängig voneinander betreiben, einer für das Display den anderen für den Controller? Ansonsten gilt es die Taktbereiche gut zu definieren, nur der Memorycontroller braucht in deinem derzeitigen Ansatz den hohen Takt. Das wird das Ganze auch entspannen.
Hallo duke. Danke noch einmal. Duke Scarring schrieb: > Christian Armbruster schrieb: >> Dann läuft es nicht mehr in einem Takt. Und das ist >> doch genau das Problem das ich habe? Die Displayansteuerung kann man >> zwar mit Burst "laufen" lassen, jedoch nicht die Controllerseite oder >> sehe ich da was falsch? > Was verwendest Du den für einen Controller? Die meisten haben heutzutage > einen Cache. > > Wenn Du was fertiges für Dein Display suchst: > Der SVGA-Core aus der grlib verwendet einen FIFO um sich die > Displaydaten schonmal zurechtzulegen. Den sehe ich mir mal an. Vielleicht kann ich ihn verwenden und auch einbinden. Gute Idee. Falls ich es im Web nicht finde, melde ich mich noch einmal diesbezüglich. (Hast du damit schon was gemacht?) > > Christian Armbruster schrieb: >> Du hast es schön 1:1 gerechnet. Ich >> habe hier aber kein SRAM, sondern ein DDR3 > Trotzdem bist Du bei einer Transferrate von 1:8 (benötigt/theoretisch > nutzbar) > > Deine Istwertmessung könnte ihre Schreibzugriffe in einem FIFO > vorbereiten und dann während des Refresh die Daten am Stück in den > Speicher schieben. Auch eine sehr gute Idee. An diese habe ich wirklich noch nicht gedacht. An die Fifo habe ich gedacht, aber während der Ruhezeit schreiben ... könnte man probieren. > Ich sehe da also drei Module die per Burst Ihre Daten mit den Speicher > austauschen können. Na ja, der Controller (SH2A 7216...) hat Burst. Aber was tut er, wenn ich die Bytes total durcheinander ins DDR3 schreibe, dann kann er doch auch keinen Burst nutzen oder? Ab und zu mit Sicherheit, aber es kommt doch vor, dass es ständig Adresswechsel gibt und dann geht nun mal kein Burst. noeppkes ...
Hallo Lattice User. Lattice User schrieb: > Christian Armbruster schrieb: >> Wie sieht es aber aus, wenn ständig die Adressleitungen des DDR3-Ram >> gewechselt werden. Dann läuft es nicht mehr in einem Takt. Und das ist >> doch genau das Problem das ich habe? Die Displayansteuerung kann man >> zwar mit Burst "laufen" lassen, jedoch nicht die Controllerseite oder >> sehe ich da was falsch? > > Dem Controller kann man einem Cache verapssen, das macht ihn auch burst > fähig. Er hat ja schon Standardmäßig Burst. Den werde ich auch nutzen. > Wenn ich es richtig sehe sind doch die beiden Rams auf dem Board an > getrennten Memorycontrollern des S6 angeschlossen. Warum die beiden > nicht unabhängig voneinander betreiben, einer für das Display den > anderen für den Controller? Genau das habe ich auch vor. Das ursprüngliche Thema war ja ein anderes. Ich konnte ja nicht von vorne weg all meine Vorstellungen schreiben. Es ist auf jeden Fall so vorgesehen. > > Ansonsten gilt es die Taktbereiche gut zu definieren, nur der > Memorycontroller braucht in deinem derzeitigen Ansatz den hohen Takt. > Das wird das Ganze auch entspannen. Vielen Dank für deine Hilfe. noeppkes ...
Gast
#2247072
Christian Armbruster schrieb: > Na ja, der Controller (SH2A 7216...) hat Burst. Aber was tut er, wenn > ich die Bytes total durcheinander ins DDR3 schreibe, dann kann er doch > auch keinen Burst nutzen oder? Ab und zu mit Sicherheit, aber es kommt > doch vor, dass es ständig Adresswechsel gibt und dann geht nun mal kein > Burst. Richtig. Bei dem Controller sind die Speicherzugriffe wahrscheinlich nicht immer burstfähig. Aber es kam ja auch schon die Idee ein Speichermodul für den Controller zu verwenden und das andere als Bildwiederholspeicher. Wie ist denn der Controller eigentlich am FPGA angebunden? Duke
Gast
#2247115
DDR2/3 auf Höchstleistung zu trimmen ist nicht trivial. Z.B. kann der Speicherbaustein nur Burst, wobei die Länge bei der Initialisierung eingestellt wird. Dynamisch zu veräündern wäre zwar möglich braucht aber mehr Takte als das was man an vergeuteten Burstcyclen spart. Weitere Tricks sind Bankinterleaving, allerdings hilft das meiste bei zufälligen Zugriffen nicht wirklich. Glücklicherweise tut bei den meisten Anwendungen der Controller keineswegs wild zufällig schreiben/lesen, eine gewisse Nähe zum vorigem Zugriff ist oft gegeben und Zugriffe auf die gleiche Memorypage im DDR2/3 Baustein sind um einiges schneller. Dein Ansatz das Problem anzugehen indem du die Speicherbandbreite möglichst gross haben möchtest ist selbverständlich legitim. Dummerweise rennst du damit in das Problem den FPGA an seiner Grenze zu betreiben, das ist auch nicht trivial. Bei der Latticetoolchain habe ich die Möglichkeit eine gegebenes Plazierung/Routing einlesen zu lassen, und es werden dann daran nur Änderungen durchgeführt. Hatte ich mal versucht, aber habe es relativ schnell wieder aufgegeben, da bereits bei relativ kleinen Änderungen das Ergebniss nicht so toll war, vom Hinzufügen ganzer Componeneten ganz zu schweigen.
Gast
#2247332
Meine 2 Cent: Der Memory Controller Block im Spartan-6 kann nicht schneller als 312,5 MHz. Diese oben genannten 625 MHz sind die Frequenz mit der die Double-Data-Rate I/O innerhalb des MCBs betrieben werden. Als Systemclock taugen die nicht. Um die musst Du dich auch nicht kümmern, die werden innerhalb des MIG-Designs erzeugt und gelangen auch gar nicht nach draußen. Der MIG geht zwar davon aus, dass es als Systemclock die Memoryclock bekommt (also 312,5 MHz), üblicherweise wird aber eine niedrigere Systemclock benutzt und die im MIG-Design enthaltene PLL nach AR# 37224 (http://www.xilinx.com/support/answers/37224.htm) eingestellt. Hilfreich, da zwei Memory-Bänke vorhanden sind, ist auch noch AR# 34934 (http://www.xilinx.com/support/answers/34934.htm). Als Systemclock empfehlen sich die auf dem Board vorhanden 125 MHz. Diese großartig hochzudrehen halte ich für Tüddelkram. Das schafft im Zweifel Probleme, die man vielleicht durch Änderungen in der Architektur besser in den Griff bekommt. Wenn Du mehrere Ports auf das gleiche DDR3-Ram hast, hat dieses auch bei dem "langsamen" Systemtakt sowieso genug zu tun alle Zugriffe abzuarbeiten. Solange Du nicht genau weisst, was Du tust (un diesen Eindruck hab' ich nicht), brauchst Du über Taktfrequenzen, die an die Grenzen des Baustein gehen, gar nicht nachzudenken. Und Sachen wie Pipeling und dergleichen treten dann auch wieder in den Hintergrund. Und ich würde deine "vertrauenswürdige Quelle" nochmal fragen, was er mit "625 Mhz geht auch noch" wirklich meinte.
Hallo Duke. > Aber es kam ja auch schon die Idee ein Speichermodul für den Controller > zu verwenden und das andere als Bildwiederholspeicher. Genau das hatte ich auch von Anfang an vor. Der Controller kann sowieso nur 2 CS a 64 MB. Die DDR3 haben wesentlich mehr Speicher. > Wie ist denn der Controller eigentlich am FPGA angebunden? Tja. Das hatte ich oben schon geschrieben. Über ein SDRAM-Interface mit ADDR 0 ... irgendwas (müsste nachsehen), DATA 0 ... 15, RAS, CAS, SDRAM_CLK, CS, usw. Disher hatte ich das SDRAM-Interface im FPGA mit den Systemclock versorgt. Dieser Clock musste um einiges höher sein als der Clock von SDRAM (50 Mhz.) um ihn vernünfig "abtasten" zu können. Die Adressleitungen kommen ja bekanntlich über RAS/CAS rein und müssen dann wieder zusammengesetzt werden. (Burst-Mode mal nicht berücksichtigt). Gestern ist mir eingefallen, dass ich doch den SDRAM_CLK von Controller direkt für mein SDRAM-Interface nutzen könnte. Auf jeden Fall mal zum reinclocken der Adresse und der Daten. Somit brauche ich es nicht mehr mit meinem erhöhten Systemclock abzutasten. Ich hätte dann nur 50 Mhz auf den SDRAM-Interface. Irgendwo muss ich aber dann noch den Schnitt machen, da der externe SDRAM_CLK und der interne CLK nicht synchron laufen. Die Empfangenen Daten (Write ins DDR3) und die zu lesenden Daten (READ aus dem DDR3) müssen ja irgenwie intern übergeben werden. Ich glaube das wäre wolhl der bessere Ansatz, den SDRAM_CLK (von extern) zum auswerten des SDRAM-Interfaces zu nehmen, als der interne oder? noeppkes ...
Hallo Rudolph. Danke für deinen Beitrag. > Der Memory Controller Block im Spartan-6 kann nicht schneller als 312,5 > MHz. Diese oben genannten 625 MHz sind die Frequenz mit der die > Double-Data-Rate I/O innerhalb des MCBs betrieben werden. Als > Systemclock taugen die nicht. Um die musst Du dich auch nicht kümmern, > die werden innerhalb des MIG-Designs erzeugt und gelangen auch gar nicht > nach draußen. O.K. Das habe ich auch so gemacht. > Der MIG geht zwar davon aus, dass es als Systemclock die Memoryclock > bekommt (also 312,5 MHz), üblicherweise wird aber eine niedrigere > Systemclock benutzt und die im MIG-Design enthaltene PLL nach AR# 37224 > (http://www.xilinx.com/support/answers/37224.htm) eingestellt. > Hilfreich, da zwei Memory-Bänke vorhanden sind, ist auch noch AR# 34934 > (http://www.xilinx.com/support/answers/34934.htm). Da hatte ich auch daran herumgespielt. Bin allerdings noch nicht so fit in PLL'S DCM usw. Hatte bisher nur mit Spartan2 zu tun. Da läuft alles etwas "ruhiger" ab. Im Endeffekt muss ich 2 PLL'S parallel schalten. Der Eingangstakt von 125 Mhz nutze ich auch. Gehe dann auf die MIG und drehe ihn mit der "MIG PLL" auf 312.5 Mhz. Parallel dazu erzeuige ich mit einer 2. PLL meinen Systemtakt. Sagen wir mal 250 Mhz. Ist das der richtige Ansatz? > Solange Du nicht genau weisst, was Du tust (un diesen Eindruck hab' ich > nicht), brauchst Du über Taktfrequenzen, die an die Grenzen des Baustein > gehen, gar nicht nachzudenken. Und Sachen wie Pipeling und dergleichen > treten dann auch wieder in den Hintergrund. > Und ich würde deine "vertrauenswürdige Quelle" nochmal fragen, was er > mit "625 Mhz geht auch noch" wirklich meinte. Das werde ich auf jeden Fall tun. Das kannst du mir gleuben. Ich habe vergeblich TAGE damit verbracht das Design mit dem erhöhten Takt ins Laufen zu bekommen. Mit dem langsameren Takt lief es. Da hatte ich aber nur 1 Port für das DDR3 (Nur schreiben ins Display.) Ich will aber auch noch Hardwarefenster programmieren, welche dann über dem "Hintergrundbild liegen". Funktioniert auch soweit. Habe 2 Stk. davon. Kann sie bequem mit x-y-Koordinaten übers Bild wandern lassen. Allerdings möchte ich ja auch noch von der Istwertabfrage reinschreiben (Habe wir ja gelöst indem ich in der Displaypause reinschreibe.) Das Lesen ais dem Displayspeicher wäre natürlich auch noch fein. Daher kam dann der höhere Takt. noeppkes ...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.