Hallo zusammen, ein synchrones Dual Port Block RAM (Xilinx) wird an seinen Ports (A,B) mit dem gleichen Taktsignal (CLKA=CLKB=Taktsignal) betrieben. Darf man in diesem Fall gleichzeitig (mit der nächsten aktiven Taktflanke) über Port A Daten schreiben und über Port B Daten von der gleichen Adresse lesen? Oder knallt es dann?
Alex schrieb: > Darf man in diesem Fall gleichzeitig (mit der nächsten aktiven > Taktflanke) über Port A Daten schreiben und über Port B Daten von der > gleichen Adresse lesen? An und für sich und im Allgemeinen eigentlich: Nein, weil das Timing verletzt wird. > Oder knallt es dann? Aus der Praxis: Nein. Du liest einfach nur den alten Wert aus dem RAM aus. Obwohl, da war noch was mit mit irgendwelchen Schaltern wie Write-before-Read o.ä. Aber ich gehe solchen Konstrukten gern aus dem Weg, indem ich die beiden Adressen nicht gleich werden lasse...
Lothar Miller schrieb: > war noch was mit mit irgendwelchen Schaltern wie > Write-before-Read read B4 write :-) >indem ich die beiden Adressen nicht gleich werden lasse... Das lässt sich manchmal nicht verhindern - Stichwort ruckelnde Videoausgabe. Entweder man lässt es auf Pixelebene knallen, oder auf Linienebene oder auf Bildebene. Irgendwo entsteht ein zeitlicher Bruch. "Altes Pixel" ist da das unauffälligste.
Alex schrieb: > Darf man in diesem Fall gleichzeitig (mit der nächsten aktiven > Taktflanke) über Port A Daten schreiben und über Port B Daten von der > gleichen Adresse lesen? Steht in der "Memory Resources" user guide unter "Write Modes" zumindest, je nachdem welchen FPGA du einsetzt.
J. S. schrieb: > read B4 write :-) Richtig, aber der Spezialfall "annähernd gleicher Takt" ist eigentlich nicht vorgesehen. Denn auch das Lesen vor dem Schreiben geht schief, wenn der Schreibtakt z.B. 3ns vor dem Lesetakt kommt. Dann kommt es auf jeden Fall zu einer Setupzeit-Verletzung... Die gute Nachricht ist aber: auch wenn mal ein Pixel versaut ist, das FPGA geht dabei nicht kaputt.
@ Lothar Miller (lkmiller) Benutzerseite >> read B4 write :-) >Richtig, aber der Spezialfall "annähernd gleicher Takt" ist eigentlich >nicht vorgesehen. Um den geht es hier nicht. Dass asynchroner Zugriff böse, böse ist, brauchen wir hier nicht zu diskutieren.
Lothar Miller schrieb: >> Darf man in diesem Fall gleichzeitig (mit der nächsten aktiven >> Taktflanke) über Port A Daten schreiben und über Port B Daten von der >> gleichen Adresse lesen? > An und für sich und im Allgemeinen eigentlich: Nein, weil das Timing > verletzt wird. Warum wird hier ein Timing verletzt, wenn doch an beiden Taktanschlüssen der quasi gleiche Takt in Frequenz und Phase anliegt? Es soll taktsynchron mit der nächsten Flanke gelesen und geschrieben werden. Das man wenn alles klappt den noch "alten" Wert ausliest ist mir soweit klar.
@ Alex (Gast) >Warum wird hier ein Timing verletzt, wenn doch an beiden Taktanschlüssen >der quasi gleiche Takt in Frequenz und Phase anliegt? Das Timing wird nicht verletzt, alles absolut sauber weil synchron mit EINEM Takt. Lothar ist nur mal wieder drei Schritte geistig vorausgeeilt und hat einen möglichen Fehlerfall hier reingerührt. MFG Falk
Falk Brunner schrieb: > Lothar ist nur mal wieder drei Schritte geistig vorausgeeilt ;-) > und hat einen möglichen Fehlerfall hier reingerührt. Ich bin mir sicher, dass es da keinen Fehler geben kann, denn dieses Verhalten leuchtet zwar jedem ein, der synchrone Designs macht, es ist aber im Datenblatt nicht explizit beschrieben...
@ Lothar Miller (lkmiller) Benutzerseite >Verhalten leuchtet zwar jedem ein, der synchrone Designs macht, es ist >aber im Datenblatt nicht explizit beschrieben... Doch, da bin ich mir relativ sicher.
Falk Brunner schrieb: >> es ist aber im Datenblatt nicht explizit beschrieben... > Doch, da bin ich mir relativ sicher. Kannst du da mal was raussuchen? Ich nehme mal den UG331 vom S3 und schlage die Abteilung BRAM auf. Dort finde ich dann Die beunruhigende Aussage, dass beim Lesen von der selben Adresse, die vom anderen Port mit dem selben Takt beschrieben wird, der Ausgang undefiniert ist. Diese schon angesprochene WRITE-FIRST usw. Geschichte bezieht sich nur auf das Lesen vom selben Port, auf den auch geschrieben wird. Und natürlich wird auf dem selben Port mit dem selben Takt geschrieben und gelesen...
@ Lothar Miller (lkmiller) Benutzerseite >>> es ist aber im Datenblatt nicht explizit beschrieben... >> Doch, da bin ich mir relativ sicher. >Kannst du da mal was raussuchen? Hast du doch schon gemacht. Und dort steht es ja explizit drin, was passieren kann und wie man es vermeidet. >Diese schon angesprochene WRITE-FIRST usw. Geschichte bezieht sich nur >auf das Lesen vom selben Port, auf den auch geschrieben wird. Nicht ganz. "using READ_FIRST mode does not cause conflicts on the opposite port." MfG Falk
>Doch, da bin ich mir relativ sicher.
Ich schließe mich Lothar an: das gleichzeitige Schreiben und Lesen an
der gleichen Adresse sollte vermieden werden. Wenn man Read-First
implementiert, dann unterbindet man dies ja schon im Prinzip.
VG, Wat
Ich empfehle das Datenblatt zum Memory Generator aus dem CoreGenerator. Dort sind die verschiedenen Betriebsmodi und das Kollisionsverhalten beschrieben. Wat schrieb: > Ich schließe mich Lothar an: das gleichzeitige Schreiben und Lesen an > der gleichen Adresse sollte vermieden werden. Wenn man Read-First > implementiert, dann unterbindet man dies ja schon im Prinzip. Laut diesem Datenblatt ist besonders ReadFirst erlaubt und erzeugt die "alten" Daten.
Also das Block-RAM lässt sich im "Read First" Modi genau so verwenden wie ich es mir ehofft habe :-) Geht gleichzeitiges schreiben und lesen eigentlich auch beim Distributed RAM? In http://www.xilinx.com/support/documentation/application_notes/xapp464.pdf steht etwas von WRITE_MODE=WRITE_FIRST. Das verwirrt mich jetzt ein wenig, weil beim Block RAM funktioniert das gewünschte mit WRITE_FIRST ja nicht.
Bitte 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.