mikrocontroller.net

Forum: FPGA, VHDL & Co. ChipScope problem


Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Häng doch mal dein Design an oder beschreib zumindest was sich anders 
verhält.
Glaskugeln sind derzeit wieder ausverkauft :)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, der ChipScope Core ist schon ein kleiner Brocken, das Routing wird 
dadurch recht viel verändert. Was sagen denn die Timing Constraints?

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: matzunami (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mani (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mani (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal das doc des MPMCs

http://www.xilinx.com/support/documentation/ip_doc...

Seite 188/189 ist die Art der Übertragung die ich fabriziere

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Marcus W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nehme meine steigende Flanke zurück, habs mit dem Prozessor verwechselt.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die Antwort... meinst du das Datenblatt vom Virtex? Kannst du 
mir eventuell die Seite sagen, wo das steht? Ich finds nicht... :-(

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.