Hallo Gemeinde, ich brauche bezüglich Timing Problemen eure Hilfe. Kurze Erläuterung zum Projekt: Ich habe über den MIG mir eine Core zusammengestellt und in mein Hauptprojekt als Komponente eingebunden. In dem Projekt geht es darum Daten von einer Kamera in der DDR2 Ram reinzuspeichern. Dafür habe ich eine Control, Read, Write und Address-VHD-Dateien erzeugt, die nach dem Prinzip der Testbench programmiert sind. Das Schreiben und Lesen an sich funktioniert. Nun zum Problem: Ich benutze das Board ML507 von Xilinx mit dem Virtex 5 FPGA. Laut Referenzdesign müsste der DDR2 Clock (266MHz) über die GTX stecker kommen (H14/H15), da ich aber die GTX Eingänge später selber verwenden will, habe ich mir über eine DCM meine gewünschte Clock für den DDR2 selbst erzeugt. Die DCM wird mit 100MHz gespeist und liefert mir 266MHz für den DDR2. Alles schön mit einander verknüpft und instanziiert, doch leider Timing-Probleme. Anmerkungen zum Projektinhalt: Die Datei user_dcm.vhd ist für die erzeugung des 266MHz Clock fürs DDR2 zuständig und die Datei Digital_Clock_Manager.vhd ist für die Clocks der Kamera zuständig. Die Fehler passieren in der user_dcm.vhd soweit ich sehen konnte. Die Projektdateien sind als Zip im Anhang und ich habe zusätzlich noch das Timing-Report hochgeladen + noch ein Bild dazu. Falls ihr andere Informationen braucht kann ich die ja noch zusätzlich hochladen. Ich persönlich denke, dass ich noch irgendwelche Timing Constraints Angaben im UCF machen muss, aber bin mir ebend nicht ganz sicher wie und welche. Würde mich auf jede Hilfe sehr freuen. mfg Cihan
Angehängte Dateien:
-
Timing.png
270 KB
Cihan Kalayci schrieb: > Ich persönlich denke, dass ich noch irgendwelche Timing Constraints > Angaben im UCF machen muss, aber bin mir ebend nicht ganz sicher wie und > welche. Der MIG liefert doch auch eine passende ucf-Datei mit. Wo liegt das Problem? Außerdem kannst Du den Speicher auch langsamer betreiben. Duke
An der UCF an sich habe ich auch nicht großartiges geändert, die passt ja. das einzige was ich angepasst habe ist die SYS_CLK und die Pfade, da ich die Core als Komponente in mein Top Modul eingebunden habe. Trotzdem ergeben sich timing fehler. Cihan
Duke Scarring schrieb: > Außerdem kannst Du den Speicher auch langsamer betreiben. Da hast du auch recht, aber das ist ja nicht die Ursache für die Timing Fehler. oder?
Hallo Cihan Kalayci, ich habe mir den Timing Report angeschaut. So wie ich das sehen kann sind alle Timing Fehler ausserhalb des MIG in der Adressgenerierung zum MIG. Die ISE baut hier größere Multiplexerstrukturen sowie Feedthroughs durch SLICES (lokales routing resourcen Problem). Du kannst nun versuchen: Die ISE dazu zu bewegen, sich etwas mehr mühe zu geben: Implementation Optionen: -Placer Effort HIGH und Placer Extra Effort Normal Place & Route Effort Levek High & Extra Effort Normal Ggfls. Registerduplication & Reordering einstellen. In deinem Design selbst solltest Du Dir überlegen ob Du bei deiner Adressgenerierung nicht eine Pipelinestufe / Registering machen kannst, das würde das gesamte Timing wohl deutlich entspannen. Insgesamt muss man schon sagen, dass es von Dir sehr sportlich (oder sollte ich eher sagen leichtsinnig) ist als Anfänger ein Design auf 266MHz zu jagen! Wenn Du den MIG (und damit die davor liegende Adressgenerierung) von 266Mhz auf 200MHz senken würdest, würde sich das Synthesetool deutlich leichter tun, die von Dir aussergewöhlich komplexe Ansteuerung in der geforderten Performance zu synthetisieren und Map&Routen. Wenn Du Dir dann noch ansehen würdest, was aus dem von dir in VHDL (oder Verilog) geschriebenen Code entsteht, dann würdest Du ein Gespür dafür erlangen, was noch geht oder was eher nicht... Gruß Vanilla
Die Geschwindigkeit von 266MHz hatte einfach folgenden Grund: Ich lese ja die Kameradaten mit einer Geschwindigkeit von 140 MHz ein. Diese werden dann im RAM gespeichert. Nach dem eine bestimmte Anzahl von Speicher voll ist, wird der nächste schritt sein über eine gekaufte IP-Core die Daten zu komprimieren und über Funk zu senden. Das Senden muss natürlich schneller als das Empfangen der Daten sein, um mehrere Standbilder in einer Sekunde produzieren zu können. Dafür hatte ich mir dann ebend gedacht, dass ich eine schnelle Clock brauche wie die 266MHz, aber ich werde es mal auch mit 200MHz versuchen. Wenn ihr vllt. noch ein Blick in meine UCF-Files gucken könntet, ob dort die Timing Contraints richtig sind, wäre ich euch echt sehr dankbar. UCF ist im Zip Ordner mit drin gruß Cihan
Habe jetzt das Design mit 200 MHz getaktet, erstmal keine Timing Fehler. Danke an alle die beteiligt waren super gruß Cihan
Cihan Kalayci schrieb: > Dafür hatte ich mir > >Ich lese ja die Kameradaten mit einer Geschwindigkeit von 140 MHz ein. > > dann ebend gedacht, dass ich eine schnelle Clock brauche wie die 266MHz, > aber ich werde es mal auch mit 200MHz versuchen. Dir ist aber klar dass die 266/200Mhz der Ramtakt (Signallisierung) ist und das die Daten selbst mit dem doppelten Takt (da DDR) gelesen und geschrieben werden (jeweils an der positiven und negativen Taktflanke)?
Ich hätte da nochmal eine Frage. Nachdem ich jetzt alles auf 200MHz genommen habe (Clock für DDR2) läuft es besser als vorher und ich habe keine Timingverletzungen. Eine Sache fällt mir immer wieder auf, die mich noch verrückt machen wird. Ich habe sehr viele interne Signale, mit denen ich arbeite. Da ich alles in Chipscope darstelle sehe ich wie die verlaufen und weiss natürlich selber wie sie verlaufen sollten. Nun passiert es manchmal, dass ein zwei Signale sich ganz anders verhalten als programmiert, obwohl ich seiner programmierung nichts geändert habe. Warum ist das so, obwohl ich keine Timing Fehler im Report habe, passieren immer noch Fehler in der Ausführung. würde mich über jeden Denkschubser freuen danke und mfg Cihan
Mit welchem Clock sampelst Du im ChipScope? Hast Du für Chipscope allenfalls "false path"-Constraints gesetzt, um "lästige" Reklamationen vom "nicht funktionell wichtigen" Part loszuwerden? Arbeite zwar mit dem SignalTap, aber die potientiellen Probleme sind ja die gleichen... Falls Du auch für ChipScope den gleichen synchronen 200-MHz Clock benutzt und das Timing auch im Chipscope zugeht, bleibt Dir nichts anderes übrig, als nach dem funktionalen Problem zu suchen.
Die 200MHz Clock wird auch um Chipscope übergeben. Die lästigen Reklamationen wie du es sagts bekomme ich andauernd. wie kann ich denn das ausschalten, so wie ich dich verstehe macht es ja programmtechnisch kein unterschied. Es ist komisch. Das Signal was falsch ist, wird ursprünglich 3 mal erzeugt. 2 der 3 Signale laufen richtig nur irgendeiner ist manchmal spontan immer auf dem falschen Trip. Wie gesagt, Timing Fehler gabs in dem Report nicht. Was wäre denn im dem Ansatz dann die Lösung, bzw. wo sollte ich nach dem Fehler suchen, in der Programmierung wird es nicht liegen soweit ich sehe. Gruß Cihan
Cihan Kalayci schrieb: > Die lästigen Reklamationen wie du es sagts bekomme ich andauernd. Das würde dann bedeuten, dass Dein Timing ins ChipScope hinein nicht passt, und Du bist nie ganz sicher, was Du da eigentlich sampelst. > wie kann ich denn das ausschalten Du sollst es ja nicht ausschalten, sondern das Timing zukriegen.
Cihan Kalayci schrieb: > Was wäre denn im dem Ansatz dann die Lösung, bzw. wo sollte ich nach dem > Fehler suchen, in der Programmierung wird es nicht liegen soweit ich > sehe. Ich würde das erstmal in der Simulation komplett zum Laufen bringen. Chipscope ist dann das Mittel der Wahl um zu schauen, was sich in der echten Hardware anders verhält, als in der Simulation. Wenn bei größeren Projekten die Synthesezeiten länger werden, macht Chipscope-Debugging absolut keinen Spaß mehr. Da kommt man mit einer guten Simulation viel weiter. Dort kann man sich nämlich auch die Signale anschauen, die gerade nicht am Chipscope angeschlossen sind. Duke
Hier mal ein Auszug aus meiner Warning list. Ziemlich gegen Ende kommen die ganzen ILA(Chipscope) Warnings. Ich dachte immer die wären zu igrnorieren. Falls nicht, was müsste ich dann evtl. machen? PS: Warning List im Anhang als .txt
Duke Scarring schrieb: > Wenn bei größeren Projekten die Synthesezeiten länger werden, macht > > Chipscope-Debugging absolut keinen Spaß mehr. Da kommt man mit einer > guten Simulation viel weiter. Dort kann man sich nämlich auch die > Signale anschauen, die gerade nicht am Chipscope angeschlossen sind. Für den Chipscope muss es nicht immer eine Neusynthese sein. Wenn man mit dem FPGA-Editor auf Du und Du ist, kann man durchaus die Chipsope Eingänge auch an andere Signale hängen.
Die meisten ILA Meldungen kommen aufgrund unconnectierter ILA Eingänge... Dann kommen noch ein paar Trimming Meldungen welche aber alle den B-Port der RAMs betrifft ( auf welchem die Daten mit JTAG Clock abgeholt werden). Würd an der Stelle jetzt keine unsynchronitäten erwarten. Für eine tiefere Diagnose müsste man nun allerdings deutlich tiefer einsteigen. Gruß Vanilla
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.