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
Angehängte Dateien:
-
Temp.png
18 KB
Mach dein WE mal synchron zum WCLOCK oder verpasse ihm wenigstens 1 ps Dealy. So schreibst du dir die Daten ja am Ende des Taktes rein.
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
René D. schrieb: > Die Daten werden nicht hintereinander > geschrieben sondern die Ablage ist auch im Grayformat. sonst täte es auch nicht viel bringen.
> 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.
René D. schrieb: > Jedoch die Übergabe der Addressstelle muss in Gray Dann muss die Adresse aber 1clk länger eingetaktet werden
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.