Für die Halbleiterhersteller ist das Patentrezept für die Behebung eines jeden Problems klar: Größere und schnellere FPGAs wollen verkauft sein. Größe und Komplexität von Designs auf Basis von programmierbaren Logikbausteinen haben eine Größenordnung erreicht, die man in den 1990er Jahren nicht für möglich gehalten hätte. Moderne FPGAs sind mehr als eine heterogene Anordnung aus Wertetabellen (Look-up Tables, LUTs) und Flipflops, die durch unterschiedlich lange und verschieden schnelle Routing-Ressourcen miteinander verbunden sind. Basierend auf der Erkenntnis, dass moderne FPGA-Designs in mehrere Taktbereiche unterteilt sind, eingebaute Multiply-Accumulate-Funktionen verwenden, Prozessoren enthalten und auf eine Vielzahl von Speicherressourcen angewiesen sind, wurden FPGAs eingeführt, die mit spezifischen, auf den gesamten Baustein verteilten Ressourcen für die Implementierung dieser Funktionen gerüstet sind. So sehr diese Funktionsausstattung auch zu begrüßen ist: Das Problem der Timing-Closure gewinnt zusätzlich an Brisanz. Wie am folgenden Beispiel eines RAMs deutlich wird, stellen die integrierten Funktionen selbst eine Quelle für Routing-Varianzen dar.
Angenommen, in einem Design muss die RAM-Kapazität erhöht werden, um ein erst sehr spät nachgefragtes Feature zu implementieren. Obwohl grundsätzlich genügend RAM-Ressourcen im FPGA vorhanden sind, kann es nötig sein, eine andere Art von RAM-Ressource zu verwenden (z.B. einen großen RAM-Block anstatt mehrerer dezentraler RAM-Elemente). Das Synthesetool kann die Zuordnung zum erforderlichen RAM zwar problemlos vornehmen, doch steht das geforderte Block-RAM möglicherweise nur in bestimmten Spalten des FPGAs zur Verfügung, sodass die letztendlich umgesetzte Platzierung von der ursprünglichen Planung abweicht. Kritische Signalwege müssen von und nach der Spalte verlegt werden, in der sich das neu hinzugekommene RAM befindet. Die Alternative wäre eine Neuplatzierung des Designs, damit die betreffenden Signalwege näher an das neue RAM heranrücken. In diesem Fall aber würden andere Signalpfade verlängert. Insgesamt also eine Aufgabe, die mit traditionellen Synthesetools kaum zu bewältigen ist.
Bewältigung des Problems
Ein Beispiel soll verdeutlichen, wie sich das Problem lösen lässt. Häufig bedingt die Behebung eines Timingproblems Änderungen am RTL-Code. Modifikationen, die das Timing verbessern, führen in aller Regel auch zu einer besseren Ressourcennutzung. In dem Beispiel in Bild 2 wurde Modul A neben den Modulen B und C platziert. Nachdem zur Beseitigung eines Timingproblems der RTL-Code für Modul A verändert wurde, erstreckt sich dieses Modul auf Ressourcen, die bislang von den Modulen B und C genutzt wurden. Das Resultat ist ein Dominoeffekt, denn jetzt müssen auch B und C verlagert werden. Die Signalwege verlängern sich und nicht selten entstehen neue kritische Pfade. Wohlgemerkt: An der Logik der Module B und C hat sich nichts geändert, und ein normaler Logiksynthese-Flow käme auf kein anderes Ergebnis, da die geschätzten Signallaufzeiten von B und C identisch mit jenen vor der Vergrößerung von Modul A wären. Die kausale Verknüpfung zwischen dem RTL-Code in Modul A und den neuen kritischen Signalpfaden in den Modulen B und C ist physikalischer Natur. Ebenso sind ganz allgemein die Effekte, welche die Vorhersagbarkeit von Design-Iterationen vereiteln, in aller Regel physikalisch bedingt, sodass eine echte Physical-Synthesis-Lösung Abhilfe verspricht.