Hi
Hab nur eine ganz kurze Frage!
Hab eine Asynchrones FIFO geschrieben und wunder mich jetzt über die
nicht vorhandene Latenz beim Lesen.
Normalerweise müsste es doch so sein das ich im 1. Takt Lese und die
Daten erst nach dem 2. Takt am Ausgang erscheinen dürften und ich sie
dann mit dem 3. Takt weiter Verarbeiten kann!
Hier ist es aber jetzt so das schon nach dem ersten Takt die Daten
erscheinen :-/
Es wird 100% ein BlockRam genutzt wie ich dem "Design Summary" eindeutig
entnehmen kann.
Vllt. könnt ihr mir ja helfen ?
Gruß Max
Max schrieb:> Hab eine Asynchrones FIFO geschrieben
Und wie sieht diese Beschreibung aus?
Wie kommt die Waveform zustande? Ist das eine funktionale Simulation?
Tut mir Leid für die wenigen Infos, lade mal kurz die beiden
Beschreibungen + den Testbench hoch.
Das ganze ist eine Post P&R Simulation, kann wenn gewollt einmal das
ganze Projekt hochladen dann könnt ihr selbst sehen wie es aussieht ^^
Gruß Max
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;
hmm, Recht hast du auf eine gewisse Art aber am ende macht es doch
keinen Unterschied oder sehe ich das Falsch ?
Benutze den Write Counter nur auf der Write Seite Binär und das selbe
mit dem Read Counter :-/
Naja, aber vertue ich mich denn so mit der Latenz vom BlockRam oder ist
das so richtig ?
Gruß Max
> 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.
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.
Deine Beschreibung gibt den zusätzlichen Takt für den Blockram nicht
her. Das Synthesetool darf natürlich nicht nach eigenem Gusto eine
zusätzliche Latenz einfügen, auch dann nicht wenn das besser zum FPGA
passt! Das Tool ist aber garantiert schlau genug dein Ausgangsregister
im Ausgangsregister des Blockrams zu implementieren.
Bei Lattice ist das Ausgangsregister des EBR (Blockram) optional, und
ich würde mich extrem wundern wenn das nicht auch bei Xilinx/Altera der
Fall 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
>fifo_empty und fifo_full werden nach einem Vergleich generiert, ist das>erlaubt?
Wieso sollte dies nicht erlaubt sein? Solange die Vergleicher-Eingänge
aus einer Taktdomäne kommen, ist alles in Ordnung.
Karlo
@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
Der Schreiber-Füllstandszähler muss zur Generierung des
(Lese-)Empty-Flags
in die Lese-Taktdomäne
und der Leser-Füllstandszähler muss zur Generierung des
(Schreib-)Full-Flags in die Schreib-Taktdomäne umsynchronsiert werden.
Für die Umsynchronisierung dieser Füllstandszähler werden Gray-Zähler
verwendet.
Beim Block RAM kann man zwischen 3 Modien auswählen FIRST Write, First
Read und den 3. weiß ich nicht mehr aus dem Kopf.
Wenn Du im IP-Core Wizard einen BLOCK-RAM erstellst, dann kann man unten
auf Datenblatt klicken.
Bei einem Modus ist es so das was als letztes in den RAM geschrieben
wird wird auch gleich an den Leseausgang angelegt. Da Du ja gleich mit
dem auslesen beginnst muss man da aufpassen.
>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"
Karlo
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.
Temp.png
(18 KB)
