News Bis Ende Januar: Altera-Verkauf durch Intel hat einen möglichen Zeitplan

latiose88 schrieb:
wenn die das schon verlassen haben,ist das ja kein gutes zeichen.Die haben das sinkende Schiff verlassen,bevor es ganz absaufen tut.
Wenn also Intel den schweren Anker (Altera) nicht los wird,zieht es den ganzen laden mit in den den Abgrund.
Ich weiß nicht ob Du Dich auf meinen Post beziehst. Ich war vielleicht nicht klar genug.

Altera ist kein schwerer Anker. Altera zieht Intel nicht in den Abgrund. Aber ein Verkauf wäre die letzte Möglichkeit Altera zu retten und würde Intel Cash bringen. Cash, den Intel für die eigentliche Baustelle braucht.

Die eigentliche Bausstelle ist die Halbleiterfertigung, die vom Erfolgsgaranten zum Problemkind mutierte. Intel hat ein zu kleines Wafervolumen um damit eine State of the Art Halbleiterfertigung aufrecht erhalten zu können. Hier haben sich die immer weiter steigenden Kosten für Prozessentwicklung und Aussrüstung und die einbrechenden Margen

Das Problem für Intel ist, dass Intel diese Chipfertigung nicht verkaufen kann. Dieser Weg ist spätestens seit dem Ausstieg von AMD verbaut.

Pat Gelsinger hat einen sehr riskanten Weg beschritten das Problem zu lösen. Er wollte erst Mal 100 Milliarden USD*) in das Geschäft hineinpumpen, so dass es konkurrenzfähig wird. Der alte CFO wollte den Weg nicht mitgehen und ging in den Ruhestand.

Konkurrenzfähig was den Prozess in Punkto PPA anbelangt, ist dabei die leichteste Übung. Schwieriger wird es in Punkto Kosten und noch viel schwieriger in Punkto PDK und IP.

Intel hat das fatale Problem, dass die IFS praktisch keine Kunden für 14 nm Intel 7 und Intel 3 gewinnen konnte. Erst bei 18A scheint es größeres Interesse an Testchips zu geben.

*) keine exakte Zahl, aber Größenordnung

stefan92x schrieb:
Schon 14nm hatte Probleme.
14 nm war AFAIK ein halbes Jahr verspätet.

Und sobald 14 nm verfügbar war, hatte Intel einen Vorsprung von 1 1/2 Generation auf TSMC und Samsung.

Was beide mit den Namen ihrer Prozesse vertuschen wollten. Samsungs 14 nm und TSMCs 16 nm waren FinFET mit mit 20 nm. Also die Konkurrenten zu Intel 22 nm Prozess.
stefan92x schrieb:
Und die Kernentwicklung kann man bei Intel nicht davon trennen,
Das kann man nie trennen. Der Prozesses legt mit seinen Libs die Grenzen des möglichen fest.

Insofern ist die Entwicklung der CPU-Kerne bei Intel mit den 10 nm Fiasko zusätzlich belastet worden.
stefan92x schrieb:
da sie eben ganz bewusst Architekturen an Prozesse gebunden haben,
Man kann Architektur und Prozess komplett nicht voneinander trennen. Je moderner der Prozess, desto höher das Transistorbudget, dass für die Architektur verfügbar ist.
stefan92x schrieb:
was ja auch Teil des Problems war.
Klar war dies ab 2017/2018 für Intel ein Problem. Aber bis 2015 war ein entscheidender Vorteil für Intel. Und zwar doppelt.
  1. Intel war bis 14 nm immer früher als die Konkurrenz und Foundries dran.
  2. Intel hatte immer Prozesse. die auf die Anforderungen der CPUs zugeschnitten waren. Davon haben die Intel CPUs massiv profitiert.
Dass Intel bei den CPU (Client und Server) eine dominierende Stellung erreichen konnte, wäre IMO ohne die eigene Halbleiterfertigung nicht möglich geworden.

Da meine ich nicht nur AMD, sondern auch oder vor allem IBM, Motorola, Sun, RISC, MIPS und HP.

Zen musste mit dem Rückstand von einer Prozessgeneration gegen Kaby Lake antreten.
Erst mit Zen 2 ist AMD durch 7 nm an Intel vorbei gezogen.
Ergänzung ()

Es wurde gegen den Vorstand und Board von Intel eine Klage eingereicht:
https://storage.courtlistener.com/recap/gov.uscourts.cand.441318/gov.uscourts.cand.441318.1.0.pdf

Noch etwas was Intel nicht gebrauchen kann.
 
Zuletzt bearbeitet:
ETI1120 schrieb:
14 nm war AFAIK ein halbes Jahr verspätet.
Und als es verfügbar war, hatte es Taktprobleme. Es gab quasi keine Broadwell-Desktopprozessoren, weil sie langsamer takteten als Haswell in 22nm. Das war so von Intel nicht vorgesehen und hat viel dazu beigetragen, wieso in den Jahren so kleine Schritte in der Leistungsspitze gemacht wurden.
ETI1120 schrieb:
Und sobald 14 nm verfügbar war, hatte Intel einen Vorsprung von 1 1/2 Generation auf TSMC und Samsung.
Was zwar richtig ist, insbesondere in Sachen Effizienz (weshalb es Broadwell ja hauptsächlich in Mobil-Chips gab, bei denen das Taktproblem weniger relevant war), aber nichts daran ändert, dass Intel da angefangen hat, seine Entwicklungsziele zu verfehlen. Natürlich weit weniger dramatisch als später, aber an dieser Stelle ist das Tick-Tock-Modell halt gestorben. Seitdem hat es Intel bei großen Fertigungssprüngen nicht mehr geschafft, seinen eigenen ausoptimierten Vorgängerprozess zu schlagen, und dann teils über mehrere Generationen nicht.

Broadwell kam nicht in den Desktop.
Cannon Lake starb komplett.
Ice Lake kam nicht in den Desktop (bzw nur als Backport Rocket Lake)
Tiger Lake kam nicht in den Desktop (3 Generationen 10nm!)
Meteor Lake kam nicht in den Desktop (Intel 3)
ETI1120 schrieb:
Man kann Architektur und Prozess komplett nicht voneinander trennen. Je moderner der Prozess, desto höher das Transistorbudget, dass für die Architektur verfügbar ist.
Ist natürlich richtig, aber bei Intel war die Bindung von Produkt und Prozess aneinander halt deutlich stärker als bei denen, die auf TSMC gesetzt haben.
ETI1120 schrieb:
Dass Intel bei den CPU (Client und Server) eine dominierende Stellung erreichen konnte, wäre IMO ohne die eigene Halbleiterfertigung nicht möglich geworden.
Ich glaube, das hat auch keiner bestritten. Die Frage ist halt nur gewesen, ob Intel bewusst faul geworden ist, oder ob sie einfach wirklich Fehler gemacht haben. Und wenn ich mir Intels Roadmaps und deren Umsetzung aus den Jahren anschaue, dann sehe ich keine fehlende Ambition in den Roadmaps (also belege für "sie waren so langsam, weil sie es nicht nötig hatten) sondern stattdessen viel Scheitern in der Umsetzung der Roadmaps. Und das beginnt eben sichtbar mit der Vorstellung von Broadwell Ende 2014, also genau drei Jahre nach AMDs Bulldozer. Das ist zu wenig Zeit, um sich bewusst auf die faule Haut gelegt zu haben, weil AMD sich selbst ins Aus geschossen hätte.
 
  • Gefällt mir
Reaktionen: PascalFtr
stefan92x schrieb:
Ist natürlich richtig, aber bei Intel war die Bindung von Produkt und Prozess aneinander halt deutlich stärker als bei denen, die auf TSMC gesetzt haben.
Die Bindung ist genau diesselbe. Und deshalb ist es TSMC auch so wichtig, dass die Kunden sich auf die Roadmap von TSMC verlassen können.
 
stefan92x schrieb:
Ich glaube, das hat auch keiner bestritten.
Es wird meist ignoriert.
stefan92x schrieb:
Die Frage ist halt nur gewesen, ob Intel bewusst faul geworden ist, oder ob sie einfach wirklich Fehler gemacht haben.
Frei Nach Daniel Nenni: Wer keine Fehler macht, hat sich nicht genug angestrengt. Das Problem sind meistens nicht die Fehler an sich, sondern wie man damit umgeht.*)

In den letzten 20 Jahren gab es bei Intel ständige Strategiewechsel und durchweg "bad execution". Auf dem Client- und dem Servermarkt konnte Intel dank des Fertigungsvorsprungs die Position ausbauen. AMD hat zusätzlich mitgeholfen in dem AMD K9 eingestellt hat, bei K10 einen Bug eingebaut hat und K11 (Bulldozer) komplett versemmelt hat. Die RISC-Architekturen haben sich nach und nach aus dem Servermarkt verabschiedet. Die letzte überlebende klassische RISC-Architectur ist Power.

Intel hat es nie weh getan, wenn bei einem Richtungswechsel Mal wieder mehrere Milliarden USD in den Wind geschrieben wurden. Und mit den Milliarden gingen freiwillig oder unfreiwillig viele guten Leute.

Den Embedded Markt hat Intel bis auf ein paar Nischen Arm überlassen. Alle Versuche in neuen Märkten Fuss zu fassen sind gescheitert. Beim Mobilphonemarkt gab es einen Versuch. Das war es dann.

Dass Intel jetzt auch noch die Battleimage Generation bringt, ist total untypisch für Intel. Nach dem Muster der letzten 20 Jahre wären die Desktop-GPUs nach der Alchemist Generation eingestampft worden.


*)Die japanischen Autobauer haben Anfang der 1980er Jahre sich beim Bau der neuen Motorenfabriken falsch entschieden. Sie haben angesichts der 2. Ölkrise ausschließlich auf 4-Zylindermotoren gesetzt. Als die Ölkrise vorbei war und wieder leistungsstarke Motoren nachgefragt wurden, konnten die japanischen Autobauer nur 4-Zylindermotoren anbieten. Also haben sie alles getan um aus diesen kleinen Motoren mehr Leistung herauszukitzeln. Sie waren dabei so erfolgreich, dass sie von den Kunden in den USA wegen hier kleinen, leistungsstarken Motoren als technisch überlegen angesehen wurden.
 
  • Gefällt mir
Reaktionen: stefan92x
TorenAltair schrieb:
Bisher wurde doch von den Chipgrössen immer propagiert, dass die Integration von FPGAs in ASICs der grosse kommende Sprung sein soll.

Ja, nur habe ich das noch nie verstanden. Mir scheint, FPGAs sind grundsaetzlich Nische: Immer x-mal langsamer und y-mal groesser als das gleiche als ASIC. Wobei x>10 ist, und y auch recht betraechtlich, aber dafuer habe ich keine Zahl. Also wenn man die Stueckzahlen fuer ASIC hat, verwendet man kein FPGA. Wenn man die Performance von ASIC braucht, verwendet man kein FPGA. Wenn eine Softwareloesung weniger als x-fach langsamer ist als ein ASIC, verwendet man keinen FPGA. Wofuer FPGA gut ist, ist fuer Prototypen, wo FPGA Vorteile in der Zeit bis zum fertigen Produkt hat, die Stueckzahlen fuer ASIC zu gering sind, und man mit der Langsamkeit und den Kosten leben kann.

Aber Integration von ASIC und FPGA? Wozu?
 
FPGA sind halt langsamer als ASIC, aber schneller als Software. Und wie Software programmierbar. Wenn man also eine Anwendung hat, die man gerne in Hardware gießen würde, aber von der man weiß, dass man sie aktualisieren muss, dann sind FPGA eine Option.
 
  • Gefällt mir
Reaktionen: ETI1120
stefan92x schrieb:
FPGA sind halt langsamer als ASIC, aber schneller als Software.

Ob ein FPGA schneller ist als Software, haengt sehr von der Anwendung ab. Z.B. sind funktionale Architektursimulatoren (wie Rosetta/Rosetta2 auf MacOS) oft nicht viel langsamer als der Kern (also ASIC), auf dem sie laufen, und damit auf jeden Fall schneller als das gleiche in FPGA. Im Fall von RISC-V ist Softwareemulation auf einem schnellen Prozessor derzeit die schnellste Art, Programme dieser Architektur auszufuehren (weil auch die ASICs fuer diese Architektur noch nicht besonders schnell sind).

Und wenn man sich die Sachen anschaut, wo Software nicht so toll ist, z.B. diverse Krypto-Algorithmen oder decoding und encoding fuer Video oder Audio, da werden die populaeren Algorithmen nach ein paar Jahren in ASICs gegossen. Am Ende bleibt fuer FPGA nur die Nische: Prototypen (wo's auf die Aenderbarkeit ankommt, wie Du richtig schreibst) und Sachen, die geringe Stueckzahlen haben.
 
Hast Du Dir jemals die Produktseiten von Altera oder AMD Embedded angesehen?

Das klassische FPGA als einzelner Chip ist nur noch ein Teil des Angebots. Altera und AMD bieten SoCs an, in denen das FPGA von CPU-Kernen und anderen Funktionsblöcken umgeben ist. Dabei gibt es je nach Anwendungsgebiet unterschiedliche Zusammenstellungen von Funktionsblöcken. Natürlich werden SoCs angeboten die FPGA, DSPs und Video-De/Encoder vereinen.

Das ist Versal AI Edge Series Gen 2, das AMD im April 2024 angekündigt hat und Ende 2025 in HVM geht:
1734866920305.png

https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal/gen2/ai-edge-series.html

Dabei sind die LUTs der FPGA-Anteil.

Bei Altera heißen solche SoCs z. B. Agilex, aber ich habe dort auf die Schnelle kein so aussagekräftiges Blockdiagramm gefunden.

Die eigentliche Konkurrenz für "FPGAs" sind AFAIU nicht ASICs, sondern Standard ICs, die es den Kunden ermöglichen dasselbe System zu implementieren. Diese Standard ICs benötigen weniger Chipfläche als ein SoC mit FPGAs. Flexibilität hat immer einen Preis.

FPGAs und adaptive SoCs (wie es AMD nennt) sind eigentlich per Definition keine Massenware. FPGAs und adaptive SoCs haben sich trotzdem im Markt etabliert. Und da die Systeme immer komplexer werden gibt es immer neue Anwendungsfälle für adaptive SoCs. Subara hat den Versal AI Edge Series Gen 2 als Basis für ihr nächstes Sicht basiertes ADAS gewählt. Für die Serie, nicht für als Prototyp.

Dein Beispiel mit Roseta hinkt. Ein Arm Kern ist per Definition kein ASIC, sondern ein Prozessor. Arm hat beim Design der ISA dafür gesorgt, dass das emulieren von X86 nicht übermäßig schwer ist.
 
ETI1120 schrieb:
Die eigentliche Konkurrenz für "FPGAs" sind AFAIU nicht ASICs, sondern Standard ICs, die es den Kunden ermöglichen dasselbe System zu implementieren.

Hast Du da ein Beispiel? Warum sollte das so sein? Bei einer gegebenen Anwendung scheint die Entwicklung Software->(FPGA)->ASIC mit steigender Nachfrage recht offensichtlich, wobei der FPGA-Schritt nur kommt, wenn Software fuer diese Anwendung schlechter ist.

Dein Beispiel mit Roseta hinkt. Ein Arm Kern ist per Definition kein ASIC, sondern ein Prozessor.

Ich war da recht frei in der Verwendung des Begriffs ASIC fuer alle hardware, die nicht field-programmable ist (ausser ueber Software). Die Unterscheidung zwischen FPGA und nicht-FPGA ist recht einfach, waehrend ich fuer Deine Unterscheidung zwischen ASIC, Standard IC, und Prozessoren keine so klaren Kriterien kenne.

Arm hat beim Design der ISA dafür gesorgt, dass das emulieren von X86 nicht übermäßig schwer ist.

Davon habe ich noch nichts bemerkt. Im Gegenteil, Apple hat extra ein flag eingebaut, um TSO (total store order) aufzudrehen, was fuer die Simulation von IA32 und AMD64 wichtig ist, waehrend ARM so ein Flag nicht vorsieht.
 
Deine Einschätzung, dass mit einem FPGA nur geringe Geschwindigkeitsgewinne gegenüber einem System mit Prozessor möglich sind, trifft nicht zu.

AFAIU ist Geschwindigkeit im Vergleich zu Prozessoren nur ein Aspekt der für FPGAs spricht. Prozessoren sind komplexe Hardware die eigene Komplikationen mit sich bringen.

mae schrieb:
Ich war da recht frei in der Verwendung des Begriffs ASIC fuer alle hardware, die nicht field-programmable ist (ausser ueber Software).
Application Specific Integrated Circuit bedeutet nun Mal Integrierte Schaltungen die Speziell für eine Anwendung entwickelt wurden. D. h. man hat die Funktionen fest im Silizium implementiert.

mae schrieb:
Die Unterscheidung zwischen FPGA und nicht-FPGA ist recht einfach,
Deine Unterscheidung ist irrelevant, weil Du damit auch Prozessoren unter ASIC einordnest. Prozessoren sind per definition keine ASIC, weil sie dank der Software nicht nur für eine einzige Anwendung entworfen wurden sondern universell einsetzbar sind.
mae schrieb:
waehrend ich fuer Deine Unterscheidung
ASIC stand Mal für eine Produktkategorie, die heute praktisch verschwunden ist. Sie wurden unter anderem durch FPGAs obsolet gemacht.

Application Specific steht heute für jede Funktion die direkt in Transistorlogik implementiert wird. Insofern sind heutzutage alle ICs, die ihre Funktion direkt in der Transistorlogik implementieren ASICs. Die Masse dieser ICs werden von Herstellern als fertige Produkt verkauft, das meinte ich mit Standard ICs. Einen eigenen IC zu entwickeln und bei einer Foundry fertigen zu lassen, ist ist für viele Unternehmen nicht möglich.

FPGAs kamen in den 1980iger Jahren auf den Markt und haben sich seitdem etabliert. FPGAs haben ihren Platz bei Simulatoren, Prototypen und Kleinserien gefunden. Richtig, das sind keine Massenmärkte.

Wenn man den Blickwinkel ändert und das ganze aus der Systemseite anschaut, dann bieten FPGAs etwas einzigartiges, sie ermöglichen Hardware, die noch im Betrieb geändert werden kann. Auch diese Flexibilität benötigen nicht viele, aber für diejenigen die sie benötigen gibt es keine Alternative.

Aber so wie die CPUs zu SoCs wurden, wurden auch die FPGAs von den Herstellern in SoCs integriert. AMD nennt es adaptive SoCs. Und diese adaptive SoCs stehen im Wettbewerb mit SoC ohne FPGA. Hier belegen die adaptive SoCs AFAIU das High End. Sie können viel mehr Funktionen in Hardware implementieren als es SoC können, die nur Prozessoren und ASIC enthalten. Natürlich enthalten die adaptive SoCs auch Funktionsblöcke per ASICs.

Ein weiterer Aspekt aus der Systemebene ist, dass sich mit der Zeit die Anforderungen ändern. Vieles kann man mit einem Softwareupdate abfangen. Eine Hardware zu haben, die an neue Anforderungen angepasst werden kann, ist für einige Anbietern von langlebigen Gütern eine wichtige Option.
 
ETI1120 schrieb:
FPGAs haben ihren Platz bei Simulatoren, Prototypen und Kleinserien gefunden. Richtig, das sind keine Massenmärkte.
Mal als Einwurf:
FPGAs findet man heutzutage (bzw. sind meine Beobachtungen jeweils ~5 Jahre zurueck) in professioneller Hardware. Netzwerkswitche, Router, Storagesysteme, Netzwerkkarten.

Das ist keine Endkundenware, aber dennoch im professionellen Umfeld eigendlich irgendwo Standardkram.
5 Jahre zurueck deswegen, weil ich gerne mal wenn Zeit ist bei Hardware die fuer die Verwertung bestimmt ist den Schraubenzieher zuecke um meine Neugierde zu befriedigen :D
 
Ranayna schrieb:
Mal als Einwurf:
FPGAs findet man heutzutage (bzw. sind meine Beobachtungen jeweils ~5 Jahre zurueck) in professioneller Hardware. Netzwerkswitche, Router, Storagesysteme, Netzwerkkarten.
Sind das tatsächlich hauptsächlich FPGAs und keine adaptive SoCs?
 
ETI1120 schrieb:
Deine Einschätzung, dass mit einem FPGA nur geringe Geschwindigkeitsgewinne gegenüber einem System mit Prozessor möglich sind, trifft nicht zu.

So eine Einschaetzung habe ich nicht gemacht. Es gibt schon Faelle, in denen FPGAs schneller sind als Software auf einem Prozessor, aber eben auch umgekehrt.

Deine Unterscheidung ist irrelevant, weil Du damit auch Prozessoren unter ASIC einordnest.

Deine Begruendung ist nicht nachvollziehbar. Ein z.B. 64-bit-Multiplizierer in einem Prozessor ist genauso schnell und belegt dieselbe Flaeche wie ein 64-bit-Multiplizierer in etwas, das Du als ASIC bezeichnen wuerdest (ok, es gibt noch verschiedene Arten, Multiplizierer zu implementieren, aber nehmen wir einmal an, in beiden Faellen wird das gleiche Multiplizierer-Design verwendet), waehrend es mit LUTs implementiert x mal langsamer und y mal so gross ist. Deswegen ziehe ich die Linie zwischen FPGA und nicht-FPGA. Wobei FPGAs ja inzwischen nicht nur aus LUTs bestehen, sondern auch haeufige Funktionsbloecke enthalten (vielleicht auch Multiplizierer), um diese Nachteile von LUTs zumindest in einem Teil des FPGA zu vermeiden.

ASIC stand Mal für eine Produktkategorie, die heute praktisch verschwunden ist. Sie wurden unter anderem durch FPGAs obsolet gemacht.

Eher nicht. Wenn etwas die Stueckzahlen hat, um einen eigenen Chip zu rechtfertigen, wird das halt heutzutage zusammen mit Prozessor-Kern und anderen Funktionen zu einem SoC gemacht, wo der ehemalige ASIC dann ein Funktionsblock ist. Du wuerdest das SoC dann nicht als ASIC bezeichnen, aber das ist eben das Problem mit Deiner Einteilung.

Aber klar, wenn die Stueckzahlen fuer sowas nicht reichen, und FPGA im Vergleich zu Software fuer die Anwendung besser ist, dann kann man stattdessen einen SoC mit einem FPGA-Block nehmen (sowas in der Art wie das Ding, was Du oben gezeigt hast), und den FPGA-Teil entsprechend programmieren.

Insofern sind heutzutage alle ICs, die ihre Funktion direkt in der Transistorlogik implementieren ASICs.

So habe ich den Begriff verwendet.

Einen eigenen IC zu entwickeln und bei einer Foundry fertigen zu lassen, ist ist für viele Unternehmen nicht möglich.

Das geht fuer Prototypen sogar erstaunlich guenstig, aber fuer die Serienfertigung ist der Sockelbetrag halt hoch, das zahlt sich nur bei hohen Stueckzahlen aus.

Ansonsten: Zustimmung.
 
Mit FPGAs werden gerne Custom DSPs umgesetzt, zb für LWL-Backbone, Bild oder Tonverarbeitung.
Insbesondere wenn so was nur in Kleinserie läuft (Infrastruktur, Militär, Speziallösungen in der Forschung) ist ein FPGA die günstige und schnellste Möglichkeit, solche Lösungen umzusetzen.
Oder auch, um die Funktion von veralteter Hardware 1-1 nachzubauen.
 
Zurück
Oben