Hi, ich habe das Problem, dass ich vom BRAM die Daten gerne schon bei der nächsten steigenden Taktflanke hätte, wenn ich die Adresse anlege. Aber mein FPGA (MAX 10) hat nur synchrone BRAM-Blöcke. Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln und einfach über eine Schaltung mit der einfachen Frequenz (auch Ausgabe der PLL) steuern und auswerten? Grundsätzlich sind es ja zwei Taktdomänen und müssen daher synchronisiert werden, aber wie gestaltet sich das mit n-fachen Frequenzen ? Bin kein Elektrotechniker. Habe im Netz auch nichts dazu gefunden, es sieht also schlecht aus...
True Dual Port RAM schrieb: > ich habe das Problem, dass ich vom BRAM die Daten gerne schon bei der > nächsten steigenden Taktflanke hätte, wenn ich die Adresse anlege. Aber > mein FPGA (MAX 10) hat nur synchrone BRAM-Blöcke. Herzlichen Glückwunsch, du hast die "Latency" entdeckt. Warum kannst du nicht einfach die Adresse einen Takt früher anlegen? > Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln Warum taktest du dein gesamtes Desgin insgesamt nicht einfach doppelt so schnell? > Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln Warum taktest du dein BRAM nicht einfach mit der fallenden Flanke? Auch das wäre eine Verdopplung der Taktfrequenz... > Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln und > einfach über eine Schaltung mit der einfachen Frequenz (auch Ausgabe der > PLL) steuern und auswerten? Grundsätzlich sind es ja zwei Taktdomänen > und müssen daher synchronisiert werden Das Synchronisieren übernimmt die PLL für dich: die sorgt dafür, dass die zeitliche Verzögerung konstant ist und die Toolchain kann überprüfen, ob die zeitlichen Zusammenhänge passen.
:
Bearbeitet durch Moderator
Ich vermute dass das eher ein Konfigurationsproblem oder Verständnisproblem ist. Normalerweise funktioniert der M9k so: 1: du legst die Adresse an die Adresspins an 2: die Clock steigt 3: der BRAM gibt etwas später (< 1-2 Nanosekunden) die Daten an den Datenpins aus 4: bis zur nächsten Clockflanke sind die Daten auf jeden Fall stabil und du kannst sie in nachfolgender Logik verwenden. Eventuell hast du Die Registeroption für "'address' input port" aktiviert gelassen (ist per default so), oder hast Register am Ausgang. Das ist zwar besser fürs Timing und so, gibt aber halt ein bis zwei Schritte Latenz. Google mal nach UG-M10MEMORY und schau das Timingdiagramm auf Seite 8 an, rechte Hälfte (wren = 0). Da wird bei address z.B. a1 angelegt, dann steigt die Clock und fast sofort später erscheint "FFCD" am Ausgang.
True Dual Port RAM schrieb: > die Daten gerne schon bei der > nächsten steigenden Taktflanke hätte, wenn ich die Adresse anlege Verstehe ich das so richtig: 1: du legst irgendwann deine Adresse an 2: die Clock steigt 2: gleichzeitig sind die Daten schon da Weil das macht designtechnisch keinen Sinn. Entweder sind die Daten deutlich vor der Clockflanke da, damit du Zeit hast die Daten zu verarbeiten, oder sie kommen erst nach der Flanke und werden einen Takt später verarbeitet. Oder meinst du: 1: steigende Clockflanke 2: eine Logik berechnet deine Adresse 3: jetzt ist deine Adresse valid 4: die Daten kommen aus dem BRAM 5: die Daten werden verarbeitet 6: steigende Clockflanke Das geht dann eben nicht, weil der BRAM eben nur synchron läuft. Es gibt aber ein paar dreckige Tricks mit denen das trotzdem ginge: - negative/invertierte Clock verwenden, dann hast du die Daten schon nach einer halben Taktperiode gültig, aber das Timing wird enger. - mit XOR und Invertern händisch eine Flankenerkennung bauen, die dir kombinatorisch zwei positive Clockpulse erzeugt wann immer die Clock sich ändert. Garstig und nicht zu empfehlen, außer man hat genug Erfahrung mit manueller LUT-Platzierung und den Gatterlaufzeiten über alle design corners.
Lothar M. schrieb: > True Dual Port RAM schrieb: >> ich habe das Problem, dass ich vom BRAM die Daten gerne schon bei der >> nächsten steigenden Taktflanke hätte, wenn ich die Adresse anlege. Aber >> mein FPGA (MAX 10) hat nur synchrone BRAM-Blöcke. > Herzlichen Glückwunsch, du hast die "Latency" entdeckt. Warum kannst du > nicht einfach die Adresse einfach einen Takt früher anlegen? Das wäre schön, aber das klappt wahrscheinlich nicht. Bin noch in der Planungsphase, deshalb ist das ganze noch etwas unkonkret. Der Fall hat mich aber jetzt schon beschäftigt und wollte dem nachgehen. Lothar M. schrieb: >> Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln > Warum taktest du dein gesamtes Desgin insgesamt nicht einfach doppelt so > schnell? Ich vermute, dass das Design das nicht mitmachen wird. Lothar M. schrieb: >> Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln > Warum taktest du dein BRAM nicht einfach mit der fallenden Flanke? Auch > das wäre eine Verdopplung der Taktfrequenz... Stimmt, daran habe ich gar nicht gedacht. Das werde ich dann ausprobieren. Lothar M. schrieb: >> Kann ich über eine PLL die Eingangsfrequenz des BRAMs verdoppeln und >> einfach über eine Schaltung mit der einfachen Frequenz (auch Ausgabe der >> PLL) steuern und auswerten? Grundsätzlich sind es ja zwei Taktdomänen >> und müssen daher synchronisiert werden > Das Synchronisieren übernimmt die PLL für dich: die sorgt dafür, dass > die zeitliche Verzögerung konstant ist und die Toolchain kann > überprüfen, ob die zeitlichen Zusammenhänge passen. Ah sehr schön. Da war ich mir nicht sicher. @bla Der Vorgang sieht so aus: 1. steigende Clockflanke 2. Adresse wird berechnet 3. Adresse ist gültig und liegt am RAM an 4. ... 5. steigende Clockflanke 6. jetzt hätte ich gerne die Daten zum Verarbeiten bla schrieb: > Google mal nach UG-M10MEMORY und schau das Timingdiagramm auf Seite 8 > an, rechte Hälfte (wren = 0). Da wird bei address z.B. a1 angelegt, dann > steigt die Clock und fast sofort später erscheint "FFCD" am Ausgang. Ja genau das habe ich mir zuvor angeschaut und muss zugeben, dass mich das Diagramm verwirrt hat. Warum ist der Ausgang plötzlich nicht mehr getaktet q (asynch)? Auf der nächsten Seite gibts hingegen wieder den Ausgang q (synch), also synchron mit der Latenz. Ich hab dann ins Quartus Handbuch geschaut, um zu sehen wie man den BRAM in HDL beschreibt. Und da war der Lesevorgang im getakteten Prozess. Testweise habe auch den Code mal mit asynchronem Lesen durch den Synthesizer gejagt. Da kam dann wie erwartet auch die Warnung: "RAM logic "Ram:ram0|mem" is uninferred due to asynchronous read logic". Also bedeutete das für mich, dass ich die Latenz anders weg kriegen muss.
True Dual Port RAM schrieb: > Das wäre schön, aber das klappt wahrscheinlich nicht. Bin noch in der > Planungsphase, deshalb ist das ganze noch etwas unkonkret. Der Fall hat > mich aber jetzt schon beschäftigt und wollte dem nachgehen. Das klappt schon, nur eben nur bei "geringen" Taktgeschwindigkeiten. Beim Artix z.B. bis 80MHz. Allerdings kann man den mit dem doppelten Takten und ist letztlich mit einem FF genau so weit. Man kann ihn auch mit dem Dreifachen Takten und braucht dann gfs noch ein weiteres FF. Man kommt eben um die Physik nicht drum herum. Die BRAMs sitzen in Blöcken an bestimmten Stellen im FPGA und da muss man hin. Laufzeiten kosten. Das ist mit externen SRAMs auch nicht anders. Die reagieren auch nicht binnen 5ns.
True Dual Port RAM schrieb: > Der Vorgang sieht so aus: > 1. steigende Clockflanke > 2. Adresse wird berechnet > 3. Adresse ist gültig und liegt am RAM an > 4. ... > 5. steigende Clockflanke > 6. jetzt hätte ich gerne die Daten zum Verarbeiten Vorsicht! In so ziemlich jedem Syntheseratgeber steht, dass die Adressen gefaelligst aus FFs zu kommen haben. Und das hat einen guten Grund... Nach deinem Punkt 1. passiert folgendes: Deine Adressbits flippen fuer eine ganze Weile munter hin und her. Und das bzgl. Laufzeit sogar Daten-/Zustandsabhaengig... Dein READ_ENABLE am SRAM ist schon aktiv (aktiviert zum Zeitpunkt 1.)... Dein SRAM besteht aus vielen Bits, gebaut im Prinzip aus 6T-Zellen... Deine wackelnde Adresse stimuliert jetzt munter die Word- und Bit-Lines (siehe hier https://de.wikipedia.org/wiki/Static_random-access_memory#Eigenschaften_und_Aufbau als Beispiel). Und damit kannst du dir deine gespeicherten Bits ueberschreiben! Nicht aus Haeme oder Theorie, sondern vor ca. 20 Jahren leidvoll selber erfahren... Wir hatten ein SRAM, das hing ueber Chip-I/Os an einem anderen Chip. Und wir hatten an unserem Chip-Eingang Pulldowns. Und in ganz bestimmten Faellen, relativ selten, hat das andere Chip den Adressbus (der an unser SRAM angeschlossen war) auf high-Z geschaltet. Und dann sind die '1'er Bits langsam nach '0' gedriftet... Und das hat die Daten im SRAM zerstoert/umgeschrieben... Also Vorsicht mit sowas. Lothar hat dir ja den praktischen Weg beschrieben: SRAM mit fallender Flanke takten. Dann aber auch den READ_ENABLE sowie die Adressen mit der fallenden Flanke ans RAM verdrahten. Dann funktioniert das zuverlaessig, wenn's halt mit dem Timing reicht...
True Dual Port RAM schrieb: > Der Vorgang sieht so aus: > 1. steigende Clockflanke > 2. Adresse wird berechnet > 3. Adresse ist gültig und liegt am RAM an > 4. ... > 5. steigende Clockflanke > 6. jetzt hätte ich gerne die Daten zum Verarbeiten Bis auf die erwähnte Tatsache, dass man die Adressse gerne aus FFs hätte, ist daran nicht auszusetzen und würde bei heutigen BRAMs funktionieren. Die FFs sind jedoch "nur" eine Recommendation, kein must. Ohne FFs hat man u.a. natürlich ein schlechteres Timing. Ob man es sich leisten kann, hängt vom Takt ab und sagt dir die "Static Timing Analysis". Weiterer Nachteil ist, dass der Energiebedarf (minimal) höher sein wird, da die Adresse nicht gleich stabil ist und somit der BRAM versucht, den Adressen zu folgen und ggf. auf mehrere Zellen nacheinander zugreift. Solange die STA aber keinen Fehler wirft, werden die richtigen Daten nach der Taktflanke am Ausgang anliegen. Auch beim Schreiben würde es zu keinem Fehler kommen, da der BRAM erst bei der Flanke aktiv wird. PS: Je nach Datenmenge kann man auch distributed RAM verwenden. Ausreichend Timingreserven vorausgesetzt, liefern die die Daten noch vor der Taktflanke.
Ich wollte mich noch recht herzlich für eure Vorschläge und Ausführungen bedanken. Das hat mir wirklich weiter geholfen. Danke dafür :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.