Was beim Balanceakt LVS-Verifikation beim Chipdesign hilft

Bei Halbleiter-Technologieknoten von 10 nm und darunter nehmen Standardzellen integrierter Schaltungen nurmehr sehr wenig Fläche ein. In der Folge steigt die Designdichte im Vergleich zu früheren IC-Generationen deutlich an (Bild 1). Je komplexer die Schaltungen, umso größer die Gefahr potenzieller Verstöße gegen Designregeln. Daher ist eine gründliche physikalische Überprüfung auf fehlende oder nicht angeschlossene Elemente und sonstige während des Entwurfsprozesses auftretenden Schaltungsfehler unumgänglich.

Andererseits erfordern die knappen Zeitpläne zur Markteinführung immer kürzere Laufzeiten dieser Verifizierung, damit Entwicklerteams die Tapeout-Deadlines einhalten können. Dieses fortwährende Balancieren zwischen Präzision und Geschwindigkeit beim Verifizieren von Schaltungen führt zu einem Konflikt zweier Schlüsselaspekte des IC-Designs: Leistungsoptimierung und Debugfähigkeit. Zum einen müssen die Teams schnell überprüfen, ob die von ihnen entworfenen Schaltungen effizient funktionieren und die gewünschten Leistungskennzahlen erreichen. Zum anderen müssen sie, wenn der Verifikationsprozess Probleme in einer Schaltung erkennt, in der Lage sein, diese zu identifizieren, zu debuggen und die nötigen Änderungen umzusetzen.

Herausforderung hoch entwickelter Knoten

Das Verifizieren des Layouts im Vergleich zum Schaltplan (Layout Versus Schematic, LVS) stellt sicher, dass das endgültige Layout den Funktionsumfang der Schaltung korrekt widerspiegelt [1]. Designer verwenden die LVS-Verifikation, um eine aus dem physikalischen Layout extrahierte Netzliste mit den ursprünglichen Schaltplänen zu vergleichen und Fehler oder Abweichungen zu finden, die Leistung, Funktionen oder Zuverlässigkeit der Schaltung beeinträchtigen könnten. Bei hoch entwickelten Knoten ist es – aufgrund der Dichte und der Komplexität des Designs – schwierig, aus dem Layout eine genaue Netzliste zu extrahieren. Infolgedessen nehmen Laufzeiten und Ressourcenbedarf zu. Für LVS-Werkzeuge ergibt sich damit die Herausforderung, große Designs effizient zu verarbeiten und Ergebnisse innerhalb akzeptabler Laufzeiten zu liefern.

Eine weitere Schwierigkeit, die sich aus der Zahl von Funktionen und Zellen in neuen Entwürfen ergibt, besteht darin, Verstöße zu debuggen, ohne die Netzlisten hierarchisch verarbeiten zu können. Das Debuggen eines Verstoßes in einer Zelle, der sich 100 Mal wiederholt, erfordert ohne hierarchische Verarbeitung mit flachem LVS-Durchlauf die Behebung von 100 Verstößen. Wird der LVS dagegen hierarchisch ausgeführt, ist nur ein Fehler zu beheben anstelle von 100 (Bild 2).

Die Vergleichsphase in einem hierarchischen LVS-Durchlauf prüft, ob das extrahierte Layout und die Schaltplannetzlisten hierarchisch äquivalent sind. Für diese Auswertung wird eine erste Liste korrespondierender Zellen aus den beiden Netzlisten benötigt, die beim Aufbau dieser hierarchischen Netzlisten verwendet werden soll. Hcell ist die Standardbezeichnung für diese hierarchisch korrespondierenden Zellen. Hcells stellen die Zellen dar, die sowohl im Layout- als auch im Quelldesign existieren und (vermutlich) die gleiche Funktion erfüllen. Hcells werden als hierarchische Einheiten verglichen. Für jedes Paar Hcells wird die Layout-Hcell mit der angegebenen Quell-Hcell verglichen. Alle anderen Zellen in den beiden Netzlisten werden während des Schaltungsvergleichs auf die nächstniedrigere Zellebene erweitert.

Entwickler und/oder CAD-Teams können Hcells manuell erstellen, indem sie Zellen mit jeweils passenden Namen aus in den Quell- und Layout-Netzlisten zusammenfügen, um so umfassende Hcell-Listen für Standardzellen, Speicherzellen und größere Blöcke wie IP, Makros oder Partitionen zu erstellen. Alternativ ist das automatisierte Erstellen von Hcell-Listen mit einigen EDA-Tools möglich, zum Beispiel mit Calibre Interactive von Siemens EDA [2]. Bild 3 zeigt eine Hcell-Liste, die Paare äquivalenter Hcells aus Layout- und Quellnetzlisten enthält.

Bei der physikalischen Verifikation besteht eine der größten Herausforderungen darin, dass verschiedene SoC, Speicher und IP-Blöcke aus unterschiedlichen Quellen stammen. Toplevel-Ingenieure, die eine LVS-Verifikation vornehmen, müssen die Position eines Blocks mit LVS-Verstößen wie Kurzschlüssen, offenen Verbindungen oder fehlenden Komponenten identifizieren, damit sie diesen Block zur Fehlerbehebung an den betreffenden Block Owner zurückleiten können. Bild 4 zeigt ein Layoutdesign mit verschiedenen Speicher- und IP-Blöcken.

Einer der Hauptvorteile bei der Verwendung von Hcells in der LVS-Verifikation besteht darin, dass jeder hierarchische Block verglichen wird und Fehler mit Details zur möglichen Ursache des Verstoßes gemeldet werden, was den Debugprozess einfacher und effizienter machen kann.

Leistungs- kontra Debugfähigkeit

Die erste Phase der hierarchischen LVS-Verifikation erfordert den Aufbau einer internen hierarchischen Datenbank aus der ursprünglichen Layout-Datenbank. Je nach verwendetem LVS-Tool wird die ursprüngliche Datenbank in der Regel mit verschiedenen Algorithmen (Heuristiken) modifiziert, um während der LVS-Durchläufe eine bestmögliche Leistung zu gewährleisten. Wenn beispielsweise das Calibre-nmLVS-Tool von Siemens verwendet wird, werden bestimmte Zellplatzierungen automatisch erweitert und neue Zellen und Platzierungen erstellt. Eine automatische Erweiterung der Zellplatzierung erfolgt aus vielen Gründen, die alle dazu dienen, die Hierarchie für Leistungsalgorithmen zu optimieren. Die Nutzung der Designhierarchie ist eine bewährte Methode, um eine ausreichende Partitionierung für schnellere Verarbeitung bereitzustellen, wobei jede Partition von einem separaten Kern verarbeitet wird. Sie bietet eine hervorragende skalierbare Verarbeitung mit Tausenden von Rechenkernen [3].

Die Hcell-Liste verhindert die Zellexpansion während der Schaltungsextraktionsphase, und der hierarchische Schaltungsextraktor bewahrt alle Hcells des Layouts und erweitert sie niemals. Die Angabe von Hcells in der Schaltungsextraktionsphase stellt sicher, dass alle Hcells als Subschaltungen in der extrahierten Layoutnetzliste erhalten bleiben und als Hcells in der Vergleichsphase zur Verfügung stehen.

Eine ausgezeichnete Laufzeitleistung wird in der Regel mithilfe einer relativ kurzen Liste von Hcells erreicht. Dies erleichtert die Anwendung von Änderungen an der Designhierarchie und von Heuristiken für die Serverleistung. So können mehr Kerne verwendet und die Designhierarchie für eine bessere Leistung optimiert werden. Eine Änderung der Designhierarchie und die Erweiterung von Layoutzellen kann jedoch Probleme beim LVS-Debuggen verursachen, da erweiterte Zellen nicht verglichen und dadurch Fehler zwischen Schaltplan und Layout nicht erkannt werden. Andererseits kann die Verwendung einer großen Hcell-Liste zur Gewährleistung der bestmöglichen Debugfähigkeit die Laufzeitleistung erheblich beeinträchtigen.

Um den Widerspruch zwischen Leistungsoptimierung und Debugfähigkeit zu lösen, ist ein ganzheitlicher Ansatz erforderlich. Die Zusammenarbeit zwischen Schaltungsentwicklern, Layoutingenieuren und Verifikationsteams ist entscheidend, um ein Gleichgewicht zu erreichen, das beide Kriterien erfüllt. Das Ergebnis berücksichtigt sowohl die Designhierarchie als auch die aktuelle Sauberkeit des Designs. Es definiert einen Mindestsatz von Hcells, die während der Ausführung des hierarchischen LVS erhalten bleiben müssen, um so viel Debugunterstützung wie möglich zu bieten, ohne die Extraktions- und Vergleichslaufzeitleistung stark zu beeinträchtigen. Diesen Idealbereich frühzeitig zu erkennen ist entscheidend, insbesondere wenn die Designs unsauber sind. Eine maximale Debugfähigkeit ist essenziell, damit Ingenieure die Quellen von Designverletzungen leicht identifizieren können.

In verschiedenen Phasen des Designablaufs bietet ein Calibre-nmLVS-Dienstprogramm mehrere Optionen zur automatischen Erstellung verschiedener Hcell-Listen, die unterschiedliche Bereiche der Hierarchietiefe abdecken. Die Abstimmung zwischen Designern und CAD-Ingenieuren, basierend auf der Designhierarchie und deren Reinheitsgrad, definiert die Ebene der Hcells, die in diesen Hcell-Listen enthalten sind. Die Verwendung von mehreren Hcell-Optionen für verschiedene Durchläufe kann Designern mehr Debugptionen bieten, in Form größerer Hcell-Listen in sehr frühen Phasen, wenn Designs unsauber sind. Zudem helfen sie Designern, kürzere Durchlaufzeiten zu erzielen, indem sie später einen kleinen Satz Hcells verwenden, wenn die Entwürfe sauberer sind.

Die Abwägung zwischen Leistungsoptimierung und Debugfähigkeit bei der Schaltungsverifikation kann ein großes Dilemma für Ingenieure darstellen, die innerhalb enger Zeitpläne hochwertige Entwürfe erstellen müssen. Das Streben nach Leistungsoptimierung kann den Debugprozess erschweren – vor allem bei der Layoutverifizierung, wo mehr Hcells verwendet werden könnten, um eine bessere Hierarchiemanipulation und eine bessere Skalierbarkeit zu erreichen. Ein entscheidender Schritt auf dem Weg zu einem robusten und effizienten IC-Verifikationsprozess ist es, durch eine intelligente Auswahl von Hcell-Listen den Kompromiss zwischen Leistung und Debugfähigkeit zu erreichen. Indem Ingenieure diese Herausforderungen direkt angehen, können sie die Leistungsgrenzen verschieben und dennoch zuverlässige, debugbare Schaltungsentwürfe erreichen.

Quellen:

[1] R. Agarwal, et al.: An Insight into Layout Versus Schematic; EDN, Juli 2013, https://www.edn.com/an-insight-into-layout-versus-schematic/

[2] Calibre Design Solutions: Creating an Initial Hcell List for Calibre LVS Jobs, Using Calibre Interactive; Januar 2017, https://blogs.sw.siemens.com/calibre/23.01.2017/creating-an-initial-hcell-list-for-calibre-LVS-jobs-using-calibre-interactive

[3] Hien T. Vu, Soohong Kim, James Word, Lynn Y. Cai: A Novel Processing Platform for Post Tape-out Flows; Proc. SPIE 10587, Optical Microlithography XXXI, 105870R (20. März 2018), DOI: 10.1117/12.2297240