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
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
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
Timing.png
(270 KB)
