Hallo, ich habe ein FPGA-Design auf einem XC2VP70, für welches ich nicht genügend Clockbuffer (bufg) habe. Indirekte Folge dessen ist, dass ich z.Z. einen Takt invertiere, um ihn phasenverschoben auf 180° zu bekommen. Dass das ganze keine schöne Sache ist, ist mir klar. Nun zum Problem: In einem vereinfachten Design funktioniert das ganze wunderbar. Der Takt wird für einen Speicherkontroller benötigt. Ich habe ein Testprogramm geschrieben, welches Daten in meinen Speicher schreibt und diesen anschließend ausliest und vergleicht. Wenn alles korrekt war, dann geht eine LED an. Ein anderer Teil des Designs berechnet Daten, die in den Speicher geschrieben werden sollen. Mache ich den Umweg über den Speicher nicht, dann kann ich die Daten korrekt versenden (über Netzwerk). Füge ich den Speicher hinzu, dann sind die Daten fehlerhaft. Meine erste Idee war jetzt, dass mein Speicherkontroller vielleicht doch nicht so toll arbeitet. Ich habe ein Chipscope-Modul am Eingang des Speichers hinzugefügt und musste feststellen, dass jetzt falsche Daten IN DEN Speicher geschrieben werden. Für die Module vor dem Speicher habe ich bereits eine "Post-Place-Simulation" durchgeführt. Alles wunderbar. Auf dem FPGA aber nicht (Chipscope). Es ist also in irgendeiner Form eine Rückwirkung von Speichercontroller auf die Module davor vorhanden. Die üblichen verdächtigen: "unconstrainted paths", timing score, reset kann ich ausschließen. Das ganze Design läuft mit minimal 100MHz (ein sind noch 125MHz für eine Netzwerkschnittstelle sowie 300MHz für den PowerPC drin). Es werden nur eine handvoll FlipFlops an den invertierten Takt angeschlossen. Wo kann ich noch suchen? Welche Constraints kann ich ggf. setzen, damit es dennoch funktioniert? Welche Probleme kann ein solcher Takt verursachen? Vielen Dank schonmal!
> dass jetzt falsche Daten IN DEN Speicher geschrieben werden. Sind alle Daten falsch, oder nur ab und zu? > Wo kann ich noch suchen? Wenn du tatsächlich 8 Takte verwendest: An den Taktdomänen-Übergängen. Da ist sicher der eine oder andere noch nicht ganz synchron zum Gegenstück. :-o
>Sind alle Daten falsch, oder nur ab und zu? Es sind "sehr viele" Daten falsch. Im Schnitt jedes 10 Byte würde ich schätzen. >Wenn du tatsächlich 8 Takte verwendest: An den Taktdomänen-Übergängen. >Da ist sicher der eine oder andere noch nicht ganz synchron zum >Gegenstück. :-o Tatsächlich läuft die Datenverarbeitung in einer Taktdomöne. Ich brauche für den Speicher drei zusätzliche Taktdomänen (DDR2 SRAM), für den Netzwerkcontroller zwei (jeweils 125MHz), für den Eingangstakt eine (100MHz) und für den Prozessor (300MHz) eine. Problematisch ist in meinem Design, dass die Virtex-II DCMs nur 4 Signale treiben können und dass ich für zusätzliche DCMs immer Clockbuffer brauche. Die Taktdomänen der Module untereinander sind an den Stellen, wo es nötig ist, mit Asynchronen FIFOs entkoppelt. Handshake-Signale werden entsprechen mit Registern zwischen den Taktdomänen überführt. Ich hätte da noch eine zusätzliche Frage. Ich würde das ganze Design gern einmal mit Mentor Precision übersetzen. Gibt es eine einfache Möglichkeit, Precision XST im XPS (oder EDK) zu integrieren, d. h. ohne, dass ich alles Scripte umschreiben oder neu schreiben muss? Gruß, Kristian
"Handshake-Signale werden entsprechen mit Registern zwischen" "den Taktdomänen überführt" Wenn das manuell geschieht, gibt es manchmal Fehlinterpretationen, wann ein Dateum gültig wird. Ich übergebe solche Sigs immer über den Ffof: Eine Fifo-pie für Hin und ein für Rück.
>Ich übergebe solche Sigs immer über den Ffof: >Eine Fifo-pie für Hin und ein für Rück. Das hab' ich jetzt so schnell nicht ganz verstanden.
Kristian K. wrote: >>Ich übergebe solche Sigs immer über den Ffof: >>Eine Fifo-pie für Hin und ein für Rück. > Das hab' ich jetzt so schnell nicht ganz verstanden. Ganz einfach: Die sauberste Möglichkeit, Signale zwischen 2 Taktdomänen zu übertragen ist, sie durch ein FIFO zu schicken. Das hat 2 Takte (1 mal Lesen, 1 mal Schreiben) und somit ist garantiert, dass die Signale auf beiden Seiten synchron zum jeweiligen Takt sind.
und wenn man es richtig machen will, muss das fifo 4 stufen haben, beim negierten takt 3
Ich habe den Fehler jetzt offenbar an einer ganz anderen Stelle im Design gefunden. Der FIFO Generator v4.3 scheint mir eine fehlerhafte FIFO erzeugt zu haben: Ich habe die FIFO mit "Full Flags Reset Value=1" erzeugt, d. h. die FULL-Flags sollten beim Reset auf "1" gehen. Das haben sie offenbar nicht immer gemacht. Die Umstände unter denen dieser Fehler auftritt konnte ich bis jetzt in der Simulation nicht nachstellen, denn dort trat der Fehler nicht auf (struktuelles als auch Verhaltensmodell). Mit der selben FIFO aus dem FIFO Generator v4.4 tritt der Fehler nicht auf (im Xilinx IP Release Notes Guide konnte ich keinen Hinweis darauf finden). Es ist also keine indirekte Folge meines unschönen invertierten Taktes. Bei der Überführung zwischen den Taktdomänen habe ich bis jetzt immer nur für die Daten FIFOs verwendet. Das mit den FIFOs für die Handshake-Signale werde ich mal ausprobieren, wenn ich wieder einen Fehler habe! Danke!
> ... FIFO Generator v4.3 scheint .. eine fehlerhafte FIFO erzeugt ... > ... FIFO aus dem FIFO Generator v4.4 tritt der Fehler nicht auf. Das würde mir ein echt mulmiges Gefühl hinterlassen.... Fifo sind soooo neu ja nun auch wieder nicht :-o
aber sie werden in jedem fpga anders gebaut - hatte auch schon mal timing aerger mit fifos. manuell gebaute liefen und lösten das problem
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.