Hallo allezusammen, habe ein kleines Problem. Ich habe ein Design mit vielen Submodulen, die über ein Hauptmodul (Top Modul) verbunden sind. In einem der Submodule lese ich vom DDR2 Speicher 256 Bit Daten aus mit einer Taktgeschwindigkeit von 200 MHz. Anschließend lege ich die Daten auf einem STD_LOGIC_VECTOR Signal und die Daten kommen zu einem anderen Submodul, der mit 140 MHz arbeitet. Leider sind die ankommenden Daten bis jetzt immer Falsch gewesen. Ich habe dann natürlich versucht die Daten zu synchronisieren mit FF, aber bisher ohne Erfolg. Die Frage ist einfach nun, wie sollte man zwischen unterschiedlichen Taktdomänen std_logic_vector signale verbinden bzw. einsynchroniseren? Hilft hierbei nur noch ein FIFO oder geht es auch ohne, evtl. mit FF-Logik. Bräuchte in dieser Hinsicht euren Rat. Danke im voraus Gruß Cihan
Für Datenbusse nimmt man in der Regel FIFOs zwischen den Clock-Domains. Gruß Marius
Ist das ein instaziierter Controller-Core? Der hat die FiFos in der Regel schon drin, sodass man in der Zieldomain lesen und schreiben kann. Die Lese und Schreibanforderungen werden durch den Controller selbst synchronsisiert, also eingetaktet. Kann es sein, dass Du halbleere FiFos ausliest?
Hallo, der DDR2 ist eine Core vom MIG erzeugt. Beim Schreiben und Lesen auf dem DDR2 Core gibt es keine Probleme, da sind auch die FIFOs für lesen, schreiben und addressieren schon erhalten. Bei mir liegt das Problem im folgenden Bereich: Ich lese zweimal aus dem Ram 256Bit Daten aus. Einmal werden die Daten über dem PLB Bus über die SDK ausgelesen, funktioniert einwandfrei und einmal werden die Daten zum 140MHz schnellen Submodul geschickt, wo sie dann per I/O Pins zu einem anderem Board (FGPA) geschickt werden. Die Daten werden dann vom anderen Board empfangen und in Chipscope dargestellt und siehe da die Daten sind falsch. Wie gesagt in SDK ist alles in Ordnung. Im Allgemeinen brauche ich im Prinzip einen FIFO, um die Daten richtig synchronisieren zu können. Am besten bzw. muss sogar den FIFO mit 2 Clockansteuerungen für jeweils Lesen und Schreiben nehmen. Ich hätte evtl. noch zum FIFO mal ne Frage. Wenn ich ein FIFO generiere bei dem immer 256Bits eingelesen und ausgelesen werden mit unterschiedlichen Takten (RD_CLK und WR_CLK), werden ja die FULL und EMPTY bits dem entsprechend gesetzt. FULL wenn 256 Bits in FIFO geschrieben wurden und EMPTY wenn Bits ausgelesen wurden. Was ist nun wenn ich nur 200 bits reinschreibe und dann wieder auslese. Was ist nun mit den restlichen 56 bits, gleich null oder evtl. sogar irgendwelche Altdaten? Vllt. macht die Frage evtl. überehaupt kein Sinn, da ich evtl. etwas Falsch verstanden habe, aber würde mich freuen wenn ich dazu Anregungen bekommen könnte. Danke schon im voraus für eure netten Beiträge. mfg Cihan
>dann per I/O Pins zu einem anderem Board (FGPA) geschickt werden. Die >Daten werden dann vom anderen Board empfangen Wie genau machst du das?
> Vllt. macht die Frage evtl. überehaupt kein Sinn, da ich evtl. >etwas Falsch verstanden habe, aber würde mich freuen wenn ich dazu >Anregungen bekommen könnte. Generiere dir ein entsprechendes FIFO-Template und bau eine Testbench, in der du veschiedene Schreib- und Lese-Sequenzen testen kannst. Dann siehst du auch, wie sich die verschiedenen Füllstands-Flags verhalten.
Cihan Kalayci schrieb: > Ich hätte evtl. noch zum FIFO mal ne Frage. Wenn ich ein FIFO generiere > bei dem immer 256Bits eingelesen und ausgelesen werden mit > unterschiedlichen Takten (RD_CLK und WR_CLK), werden ja die FULL und > EMPTY bits dem entsprechend gesetzt. FULL wenn 256 Bits in FIFO > geschrieben wurden und EMPTY wenn Bits ausgelesen wurden. Was ist nun > wenn ich nur 200 bits reinschreibe und dann wieder auslese. Ich weiß nicht, ob ich Dich richtig verstanden habe. Der Sinn des Fifos ist, daß die einzelnen Bits eines Vektors (also parallel gleichzeitig angekommende Bits) zu einander synchron sind. Damit kannst Du die Integrität des Datenwortes sicherstellen. Entsprechend muß das Eingangswort des FIFOs 256Bit breit sein, damit die 256 Bits auf einmal geschrieben bzw. gelesen werden. Dann kannst Du sicher sein, daß die 256 parallelen Einzelbits eine zeitliche Einheit bilden. Da Du also einen 256 Bit breiten Vektor verwendest, hast Du auch immer 256 Bits und nie nur 200Bits, weil ja in Hardware tatsächlich 256 parallele Signale da sind.
Pako schrieb: > Cihan Kalayci schrieb: >> Ich hätte evtl. noch zum FIFO mal ne Frage. Wenn ich ein FIFO generiere >> bei dem immer 256Bits eingelesen und ausgelesen werden mit >> unterschiedlichen Takten (RD_CLK und WR_CLK), werden ja die FULL und >> EMPTY bits dem entsprechend gesetzt. FULL wenn 256 Bits in FIFO >> geschrieben wurden und EMPTY wenn Bits ausgelesen wurden. Was ist nun >> wenn ich nur 200 bits reinschreibe und dann wieder auslese. > > Ich weiß nicht, ob ich Dich richtig verstanden habe. > Der Sinn des Fifos ist, daß die einzelnen Bits eines Vektors (also > parallel gleichzeitig angekommende Bits) zu einander synchron sind. > Damit kannst Du die Integrität des Datenwortes sicherstellen. > Entsprechend muß das Eingangswort des FIFOs 256Bit breit sein, damit die > 256 Bits auf einmal geschrieben bzw. gelesen werden. Dann kannst Du > sicher sein, daß die 256 parallelen Einzelbits eine zeitliche Einheit > bilden. > Da Du also einen 256 Bit breiten Vektor verwendest, hast Du auch immer > 256 Bits und nie nur 200Bits, weil ja in Hardware tatsächlich 256 > parallele Signale da sind. Ja du hast recht. Ich habe mir das gerade nochmal so durchdacht und sah, dass es nie zu solch einem Fall kommen wird. Es werden wie du auch gesagt hast immer 256 Bits ins FIFO eingelesen und dann wieder ausgelesen. Stachele schrieb: >>dann per I/O Pins zu einem anderem Board (FGPA) geschickt werden. Die >>Daten werden dann vom anderen Board empfangen > > Wie genau machst du das? Die Daten werden per CameraLink zum anderen FPGA geschickt und auch per Camerlink Protok. eingelesen. Dies funktioniert einwandfrei, da ich schon viele Tests, auch mit Dummy-Daten vollbracht habe. Stachele schrieb: >> Vllt. macht die Frage evtl. überehaupt kein Sinn, da ich evtl. >>etwas Falsch verstanden habe, aber würde mich freuen wenn ich dazu >>Anregungen bekommen könnte. > > Generiere dir ein entsprechendes FIFO-Template und bau eine Testbench, > in der du veschiedene Schreib- und Lese-Sequenzen testen kannst. Dann > siehst > du auch, wie sich die verschiedenen Füllstands-Flags verhalten. Genau da bin ich jetzt auch dabei, denke ich kriege das dann auch so hin. Vielen Dank für eure Anregungen, ihr habt mir geholfen. Gruß Cihan
Cihan Kalayci schrieb: > wo sie > dann per I/O Pins zu einem anderem Board (FGPA) geschickt werden Und du bist dir 100% sicher, dass das klappt? Tom
Einfachste Lösung sollte sein, dem MIG noch einen Datenport hinzuzufügen und diesen dann mit der 140 MHz-Domäne zu takten. Braucht keinen extra FIFO (der Port hat diesen ja schon), nur etwas Steuerlogik mehr.
Thomas Reinemann schrieb: > Cihan Kalayci schrieb: >> wo sie >> dann per I/O Pins zu einem anderem Board (FGPA) geschickt werden > > Und du bist dir 100% sicher, dass das klappt? > > Tom Ja, das bin ich, warum die Nachfrage? Ich habe im Prinip nichts anderes gemacht als Sender und Empfänger zu programmieren auf Basis von Cameralink. Hab schon sehr viele Tests gemacht, alles einwandfrei. wosnet schrieb: > Einfachste Lösung sollte sein, dem MIG noch einen Datenport hinzuzufügen > und diesen dann mit der 140 MHz-Domäne zu takten. Braucht keinen extra > FIFO (der Port hat diesen ja schon), nur etwas Steuerlogik mehr. Du meinst also beim MIG-Generator kann man noch was einstellen. Wo genau kann man es unter MIG denn festlegen, wäre auch eine Variante. Cihan
Cihan Kalayci schrieb: >> Und du bist dir 100% sicher, dass das klappt? >> >> Tom > > Ja, das bin ich, warum die Nachfrage? Du hast eine Kette über mehrere Stufen und da kann überall der Fehler sein. In deinem Post steht nicht, dass du andere Stellen ausschließen kannst. Tom
Wenn Du den MIG-Ipcore öffnest, kann man sich ja in einer Art Wizard durchklicken. Irgendwann kommt dann die Spezifikation der Ports (dort kann man die Bitbreite, Anzahl, Direktionalität usw. festlegen). Dort sollte es auch möglich sein, weitere Ports zu aktivieren. Meines Wissens nach gehen da bis zu 6 unabhängige Ports (mit jeweils auch beliebigen Taktdomänen).
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.