Hallo, ich arbeite gerade mit der TSMC 130nm Bibliothek und versuche mich an den ersten Schritten auf dem Weg zu einem ASIC. Jetzt benötige ich für mein Design verschiedene RAM-Blöcke, momentan habe ich aber nur die Standardzellen- und IO-Bibliothek. Welche Möglichkeiten gibt es denn jetzt an einen RAM-Compiler zu kommen und was ist dabei zu beachten bzw. zu empfehlen. Danke!
Hallo Jan, Das ist natürlich eine sehr spezialisierte Frage für eine Gruppe, die sich eher mit FPGA beschäftigt. Vielleicht sind folgende Links wenigstens ein Startpunkt: http://www.vlsitechnology.org/ http://www.mosis.com/ wenn du in der Forschung bist hilft auch vielleicht Europractice weiter http://www.europractice-ic.com/ Meine Kunden, die so etwas machen, nehmen aber meistens eher z.b. Artisan RAM IP aber das ist richtig teuer. Ich kann mir nicht vorstellen, dass es hier "Versionen zum ausprobieren gibt". Höchstens vielleicht noch unter http://www.design-reuse.com/ nachschhauen. Grüße, Charles
Also, wenn ich mich recht erinnere (130nm TSMC ist ja schon ein paar Tage her, aktuell arbeite ich eher mit 65 und 40nm) dann hat(te) TSMC eine Kooperation mit Artisan, d.h. normalerweise bekommst Du von TSMC einen RAM-Compiler von Artisan. Also prinzipiell würde ich mich da schon an TSMC selbst wenden. Die können Dir dann auch sagen, welche Compiler zu deren Prozesse passen. Auf was Du achten musst? Single- oder Dual-PortRAM, synchron, asynchron, Zugriffszeiten, Taktraten, Leistung design-reuse bietet eigentlich keine "RAM-Compiler zum ausprobieren" an. Das ist ja eigentlich nur eine Sammlung von Adressen aus dem HL-Bereich mit vielen Informationen und vor allem Kontaktadressen zu den Anbietern. Mit welchen Tools arbeitest Du denn? Also was nimmst Du zur Synthese? Wie sieht es mit Simulation bzw. STA aus? Welche Tools verwendest Du für das Layout?
Danke für die Antworten. Ich werds mal bei Artisan (bzw. jetzt ARM) und direkt bei TSMC versuchen. artisane schrieb: > Mit welchen Tools arbeitest Du denn? Also was nimmst Du zur Synthese? > Wie sieht es mit Simulation bzw. STA aus? Welche Tools verwendest Du für > das Layout? Momentan benutze ich für die Simulation VCS-MX, die Synthese läuft mit dem Cadence RTL Compiler und das P&R mit dem Cadence Encounter.
Cadence RTL Compiler und Cadence Encounter? Darf ich fragen, warum gerad Cadence und vor allem, wie komplex der Chip werden soll, sprich wieviele Instanzen da erwartet werden. Für kleinere ASICs ist Cadence ok. Da gibt es ja die VDI-Option. Aber für komplexere ASICs würde ich eher Synopsys empfehlen. Für die Syntheses sowieso, aber auch für das P&R. Oder hat Cadence ein "unschlagbares" Angebot gemacht?
artisane schrieb: > Cadence RTL Compiler und Cadence Encounter? > Darf ich fragen, warum gerad Cadence und vor allem, wie komplex der Chip > werden soll, sprich wieviele Instanzen da erwartet werden. > Für kleinere ASICs ist Cadence ok. Da gibt es ja die VDI-Option. Aber > für komplexere ASICs würde ich eher Synopsys empfehlen. Für die > Syntheses sowieso, aber auch für das P&R. Oder hat Cadence ein > "unschlagbares" Angebot gemacht? Also generell ist das mein erster Gehversuch in Richtung ASIC, daher ist mein "Beispielprojekt" mit wenigen Instanzen eher klein. Später wird das ganze aber größer, wobei ich die Komplexität noch nicht abschätzen kann. Die Cadence Software nehme ich, weil sie mir am komplettesten erscheint. Der RTL Compiler generiert nach der Synthese das Konfigurations-Template für den Encounter, so dass nur kleinere Anpassungen (Min/Max-Libs und Vdd/Vss-Netze einpflegen) benötigt werden und man direkt damit anfangen kann. Zudem sind die Analyse-Tools für Timing/Power direkt integriert. Wo genau liegt der Vorteil des Design Compilers gegenüber dem RTL Compiler? Und was wären die Synopsys Alternativen zum Encounter? Ich bin bisher davon ausgegangen, dass Cadence und Synopsys auf dem Gebiet gleichwertig sind.
smörre schrieb: > > Also generell ist das mein erster Gehversuch in Richtung ASIC, daher ist > mein "Beispielprojekt" mit wenigen Instanzen eher klein. Später wird das > ganze aber größer, wobei ich die Komplexität noch nicht abschätzen kann. > > Die Cadence Software nehme ich, weil sie mir am komplettesten erscheint. > Der RTL Compiler generiert nach der Synthese das Konfigurations-Template > für den Encounter, so dass nur kleinere Anpassungen (Min/Max-Libs und > Vdd/Vss-Netze einpflegen) benötigt werden und man direkt damit anfangen > kann. Zudem sind die Analyse-Tools für Timing/Power direkt integriert. > > Wo genau liegt der Vorteil des Design Compilers gegenüber dem RTL > Compiler? Und was wären die Synopsys Alternativen zum Encounter? Ich bin > bisher davon ausgegangen, dass Cadence und Synopsys auf dem Gebiet > gleichwertig sind. Hmmm, wo fange ich jetzt am Besten an? Also die Cadence Software ist an sich komplett, da stimme ich zu. Es gibt einen RTL-Compiler, es gibt das Layouttool, es gibt (ausser dem in Encounter implementierten) ein Extraktionstool, es gibt auch ein Tool für STA, denn das integrierte Timing-Tool ist im ersten Ansatz eher weniger SignOff-geeignet. Und die Tools für LVS und DRC, nicht der in Encounter implementierte DRC/LVS, sondern der richtige, der auf den GDS-Daten aufsetzt, sind auch vorhanden. Aber, es gehört ja noch mehr dazu: Timing-Constraints werden üblicherweise im SDC-Format geschrieben, Cadence übersetzt das dann und versteht nicht unbedingt jedes Statement oder unterstützt nicht jedes. Die Constraints für die Clocktree-Synthese müssen auch noch irgendwo herkommen. Meistens stehen die auch im SDC-File und sind normalerweise recht einfach. Aber Cadence hat da so ein eigenes, nicht unbedingt einfach zu überblickendes Format. Die Vorteile des DesignCompilers liegen darin, dass dieser Industriestandard ist, während der Cadence Compiler das vielleicht mal werden möchte. Die Timing-Constraints sind dann entsprechend im SDC-Format und werden vom Synopsys P&R Tool deutlich besser verstanden, da sie nicht übersetzt werden müssen. PrimeTime, das Synopsys STA-Tool, ist ebenfalls quasi-Industriestandard. Das P&R Tool heisst übrigens ICCompiler und beinhaltet ebenfalls Analyse-Tools für Timing und Power. ICCompiler ist allerdings, genau wie Encounter, sagen wir mal die HighEnd-Variante. Sowohl von Synopsys als auch Cadence gibt es da noch "LowEnd-Versionen". Bei Cadence ist das VDI, Virtuoso Digital Implementation genannt. Eigentlich dafür da, um richtig MixedSignal-Designs zu machen. Der Analogkollege schiebt seine Klötzchen für den Analogkram und der Digitalo drückt aufs VDI-Knöpfchen. Einer von beiden muss dann eben das entsprechende Makro (Analog oder Digital) noch bei sich einbauen. Mit einer VDI-Lizenz kann man glaube ich 40K Instanzen von RTL bis GDS-Out durchnudeln. Mit einer zweiten VDI-Lizenz kann man 80K Instanzen (nicht Gatter-Äquivalente) bearbeiten. Ab 80001 Instanz muss man dann in den sauren Apfel beissen und richtig Geld für die Tools bezahlen! Während man mit VDI noch irgendwo bei 2000 Euro pro Woche liegen kann (für die komplette Toolsuite), bekommt man nur die Encounter-Lizenz vielleicht mal für 20000 Euro pro Monat - und muss noch die Kosten für all die anderen Tools bezahlen. Bei Synopsys heisst die LowEnd-Version des P&R-Tools Astro, die ist für 130nm allemal geeignet, hat den Vorteil, dass sie nicht in der Komplexität limitiert ist, aber den Nachteil, dass es nur das P&R-Tool ist, und eben keine Toolsuite. Also für kleine Digitalprojekte oder für MixedSignal-Projekte, in denen der Digitalanteil sowieso überschaubar ist, würde ich sicherlich Cadence VDI bevorzugen. Wenn ich aber damit rechnen muss, dass die Komplexität für VDI nicht ausreicht, würde ich definitiv auf Synopsys Astro gehen. Letztendlich ist das alles eine Frage - des Geldes - der Unterstützung des EDA-Herstellers - der eigenen Vorliebe - je nachdem, welche Erfahrung man damit hat Ein Nachteil beider Tools ist meiner Meinung nach die Struktur der Datenbasen. Die Datenbasen sind bei beiden Tools recht gross. Wobei Synopsys beim Generieren bzw. Einlesen der Datenbasen deutlich schneller ist als Cadence. Ach so, und egal wie das Tool auch heissen mag, mit den "kleineren Anpassungen (Min/Max-Libs und Vdd/Vss-Netze einpflegen)" ist es keinesfalls getan. Sowohl Cadence als auch Synopsys bieten zwar einen Flow an, aber in den weingsten Fällen kommt man ohne Anpassungen damit zum Ziel. So, jetzt habe ich vermutlich viel zu viel geschrieben. Eines wollte ich allerdings noch anmerken: Ich arbeite für keinen der genannten EDA-Hersteller, auch nicht für Magma-DA oder MentorGraphics (die ebenfalls P&R-Tools herstellen). Ich habe mittlerweile lediglich sehr viele lange Jahre Erfahrung mit diesen Tools. Also falls es noch unbeantwortete Fragen geben sollte - ich bin gerne bereit, so gut es geht diese zu beantworten. Darf ich noch fragen, in welcher Ecke Deutschlands (oder Europas) Ihre Firma sitzt und welche Art von ASICs entwickelt werden sollen?
Danke für die ausführliche Antwort :-) Der Überblick über die verschiedenen Tools hat mir noch gefehlt, da das große Angebot für Einsteiger schon etwas verwirrend ist. artisane schrieb: > > Die Vorteile des DesignCompilers liegen darin, dass dieser > Industriestandard ist, während der Cadence Compiler das vielleicht mal > werden möchte. Ich habe jetzt erstmal den RTL Compiler und Design Compiler parallel laufen, so dass ich jederzeit wechseln kann. In die anderen Tools (IC Compiler, PrimeTime, Astro und Virtuoso) müsste ich mich erstmal einarbeiten, da ich bisher den SoC Encounter benutzt habe. Da wird sicherlich noch die ein oder andere Frage auftauchen. > Also für kleine Digitalprojekte oder für MixedSignal-Projekte, in denen > der Digitalanteil sowieso überschaubar ist, würde ich sicherlich Cadence > VDI bevorzugen. Wenn ich aber damit rechnen muss, dass die Komplexität > für VDI nicht ausreicht, würde ich definitiv auf Synopsys Astro gehen. Die Zielanwendung liegt im Bereich digitaler Bildsignalverarbeitung, so dass die analogen Komponenten für den ASIC vermutlich überschaubar bleiben. Die Komplexität ist schwer einzuschätzen, prinzipiell würde ich das Ganze in der goldenen Mitte ansiedeln. Ich habe bisher nur Teilkomponenten synthetisiert und liege bei etwa 300k Äquivalenzgattern. Dazu kommen noch diverse RAMs.
jan schrieb: > Ich habe jetzt erstmal den RTL Compiler und Design Compiler parallel > laufen, so dass ich jederzeit wechseln kann. Also für die "ersten Schritte auf dem Weg zu einem ASIC" ist das aber keine schlechter Anfang. jan schrieb: > Die Zielanwendung liegt im Bereich digitaler Bildsignalverarbeitung, so > dass die analogen Komponenten für den ASIC vermutlich überschaubar > bleiben. Die Komplexität ist schwer einzuschätzen, prinzipiell würde ich > das Ganze in der goldenen Mitte ansiedeln. Ich habe bisher nur > Teilkomponenten synthetisiert und liege bei etwa 300k Äquivalenzgattern. > Dazu kommen noch diverse RAMs. 300K Gatter für Teilkomponenten - das verspricht ja in Richtung 1 Mill Gates zu gehen, zzgl. RAM sind das in 130nm aber auch nicht gerade die kleinsten Chips. Und in dieser Komplexität da kosten die Tools ja auch 'ne Stange Geld, zumal weder die Synthese noch P&R innerhalb von 4 Wochen abgeschlossen sein werden. Die Sparversion von Cadence, VDI, kommt da keinesfalls mehr in Betracht, Synopsys Astro könnte eventuell noch eine Möglichkeit sein. Was die Timinganalyse angeht, da reicht sicherlich das in Cadence implementierte Tool nicht mehr aus. Bei der zu erwartenden Kantenlänge des Chips und damit auch zu erwartenden Leitungslängen sollte auch in 130nm auf jeden Fall PrimeTimeSI die erste Wahl sein, um xtalk zuverlässig zu finden und zu analysieren. Eine weitere Alternative wäre auch Magma-DA, die hatten ursprünglich mit P&R angefangen und sich dann auch den Rest, sprich Synthese, TA, Extraktion, mit ins Boot geholt. Dort heisst das aktuelle Produkt Talus (magma-da.com). Achso, und DFT-Insertion uns später noch ATPG gehören ja auch noch dazu. DFT-Insertion wird am besten mit dem Synthese-Tool gemacht. ATPG, da würde ich mich mal bei MentorGraphics umschauen, die haben da recht gute Produkte. Bildsignalverarbeitung heisst, dass da auch ein A/D- oder D/A-Wandler mit auf den Chip kommt? Und der wird ebenfalls selbst entwickelt? Und alles innerhalb der Firma? Wie gross ist da denn die Entwicklungsmannschaft? Um P&R für ein solch komplexes Projekt innerhalb eines vernünftigen Zeitrahmens zu machen, gehört aber auch eine gehörige Menge Erfahrung dazu - oder excellente Unterstützung seitens des Tool-Herstellers. Da ist Magma-DA sicherlich führend.
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.