Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich habe ein paar Probleme mit einem VI das auf dem FPGA des CompactRIO läuft...
Das VI im Anhang funktioniert momentan. Wenn ich jedoch beispielsweise nur die Variable "Frequenz" in der While-Schleife rechts oben durch das Element "Nach Festkomma" in den Datentyp Fixedpoint umwandeln möchte kommt es beim kompilieren zu einem Fehler (Timing Error). Wenn ich dann auf den "Investigate Timing Violation" Button drücke um mir anzeigen zu lassen wo der Fehler auftritt wird eine Multiplikationsstelle in der ersten While-Schleife (die große) angezeigt....
Des weitern habe ich in jeder While-Schleife mal einen Timer eingebaut um die zu überprüfen wie lange die Berechnungen in den jeweiligen Schleifen brauchen. Dabei ist rausgekommen, dass die erste Schleife weniger als eine µSekunde braucht, die 2. Schleife ca. 1 µSekunde und die 3. Schleife (die mit den Analogausgaben) ca. 5µSekunden.
Deshalb verstehe ich nicht warum in der Schleife, die die wenigste Zeit in Anspruch nimmt ein Timing-Fehler angezeigt wird. Wobei die Änderung, die diesen Timing-Fehler auslöst in einer anderen Schleife vorgenommen wurde....
Ich hoffe irgendjemand kann mir da mal weiterhelfen... Ich habe auch schon im Internet bzw. in den LabVIEW Tutorials gelesen was man tun kann um FPGA-VI´s vom Timing her sauberer zu programmieren (siehe pipelining...), jedoch geht es mir zunächst um das Verständnis...
Erst einmal danke für die schnelle Rückmeldung!
Ich verwende ein Ni-cRio 9074 mit dem analogen Ausgangsmodul NI9263.
Ok das mit den beiden lokalen Variablen ist in diesem VI wirklich Schwachsinn... Das VI wird später noch Erweitert, dann werden diese erst benötigt...
Dass man globale Variablen für den Austausch von Werten benutzt wusste ich nicht.
Ich habe soeben folgende PDF-Datei gefunden: ftp://ftp.ni.com/pub/branches/germany/vi...w_fpga.pdf Darin steht, dass ein Timing-Error aus diesem Grund kommt: "Wenn die gesamte Abarbeitung eines Pfads mehr als einen Taktzyklus benötigt, schlägt die Kompilierung fehl."
Als Lösung dieses Problems wird das Pipelining oder die Benutzung von zeit gesteuerten Schleifen angegeben. Das werde ich morgen mal ausprobieren. Wobei ich hier die Lösung mit zeit gesteuerten Schleifen vorziehen möchte, da ich sowieso mit einer bestimmten Taktfrequenz (momentan 20kHz also einer Schrittweite von 50µs) arbeiten möchte. Also hat das FPGA theoretisch 50µs Zeit um alle Berechnungen durchzuführen, wenn es schneller ist wird halt der Rest gewartet. Das sollte ja auch kein Problem sein, da die Schleife 1 weniger als 1µs braucht...
Jetzt habe ich jedoch noch folgende Frage: In der oben genannten PDF-Datei wird bei verschiedenen Beispielen die Auslastung des FPGA angegeben. Das würde mich bei meinem Projekt auch interessieren, da ich verschiedene Lösungen für ein Problem erarbeitet habe. Kann mir vielleicht jemand sagen wie man die FPGA Auslastung ermitteln kann?
Deine Aussage mit dem Abarbeitungspfad gilt für Single Cylce Timed Loops (SCTL), die verwendest du ja gar nicht. Das kann es jetzt nicht sein. Was spukt denn die Info "Investigate Timing Violation" aus?
Dann muss ich dich gleich enttäuschen, eine 20 kHz Derived FPGA Clock wirst du beim 9074 nicht hinbekommen. Die Base-Clock ist 40 MHz, der größte mögliche Teiler ist 16, somit kommst du auf minimal 2,4 MHz.
Auslastung FPGA bezieht sich immer auf die Resourcen, diese Information bekommst du am Ende des Kompilier-Vorgangs. Wenn der Bitfile am Ende in den FPGA passt und läuft, dann ist alles gut. Im Gegensatz zu einem "normalen" Computer gibt es sowas wie CPU oder RAM Auslastung nicht.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Morgen werde ich mal einen Screenshot vom "Investigate Timing Violation" posten bei einem VI wo ein Timing-Error auftritt.
Zitat:Die Base-Clock ist 40 MHz, der größte mögliche Teiler ist 16, somit kommst du auf minimal 2,4 MHz.
Ok, dann muss ich wohl mit Pipelining arbeiten wenn es nicht anders geht...
Noch einmal zum Verständnis: Ist es so, dass das FPGA mehr Zeit zum rechnen hat wenn ich eine zeitgesteuerte Schleife mit 2,4MHz verwende? Oder habe ich hier schon einen Denkfehler?
Zitat:Auslastung FPGA bezieht sich immer auf die Resourcen, diese Information bekommst du am Ende des Kompilier-Vorgangs.
OK muss ich morgen mal beim kompilieren drauf achten!
Noch was zu deinem ersten Post Jens:
Ich hatte heute Mittag mal die beiden "unnötigen" Variablen weggelassen und alles direkt mit dem Schieberegister verbunden. Die Folge war wieder ein Timing-Error...
Morgen lade ich mal das VI hoch, dann wird die Diagnose denke ich einfacher.
(12.06.2014 17:35 )n4f3ts schrieb: Ok, dann muss ich wohl mit Pipelining arbeiten wenn es nicht anders geht...
Noch einmal zum Verständnis: Ist es so, dass das FPGA mehr Zeit zum rechnen hat wenn ich eine zeitgesteuerte Schleife mit 2,4MHz verwende? Oder habe ich hier schon einen Denkfehler?
Irgendwie ja. Du willst doch auf nur auf 20 kHz kommen. Wir reden hier immer noch vom Mega-Hertz Bereich einer SCTL.
Indirekt hast du Recht, in einer SCTL mit 20/10/5/2,5 etc Mhz kann der Compiler einen längeren Pfad im FPGA anlegen, das kann man interpretieren als FPGA hat mehr Zeit.
Versteife dich aktuell nicht so auf das Pipelining, solange du nicht die wahre Ursache für den Compile-Error herausgefunden hast. Ich hatte schon mal geschrieben, Timing-Violation macht als Fehlermeldung eigentlich keinen Sinn, da du bisher keine SCTL verwendest. Ich denke, da läuft was anderes schief.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Im Anhang habe ich jetzt mal 2 VI´s hochgeladen.
Die beiden VI´s unterscheiden sich lediglich dadurch, dass zwei lokale Variablen entfernt wurden und die Verbindung direkt zum Schieberegister durchgezogen wurde (wie es im 2. Post empfohlen wurde). Diese Version geht nicht es kommt ein Timing-Error. Die andere Version funktioniert.
Des weitern habe ich mal ein Screenshot vom "Investigate Timing Violation" gemacht:
1. die AOs bekommen ihre Daten von einem DMA-FIFO, der über einen Interrupt mit dem RT-VI synchronisiert ist
2. die Erzeugung der Waveforms wird auf dem RT-Device gerechnet und anschließend in den DMA-FIFO geschoben
Multilpikationen und Divisionen auf dem FPGA sind eher ungünstig, weil diese Operationen mehrere Clock-Cycles brauchen. Bei deinem Timing-Problem kommt vermutlich alles zusammen: du hast u.A. eine Multiplikation mit Saturation im Pfad und dann noch Zugriffe auf lokale Variablen - vermutlich mit Arbitration, das kostet alles Tics und irgendwann kommt halt das Loop-Timing nicht mehr hinterher ...
1. die AOs bekommen ihre Daten von einem DMA-FIFO, der über einen Interrupt mit dem RT-VI synchronisiert ist
2. die Erzeugung der Waveforms wird auf dem RT-Device gerechnet und anschließend in den DMA-FIFO geschoben
ok das werde ich mal versuchen, ist mein erstes Programmier-Projekt mit LabVIEW sowie mit dem CompactRIO. Dachte eigentlich nicht das das FPGA schon Problem mit solch einem kleinen Programm bekommt... Wenn ich mir vorstelle dass das erst ca. 10-20% des endgültigen Programms ist...
Zitat:Multiplikation mit Saturation
Ist der Überlaufmodus "Umbruch" günstiger für das FPGA? Wenn ja, kann ich das ja umstellen das wurde nämlich unbewusst so eingestellt...
Zitat:Zugriffe auf lokale Variablen - vermutlich mit Arbitration
Versuche ich dann auch noch auf globale Variablen umzustellen. Was ist Arbitration?
Ich habe gestern mal versucht, deine Bsp-VIs zu kompilieren. Auch ich bekomme Timing-Violations, und wenn man sich dann schrittweise durch die Fehlermeldungen durchklickt kommt man auch auf die Ursache: Das sind die "normalen" LabVIEW-Multiplikationen deiner Fixed-Point-Daten in der mittleren Schleife. Der Compiler muss diese Multiplikation inkl. Zwischenspeicherung der Aus- und Eingänge innerhalb eines Ticks erledigen, schafft das aber nicht.
Du könntest jetzt folgendes versuchen:
- Verwendung der High-Troughput Multiplikation
- Pipelining vor und nach den Multiplikationen, um dem Compiler die Möglichkeit zu geben, zusätzlich Register zur Speicherung in der Nähe der Multiplizierer anzulegen.
- Die Fixed-Point-Datenlängen abändern.
Wenn du mit den Berechnungen im FPGA bleiben willst, dann Schleife 1 & 2 zusammenlegen. Die sind aktuell nicht synchronisiert, dein per lokaler Variable weitergegebener Sinus und Cosinus passen vom Zeitablauf nicht zu Schleife 2.
--
Arbitration: Wenn du im FPGA auf eine Shared Resource zugreifst (z.B. in 2 parallelen Schleifen dieselbe lokale Variable schreibst), dann muss durch einen Schiedsrichter/Entscheider sichergestellt werden, dass das nicht aus Versehen gleichzeitig passiert. Das kostet natürlich Zeit und Resourcen im FPGA.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
