Guten Tag. Ich möchte mir in Chip Scope Signale anschauen. In der Beschreibung zum zugehörigen IPCore steht einer maximale Taktrate von 412 MHz (bei entsprechender Konfiguration). 1) Ist es irgendwie mit einem anderen Core möglich dich Signale um die 500 MHz darzustellen? (Außer mit einem externen LogicAnalyzer) 2) Der chipScope Block wird momentan mit einem Takt von 100 MHz getaktet. Im FPGA selbst sei der schnellste Takt nun 250 MHz (nicht in ChipScope 'rein geführt'). Die übrigen Signale sehen gut aus und Verhalten sich wie in der Simulation. Jetzt erhöhe ich den internen Takt von 250 MHZ auf 500 MHz. ChipScope wird immer noch mit 100 MHz getaktet. Die anzuzeigenden Signale liegen immernoch unter 100 MHZ wie im ersten Fall. Müsste also alles gehen. ANMERKUNG: laut Timing Analyse im Post Processing 'darf' ich die Takte verwenden. Hier gibt es keine Fehler. Teste ich es nun, sieht das Signalverhalten fehlerhaft aus. Es passt nicht zur Simulation. Daher die Frage: kann es sein, dass der maximal zulässige ChipScope Takt von 412 MHz der limitierende Takt im Gesamtsystem ist? Werden -sobald ChipScope eingebunden ist- alle schnelleren Takte (auch wenn die nicht mit dem Core verbunden sind€ heruntergetaktet? Wenn ja, kennt einer eine Abhilfe? Ich arbeite auf dem Virtex6.
ChipScopeUser schrieb: > Ist es irgendwie mit einem anderen Core möglich dich Signale um die > 500 MHz darzustellen? Wäre mir nicht bekannt. ChipScopeUser schrieb: > ChipScope wird immer noch mit 100 MHz getaktet. CS sollte dringend synchron mit den Signalen betrieben werden (selbe Taktquelle), ansonnsten sind es asynchrone Signale und müssen entsprechend behandelt/interpretiert werden. Bei einem 100Mhz ILA (der Part der die Daten aufzeichnet) werden z.b. Signale unter 10 ns nicht zuverlässig erfasst, auch bei Bussen ist die Integrität der Daten keinenfalls mehr gegeben. Heißt also: ILA synchron zur Datenquelle. Und je nach Auslastung des FPGAs, Komplexität des ILAs (Breite, Feature), etc. bezweifle ich, dass selbst 412 MHz zuverlässung arbeiten. Und leider: Ist der ILA synchron zum Design bestimmt er Fmax mit. grüße
daniel__m schrieb: > CS sollte dringend synchron mit den Signalen betrieben werden (selbe > Taktquelle), ansonnsten sind es asynchrone Signale und müssen > entsprechend behandelt/interpretiert werden. Aber das ist ja bei jedem "echten" LA auch nicht anders.
Schlumpf schrieb: > daniel__m schrieb: >> CS sollte dringend synchron mit den Signalen betrieben werden (selbe >> Taktquelle), ansonnsten sind es asynchrone Signale und müssen >> entsprechend behandelt/interpretiert werden. > > Aber das ist ja bei jedem "echten" LA auch nicht anders. ja das stimmt. Aber der Herr Nyquist redet bei asynchronen Signalen mit ... Sprich, man muss mit mind. doppelter Frequenz des Signaltakts abtasten, sonst kann dir passieren, dass du ein kurzes Signal nicht detektieren kannst.
qwerty schrieb: > ja das stimmt. Aber der Herr Nyquist redet bei asynchronen Signalen mit > ... Sprich, man muss mit mind. doppelter Frequenz des Signaltakts > abtasten, sonst kann dir passieren, dass du ein kurzes Signal nicht > detektieren kannst. Auch das ist bei einem "echten" LA nicht anders..
Das ist doch nur ein virtueller LA. Läuft voll synchron. Der kann nicht mehr, als FPGAs so üblicherweise können, als 200-300 MHz. Wenns hoch kommt.
Vielleicht musst du einfach nur die beiden Taktpfade durch ein false path constraint voneinander entkoppeln, wenn du wirklich nur Signale messen willst, die zwar aus der schnellen Taktdomäne kommen, aber mehrere Takte lang sind.
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.