Geändert: 22. 8. 2007, 17:56
Jäger der verlorenen Nanosekunden
So langsam geht es dem Ende zu, deshalb gibt es jetzt ein paar neue Mitspieler. Dazu gehören diverse Tools der Firma Xilinx, die meinen VHDL-Code mal irgendwie in Hardware übersetzen sollen. Und natürlich wieder haufenweise Bugs haben, die sich vorzüglich als Zielscheibe für meine Lästereien eignen.
Fangen wir doch einfach am Anfang an. Es gibt in VHDL im groben zwei Arten von Anweisungen: solche, die sich in Hardware gießen lassen, und die anderen. Der unbedarfte Leser mag jetzt Denken, das das irgendwie blöd ist: eine Hardwarebeschreibungssprache, die sich nicht in Hardware übersetzen lässt. Nein, da stecken sogar eine ganze Menge guter Ideen dahinter. Man kann in VHDL zum Beispiel Dateien öffnen und Meldungen ausgeben, beides lässt sich natürlich nicht in Hardware bauen. Allerdings sind solche Dinge ganz furchtbar praktisch, wenn man die Hardware im Simulator laufen lässt (siehe Teil 1). Man schreibt einfach an den passenden Stellen ein hin report "hier bin ich" severity note; und schon kann man sehen wenn der Codefluss an dieser Stelle vorbeieiert.
Diese Anweisungen sind überhaupt nicht für das Synthetisieren gedacht, deshalb wunderte es mich als das Xilinx Synthesis Tool auf einmal mit der Fehlermeldung "ReportStatement not supported" verreckte. Hallo? Dann ignorier es doch einfach! Denk dir es ist ein Kommentar!
Nachdem alle derartigen Anweisungen auskommentiert waren liefen die Module so nach und nach durch. Dabei wird auch gleich ein Bericht erstellt, an welcher Stelle er meint, etwas entdeckt zu haben. So berichtet er munter über Register, Multiplexer und was er sonst noch so aus dem Hut zaubert. Ich oute mich ja jetzt vielleicht als Pedant, aber ich habe die Berichte tatsächlich grob auf Plausibilität geprüft. Manchmal entdeckte er dabei Dinge, die mir so gar nicht sinnvoll erschienen. Aber er war ja nett und sagte mir auch gleich die Nummer der Zeile dazu, in der er etwas gefunden hat. Wenn man unter der angegebenen Zeilennummer dann mitten in einem Kommentar landet fängt man aber schon an zu zweifeln. Ich weiß immer noch nicht in welcher Datei er die Zeile meint, meine Quelldateien sind es jedenfalls nicht.
Ab und zu spuckt der auch mal Ergebnisse aus, die mir so gar nicht in den Kram passen. Alle meine Module müssen mit einer Geschwindigkeit von 125 Mhz klarkommen. Wenn ein Modul dann plötzlich eine maximale Taktfrequenz von 65 Mhz hat wird es Zeit für ein bisschen Fehlersuche. Nach endlosen Stunden stellte sich heraus, das meine Berechnung für den Byte Count in einer PCI Express Completion zu lange dauert. Das muss jetzt keinem was sagen, ich erwähne das nur der Vollständigkeit halber. Jedenfalls wird dort in Abhängigkeit von zwei jeweils 4 Bit langen Bitmasken und einem 10 Bit langen Zähler berechnet, wie viele Bytes wohl in diesem Paket stecken. In der Spec von PCI Express ist das eine Tabelle von einer ganzen Seite, also nicht wirklich trivial. Ich hab einige Dinge ausprobiert und war ganz offensichtlich nicht gut genug dabei. Inzwischen habe ich eine Möglichkeit gefunden, die Berechnung in zwei Takten auszuführen ohne den Datenfluss aufzuhalten. Schwein gehabt.
Aber um gar nicht erst den Verdacht aufkommen zu lassen, die Tools wären nicht völlig belämmert: mein Problem war die Geschwindigkeit. Also stellt man die Optimierung von "Area" (verbratene Chipfläche) auf "Speed". Und damit er sich richtig Mühe gibt auch noch auf hohe Optimierung. Nun ja, als ich die Berechnung dann endlich in zwei Takten geteilt hatte machte mein Modul auf einmal einen Sprung von 75 auf 147 Mhz Maximalfrequenz.
Gut dachte ich, da ist noch viel Luft. Also sorge ich besser dafür, das außer diesem Modul auch der Rest noch in den FPGA passt. Optimierungslevel wieder auf normal zurückgedreht und wieder auf Area optimieren. Das Ergebnis erklärte mir ein Kumpel dann einfach mit "er hat jetzt nicht mehr so viel Platz, darin herumzupfuschen". Jedenfalls wurde das Modul auf einmal um noch 2 Mhz schneller(?!). Völlig Banane, aber alles. Und sowas von.
Das war der größte Bremser, also gucken wir uns doch die ganzen Dinge mal im Zusammenspiel an. Synthesis Tool sagte was von 122 Mhz für eine Kombination von 6 Teilmodulen. Nicht wirklich schlecht, auch wenn die Teilmodule laut seiner eigenen Aussage alle deutlich schneller sind. Also ließ ich das ganze durch Place&Route laufen. Das ist das nächste Tool in der Reihenfolge. Nur mit seiner Hilfe kann ich mir anschließend den Pfad durch die Logik anzeigen lassen, der die Verzögerung verursacht. Ging aber nicht. Er zeigte mir zwar einen Pfad an, der war aber irgendwie nicht das Problem. Place&Route meinte nämlich die maximale Taktzeit sei knapp über 4 ns, also am Ende 211 Mhz. Wenn die Tools leicht unterschiedliche Ergebnisse abgeben wundere ich mich ja nicht. Aber das ist ja meilenweit auseinander.
Nachdem auch das geklärt war, machte ich das einzige was in diesen Situationen immer hilft: laut Musik hören. Und weil Metallica für alles die passende Antwort hat, hier der Beginn meiner Playlist:
- St. Anger (klar, sauer bin ich)
- Frantic (rasend vor Wut, ja das kommt hin)
- Sanatarium (so kann es enden)
- Whiskey in the jar (Alkohol am Arbeitsplatz? Dafür!)