Hallo, ich habe momentan das Problem, dass mein Design im Simulator funktioniert, aber nicht auf der Hardware. Nun habe ich gehoft, dass mir ChipScope bei der Sache weiterhilft. Jedoch habe ich den Effekt, dass sich mein Design mit dem ChipScope Core anders verhält als ohne... hat eventuell jemeind ein Tip für mich, worin der Grund dafür liegen könnte? In meinem Design spielt sich eigentlich alles in StateMachines ab, alles schon synchron. wäre für ein paar Tips dankbar
Häng doch mal dein Design an oder beschreib zumindest was sich anders verhält. Glaskugeln sind derzeit wieder ausverkauft :)
Naja, der ChipScope Core ist schon ein kleiner Brocken, das Routing wird dadurch recht viel verändert. Was sagen denn die Timing Constraints?
Das Project ist jetzt schon ziehmlich groß. Ich habe eine Bildaufnahme -> Zwischenspeicherung -> Bildausgabe realisiert. Dies hat auch funktioniert. Nun möchte ich allerdings etwas am Design verändern, aufgund von Erweiterungen, allerdings funktioniert dann nur noch die Bildausgabe. Nach einbinden den Cores, wird nun auch das ausgegebene Bild verzehrt. Ich beschäfftige mich noch nicht so lange mit ISE und VHDL, auf was genau ,muss ich bei den Timing Constraints achten? Wird kein fehler erzeugt, wenn es dort probleme gibt?
Wenn ich die Signale in CipScope ändere, ändert sich auch das Verhalten meines Boards. Ich hab mal die zwei wichtigen Componenten angehangen, die den Speicherzugriff regeln. Dies sind auch die einzigsten Componenten, die ich geändert habe, nachdem es ging.
Bin auch dankbar für jede Designverbesserung die mir keine Timing probleme verursachen . Die Componente MPMC_interface organisiert den Zugriff auf den ddr2 speicher (ich hab einen microplaze mit einem mpmc eingebunden). Und die Componente NPI_interface regelt wann geschrieben und gelesen werden soll und generiert mir ein fifo reset signal.
> Ich beschäfftige mich noch nicht so lange mit ISE und VHDL Scheint aber schon ein eher fortgeschrittenes Design zu sein :) Haben deine Clocks alle ein entsprechendes Timing Constraint? > auf was genau ,muss ich bei den Timing Constraints achten? Wird kein fehler > erzeugt, wenn es dort probleme gibt? Das Bitfile wird standardmäßig trotz Timingerrors erzeugt (und gelegentlich läuft sogar das Design noch fehlerfrei). Zeigt die Design Summary Timingerrors?
Du arbeitest mit Videodaten oder? Könnte Jitter ein Problem sein? Hatte mal ein schnelles serielles Interface, dass bei FPGA-Temperaturen > 30°C nicht mehr richtig funktioniert hat. Abhilfe schuf damals eine PLL anstelle einer DCM. Die DCM hat zu viel Jitter verursacht.
meinen Takt nehm ich momentan vom Port Pin, also ohne PLL oder DCM dazwischen... ist das ungünstig? Und Clocks benutz ich eigentlich nur einen, den Boardtackt und der hat ein Timing Constrain. Den Takt für den MPMC hab ich mir nur aus dem MicroPlaze herausgeführt, dieser dürfte von einer PLL erzeugt werden. Timingerrors hab ich noch keine gesehen. Und ja ich arbeite mit Videodaten, die ich mir über ein FIFO einsynchronisiere. An welcher stelle und warum sollten Jitter auftreten?
> meinen Takt nehm ich momentan vom Port Pin, also ohne PLL oder DCM > dazwischen... ist das ungünstig? Nein, das passt in der Regel schon, gibt aber auch Ausnahmen. (Ich nehme an, der Pin führt an einen "global clock input"?) Benutzt du ein selbst entworfenes Board oder ein gekauftes Entwicklungsboard? > Und Clocks benutz ich eigentlich nur einen, den Boardtackt und der hat > ein Timing Constrain. Ok, ich hab mit dem Denglisch angefangen :) Sind das jetzt zwei Takte oder nur einer? Zu deinen Videodaten: Wie kritisch ist denn das Timing dieser Videodaten? Um welches Protokoll gehts da? Es gibt (professionelle) Videoprotokolle, die in Sachen Jitter sehr sensibel sind. Hab da allerdings nur Halbwissen, hab das mal bei den Kollegen mitbekommen. Beispiel: Wenn deine Taktquelle schon viel Jitter enthält, dann wird das im FPGA (ohne PLL/DCM) nicht besser, und wenn man sich eh schon am Rande der Spezifikation aufhält, dann kann evtl. schon ein CS-core bewirken, dass garnichts mehr geht. Gehts hier um ein Studienprojekt oder um eine kommerzielle Anwendung? Siehst du im Chipscope eigentlich auch Fehler, die in der Simulation nicht da sind, oder schaut im Chipscope alles so aus wie es soll und es erscheint nur das Bild am Monitor nicht so wie es soll?
1. Ich benutze das Eval-Board ML505 von Xilinx 2. Dieses Board besitzt einen 100MHz Quarz 3. Der MicroPlace erzeugt über eine PLL die 200MHz für den DDR2 Speicher und den MPMC. Diesen Takt habe ich mir aus dem MB herausgeführt, um die StateMachine für den MPMC damit zu takten. Sind also an sich zwei Takte (100MHz und 200MHz) 4. Hier mangelt es mir an Erfahrung, aber ich wüßte nicht was an den Videodaten kritisch sein soll (Ein- und Ausgabe hat ja auch schon funktioniert). Ist ein 640x512 14Bit Bild eventuelle besonderheit: high aktive Frame Sync Signal und dann ein Linesync über ALLE Pixel, ohne Unterbrechung nach einer Zeile. Pixeltakt müsst 50MHz sein. 5. Aussagen über ChipScope zu treffen fällt nicht leicht, weil sich das verhalten ja jedesmal ändert. Ich hab aber in CS schon fehler gesehen, die in der Simulation nicht auftraten... das mysteriöste was ich bisher hatte war, dass mein Prog in ein State ging, den es garnicht gab und somit auch hingen blieb (hab auch sowas in meiner SM wie when others => State <= idel, dass hatte da aber keine Auswirkungen) Zu einen Punkt hätt ich gerne noch eine zweite Meinung. Der MPMC ändert laut Datenplatt seine Signale (auch Datenwort) mit der Steigenden Flanke. Beim Schreiben ist das kein Problem, da kann ich den MPMC Takt einfach an mein FIFO anlegen, um die Daten mit der steigenden Flanke aus dem FIFO auszulesen. Wenn ich diesen Takt nun auch zum schreiben in das FIFO Out benutze, würde ich mit steigender Flanke die Daten einlesen und zum selben Zeitpunkt, würde der MPMC neue daten Anlegen. Was ist nun am besten: 1. selben Takt verwenden (habe zum FIFO keine Sample and Hold Zeiten gefunden) oder 2. den Takt 180 Phasenverschoben benutzen (ist an sich würde ich sagen auf der sicheren Seite) und wenn ja über einen negator wie CLK <= not(MPMC_CLK) oder lieber über einer DCM (MPMC_CLK beträgt 200MHz) Als das Design noch funktionierte, hab ich beides mal ausprobiert -> Takt direkt genomen und über negator und es hat beiden funktioniert.
Hier mal das doc des MPMCs http://www.xilinx.com/support/documentation/ip_documentation/mpmc.pdf Seite 188/189 ist die Art der Übertragung die ich fabriziere
(Kleine Anmerkung vorweg: Der Prozessor heißt Microblaze) > Der MPMC ändert > laut Datenplatt seine Signale (auch Datenwort) mit der Steigenden > Flanke. Wo steht das? Soweit ich weiß liegen die bei der steigenden Flanke stabil an, damit sie übernommen werden können. Also ich hab ehrlich gesagt keine Zeit mich da richtig rein zu denken, aber ich würde folgendes machen: 1. Standbild ausgeben 2. Im CS Schauen wo es klemmt bzw. Kontrollieren des Protokolls: - Sync an richtiger Position mit richtiger Dauer? - Statemachine läuft wie gedacht? - FIFO läuft nicht leer/voll - ... 3. entdeckten Fehler lösen Alternativ: Kollegen fragen, der sich mit sowas auskennt. Oder bist du der einzige bei euch? (Je nach Ausstattung kann man das Protokoll auch mit externen Geräten anstelle CS prüfen) > Hier mangelt es mir an Erfahrung, aber ich wüßte nicht was an den > Videodaten kritisch sein soll Du hast ja nicht gesagt was du für ein Protokoll/Format benutzt... Bsp.: HD-SDI mit bis zu 3GBit/s ist schon recht kritisch. Ein PAL-Stream mit 13,5 MHz Pixeltakt eher nicht.
und das heißt? Takt über negator generieren oder über DCM? Ich werd versuchen das schreiben und lesen nochmal seperat zu testen, vielleicht bringt das ja noch was.
matzunami schrieb:
> und das heißt? Takt über negator generieren oder über DCM?
In Ermangelung so vieler DCMs musst du den Inverter auf dem IOB nehmen,
was laut Datenblatt geht, aber nicht so schnell wie mit DCM.
danke für die Antwort... meinst du das Datenblatt vom Virtex? Kannst du mir eventuell die Seite sagen, wo das steht? Ich finds nicht... :-(
Ach Shit, ich hab 2 Threads durcheinander gehauen. Sorry. Du hast wahrscheinlich genug DCM drin, da solltest du das auf jeden Fall darüber machen. Ich hatte es mit dem Thread über die 6 Video-Stream Eingänge am Spartan 3 verwechselt.
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.