Guten Tag, ich interessiere mich dafür, wie das Design eines eigenen ASICs abläuft. Ich selbst arbeite primär als Embedded-SW-Entwickler bei einer kleineren Firma. Ab und zu mache ich auch mal ein kleines FPGA-Design für Testplatinen etc. Vornweg: Natürlich habe ich ich nicht vor einen eigenen Asic zu entwickeln. Trotzdem interessiert mich ein Einblick, wie der Entwicklungsprozess eines modernen Mikrocontrolelrs digital und analog aussieht. Morderne FPGA Tools sind mittlerweile für die einfachen Sachen, die ich mache, schon richtig luxuriös. Man schreibt sein VHDL und klickt sich eventuell noch einen softcore dazu und drückt einfach auf "Mach mal" und es kommt ein bitfile raus. Klar hat man mit mehr Komplexität auch bei FPGAs mehr Aufwand mit constraining etc. Aber für meine Anwendungen ist das bisher immer sehr problemfrei. Auf der einen Seite glaube ich nicht, dass das bei einem Halbleiter so einfach geht. Aber andererseits ist es vom Prinzip ja auch nichts anderes. Man synthetisiert, bildet die Logik auf die verfügbaren Zellen ab und routet es zusammen. Komplexer, mehr Freiheitsgrade. Aber prinzipiell ähnlich. Online findet man dazu einige youtube-Videos, mit denen ich aber wenig anfangen kann. Teils in schlechtem Englisch und ohne Kontext. Also Froum finde ich viel von "edaboard". Bspw.: https://www.edaboard.com/threads/how-can-i-check-synthesis-clock.414006/ Aber das Froum bringt mich auch nicht wirklich weiter bei meinem Versuch mir einen Überblick zu verschaffen. Hat jemand hand-on Erfahrung mit dem Desing eines Halbleiters und kann da ein wenig erzählen, was man da so wie macht? Welche Tools werden verwendet? Was ist der Unterschied zum FPGA design? Analog bin ich relativ Blank. Stelle mir das vor, wie wenn man in LT-Spice einen Schaltplan zusammenbaut und dann eben simuliert.
Wir haben das mal im Studium gemacht. In früheren Semestern wurde der Chip wohl auch gefertigt, als ich dran war, seit ein paar Semestern leider nicht mehr. Die Bedingung 'ASIC entwickelt' erfülle ich damit. ;-) Allerdings weiß ich nicht mehr so viel davon. So allgemein ist die Frage aber auch sehr umfangreich zu beantworten, weil es verschiedene Entwicklungsstufen gibt. Es geht von FPGA-ähnlichen Strukturen, bei denen nur nie Verbindungen (und die Programmierung der LUTs?) kundenspezifisch hergestellt werden über vorgefertigte Designblöcke des Herstellers, die platziert und verbunden werden, bis runter auf Bauteilebene, wo wirklich die Bauteile (Transistoren, Widerstände, Kondensatoren) einzeln geplant werden. Für deine Fragen gilt damit: Kommt darauf an (welche 'Entwicklungstiefe' du betrachten willst). Das kann vom einfachen VHDL-Design bis zu hochkomplexen Aufbauten an den Grenzen der Physik alles sein.
Andi schrieb: > Natürlich habe ich ich nicht vor einen eigenen Asic zu entwickeln. .Schade eigentlich. Hunderte Firmen in China tun das, nur für Deutsche ist es Magie. > Trotzdem interessiert mich ein Einblick, wie der Entwicklungsprozess > eines modernen Mikrocontrolelrs digital und analog aussieht. Oje, siehe ST Microsystems: Man kauft ein paar IP (intellektual properties, fertig definierte Funktionseinheiten) zusammen, einen ARM Core, eine Peripherieeinheit, einen ADC, eine DMA Einheit, und 'verdrahtet' die. Hier gibt es die IP https://racyics.de/ Superprimitiv, die Lizenzkosten sind halt hoch, und oft wird unpassendes zusammengewürfelt weil nur das billig zu kriegen ist (z.B. weil man die Lizenz schon hat oder weil es die gewünschte für den Fertigungsprozess nicht gibt). Kommt halt Scheisse bei raus. Egal wenn es sich wie geschnitten Brot verkauft weil man früh am Markt war. Wenn du was als FPGA definiert hast, bevorzugt in Verilog aber auch VHDL, kann dir jemand ein ASIC draus machen. Nur der Analogteil fehlt halt. Simples Analog mit Standardzellen http://www.designinganalogchips.com/ oder deine ASICs https://www.linkedin.com/posts/jean-francois-debroux-b0977112_analog-ic-design-activity-6701215416393445376-CkW-/ Sich mal gratis ausprobieren https://fossi-foundation.org/blog/2020-06-30-skywater-pdk Hier mehr zum Thema https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.7.4
:
Bearbeitet durch User
Mir ist gerade der Fehler aufgefallen. Florian schrieb: > Es geht von FPGA-ähnlichen Strukturen, bei denen nur nie > Verbindungen (und die Programmierung der LUTs?) > kundenspezifisch hergestellt werden Es sollte "nur die Verbindungen" heißen.
> So allgemein ist die Frage aber auch sehr umfangreich zu beantworten, > weil es verschiedene Entwicklungsstufen gibt. Es geht von FPGA-ähnlichen > Strukturen, ... > über vorgefertigte > Designblöcke des Herstellers, die platziert und verbunden werden, bis > runter auf Bauteilebene, wo wirklich die Bauteile (Transistoren, > Widerstände, Kondensatoren) einzeln geplant werden. > > Für deine Fragen gilt damit: Kommt darauf an (welche 'Entwicklungstiefe' > du betrachten willst). Stichworte: "Full custom", *Sea of Gates", "Gate array", "Standard cell" https://de.wikipedia.org/wiki/Anwendungsspezifische_integrierte_Schaltung#Einteilung Am besten man fragt ein Designhouse, Asic-Fab, die stellen dann auch die Software zur Verfügung ("Cadence", "Synopsys"). In .de wendet man sich auch gerne an ein Inbstitut der Industrieforschung: * https://www.ims.fraunhofer.de/de/Geschaeftsfelder/ASICS/Leistungen.html * https://europractice-ic.com/technologies/asics/x-fab/ * https://www.elmos.com/produkte/special-projects/asic-design.html
Ich war paar Jahre in der Halbleiter-Industrie. Ich war zwar nicht direkt in den Design-Teams, habe aber sehr nah mit den Analog- und Digitaldesignern gearbeitet. Der Bereich in dem ich tätig war, war so Mixed-Signal Digital/Analog/Power. Ganz grob würde ich folgendes sagen: Analoges Design ist echt eine Welt für sich und hat nur sehr wenig mit dem zu tun, was man als normaler Elektronik/Hardware-Entwickler unter "analog" versteht. Selbst vordergründig einfache Funktionen werden in der Regel aus einem großen Sammelsurium wild verschalteter Transistoren realisiert. Wenn man da nicht täglich drinnen ist, versteht man da erstmal nur relativ wenig. Die Simulationsmodelle sind in der Regel aber sehr akkurat sodass man in der Realität später ziemlich genau das bekommt was man vorher simuliert hat. Man kann hier auch alle Randbereiche durchsimulieren bzgl. vorhersehbare Produktionsschwankungen / Temperaturen etc. Digital-Design kommt da schon eher dem gleich, was man von den FPGAs kennt. Hier kommt auch ganz normal VHDL / Verilog / System-Verilog etc zum Einsatz und simuliert das mit entsprechenden Testbenches - nur dass die Tools um ein vielfaches dämlicher zu bedienen sind. Das Layout wird dann automatisiert gemacht. Komplexe Digital-Designs werden vorher zum Teil auch mal auf FPGAs getestet. Diese Tiny-Tapeout Initiative die oben verlinkt ist zeigt das auch ganz gut: Tiny-Tapeout beschränkt sich aktuell nur auf digitale Designs. Die testen das auf FPGAs vorher und so läuft das dann auch 1:1 in dem Silizium.
Wir machen auf Arbeit full-custom Asic-Design. Sprich "alles" von selbstgebauten AD-Wandlern bis zu multi-millionen Flip-Flop Digitaldesigns auf einem Chip. https://tinytapeout.com/ -> Das ist ein extrem cooles Projekt. auf jedenfall anschauen. Denke selbst, dass etwas open-source Gedanke meiner Industrie guttun wird. die ganze Toollandschaft ist sehr "inzestiös". Andi schrieb: > Auf der einen Seite glaube ich nicht, dass das bei einem Halbleiter so > einfach geht. Aber andererseits ist es vom Prinzip ja auch nichts > anderes. Man synthetisiert, bildet die Logik auf die verfügbaren Zellen > ab und routet es zusammen. Komplexer, mehr Freiheitsgrade. Aber > prinzipiell ähnlich. Im Prinzip hast du recht. Die Schritte sind ähnlich. Aber es geht ansich schon beim RTL Design los. Seitdem ich für ASICs VHDL schreibe, haben sich meine Coding-Praktiken verändert. Früher bei FPGAs habe ich viel mehr Register (FFs) verwendet und quasi alle FSM Ausgänge etc registriert. Im FPGA kommt nach jeder LUT das enstprechende FF auch fast umsonst mit. Im Asic tendiere ich viel stärker dazu kombinatorikgräber zu bauen, wenn die Performance es zulässt. Zum einen sind die Asic-Technologien einfach schneller. Gerade, wenn man in modernen Knoten arbeitet. Bspw. habe ich eine 100 MHz Domain im Chip. Die clock-to-Q Zeit (lesen) eines SRAMs + ECC Logik + 3 kombinatorische APB Arbiter + Entwas Datenverarbeitende Logik passen da problemfrei in einen Takt. Im FPGA läuft das selbe Design "nur" mit 10 MHz. Wäre das für einen FPGA designt worden, hätte man die ein oder andere Pipeline Stufe einbauen müssen / sollen. Flip Flops sind im Asic relativ teuer. Sie verbrauchen verglichen mit den meistern Logikzellen viel Platz. Teilweise so viel wie 10-15 nand Gatter. Einen Anschluss an die Scan Kette. Ein Standard FF hat somit die Anschlüsse: D (Daten Eingang), Q (Ausgang), SE (Scan enable), SI (Scan Input), RSTn (negativer reset). Das sind fünf Connections, die geroutet werden müssen (VDD / VSS und Wannen kommen "for free"). Für jedes FF. Details zum Scan Test: https://semiengineering.com/knowledge_centers/test/scan-test-2/ Andi schrieb: > Welche Tools werden > verwendet? Grundsätzlich gibt es das de-facto Standardtool für full custom Design "Cadence Vrtusoso". Bisher ist mir das bei allen Firmen begegnet. Kombiniert mit verschidenen Dritt-tools wie bspw. Mentor calibre für DRC und LVS (layout vs. Schematic) ergibt sich daraus eine "all-in-one" IDE für alles vom Schaltplan bis hin zum fertig simulierten Chip. Andi schrieb: > Analog bin ich > relativ Blank. Stelle mir das vor, wie wenn man in LT-Spice einen > Schaltplan zusammenbaut und dann eben simuliert. Ist es im Prinzip auch. Für niederfrequente Analogschaltungen. Man fängt an seinen Schaltplan zu zeichnen. Diesen kann man dann simulieren. Die Foundry, in deren Technologie du entwickelst, wird dir ein PDK (Process Design Kit) zur Verfügung stellen mit Modellen für Transistoren, Widerstände, Kondensatoren. Wenn alles halbwegs geht, geht man zum Layout über und layoutet bis es DRC und LVS clean ist. Danach kann man eine Parasiten-Extraktion machen (PEX) bspw. mit Synopsys Star RC https://www.synopsys.com/implementation-and-signoff/signoff/starrc.html Dieses extrahierte Layout kann dann mit allen Widerstands- und Kapazitätsbelägen zwischen den Leitungen simuliert werden. Je nach Größe kann der numerische Aufwand explodieren! Digital läuft das alles etwas automatisierter. Ich persönlich arbeite mit Synopsys Tools. Cadende hat dasselbe in grün. Damit habe ich aber selbst nie gearbeitet. -> Encounter für Synthese, Innovus für PnR. Meine Toolchain: - Synthese: Design Compiler (DC / DC-NXT) https://www.synopsys.com/implementation-and-signoff/rtl-synthesis-test/design-compiler-nxt.html - Place and Route: IC-Compiler (ICC2) https://www.synopsys.com/implementation-and-signoff/physical-implementation/ic-compiler.html Seit einigen Jahren gibt Synthese und PnR auch in einem Tool für bessere Ergebnisse. - Fusion compiler (FC) https://www.synopsys.com/implementation-and-signoff/physical-implementation/fusion-compiler.html - Synopsys TetraMAX für Dft (Scan Test) - Parasiten Extraktion: Star RC - Timing STA: Synopsys Primetime https://www.synopsys.com/implementation-and-signoff/signoff/primetime.html - DRC / LVS: Synopsys ICValidator (ICV) https://www.synopsys.com/implementation-and-signoff/physical-verification.html - Redundanter DRC + LVS: Siemens (früher Mentor) Calibre: https://eda.sw.siemens.com/en-US/ic/calibre-design/physical-verification/nmdrc/#:~:text=The%20Calibre%20nmDRC%20platform%20has%20been%20adopted%20as,as%20well%20as%20its%20industry-leading%20performance%20and%20capacity. - EMIR (elektromigaration + IR-Drop (spannungsabfall) Simulation: redhawk: https://www.ansys.com/products/semiconductors/ansys-redhawk-sc - Formale Äquivalenzzprüfung (LEC) Synopsys Formality. Grundsätzlich kann keins dieser "Tools" von Haus aus irgendetwas von alleine. Das wird alles durch eigene TCL Skripte zusammengehalten. Bei kleinen RTL designs ist es oft so, dass unser RTL2GDS Flow (also RTl zu Layout. Die Layout files sind am Ende GDS files) mehr code hat, als das eigentliche Design. 100k tcl Zeilen sind da keine Seltenheit. Die grundlegenden Schritte sind: 1) Design Elaborieren: Die sourcen (RTL) und IPs (RAMs und Standardzellen etc.) werden eingelesen. RTL ist klassich Verilog, VHDL, SV. Standardzellen und andere IPs brauchen liberty (*.lib) files bzw. die binäre Repräsentation (*.db). In der Regel bekommt man für jeden Zellensatz bei jeder Corner, also Slow, typical, fast und jeder temperatur und jede Gatelänge eine Datei. bei modernen Knoten kann man dann durch die ganzen Permutationen schonmal Größenordnugn >50 Files haben. In einem Lib file steht prinzipiell für jede Zelle: - Die Größe - Die Pins und ihre Eigenschaften (Eingangskapazität etc.) - Timing-Arcs durch die Zelle - Logikfunktion (siehe function. das ist das, was der Synthese das Mapping ermöglicht) Bspw: https://users.cs.utah.edu/~elb/cadbook/color-figs/Chapter8-Char.pdf
1 | /* -------------- * |
2 | * Design : INVX1 * |
3 | * -------------- */ |
4 | cell (INVX1) {
|
5 | cell_footprint : inv; |
6 | area : 129.6; |
7 | cell_leakage_power : 0.0310651; |
8 | pin(A) {
|
9 | direction : input; |
10 | capacitance : 0.0159685; |
11 | rise_capacitance : 0.0159573; |
12 | fall_capacitance : 0.0159685; } |
13 | pin(Y) {
|
14 | direction : output; |
15 | capacitance : 0; |
16 | rise_capacitance : 0; |
17 | fall_capacitance : 0; |
18 | max_capacitance : 0.394734; |
19 | function : "(!A)"; |
20 | timing() {
|
21 | related_pin : "A"; |
22 | timing_sense : negative_unate; |
23 | cell_rise(delay_template_5x5) {
|
24 | index_1 ("0.06, 0.18, 0.42, 0.6, 1.2");
|
25 | index_2 ("0.025, 0.05, 0.1, 0.3, 0.6");
|
26 | values ( \ |
27 | "0.147955, 0.218038, 0.359898, 0.922746, 1.76604", \ |
28 | "0.224384, 0.292903, 0.430394, 0.991288, 1.83116", \ |
29 | "0.365378, 0.448722, 0.584275, 1.13597, 1.97017", \ |
30 | "0.462096, 0.551586, 0.70164, 1.24437, 2.08131", \ |
31 | "0.756459, 0.874246, 1.05713, 1.62898, 2.44989"); } |
32 | .............. |
33 | } /* end internal_power */ |
34 | } /* end Pin Y */ |
35 | } |
In der Regel gibt es diese Files in mehreren timing Modellen. NLDM (non-linear-delay-model) files sind die kleinsten, aber auch die unpräzisesten. Composite Current Source (CCS) Files sind viel detailierter, verlängern aber auch die Runtime. man kann bspw. die initiale Synthese mit NLDM Modellen machen und dann im routing auf CCS wechseln. In der Regel macht man MCMM Synthese. Sprich: Multi-Corner Multi-Mode. dafür wird den Tools jede Permutation aus Operativem Modus (funktional, scan shift, etc) mit jerder relevanten Corner (permutation aus typisch, schnell, langsam bei jeder relaevanten Temperatur) als Szenario bekanntgemacht. Das tool muss also somit 10-30 Szenarien betrachten für Power und Timing. Eckdaten: Bei uns dauert alleine das initiale Einlesen aller Standardzelllibraries für alle Corner Stunden (>100 GB an Daten). Timing Constraints sehen ähnlich aus, wie beim FPGA. Am Ende werden da für jede Corner auch SDC file rasugespuckt, die dann in der STA verwendet werden. 2) Synthese (Synopsys nennt das "compile"). Hierbei wird das Design auf die Standardzellbibliothek gemappt. Beim Fusion Compiler bzw. bei der topografischen Synthese mit DC, wird das Layout mitberücksichtigt zur Logikoptimierung. Den primitiven Ablauf kann man aber auch mit schlechteren Ergebbnissen ohne topografische Information und ohne physical Guidance machen. Dafür ist dann prinzipiell nur das LIB/DB File der Standardzelllibrary erforderlich. Die Synhtese versucht hierbei die Kostenfunktion aus Power, Area und Performance irgendwie zu optimieren. Dafür gibt es sehr viele Einstellungen und viele Fallstricke. Das Design ist nun voll gemappt. 3) Post-Synthese Schritte - Hier wird klassisch die Scan-Kette verdrahtet und die ensprechenden Testmodi verdrahtet (testenables, um alle clockgates zu aktivieren, damit ein Schieben des Testpatterns möglich ist etc). - Falls der Testcontroller nicht im RTL ist, kann er hier insertiert werden. - OCC Insertion. Falls der OCC nicht im RTL ist, können die Clock Controller hier insertiert werden. Der OCC (On Chip Clock Controller) steuert die clocks während des Scantests. In der Regel wird domainunabhängig mit einer spezifischen Schibe-Clock das Testpattern eingetaktet. Um dann transition faults zu testen, werden 2 Pulse mit funktionaler Clock-Frequenz getriggert, die das Pattern “at-speed” durch die funktionale Logik schieben. Siehe: https://vlsitutorials.com/scan-on-chip-clock-controller/ - Insertierung von Scanisolation. Während des Scan-Tests toggelt die Logik zufällig. Es ist blöd, wenn diese Signale in analogteile bspw. Plls gehen und bspw. Den Takt abdrehen. Deswegen werden Muxe an den Ein- und Ausgängen platziert, um das Design nach außen zu isolieren für den Scantest. 4) Finalisieren der Netzliste: Final wird dann noch die fertigsynthetisierte Netzliste bisschen aufbereitet und bspw Zellen entfernt, die nicht in Clocktrees sein dürfen etc. Bei einem primitiven Flow ohne topografische Information ist das Ergebnis eine Verilog-Netzliste. Diese kann nun mittels LEC Tools auf formale Äquivalenz gegenüber dem RTL getestet werden. Durch die ScanKetten insertion etc ist die Netzliste de-facto nicht gleich dem RTL. Deshalb müssen die constraints richtig gesetzt sein! 5) Layout Initialisierung Das Layouttool lädt nun die verilog Netzliste und sämtliche Corner + Modi und die entsprechenden SDC files für die constraints. Mittels eines Technologie-Files (*.tf) wird dem Tool die Technologie bekannt gemacht. Darin sind Definitionen, welche Metalllagen es gibt und wie Vias etc. auszusehen haben. Ebenso sind grundlegende DRC Regeln angegeben, wie Abstände und enclosures. Ein voller DRC Satz ist nicht enthalten. Bei modernen Technologien umfasst dieser meist zehntausende Regeln, die nur zu Runtime-Verlängerungen führen würden. Die Kunst ist, das Routing so prediktiv zu halten, dass das später entstehende Layout iterativ mit vollem Regelsatz repariert werden kann. In der Initialisierung wird der Floorplan geladen. Also die Boundary, wie das Design auszusehen hat und wo an der Kante welche Pins etc sind und wo IPs wie Speicher / PLLs etc. platziert werden. Dann werden die Standardzellen-Reihen reingescripted. Die Standardzellen haben alle oben ein VDD rail und unten ein VSS rail und können so aneinandergelayouet werden, sodass sich horizontal verlaufende VDD/VSS rails ergeben. Die Floorplan Initialisierung beinhaltet auch das Platzieren spezieller Randzellen and den Kanten und Ecken und das Insertieren von TAP Cells (Wannenkontaktierungen), um das Bulk bzw. Beim SoI Prozess das Backgate zu kontaktieren. Eventuell sind dafür spearate Power Netze notwendig. Das muss über das UPF geregelt werden welche Powernetze vorhanden sind. Im einfachen Fall hat man nur VDD/VSS und klemmt die Wannen auch auf diese Netze. Um Standardzellen richtig zu platzieren, braucht das Tool ebenfalls mindestens einen Frame-view (Also ein abbild der Zellen mit Bounding box und Angaben, wo welche Pins sind) und den Regelsatz, welche Zelle wie mit anderen platziert werden kann und wie gespiegelt werden darf, damit das Design DRC clean ist! Danach wird das Power Grid (PG) assembliert. Die meisten Foundries haben eine Referenz. Aber im Detial ist das erstmal auch ein Fulltime job: Hier wird gescripted, auf welchen Metalllagen und mit welchen Vias die Power Netze nach unten verdrahtet werden. Schematisch hier dargestellt: https://digitalsystemdesign.in/wp-content/uploads/2020/07/floorp.png Ich möchte nochmals erwähnen, dass das alles deine Einstellungen sind, die aktiv in den tools gescripted werden müssen. Zwar gibt es von den Tool-Herstellern Referenzen und Appnotes von den Foundries. Aber häufig ist hier viel Arbeit zu tun. Das Powergrid hängt nämlich auch von deinem usecase ab. Wenn man mehrere Powernetze hat ggf mit powergating wird der Prozess hier natürlich deutlich komplexer, da die voltage domains separiert werden müssen. Levelshifterzellen insertiert werden müssen etc. 6) Nachdem Der Floorplan initialisiert ist und grob abgesteckt ist, was wo hin muss, erfolgt der Platzierungsschritt. Hier optimiert das Tool die Platzierung unter Berücksichtigung der Timings bei allen Modi / Corners. In der Regel werden nun spätestens auch antenna-Dioden etc in die Netzliste gepackt und mitplatziert. Natürlich technologie-spezifisch mit TCL gescripted. https://en.wikipedia.org/wiki/Antenna_effect Vereinfacht gesagt, sind beim Fusion compiler die obigen 6 Schritte ein großer “Compile-Schritt” 7) Clock Tree Synthese (CTS) Hier werden die clocknetze geroutet und der Buffertree gebaut. Das Tool wird die Clock so routen, dass es das Timing hält, eventuell sogar Ziel FFs mit langen Pfaden aktiv nach hinten skewen, damit die Logik relaxt wird. Mindestsetup hierfür ist es, dem Tool beizubringen, welche Zellen verwendet werden dürfen (Appnotes deines Standardzellen lieferanten!!!) und Routing Regell für clocks zu definieren (Letungsdicke, Abstände, spezielle Vias etc…) 8) Routen der restlichen Logik. Nun wird der Rest geroutet (inkrementell in mehreren Durchgängen). Hierbei werden Buffer eingebaut, um Hold-Timings zu fixen und Zellen aus der Synthese “umgesized” um Pfade schnelle zu bekommen, um setup Timings zu reparieren. Dafür benötigt das Tool natürlich die Timing Daten von oben wieder und die entsprechnden TLU+ Modelle der Metalle, damit abgeschätzt werden kann, wie hoch die Widerstände und Kapazitäten etc sind. In der regel erlaubt man dem Tool hierbei die Scan-Ketten nach gewissen Regeln umzuordnen. Ebenso, muss beim Roting beachtet werden, keine Antenna-Verletzungen (siehe oben Antenna-Effekt) zu erzeugen. Dazu wechselt das Tool für den ungeübten Betrachter "ohne Not" die Metalllagen beim Routing. 9) Finalisieren des Layouts. Ist alles geroutet und soweit in Ordnung werden die Lücken zwischen den Zellen mit Filler-Zellen wie Blockkondensatoren gefüllt, damit sich ein DRC cleanes Layout ergibt. Ebenso werden die Metallagen mit Filler gefüllt. Es gibt nämlich gewisse Mindestdichten, die eingehalten werden müssen, da sonst der Metallstack nicht pozessierbar ist. Bei modernen Prozessen, die Multipatterning verwenden. Also pro Lage mehrere masken verwenden, um die optische Auflösung zu erhöhen, müssen die Metallstrukturen einer Lage auf verschiedene Masken aufgesplittet werden. Das nennt man Colorierung. https://learnvlsi.com/pd/dpt-in-physical-design/748/ Damit das überhaupt möglich ist, müssen die Layouts gewisse DRC Regeln einhalten. Dann wird final noch ein DRC + LVS check gemacht und ggf Toolgestuert bisschen rumoptimiert, bis alles DRC clean ist. LVS clean sollte es hier sein. Wenn man frisch in einer neuen technologie anfängt, sind in den ersten Test mehrere Millionen Fehler durchaus normal, bis alles richtig eingestellt ist. 10) Parasitenextraktion: Das layout wird bspw. Mit StarRC extrahiert. Es enteht ein *.spef File, dass die Kapazitäten (auch zu den Fillerstrukturen!) und Widerstandsbeläge der Leitungen beinhaltet. 10) Aus Netzliste und spef file + Timingmodellen + Constraints kann mittels Primetime ein voller STA Run gemacht werden für jeden Modus und jede Corner. Sollte das Design nicht clean sein kann primetime automatisch ein ECO (engineering change order) TCL script generieren, dass so Sachen enthält wie
1 | insert_buffer [get_pins mein_pin_name] meine_buffer_zelle, |
um das layout zu patchen. Sollte das notwendig sein wird das File reingekippt und der Flow ab Schitt 8 widerholt. Hier ist es teilweise auch durchaus notwendig, dass man manuell eingereift und Platzierungen forciert oder manuell Logikbäume umstrukturiert. 11) Ist alles fertig können die finalen Daten, wie Netzliste, SDF files für Timing Sims, Layout und Scanmodell exportiert werden. In einem analogen toplevel kann jetzt das Layout + Netzliste bspw. In Virtuoso im analogen Layout platziert werden. Wir machen das in der Regel andersrum und packen die Analogteile als “IP” mit in die digitalnetzliste und lassen den Digitalflow das komplette toplevel bauen. 12) Elektromigration + Voltage Drop Simulation. Wir nutzen Ansys Redhawk, um das feritge Layout zu simulieren. Dafür wird dem Tool gesagt, wo und wie power-eingespeist wird und das Tool rechent dann den Voltage drop aus und checkt, ob Metalle zu stark belastet werden, sodass sich druch Elektomigration probleme einstellen können. Wenn man es beim grob Powergrid vergeigt hat, bzw. das Design zu dicht ist, fängt man wieder von vorne an. Ist alles clean kann man noch Timing simulatione etc machen und irgendwann das Layout als GDS File an seine Foundry schicken. Sollten Bugs gefunden werden, während dieser Prozess läuft, passiert es oft, dass der Flow nicht abgebrochen wird, sondern die Änderung als ECO vorbereitet wird, sodass das über “insert_buffer, create_net, create_cell, etc” manuell umverdrahtet wird, da ein neues Durchlaufen der obigen Kette oft Wochen dauert. Der formale Äquivalenzcheck der feritgen Netzliste mit der synthetisierten Netzliste über ein Dritt-Tool garantiert die Korrektheit. Alle diese Schritte sind technologiespezifisch und müssen korrekt gescripted sein. Alles in allem ist "digitales Backend" ein fulltime-Job für mehrere Leute, je nach Design. Solltest du konkrete Fragen haben, die generell beantwortbar sind meldest dich einfach. Es freut mich, wenn sich jemand dafür interessiert :) Alles in allem ist es keine Magie. Aber eben ein sehr spezielles Feld, zu dem vielen der Zugang fehlt. Ich bin damals in der Uni so "reingerutscht".
:
Bearbeitet durch User
Der Vollständigkeit halber noch einen Link zu dem Flow für das weiter oben erwähnte Skywater 130nm-PDK: https://openlane.readthedocs.io/en/latest/flow_overview.html Da Opensource kann auch mal praktisch herumexperimentiert werden
Wir haben $(DAMALS) im Studium eine Einspritzsteuerung mit Lambda-Sonden-Verarbeitung auf einem Analog-Array gemacht und auch mit Nadeln unter dem Mikroskop darauf herumgemessen. Das Array hatte unterschiedliche NPNs und PNPs, Widerstände, ein paar Kondensatoren (teuer!), Polysilizium-Brücken etc und eine Metall-Lage zum Konfigurieren. Tools waren hauptsächlich Spice 2G6 auf einer Vax/11-750 und ein Grafik-Editor für die Metallisierung. Die Modelle waren recht gut. (AEG-Prozess) Für's Digitale gab es den dynamischen n-MOS-Prozess von HP, auch als Multi-Projekt-Wafer. Wir haben eine stackorientierte CPU implementiert, stark angelehnt an Andrew Tanenbaum's Experimental Machine, aber deutlich abgemagert. Tools waren Spice auf CDC Cyber-176 und ein Tischrechner von HP mit deren Digitalsimulator. Der SimuCad SILOS, den ich damals schon selbst hatte, wäre dem bestimmt nicht unterlegen gewesen. (War eine Option für die Xilinx-Suite.) Der Multi-Projekt-Wafer hat sich dann gerächt. Eine Nachbar- Arbeitsgruppe hat uns einen Metallstreifen quer über die ALU verehrt; die error checker waren damals noch nicht so gut. Damit hatte sich das Ausprobieren des Chips schon erledigt. :-( Es soll von Google übrigens einen Multi-Project-Wafer geben, so ziemlich für lau, muss aber open source sein. Alle paar Monate ist wohl ein neuer Run. Gruß, Gerhard, DK4XP
Es gibt verschiedene Sorten ASIC. Das eine sind vorgefertigte Strukturen, welche per fuse verbunden werden. Die gibt es auch in Analog. und dann gibt es custom ASIC. Da macht man den gesammten chip selbst. Je nach Komplexitaet fallen dann ein Duzend Masken an, zu 100k das Stueck. Bei einem Fehler - alles nochmals. Bedeutet extensive simulationen kommen zuerst. Man sagt, ein full custom ASIC lohne sich erst ab 100k .. 1M Stueckzahlen. Und dass auch Graphik Copozessoren erst, und lange als FPGA laufen, bevor ein ASIC in betracht gezogen wird.
Gerhard H. schrieb: > Es soll von Google übrigens einen Multi-Project-Wafer geben, so > ziemlich für lau, muss aber open source sein. Alle paar Monate > ist wohl ein neuer Run. > > Gruß, Gerhard, DK4XP Das ist leider schon lange vorbei, die letzten voll kostenlosen Google sponsored MPW waren glaubich 2022. Auch Efabless, die Firma die das MPW organisiert (eigentlich natuerlich kommerziell, ein Slot fuer 10k), ist gerade kuerzlich erst bankrott gegangen. Das TinyTapeout Projekt war noch spannend, da bekommt man einen kleinen Teil eines geteilten Chips, aber superguenstig (so 100 Euro). Die Zukunft ist da auch nur ungewiss da die eben auch auf dem Betrieb von Efabless aufgebaut haben.
M. N. schrieb: > Alles in allem ist es keine Magie. Aber eine wunderbare Beschreibung deinerseits! (Meine Kollegen designen ebenfalls ASICs, aber so geschlossen habe ich das noch nicht beschrieben gesehen.) Müsste man eigentlich in einem Artikel im Wiki aufheben für die Nachwelt.
> Aber eine wunderbare Beschreibung deinerseits! (Meine Kollegen designen > ebenfalls ASICs, aber so geschlossen habe ich das noch nicht beschrieben > gesehen.) > > Müsste man eigentlich in einem Artikel im Wiki aufheben für die > Nachwelt. Sorry, aber das Wiki hier ist eher ein finsteres Museumskeller in dem nicht mal die Putzfrau vorbeischaut. Da hat es seit Jahren Artikel zum FPGA/ASIC - Design die außer dem Ersteller keiner gelesen hat bspw.: https://www.mikrocontroller.net/articles/Xilinx_Microblaze_MCS_Workflow Wer ernsthaft an dem Thema interessiert ist, hat sich längst die Fachliteratur besorgt, meistens auch Mikrosystemtechnik o. ä. studiert und hält sich mit Konferenz-/Messebesuchen up-todate. Irgendein Amateurwiki mit Info füllen ist da vergebliche Liebesmüh und kann als zweckfreie Selbstausbeutung tituliert werden. Wenn man wirklich etwas von seiner schriftstellerischen Arbeitszeit zurück haben möchte, dann veröffentlicht man in Fachmagazinen oder hält vor Fachpublikum Präsentationen. BTDT
:
Bearbeitet durch User
Es würde diese Information trotzdem etwas besser konservieren als in einem volatilen Forenthread. Es geht ja auch nicht darum, ein Studium zu ersetzen. Bezüglich der "schriftstellerischen Tätigkeit": die hat ja M.N. eh schon geleistet.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Es würde diese Information trotzdem etwas besser konservieren als in > einem volatilen Forenthread. Ist den die mittelfristiger Entfernung dieses Forenthreads zu erwarten ? Allerdings ist ein wiki-artikel besser find- und referenzierbar als ein Forumseintrag, das spricht schon für eine Transformation zu Nachschlag-wiki. ... wenn den genügend seriöse Nachfrage besteht. > Es geht ja auch nicht darum, ein Studium zu ersetzen. Bei vielen Anfragen hier hat man aber schon den Eindruck das der Fragesteller jeden Aufwand, auch den zur eigenen Recherche vermeiden will. Und manchmal geht es wohl nur um Zeitvertreib, schreibt den nicht der TO hier "... Vornweg: Natürlich habe ich ich nicht vor einen eigenen Asic zu entwickeln. ..." > Bezüglich der "schriftstellerischen Tätigkeit": die hat ja M.N. eh schon > geleistet. Nach meiner Erfahrung bedarf es weitere Anstrengung/Zeit um einen Text in ein passendes Format für das wiki zu bringen, mindestens die Tag für Zwischenüvberschriften sollte man setzen ... dazu muss man diese erst mal kennen resp. sie erlernen. Außer man gibt sich als "Schrift-Steller" mit einer "Bleiwüste" zufrieden. https://de.wikipedia.org/wiki/Bleiw%C3%BCste
Bradward B. schrieb: > Allerdings ist ein wiki-artikel besser find- und referenzierbar als ein > Forumseintrag Genau das meinte ich.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.