Forum: FPGA, VHDL & Co. Dual Port Block RAM - Gleichzeitiges lesen und schreiben


von Alex (Gast)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Christian L. (ijuz)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@  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.

von Alex (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@  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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von Falk B. (falk)


Lesenswert?

@  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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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...

von Falk B. (falk)


Lesenswert?

@  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

von Wat (Gast)


Lesenswert?

>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

von Klaus F. (kfalser)


Lesenswert?

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.

von Alex (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.