BRAM lesen -> Addition -> BRAM schreiben

[Gustl B. (-gb-)]

Hallo, ich habe eine Frage zum BRAM. Es heißt ja, dass wenn ich da eine 
Adresse anlege, die Daten einen Takt später zur Verfügung stehen, das 
verstehe ich auch, aber ich verstehe nicht wieso folgendes funktioniert:

RAM(adr) <= RAM(adr) +1;

Wie geht das in Hardware, also das läuft in einem Takt wo es doch 
logischerweise 2 Takte bräuchte?

Ich bin verwirrt und danke für Erklärung :-)

[Lattice User (Gast)]

Gustl Buheitel schrieb:

> Ich bin verwirrt und danke für Erklärung :-)

Die Daten sind ja schon einige Zeit vor dem nächsten Takt gültig, es 
macht also nichts aus, dass du da noch etwas combinatorischen Delay 
draufpackts. Reduziert halt die maximal erreichbare Geschwindigkeit.

[Gustl B. (-gb-)]

Du meinst die Addition? Klar die kostet nur etwas Zeit, aber ich 
verstehe nicht wie das dann im nächsten Takt schon geschrieben ist.

Also einen Takt nach der obigen Anweisung sind die neuen Daten schon im 
BRAM obwohl die zu der Zeit, also im 2. Takt erst valide gelesen worden 
sein sollten.

RAM(adr) <= RAM(adr) +1; -- 1. Takt
Neue Daten im BRAM -- 2. Takt

Für mich wäre es verständlich wenn das hier ginge:

Buffer <= RAM(adr); -- 1. Takt
RAM(adr) <= Buffer +1; -- 2. Takt
Neue Daten im BRAM -- 3. Takt

Das sind 2 Takte, und einen Takt danach, also im 3. stehen die neuen 
Daten dann im BRAM, aber anscheinend geht das auch einen Takt schneller.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Gustl Buheitel schrieb:
> Klar die kostet nur etwas Zeit, aber ich verstehe nicht wie das dann im
> nächsten Takt schon geschrieben ist.
Du denkst um 1 Takt versetzt (das ist übrigens das, was vielen auch in 
echt passiert): da werden natürlich die im vorigen Takt gelesenen 
Daten um 1 inkrementiert. Deshalb ist der jetzige Takt schon dein 
nächster Takt. Der Trick: gleichzeitig mit dem "Schreibetakt" (oder 
kurz danach) kommt das geschriebene Wort ja am Ausgang schon wieder 
heraus, wenn das RAM auf WRITE_FIRST eingestellt ist. sieh dir einfach 
mal die Timing-Diagramme des RAMs an. Da wird das eigentlich schnell 
klar...

[Gustl B. (-gb-)]

Ah! Das erklärt einiges. Danke!

Dann werden bei

RAM(adr) <= RAM(adr) +1;

wenn ich in jedem Takt die Adresse hochzähle die neuen Daten versetzt 
geschrieben. Habe das jetzt entzerrt, aber kostet eben auch Zeit und 
schmälert den Durchsatz.

[Lattice User (Gast)]

Gustl Buheitel schrieb:
> Ah! Das erklärt einiges. Danke!
>
> Dann werden bei
>
> RAM(adr) <= RAM(adr) +1;
>
> wenn ich in jedem Takt die Adresse hochzähle die neuen Daten versetzt
> geschrieben. Habe das jetzt entzerrt, aber kostet eben auch Zeit und
> schmälert den Durchsatz.

Als DP RAM konfigurieren und die write addresse verschleppen

RAM(wadr) <= RAM(radr) +1;
wadr <= radr;
radr <= next_radr;

[Gustl B. (-gb-)]

Eine elegante Methode, Danke! In meinem Fall habe ich aber genügend 
Takte Zeit.

[J. S. (engineer)]

Man sollte eventuell noch erwähnen, dass die BRAMs typischerweise mit 
einer input / output registrierung gefahren werden wobei am output sogar 
2 register liegen können / müssen, um auf Tempo zu kommen. Damit kommen 
bis zu 3 Takte Delay hinein. Man vergleiche die Einstellungen in z.B. 
CoreGen.

Und da wir gerade bei Xilinx sind: Ein einschlägig bekannter Chip hat 
hier auch noch einige issues beim write first. Da geht (ging) sogar 
teilweise die DP-Funktion an sich nicht, wenn man bestimmte 
Adressbereiche genutzt hat.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jürgen Schuhmacher schrieb:
> Ein einschlägig bekannter Chip hat hier auch noch einige issues
Man kann einen Fehler nicht oft genug wiederholen, bis man ihn perfekt 
beherrscht...