Hallo, im FIFO-IP-Core kann man einstellen wann der Core sagt er sei voll. Wie im Bildchen ist der derzeit eingestellt und ich habe dazu folgende Frage: Wenn der "Füllstand" größer ist als 122907, dann wir mit ein full ausgegeben, aber es ist ja noch Platz. Kann ich trotzdem solange weiter schreiben bis der tatsächlich voll ist oder werden keine neuen Werte angenommen sobald das full Flag ausgegeben wird? Danke!
Gustl B. schrieb: > Kann ich trotzdem solange weiter > schreiben bis der tatsächlich voll ist oder werden keine neuen Werte > angenommen sobald das full Flag ausgegeben wird? Ohne das jetzt für Xilinx und für diese Spezielle Fifo dediziert zu kennen, üblicherweise kann man immer in eine FIFO schreiben, auch wenn sie übervoll ist. Dann wird eben das älteste Datum überschrieben.
Digikundler schrieb: > Ohne das jetzt für Xilinx und für diese Spezielle Fifo dediziert zu > kennen, üblicherweise kann man immer in eine FIFO schreiben, auch wenn > sie übervoll ist. Dann wird eben das älteste Datum überschrieben. Davon würde ich jetzt eher nicht ausgehen. Die meisten FIFOs dürften eher den Write-Response aussetzen, bis wirklich geschrieben wurde. Das prog_full wird üblicherweise ein reines Info-Signal sein. Der FIFO verhält sich trotzdem normal, als gäbe es dieses Signal nicht. Ebenso beim prog_empty. Diese Signale dienen üblicherweise dazu, den FIFO nicht bei einer freien Zelle direkt wieder zu füllen, sondern damit zu warten, bis x Zellen frei sind. Falls Bursts günstiger sind als einzelne Zugriffe.
Fein, genau darum geht es mir nämlich, ich will einen Burst schreiben und derzeit unterbreche ich den sofort wenn der FIFO voll sagt, wenn aber noch einige Einträge frei sind kann ich diesen Burst fertig schreiben.
Wie waer's wenn du dir 'ne Testbench schreibt und dir dann die Signale anschaust. Dann weisst du genau was passiert. Gruss Doc_Brown
Samuel C. schrieb: > Davon würde ich jetzt eher nicht ausgehen. Die meisten FIFOs dürften > eher den Write-Response aussetzen, bis wirklich geschrieben wurde. Warum? Der Fifo ist es doch Titte welches Datum verloren geht; wer seine Daten nicht abholt hat eben Pech gehabt. Und FIFO's zum synchronisieren über verschiedene Clock Domains, vermeidet mensch "grenzüberschreitende" Signale so weit wie möglich.
Weil das nicht-deterministisches Verhalten erzeugen würde, das in den meisten Anwendungen unerwünscht sein dürfte. Selbstverständlich gibt es FIFOs, die das so machen. Für ernsthafte Anwendungen wird sowas aber hoffentlich nicht eingesetzt.
Ich verwende den FIFO Generator normalerweise nie sondern verwende die Unimacro Library von Xilinx. Dann hat man doch ein paar mehr Freiheiten, allerdings auch mehr Aufgaben wie das Reset und Enable Handling. Ich schaetze auch mal, dass das am Ende nicht das Full Flag ist, sondern das Almost Full Flag. Das verwendet man praktisch wie ein Full Flag, hat jedoch die Gewissheit, dass noch ein paar Daten ins FIFO passen bevor es ueberlaeuft. Eine gaengige Anwendung ist z.B. wenn ich einen Datenstream aus einem DDR Memory anfordere und ich Zeit brauche den Stream sauber zu terminieren. Das geht nicht immer abrupt (z.B. weil der Speicher Arbietr das nicht zulaesst) und so vermeide ich den Verlust von "Nachzuegler" Daten. Meine Empfehlung: Generiere mal die FIFO Core Sourcen und schau mal an wie das FIFO instanziert wird. Wahrscheinlich wird mit dem Full Flag das Almost Full Flag verknuepft, das laesst sich super easy rausfinden und dann hast du auch Gewissheit.
Samuel C. schrieb: > Weil das nicht-deterministisches Verhalten erzeugen würde, das in den > meisten Anwendungen unerwünscht sein dürfte. Andersrum ,also die FIFO blockiert write, ist es genauso undeterministisch… Ich sag der Fifo Schreib! und sie tuts nicht ;-( .. -- Hab mal a bisserl bei Xilinx recherchiert: "Conceptually, a FIFO always behaves like a shift register, but with independent control of write and read operation." -> schreiben geht immer, weils lesen nicht interessiert ("independent control of write and read ") ", the FULL flag tells the user that no more write operation should be started." nach: https://forums.xilinx.com/t5/PLD-Blog-Archived/FIFOs-A-Tutorial-Description/ba-p/16959
Der Guide für den FIFO Generator (https://www.xilinx.com/support/documentation/ip_documentation/fifo_generator/v13_1/pg057-fifo-generator.pdf) wiederum sagt, dass ein write bei einem vollen FIFO ignoriert wird und die Inhalte nicht zerstört (S.22). Das wäre auch das von mir im Normalfall gewünschte Verhalten. Dann muss ich mich darum nicht selbst kümmern.
Exakt, aber was bedeutet voll? Dass das Flag das sagt, oder dass er wirklich voll ist?
Samuel C. schrieb: > Der Guide für den FIFO Generator > (https://www.xilinx.com/support/documentation/ip_documentation/fifo_generator/v13_1/pg057-fifo-generator.pdf) > wiederum sagt, dass ein write bei einem vollen FIFO ignoriert wird und > die Inhalte nicht zerstört (S.22). Ah, wieder was gelernt. >Exakt, aber was bedeutet voll? Dass das Flag das sagt, oder dass er >wirklich voll ist? irgendwo schreibt xilinx das das flag resp der zugrundeliegende write_counter "pessemistisch" reagiert, es kann also sein das als voll bezeichnet wird, obwohl gerade Platz frei geworden ist: "Write data count (wr_data_count) pessimistically reports the number of words written into the FIFO. The count is guaranteed to never under-report the number of words in the FIFO (although it may temporarily over-report the number of words present) to ensure that you never overflow the FIFO"
Auf der gleichen Seite des Dokuments sind alle drei Flags beschrieben: full: der FIFO ist voll und wird keinen write mehr annehmen almost_full: der FIFO hat noch genau eine Zelle frei und wird noch einen write annehmen prog_full: wie almost_full, nur mit selbst einstellbarer Schwelle
Das Full-Flag wird ja üblicherweise gebildet, wenn der Schreibpointer eins unter dem Lesepointer ist. Bei einem asynchronen FIFO werden die Pointer in verschiedenen Clock-Domains verweltet. Die Übertragung des Lesepointers in die Schreibdomain dauert ein paar Takte. Daher ist das Full-Flag nur sinnvoll auszuwerten, wenn man langsam in den FIFO schriebt. IMHO kann man den Abstand der Pointer beim Almost-Full-Flag einstellen. Das ist für schnelle Burstartige Zugriffe sinnvoll. Duke
Samuel C. schrieb: > Auf der gleichen Seite des Dokuments sind alle drei Flags > beschrieben: Hint am Rande: auf p.22 stehen die Flags nur für den "common clock" Fall; für den interessanteren Fall mit unterschiedlichen clocks gibt es eine xtra Beschreibung (die aber weitgehend gleich ist).
Samuel C. schrieb: > In Bezug auf diese Signale sind sie komplett gleich. Nicht komplett, in der statischen beschreibung vielleicht, aber nicht im zeitlichen Verhalten. Stichwort: delay durch Sync-Pipelines.
Gustl B. schrieb: > werden keine neuen Werte > angenommen sobald das full Flag ausgegeben wird? Sie werden überschrieben oder verworfen. Üblicherweise testet man auf "full" bevor man schreibt. Um das zumildern kann man den full dynamisch programmieren z.B. auf n-10 oder n-20 oder so.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.