Startseite > Halbleiter > Design > Unterschiede aufdecken

Schaltungssimulation mit LTSpice

Unterschiede aufdecken

5. August 2015, 13:25 Uhr | Von Mike Engelhardt

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

2. Methode: Sparse-Matrix-Methoden

Die Taylor-Reihe ist mehrdimensional; es gibt also eine Dimension für jeden unbekannten Spannungsknoten in der Schaltung. Bei einem analogen IC können das bis zu 100.000 unterschiedliche Spannungsknoten sein, was zu einer Leitwertmatrix von 100.000 × 100.000 oder zu 80 Milliarden Byte für Matrix-Koeffizienten mit doppelter Genauigkeit führt. Selbst moderne 64-bit-Prozessoren können nicht genügend Adressen ansprechen, um auf einen derart großen Speicher zuzugreifen. Glücklicherweise ist fast jeder Koeffizient gleich Null, sodass sie nicht gespeichert werden müssen. Sparse-Matrix-Methoden verfolgen nur jene Elemente weiter, welche ungleich Null sind. Dies erlaubt es, eine riesige Matrix in einem vergleichsweise winzigen Speicher zu lösen.

Die spärliche Belegung der Matrix ergibt sich aus der Physik realer Schaltungen. Die meisten Knoten sind nur mit einigen wenigen anderen verbunden. Selbst wenn man beispielsweise die Leitwertmatrix für eine Schaltung aufstellt, die wie ein Fischernetz mit Widerständen aussieht, ist die Matrix nahezu diagonal, weil jeder Knoten resistiv mit wenigen benachbarten Knoten verbunden ist. Reale Schaltungen haben – wie in dem vorhin genannten Beispiel – weitaus weniger Verbindungen. Der Grad der Matrix-Belegung einer großen analogen Schaltung liegt im Bereich von ppm (parts per million). Diese dünne Belegung erlaubt es, dass die Matrix mit einem heute verfügbaren Computer aufgelöst werden kann. Die Newton-Iteration von analogen Schaltungen ist ohne Sparse-Matrix-Methoden nicht möglich.

Alle Spice-Implementierungen sind sich bei den Sparse-Matrix-Methoden (Stichwort: LU-Faktorisierung) sehr ähnlich, und die meisten Spice-Implementierungen verwenden eine Bibliothek dünn belegter Matrizen; und zwar abgeleitet von einem Code, der zusammen mit dem akademischen Berkeley-Spice-Code verbreitet wird. Einige jedoch, die zumeist als schnelles Spice bezeichnet werden, versuchen dies zu verbessern, indem sie dafür eine erweiterte Sparse-Matrix-Bibliothek – zum Beispiel SuperLU [3] – verwenden.

Eine bessere Methode ist es, den Prozessor die mathematischen Berechnungen nahe der theoretischen FLOP-Grenze der darunter liegenden Hardware durchführen zu lassen. Das Problem dabei ist, dass es länger dauert, die numerischen Daten für die FPU zu erhalten, als den FLOP direkt ausführen zu lassen. Die FPU-Pipeline läuft üblicherweise leer. Letztendlich ist dies eine Konsequenz der Tatsache, dass alle Betriebssysteme eine dynamische Speicherallokation verwenden. Zu dem Zeitpunkt, wenn der Simulator geschrieben und kompiliert wird, ist der Speicherort, an dem die Matrix abgelegt wird, noch nicht bekannt. Denn der Simulator fordert erst zur Laufzeit mit dem Funktionsaufruf „malloc()“ Speicher an und erhält eine Adresse zurück, an der er die Matrix-Daten sicher abspeichern kann.

Da es menschlich unmöglich ist, jedem Matrixelement seinen eigenen Namen zu geben, werden Arrays verwendet. Das bedeutet, dass der Simulator zahlenmäßig weniger, dafür aber größere Speicherbereiche anfordert, und die einzelnen Koeffizienten werden aus der Basisadresse, die von „malloc()“ zurückgegeben wird, indiziert. Alles, was zum Zeitpunkt, zu dem der Simulator kompiliert wird, bekannt ist, ist die Adresse der Adresse der Basisadresse, ab der indiziert wird, um Matrixelemente zu erreichen. Das Auflösen dieser Adresse während der Ausführung und das Hereinholen der Daten, auf die gezeigt wird, in die FPU dauert länger als das Ausführen des FLOP selbst [4]. Idealerweise sollten die Adressen der Daten, die für die Berechnung erforderlich sind, vor dem Berechnungszyklus bekannt sein, sodass die Daten effizient abgeholt werden können und die FPU nicht auf sie warten muss.

LTSpice eliminiert den Aufwand, um die Daten zur FPU zu transferieren, mit einem Quellcode, der während der Laufzeit mit Hilfe einer „self-authoring“ Assembly-Sprache erstellt wird. Dies geschieht allerdings erst, nachdem der Matrixspeicher zugewiesen wurde und die Adressen bekannt sind, die durch den „malloc()“-Befehl zurückgegeben wurden. Dieser „late-authored“ Code kann konkrete Adressen von Matrixelementen in Übereinstimmung mit dem restlichen Code so bereinigen, dass die Daten effizient geladen werden können. Nur so hat die FPU die Möglichkeit, mit voller Pipeline zu arbeiten; allerdings erst, nachdem der Code mit dem in LTSpice integrierten Assembler und Linker erstellt und verlinkt worden ist. LTSpice ist der einzige Simulator mit „self-authoring“ Code und eingebautem Assembler sowie Linker. Diese Verfahren funktionieren bemerkenswert besser als jedes andere.