Wie wurden kundenspezifische Chips in den Tagen vor der Einführung von FPGAs als Hardware-Emulationsgeräte entwickelt? [geschlossen]

Wir veröffentlichen immer noch die endgültige RTL (* siehe unten), die allein auf der Simulation basiert (Simulatoren von Cadence, Mentor). Alle Funktionstests werden in der RTL-Simulation abgedeckt, einige werden zu Simulationen auf Gate-Ebene befördert. Simulationen, die tagelang auf dedizierten Servern laufen, waren und sind da keine Ausnahme. Bei den meisten Subsystem-Simulationen ist es nicht ungewöhnlich, sie über Nacht laufen zu lassen und sie über das Wochenende zu babysitten.

In diesem reinen Simulationsfluss werden FPGA-Fabrics immer noch für die Pre-Silicon-Softwareentwicklung verwendet, sodass S/W oder F/W entwickelt werden können, bevor das Silizium fertig ist und in vielen Fällen sogar lange vor dem Tape-In.

Vektorsimulationen und eine unabhängige formale Äquivalenzprüfung sind immer noch notwendig, um die logische Äquivalenz zu beweisen: Wenn sich die FPGA-Ausgabe und die RTL-Simulation unterscheiden, ist nicht immer klar, welche korrekt kompiliert oder wie erwartet codiert ist.

Ohne Zweifel bieten FPGA-Simulationen viel mehr Abdeckung in viel kürzerer Zeit. Randomisierte Simulationen (Suche nach Fehlerbehandlung, Ausnahmen, Bitfehlern usw.) sind dank FPGAs endlich praktikabel.

„Tape-out“ bedeutet, die ASIC-GDSII-Dateien und andere Designspezifikationen an eine Foundry zu senden, um mit dem Herstellungsprozess zu beginnen. Historisch gesehen wurde GDSII vor FTP und Hochgeschwindigkeitsinternet auf einem Magnetband gespeichert und das Band wurde an die Foundry geschickt.

„Tape-in“ ist unser Kult-Jargon für die endgültige Veröffentlichung der RTL und andere Designinformationen, damit das Backend-Team mit der endgültigen Synthese und dem Layout / Ort & Route beginnen kann. Für Algorithmusteam und RTL-Coder & -Verifikationsteams ist dieses „Tape-in“-Zieldatum die Markierung im Kalender, um die herum alle Arbeiten, Überstunden und Urlaube geplant werden. Es ist auch das Datum, bis zu dem alle kritischen Überprüfungen und die meisten anderen Überprüfungen abgeschlossen sein müssen.

Das Tape-In kann eine unternehmensinterne Angelegenheit sein, die eine Übergabe zwischen verschiedenen Abteilungen oder eine Übergabe an einen externen (Sub-) Auftragnehmer beinhaltet.

Obwohl das Design zu diesem Zeitpunkt ziemlich endgültig und veröffentlicht ist, wird die Überprüfung nach dem Tape-In noch fortgesetzt, und alle gefundenen Probleme werden gesichtet. Die Vorgehensweise hängt davon ab, wie weit das Backend-Team ist: (1) das Problem wird behoben und die RTL überarbeitet (auch bekannt als „Re-Spinning the RTL“), (2) das Design wird vom Backend mithilfe von Spare gepatcht Speicherplatz, Ersatz-Logikzellen und Ersatz-Flip-Flops, die absichtlich für diesen Zweck platziert und verteilt werden, oder (3) das Problem wird als bekannter Fehler zurückgestellt, durch die Dokumentation getragen, und der Designer wird für den Rest seiner kurzen Karriere beschämt (so es fühlt sich...).

Dann gibt es die Probleme, von denen wir noch nichts wissen. Die Verwendung von FPGAs hat dazu beigetragen, diese Lücke zu schließen, da wir nicht nur viel mehr Tests durchführen und die RTL für das FPGA schnell neu drehen können, sondern auch die Firmware auf einem SoC-Kern oder einem selbstgebauten Softcore-Prozessor ausführen können Hardwarebusse und Schnittstellen.

Vor der Verifikation mit FPGA war die Komplexität der Hardware begrenzt, die Verifikationsabdeckung war geringer, und man brauchte mehr Re-spins des ASIC, um zu einem akzeptabel funktionierenden Silizium zu gelangen.

Je komplexer die SoC-Architektur (DDR, CPU, Logik, Peripheriegeräte) ist, desto größer wird natürlich die Lücke zwischen der FPGA-RTL und der ASIC-RTL, und dedizierte FPGA-Teams werden die RTL ändern, um sie dem Zielemulationsgerät zuzuordnen.

Alle Patches müssen verifiziert werden, und dafür verwenden wir Gate-Level-Simulationen (sehr langsam) und Netzlisten-Audits (sehr mühsame manuelle Arbeit). Obwohl die RTL mit der Netzliste übereinstimmt, basiert jede weitere FPGA-Verifizierung des Designs auf RTL und nicht auf der Netzliste und wird als "Post-Layout"-Verifizierung bezeichnet.

Achtung: Die Bedeutung des Jargons kann je nach Unternehmen und Region leicht variieren, ist aber im Allgemeinen gut aufeinander abgestimmt.

(*) Zur Bedeutung von "RTL": Sie beschreiben Ihre Logikschaltungen mit einer Hardware-Designsprache (HDL) wie Verilog oder VHDL. RTL (Register Transfer Level) ist eine spezifische enge Art, Ihre Schaltung als Schritte kombinatorischer Berechnungen / Funktionen (und / oder Nachschlagetabellen usw.) und Speicherfunktionen (Flip-Flops, Speicher) zu beschreiben. Sie verwenden eine HDL, um diese Beschreibung zu erreichen. Ein HDL kann es auch auf andere ergänzende Weise beschreiben, z. B. auf Verhaltensebene und auf Gate-Ebene.

Ihren Code "auszuführen" bedeutet, die Beschreibung zu simulieren und zu bestätigen, dass die Schaltung, die sie impliziert, das tut, was Sie erwarten. Je größer die Codebasis wird, desto mehr CPU-Zyklen sind auf Ihrem Laptop oder Server erforderlich, um zu simulieren, was passiert, selbst bei einfachen Ereignissen . Aus diesem Grund ist das Mapping der RTL für einen ASIC zuerst auf ein FPGA zur Verifizierung eine natürliche und attraktive Wahl für immer größere Designs.

Es wurden Simulationen durchgeführt. Designer verwendeten SPICE sowie verschiedene, oft proprietäre Logiksimulatoren.

Man sollte nicht glauben, dass jeder Chip bei der ersten Herstellung perfekt funktioniert. Diese Designtools sind nicht perfekt, und eine FPGA-Emulation ist es auch nicht. Das Debuggen des ersten Siliziums ist ein Übergangsritus für VLSI-Designer.

TTL-Lash-Ups, Funktionssimulatoren, Logiksimulatoren und große Budgets für Minicomputer zum Ausführen dieser Dinge waren die Norm, bevor FPGA-Beschleunigung und Prototyping eine Sache waren.

Die Einführung von FPGAs Mitte/Ende der 1980er-Jahre änderte zunächst nicht viel. Frühe FPGA-Beschleuniger (z. B. Quickturn und seine Konkurrenten) waren ziemlich teuer. Für das ASIC-Prototyping waren die FPGAs der ersten Generation noch zu langsam, schwer zu bedienen und nicht dicht genug.

(mehr hier: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413 )

In der Zwischenzeit wurden Workstations und Server viel schneller und billiger, sodass es sinnvoller war, das F&E-Geld für immer schnellere Simulationsmaschinen auszugeben.

Bis dahin waren HDLs wie VHDL und Verilog (sowie proprietäre Inhouse-Lösungen) als Designmethode der Wahl etabliert. Infolgedessen geriet MSI/SSI-Prototyping in Ungnade, da es auf Blöcke beschränkt war, die mit hoher Geschwindigkeit laufen mussten, wie z. B. Mixed-Signal-I/O- oder SERDES-Controller (und selbst dann wurden und werden kleine Testchips verwendet). dies zur Validierung der Designs, da diese Blöcke sehr prozessabhängig sind.)

Mit der Zeit wurden FPGAs dichter, schneller und einfacher zu routen; Ihre Tools wurden besser (insbesondere Synthesetools von Drittanbietern wie Synplify); Ihre I/Os wurden flexibler, zahlreicher und nützlicher, und Multi-FPGA-Partitionierungstechniken wurden aufgrund der verbesserten I/Os für das Prototyping großer Designs besser handhabbar. Dies machte sie nicht nur nützlicher für die Beschleunigung, sondern auch kostengünstiger für das Prototyping.

Dennoch gibt es das Rätsel der ASIC- vs. FPGA-Implementierung: Modellieren Sie die ASIC-Logik Gatter für Gatter oder synthetisieren Sie speziell für FPGA neu? Die Antwort lag in verbesserten Synthese- und Validierungsstrategien, die ein größeres Vertrauen in das FPGA-Modell schafften, obwohl sich seine Low-Level-Implementierung stark von der ASIC-Standardzelle unterscheidet. Daher könnte eine FPGA-optimierte Version für das Prototyping verwendet werden, die im Vergleich zu einem Modell auf Gate-Ebene eine verbesserte Geschwindigkeit und Dichte bietet, während gleichzeitig das Vertrauen aufrechterhalten wird, dass sich die auf ASIC ausgerichtete Synthese genauso verhalten wird.