Forum: FPGA, VHDL & Co. TSMC Ram Compiler

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:

ups anderer rechner, anderer benutzer :-)

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.