Hallo zusammen, ich benötige mal eure "hellseherischen" Fähigkeiten im Probleme erraten. Ich habe hier ein DE0-Nano, an dem ein DSP hängt der synchron zu einer 27MHz-Taktleitung über einen 8Bit-Bus, Daten bei einer Flanke an meinen FPGA sendet. Mit dem DE0-Nano wird alles korrekt verarbeitet und alles funktioniert perfekt. Da nur ca. 1% der LogikElemente verwendet werden ist das DE0-Nano natürlich "völlig überdimensioniert". Nun habe ich das DE0-Nano durch ein simpleres Breakout-Board ersetzt bzw. es ersetzen wollen. Das neue Board funktioniert mit diversen Beispielen einwandfrei und hat einen EP4CE6C22C8N (144pin QFP-Package). Der "Speed Grade" des neuen FPGA ist damit nun aber C8. Der des FPGA auf dem Nano-Board C6. Die verwendeten Pins am neuen FPGA sind nun natürlich, aufgrund dessen Bauweise, nicht mit den zuvor verwendeten identisch. Das führt beim Routing folglich auch zu anderen Ergebnissen. Die Hardware-Synthese auf dem neuen FPGA tut genau bei der Datenübernahme, zum Zeitpunkt des Flankenwechsels des Datentaktes nicht was erwartet wird. Das äußert sich dadurch, dass mein Zustandsautomat keinen Wechsel in einen Folgezustand durchführt. Interessanterweise zeigt eine Analyse per SignalTrap II das die Signalpegel dennoch zur richtigen Zeit korrekt an den Pins anliegen. Die Daten liegen übrigens nur 10ns an den Pins an. Ich verwende Altera Quartus II in der Version 12.1 SP1. Die Synthese kann ich für beide FPGAs problemlos und ohne Fehler kompilieren. Die Konfiguration vom Quartus-Projekt für die Pin und Clock und Timing-Konfigurationen habe ich bereits überprüft. Wenn ich das Datenblatt der beiden FPGAs korrekt verstanden habe bewegt sich meine Datenübertragung deutlich unter den maximal möglichen Raten des EP4CE6 bei einem C8 Speed Grade. Meine Frage ist übrigens nicht warum das nun nicht geht. Meine Frage ist eher wo ich denn ansetzen kann um das Problem korrekt zu analysieren. Oder habe ich das Datenblatt bzw. die Unterscheide zwischen den Speed Grades C6 und C8 einfach falsch interpretiert? Ich bin für jeden Tipp Dankbar! Vielen Dank! klaute
Eine denkbare Erklärung wäre, dass die Signale nicht korrekt gesampelt werden und / oder die Taktreserven seitens des eingehenden Busses nicht richtig spezifiziert sind. Damit hängt das design ein wenig in der Luft und die Korrektheit der Funktion ist vom Zufall abhängig. Da Du im zweiten Fall nämlich ein breakout nimmst, könnte infolge der Signalführung der Takt der eingehenden Daten anders verzögert sein , zudem ist das physikalische Routing im Chip ein anderes. Für weitergehende Hellsehereien müsstes Du mal etwas zu Deinen Takten, deren Lage zu den Daten und etwas zum Systetakt im FPGA erzählen. So nutzen einem die "10 ns" v.o. wenig.
Mal die Frequenz herunterdrehen bis es geht. Und von dort aus weiterdenken.
Also prinzipiell sollte weder C8 noch C6 ein Problem bei 27MHz sein. Kannst du die eingehenden Daten in FFs puffern und diese in die IO-Zellen legen? Dann wird dir Quartus sicher sagen können, ob schonmal die internen Timing-Constraints eingehalten werden (können). Und: wer liefert die 27MHz-Clock? Wenn DSP: läuft die in einen Clockeingang ins FPGA rein?
Angehängte Dateien:
-
fsm_data_sampling.png
75 KB
Vielen Dank für die schnellen Antworten! Der 27MHz-Takt wird vom DSP erzeugt und ist unveränderlich. Da weder das DE0-Nano (wenn ich mich gerade recht erinnere) noch das Breadboard mit dem EP4CE6 Clock-Eingängen ausführen, ist die Clock jeweils an einem Standard-Pin der selben IO-Bank angeschlossen, gemeinsam mit den 8Bit Daten. Zur Info habe ich einen kurzen Mitschnitt angehängt (siehe Bild). Dort ist zu sehen wie die "DATACLK" sich zeitlich verändert (die Clock vom DSP). Y sind die 8Bit Daten (die unteren 2 Bit der eigentlich 10 Bit breiten Daten werden nicht beachtet). Die dritte Zeile von Oben zeigt den "SM_READER". Dieser ist der aktuelle Zustand der FSM, welcher sind laut meiner VHDL-Implementierung ausschließlich bei fallender Flanke der DATACLK ändern kann. Als Takt für das Sampling per SignalTrap II habe ich für das Bild einen Takt aus einer 200MHz PLL verwendet. Die 200MHz PLL erhält ihren Eingangstakt durch ein 50MHz welcher auf dem Breadboard integriert ist.
Dein "clock" sieht schlimm aus. Die scheinbare Asymmetrie liegt in der Interferenz von clock und sample clock begründet und ist kein problem. Dennoch sollte man ein ungradzahliges Viefaches nehmen, als Faktor 3,5, dann ist mal die negative und mal die positive Flanke zu spät dargestellt. Was da aber vorne und hinten passiert ist kein clock, sondern Rauschen. Stimmen Deine Pegel?
Hi, das Problem ist gelöst. Es lag an verschiedenen Problemen was EMV etc. angeht. Der eine oder andere Widerstand in der Clock-Leitung , um Reflexionen zu vermindern, und ein paar Änderungen in der Hardware-Synthese - was das Timing angeht - und alles funktioniert prächtig. Hier das Projekt: http://klautesblog.blogspot.de/search/label/Autonomous%20Light%20Controller Kai
Na, dann Gratulation ob des Erfolgs dieses "Lauterbach Debuggings" :-) Was genau war jetzt das timing Problem? Mir scheint das etwas seltsam, dass dort EMV eine Rolle gespielt haben soll, in welchem Umfeld wurde das betrieben? Deine Seite scrollt bei mir übrigens elend langsam :-(
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.