Dakons blog

Haben wir uns das nicht alle schon einmal gefragt? Nun, die einfache Antwort wäre vielleicht Hardwaredesigner als ein Mittelding zwischen Bauarbeitern und Softwareentwicklern anzusehen. Da beide Gruppen sich in einem steten Wettstreit miteinander befinden den größtmöglichen Pfusch abzuliefern würde das einige Ergebnisse erklären.

Doch heutzutage gibt es für alles kleine und große Helferlein, die Fehler zu großen Teilen erkennen oder verhindern sollen. Oder es einem einfach nur ermöglichen sollen eine etwas abstrakte Sicht der Dinge (also eine Sprache) in einen Haufen logische Schaltungen umzusetzen. Bereits neulich habe ich mich über die Design-Suite von Mentor beschwert, aber was mir Modelsim (der dafür benutzte Simulator) in den letzten Tagen an Kopfzerbrechen bereitet hat das schlägt dem Fass den Boden aus.

1. zyklische Abhängigkeiten: jeder hat es schon mal gemacht, meistens ist es keine Absicht. So auch in diesem Fall. Ich hatte 2 Module die sich gegenseitig referenzierten. Es wäre nicht mal schlimm gewesen, da jeweils nur eine Funktion war, die die Deklaration eines records aus der anderen Datei kennen brauchte. Wie auch immer, jedenfalls hat es den Compiler nicht weiter gestört. Er rechnet also vor sich hin. Und da der Rechner relativ schnell war, rechnete er auch schnell vor sich hin. Ganz nebenbei bemerkte er immer mal wieder das er die Zwischenergebnisse irgendwo abspeichern musste und holte sich ein Stück neuen Speicher. Um es kurz zu machen: dieses absolut simple Problem, das selbst Turbo Pascal vor 10 Jahren sofort zu einem Compilerfehler (und damit zu einem definierten Abbruch einschließlich zugehöriger Fehlermeldung) veranlasste brachte dieses sündhaft teure Stück Software dazu meinen sämtlichen Speicher (RAM und Swap jeweils >1GB in der Maschine) und nebenbei sämtliche CPU-Zeit aufzufressen. Zum Glück waren sowohl scheduler als auch OOM-Killer an diesem Tag in guter Form und die Maschine blieb halbwegs benutzbar und es wurde nur dieser eine Prozess gekillt. Wow.
2. doppelte Zuweisung: da Hardware nun mal real ist und in der realen Welt nichts sofort passiert kann man dies bei der Simulation seiner Schaltkreise berücksichtigen. Man schreibt dann solche Kontruktionen wie:
   signal <= '0' after 1 ns;
   Ausnahmsweise ist die Syntax sogar ziemlich selbsterklärend. Nun wollte ich am Anfang einen kurzen Moment das Reset-Signal auf Null ziehen und schrieb deshalb:
   res_n <= '0';
   res_n <= '1' after 1 ns;
   Auch das machte dem Compiler keine Schwierigkeiten, er lief ordnungsgemäß durch. Der Simulator jedoch entschloss sich wieder mal Heißhunger auf meine Resourcen zu bekommen und alles aufzufressen was er bekommen konnte. Ein beherztes kill -9 entledigte mich von diesem Problem, allerdings hat es 2 Anläufe gebraucht bis ich gemerkt habe was da die Probleme gemacht hat.
3. Vektor-Zerstückelung: Man braucht es ja immer mal wieder: ich habe einen Bus und benötige nur einzelne Signale. Kein Problem. Ich habe 2 Busse mit unterschiedlichen Indizes und muss einen Teil von Bus A auf Bus B umbiegen. Sollte auch kein Problem sein. Dummerweise ist es das aber doch, denn wenn A Indizes von 63 bis 2 hat und B von 61 bis 0, dann bringt ihn das aus völlig unerklärlichen Gründen mächtig aus dem Tritt. Nein, er stürzt nicht ab und tut ansonsten auch was er soll. Nur leider kommt er auf die Idee die Signale irgendwie zu mischen wenn er die Zuweisung macht, was anschließend dazu führt das der Schaltkreis nicht mal entfernt das tut was man von ihm erwartet. Sowas zu finden dauert dann schon eine ganze Weile, weil man natürlich erst mal alles andere im Verdacht hat.
4. geänderte Dateien: ab und zu erfreut mich der Simulator mit der Warnmeldung das er zwar gemerkt hat das sich eine Datei geändert hat, er diese aber nicht neu laden würde. Ich weiß zwar nicht warum er das nicht tut, aber wenigstens ist er so freundlich das Menü und den Menüpunkt gleich mitzuliefern mit dem man das von Hand machen kann. Das Menü gibt es auch, dummerweise existiert der Menüpunkt nicht. Auch die anderen Punkte in dem Menü laden die Datei nicht neu, so das man den Simulator verlassen und neu starten darf, was dazu führt das man die Einstellungen für die ganzen Signale wieder von vorne beginnen darf. Das kann man sogar skripten, nur lohnt sich das nicht wenn ich einen Schaltkreis ein halbes Dutzend mal simulieren will.
5. Tcl-Freuden: Modelsim enthält auch einen internen Editor, mit dem man vielleicht sogar arbeiten könnte wenn er nicht so ein absolut kaputtes Stück Müll wäre. Das ganze ist irgendwie in Tcl zusammengebastelt. Wenn im Editor Zeilennummern angezeigt werden und man auf den leeren Bereich zwischen Zeilennummer und Code klickt erfreut einen das Teil zum Beispiel mit einer kryptischen Fehlermeldung über irgendwelche internen Fehler.
6. Mausgeschichten: weder bei diesem Ding noch beim Mentor Designer tut der mittlere Mausbutton das was man von ihm unter Unix erwartet, nämlich einfügen. Das Mausrad funktioniert im Editor von Mentor wie gewohnt (muss wohl ein Versehen sein), wenn man sich den Schaltplan jedoch grafisch anzeigen lässt klappt das nicht mehr. Dafür zoomt er immer auf die Mitte des Schaltplans, die Schaltkreise stellt er jedoch nach oben links ausgerichtet da, man zoomt also fast immer auf den leeren Raum.

Die ganzen kleineren Eigenheiten an die ich mich inzwischen stillschweigend gewöhnt habe will ich hier gar nicht aufführen, aber eins ist klar: selbst wenn Hardwaredesigner wesentlich sorgfältiger sind als Softwareentwickler (denen kann nichts um die Ohren fliegen) und Bauarbeiter (die müssen ja nicht selber in dem Haus wohnen), kann am Ende trotzdem nichts brauchbares dabei rauskommen solange die Entwicklungswerkzeuge in einem derartig schlechten Zustand sind.