Die folgenden Ausführungen zeigen, welche Parameter gemessen werden, wie sie gemessen werden und wie die Daten zur Verbesserung der Implementierungs-Produktivität verwendet werden können. Dies beinhaltet auch eine Beschreibung, wie die Daten normalisiert werden können, damit sich verschiedene Chip-Designs überhaupt miteinander vergleichen lassen.
Was beeinflusst die Implementierungs-Produktivität?
Um die richtigen Chip-Design-Parameter zur Erfassung der Implementierungs-Produktivität zu definieren, muss man sich erst einmal ein paar Gedanken darüber machen, was die Implementierungs-Produktivität beeinflusst. Bild 1 zeigt das Ergebnis einer Umfrage während eines Synopsys-Users-Group-Treffens (SNUG) in Boston. Demnach sind viele Flaschenhälse und Probleme der Implementierungs-Produktivität, allgemein ausgedrückt, auf die Entwicklungsumgebung im weitesten Sinne zurückzuführen. Die relevanten Probleme wie verteilte Entwicklung über mehrere Orte, Stellenbesetzung (Qualifikation), gleichzeitige Entwicklung des Design Flow parallel zum Chip-Design usw. sind in Bild 1 orange markiert.
Doch die angegebenen Probleme lassen sich so nicht messen. SPS hat die Probleme weiter analysiert und aufgrund seiner langjährigen Erfahrung mit Chip-Designs in relevante und messbare Parameter umgesetzt. Bild 2 zeigt eine Zusammenfassung dieser Parameter, die für die Design-Implementierungs-Produktivitätsmessung erfasst werden sollen. Diese lassen sich grundsätzlich in zwei Kategorien einteilen: zum einen in Parameter zur Erfassung der Charakteristika eines Chip-Designs und zum anderen in Parameter zur Erfassung der benötigten Ressourcen.
Bei den Design-Charakteristika wird noch weiter unterschieden. Hier gibt es einerseits Parameter, die Informationen über den kritischen Zustand („Health“) eines Chip-Designs (z.B. Total Negative Slack, Area Utilization und Power Dissipation) geben, und andererseits existieren Parameter, die Informationen über die Komplexität geben. Anhand dieser Parameter lässt sich nun die Implementierungs-Produktivität als eine Funktion der produzierten Ergebnisse – dividiert durch die dafür aufgewendete Zeit – definieren.
Dazu ein Beispiel: Bild 3 zeigt die Veränderung des Total Negative Slack (TNS) über den Verlauf eines Projektes. Das TNS nimmt kontinuierlich über die Zeit ab, und bei Erreichen des Ziels kann man mit diesem Chip-Design guten Gewissens zum Tapeout übergehen.
Anders sieht es allerdings bei dem Beispiel in Bild 4 aus. Dieses dokumentiert, dass die Resultate über einen längeren Zeitraum oszillierten – mit diesem Projekt, speziell mit der STA-Strategie, etwas nicht in Ordnung war. Es stellt sich hier die Frage, ob man dem letzten Ergebnis trauen kann, obwohl ein TNS von 0 erreicht wurde. Um die möglichen Ursachen herauszufinden, ist eine genauere Analyse notwendig.
Aufgrund der Analyse lässt sich dann eine Entscheidung treffen, wie mit dem Chip-Design weiter zu verfahren ist. Das kann zum Beispiel dazu führen, dass die STAMethodik verbessert werden muss oder einige grundsätzliche Design-Parameter korrigiert werden müssen (z.B. Reduzierung der Taktfrequenz oder Änderungen der Architektur im RTL-Code).
Wie können nun diese angesprochenen Implementierungs-Produktivitätsparameter erfasst werden, ohne dass das Chip-Design-Team mit zusätzlichem Aufwand belastet wird? Hier hat es sich herausgestellt, dass dies am besten durch Einbau in das Design Environment (Flow) zu bewerkstelligen ist. Bild 5 zeigt den prinzipiellen Aufbau, der im Synopsys Pilot Design Environment realisiert wurde.
Beim Aufruf der einzelnen Flow-Kommandos werden automatisch verschiedene Parameter bezüglich benötigter Ressourcen (CPU-Laufzeiten, Speicher und Tool-Laufzeiten), Chip-Timing, Power, physikalische Design-Daten (Utilization, DRC-Status, Anzahl der Netze, Instanzen und Pins usw.) erfasst. Die Daten werden in einer SQL-Datenbank gespeichert und können dann tabellarisch oder grafisch ausgewertet werden. Das Speichern der Daten verursacht so gut wie keine Verzögerungen bei der Ausführung der Programme.