ARM Lizenzen für Halbleiterhersteller

Egal schrieb:
> Sieht so aus als ob sich mit Sicherheit so manche Halbleiterfirma jetzt
> Gedanken machen muss nicht doch lieber mit RISC-V zu planen?

Mancher Markt ist schwer zu knacken. Geht es um Android Geräte, wird man 
nicht so leicht von ARM weg kommen. Theoretisch geht das zwar, aber bis 
diese Kopplung fällt, muss es ziemlich übel stinken, oder Google mit von 
der Partie sein. Lieber wird man in Anwälte investierten. Das Stichwort 
wird genannt: "anti-competitive behavior", also Wettbewerbsrecht.

(prx) A. K. schrieb:
> Mancher Markt ist schwer zu knacken. Geht es um Android Geräte, wird man
> nicht so leicht von ARM weg kommen. Theoretisch geht das zwar, aber bis
> diese Kopplung fällt, muss es ziemlich übel stinken, oder Google mit von
> der Partie sein.

Android Geräte ohne ARM CPU gab es schon mal vor vielen Jahren. Siehe 
Ainol Tablets. Für die meisten Apps spielt das eh keine Rolle, weil 
Java, nur Applikationen welche mit dem NDK entwickelt wurden, müssten 
neu kompiliert werden.

Marc X. schrieb:
> Android Geräte ohne ARM CPU gab es schon mal vor vielen Jahren"

Mit Betonung auf gab es. ;-)

Ich schrieb ja, dass es theoretisch geht. Aber jeder bisherige Versuch 
landete im Graben, auch der von Intel. Wird wohl Gründe geben, das 
müssen aber nicht notwendigerweise technische sein.

Ein Schlüsselmoment wäre, wenn Google, das ja mittlerweile auch eigene 
SOCs mit eigener KI-Komponente baut, von ARM so genervt ist, dass es 
umschwenkt.

olaf schrieb:
> Ich vermute mal der Hauptgruend duerfte sein das die Energieeffizienz
> von ARM am besten war/ist.

Gut möglich. Es ist eine Sache, die Architektur zu wechseln. Und eine 
andere, die richtigen Cores zu finden, oder selbst zu bauen.

Daran ist letztlich auch Samsungs Versuch gescheitert, wie Apple eine 
eigene Linie von ARM-Cores zu bringen, die "Mongoose". Schnell waren 
sie, aber üble Stromfresser. In der 32-Bit Ära hatte Qualcomm eigene 
"Krait" Cores, die in dieser Hinsicht wesentlich besser waren, als die 
von ARM. Qualcomms Versuch, diesen Ansatz in 64-Bit fortzusetzen, ging 
ebenfalls schief.

olaf schrieb:
> Aber ich denke schon das es in der Branche ein staerker werdenden
> Unwillen gegen Arm gibt. RISC-V wird da langsam Druck aufbauen und
> irgendwann in 5-10Jahren kippt dann alles und jeder nimmt RISC-V
> weil kostenlos.

Ein starkes Moment werden die Chinesen mitbringen. Die müssen jetzt 
schon weg von ARM.

olaf schrieb:
> Ich hab jetzt sogar
> gesehen das Microchip PICs mit Arm-core hat.

Was glaubst du, warum sie Atmel kaufen mussten? Weil sie zu spät gemerkt 
haben, dass ihr MIPS-Pferd doch nicht so toll zieht, wie es anfangs 
aussah. Atmel hatte dann den deutlichen Vorsprung, denn die haben schon 
seit Jahren ARM-MCUs gebaut und hatten kurz vor der Übernahme mit den 
Cortex-M0+ dann nochmal einen guten Modernisierungsschub geschafft 
(wenngleich auch schon recht spät, viele waren da schon bei STM 
gelandet).

Mal gucken, was aus dem Gezänk da noch so wird.

olaf schrieb:
>> Mittlerweile ist das dank GCC und Open source nicht mehr ganz so
>
> Du betrachtest das alles aus Bastlersicht. Niemand in Firmen die grosse
> Stueckzahlen kaufen nutzt ernsthaft den gcc oder macht sich Gedanken
> wegen ein paar Tausend Euro fuer eine Compilerlizenz.

Widerspruch. Zu meiner Atmel-Zeit hat mich mal ein FAE kontaktiert, weil 
ein Kunde massiv IAR durch GCC ablösen wollte. Lange bevor sowas wie 
"Continuous Integration" ein gängiges Stichwort geworden war, wollte 
$KUNDE damals in einer Farm sowas wie nightly builds einführen. Das wäre 
selbst einem großen Kunden mit den Preisen von IAR dann schlicht zu 
teuer geworden.

> Dem kann ich nicht ganz folgen. Wenn ich ein Hersteller bin der
> irgendeinen Core hat und fertigen kann und dann ARM haben will, dann
> bezahle ich die Lizenzkosten, bekomme den Verilogsource, verknuepper den
> mit meiner schon vorhanden Lieblingsperipherie und bin fertig.

Aber erst zwei oder drei Jahre später. Wenn du aber merkst, dass du der 
Technologie, die jetzt gefragt ist, bereits hinterher hinkst, dann 
hast du diese Zeit nicht.

Alleine der erste Fab-Durchlauf für einen komplexen Controller dauert 
schon fast ein halbes Jahr lang. Danach bleibt die Hälfte der Testlose 
vor den Metallisierungsschichten stehen, die andere Hälfte wird zu Ende 
gefertigt. Stellt sich während der Tests heraus, dass es Fehler gibt 
(und das ist fast immer der Fall, ein "first time right" ist ein 
ziemlicher Glückstreffer), dann versucht man, diese nur durch Änderungen 
der oberen Lagen zu reparieren. Dafür gibt es sogar noch "sewing kits", 
also auf Vorrat in irgendwelchen Ecken abgelegte Gatter, Transistoren 
etc., die man bei Bedarf auf diese Weise einverdrahten kann. Wenn man 
damit das Problem repariert bekommt, spart man nicht nur viel Geld (nur 
die Masken für die Metallschichten statt des kompletten Maskensatzes) 
sondern auch Zeit, weil man das halbe Los jetzt dafür innerhalb 
vergleichsweise kurzer Zeit damit korrigieren und zu Ende fertigen 
lassen kann.

olaf schrieb:
> Niemand in Firmen die grosse
> Stueckzahlen kaufen nutzt ernsthaft den gcc oder macht sich Gedanken
> wegen ein paar Tausend Euro fuer eine Compilerlizenz.

Du kennst offenkundig keine grossen Firmen.
Da sorgen die BWLer schon dafür, daß alles nichts kostet.

olaf schrieb:
> Wenn ich ein Hersteller bin der
> irgendeinen Core hat und fertigen kann und dann ARM haben will, dann
> bezahle ich die Lizenzkosten, bekomme den Verilogsource, verknuepper den
> mit meiner schon vorhanden Lieblingsperipherie und bin fertig.

Du hast offenbar nicht mal den Artikel (z.B. bei Heise) gelesen.
Genau das soll nämlich nicht mehr gehen, ARM möchte auch Kontrolle über 
die Peripherie.

"Außerdem will ARM offenbar die Kopplung von ARM-Rechenkernen mit 
Funktionsblöcken anderer Zulieferer – etwa von GPUs, KI-Beschleunigern 
oder Bildprozessoren – untersagen"

Michael B. schrieb:
> "Außerdem will ARM offenbar die Kopplung von ARM-Rechenkernen mit
> Funktionsblöcken anderer Zulieferer – etwa von GPUs, KI-Beschleunigern
> oder Bildprozessoren – untersagen"

Bei tiefer Textexegese sollte man lieber bis zum Original vordringen, 
bevor man aus einem Heise-Text schliesst, das künftig alle CAN-Module 
von auf ARM basierenden Mikrocontrollern auch von ARM zu sein haben. 
Denn das wäre der perfekte Weg von ARM, sich schnellstmöglich aus diesem 
Markt zu katapultieren.

Das sieht auf den ersten Blick auch als perfekter Weg aus, sich bei 
sämtlichen Wettbewerbshütern zu verscheissen. Die sehen eine solche 
Kopplung unabhängiger Elemente üblicherweise recht kritisch.