BlockRam Latenz

Max schrieb:
> Hab eine Asynchrones FIFO geschrieben
Und wie sieht diese Beschreibung aus?
Wie kommt die Waveform zustande? Ist das eine funktionale Simulation?

Ich habe deine Code mal überflogen. Du hast noch nicht ganz die Sachen 
mit dem Graycode verstanden.

Die Daten werden nicht mit der binären Adresse geschrieben, sondern hier 
müsste die Adresse im Grayformat abgelegt werden.
Das ist gerade der Trick. Die Daten werden nicht hintereinander 
geschrieben sondern die Ablage ist auch im Grayformat.



Fifo(to_integer(unsigned(WriteBinaryOut))) <= Din;


Ich hätte hier erwartet.

Fifo(to_integer(unsigned(WriteGrayOut))) <= Din;

> Es wird 100% ein BlockRam genutzt wie ich dem "Design Summary" eindeutig
> entnehmen kann.

Das Summary sehe ich hier nicht.

Das Taktdiagramm gefällt mit auch nicht. Stelle die Ramadressen dar. 
Dann weisst du wann wohin geschrieben wird und auch wann von wo gelesen 
wird.

Ich habe nochmal überlegt, du kannst auch binär fortlaufend schreiben. 
Jedoch die Übergabe der Addressstelle muss in Gray sein.

Da habe ich mich zu früh gemeldet.
Ich habe mich auch vor geraume Zeit damit beschäftigt und habe es sogar 
wiedergefunden.

Es gab einen wichtigen Trick der Gray code musste 1 bit breiter sein, um 
eindeutig im Überlauf zu sein. Sonst konnte in den Überlauf nicht 
eindeutig dedektieren.

lclk ist???

read clock??

Was mir hier zu Denken gibt:
Wozu eigentlich das Rumgehampel mit dem Gray-Code?

Das ganze Design ist doch sowieso auf der jeweiligen Seite komplett 
taktsynchron. Da ist der Umweg über einen Zähler, der nur 1 Bit pro 
Schritt ändert, vollkommen unnötig und verkompliziert die Sache nur. 
Sinn macht der Graycode eh' nur, wenn von aussen asynchron ein 
(Zähler-)Wert übergeben werden soll.

Sonst: sieh dir mal den RTL-Plan der Beschreibung an, und kontrollier, 
wie dort das BlockRAM angeschlossen ist.

> zu Lothar Miller

Die beiden Takte können völlig unabhängig sein und auch die Frequenz 
können sich ändern.
Es ist auch nicht klar welcher der beiden Takte der schnellere Takt ist.

Der Wert selbst wird ja asynchron übergeben.
Da kann der Wert auch zu sehr ungünstigen Zeitpunkten übergeben werden. 
So ist der Wert im schlimmsten Fall um +/- 1 bit falsch.

René D. schrieb:
> Es ist auch nicht klar welcher der beiden Takte der schnellere Takt ist.
> Der Wert selbst wird ja asynchron übergeben.
Das sehe ich nicht so, denn die zu schreibenden Daten sind offenbar zum 
Schreibtakt synchron. Die zu lesenden Daten zum Lesetakt. Und genau 
dafür ist ein DPRAM gemacht.
Was für einen Sinn würde es machen, die zu schreibenden Daten/Adressen 
vom Schreibtakt unahängig zu haben?

René D. schrieb:
> Der Wert selbst wird ja asynchron übergeben.
Warum? Ist das tatsächlich so? Muss das so sein?
Mindestens die Adressen kommen ja von FPGA selber und werden synchron 
zum (jeweiligen) Takt erzeugt. Und wenn die Daten nicht synchron sind, 
dann hilft auch eine Gray-codierte Adresse nicht gegen Korruption...

Hallo,

muss die Lese- bzw. Schreibaddresse nicht eingetaktet werden?

fifo_empty und fifo_full werden nach einem Vergleich generiert, ist das 
erlaubt?

Bei einem Taktübergang sollte man die Signale immer eintakten, oder 
nicht?


Gruss,
Valentin

@Karlo

bei einem Async FIFO nehme ich an, dass das nicht der Fall ist, oder?

Ausserdem wird in der oben angegebenen Datei 'rgray' mit 'wgray' 
verglichen...


Gruss,
Valentin

Karlo schrieb:
>>Bei einem Modus ist es so das was als letztes in den RAM geschrieben
>>wird wird auch gleich an den Leseausgang angelegt
> Nennt sich "First Word Fall Through"
Da werden jetzt aber Birnen und Äpfel verglichen...
Das Erstere betrifft direkt das DPRAM (und ist dort nur relevant, wenn 
Schreib&Lese-Adressen gleich sind).
Das Zweite betrifft einen (z.B. mit einem RAM realisierten) Fifo, bei 
dem (im leeren Zustand) ein eingeschiebenes Wort direkt an den Ausgang 
durchgereicht wird.