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 ...
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
NET CLOCK LOC = AA12 | TNM_NET = "CLOCK_50";
2
TIMESPEC "TS_CLOCK_50" = PERIOD "CLOCK_50" 50 MHz HIGH 50 %;
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
> NET CLOCK LOC = AA12 | TNM_NET = "CLOCK_50";
2
> TIMESPEC "TS_CLOCK_50" = PERIOD "CLOCK_50" 50 MHz HIGH 50 %;
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 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
> NET CLOCK LOC = AA12 | TNM_NET = "CLOCK_50";
2
> TIMESPEC "TS_CLOCK_50" = PERIOD "CLOCK_50" 50 MHz HIGH 50 %;
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.
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)
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... ;-)
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 ...
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:
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 ...
Up to 800 Mb/s (400 MHz double data rate) performance
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...
Up to 800 Mb/s (400 MHz double data rate) performance
>> 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 ...
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.
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...
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 ...
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 ...
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 ...
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 ...
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...
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
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 ...
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
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.
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 ...
Thread beobachten
Seitenaufteilung abschalten