Hey Leute, just fyi. Eben einen interessanten Bericht von gestern gelesen: https://www.semianalysis.com/p/arm-changes-business-model-oem-partners Sieht so aus als ob sich mit Sicherheit so manche Halbleiterfirma jetzt Gedanken machen muss nicht doch lieber mit RISC-V zu planen?
Auf heise stand darüber auch was. Betrifft ja "nur" cortex-a CPU designs. Befehlssatz Lizenzen wie sie z.b. Apple verwendet sind davon nicht betroffen. Und vermutlich nur neue cortex-a designs. Die bereits bestehenden am Markt verfügbaren sind über bereits bestehende verträge abgesichert. Wird doch kein Hersteller sich einen lizenz Knebelvertrag mit ungewisser zukünftiger "kosten/Lizenz-entwicklung" ans Bein gebunden haben. Auch wenn arm das so haben möchte, nachträglich. Nvidia hat sich z.b. aufgrund der versuchten übernahme einen 20Jahre lizenz gesichert. Da wird es einige Themen geben die die Gerichte mit arm diskutieren werden, ... Bei Verkauf/übernahme einer Firma mit arm lizenz erlischt diese, und alles was damit entwickelt wurde muss vernichtet werden (aktuelle Streitigkeiten zwischen Arm und qualkom) ... Nachträgliche einseitige neu Interpretation von lizenz verträgen ... nicht einhalten von Klauseln zur lizenz verlängerung in bestehenden verträgen, ...
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.
:
Bearbeitet durch User
(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.
:
Bearbeitet durch User
Marc X. schrieb: > Android Geräte ohne ARM CPU gab es schon mal vor vielen Jahren Naja, die meisten Android Entwickler benutzen auch den Emulator, und der nutzt x86 (denn es ist eher eine VM und kein Emulator). Noch eine weitere Architektur hinzuzufügen und NDK-Komponenten dafür zu kompilieren wäre durchaus denkbar. Die Frage ist eher, ob die Prozessoren in Sachen Performance, Effizienz/Leistungsaufnahme mithalten können, und wie gut man die Integration zum Modem sowie die Grafikleistung hinbekommt.
> Ich schrieb ja, dass es theoretisch geht. Aber jeder bisherige Versuch > landete im Graben, auch der von Intel. Es gab ganz am Anfang auch mal Android-Handy mit Renesas SH CPUs. > Wird wohl Gründe geben, das müssen aber nicht notwendigerweise > technische sein. Ich vermute mal der Hauptgruend duerfte sein das die Energieeffizienz von ARM am besten war/ist. Das ist ja das womit Handys am meisten kaempfen. Olaf
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.
:
Bearbeitet durch User
> Gut möglich. Es ist eine Sache, die Architektur zu wechseln. Und eine > andere, die richtigen Cores zu finden, oder selbst zu bauen. Ich glaube das ist so komplex das die Hersteller selber nicht wissen wie die Zukunft aussieht. Urspruenglich hatte ja jeder Hersteller seine eigenen MCU und musste sich dafuer einen Zoo an Compilern und Debugger halten. Das war den kleinen dann wohl zu aufwaendig und sie haben ARM lizensiert. Irgendwann sind dann auch die Grossen mit Zaehneknirschen auf ARM umgestiegen weil es die Kunden verlangt haben. Ich hab jetzt sogar gesehen das Microchip PICs mit Arm-core hat. Das haben die vermutlich nicht freiwillig gemacht. Auch TI hat den ARM in ihren MSP432 drin weil die Kunden es verlangt haben. 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. Immerhin der J-Link kann schon RISC-V. Olaf
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.
:
Bearbeitet durch User
Man sollte aber auch berücksichtigen, das es immer weniger chip hersteller wurden in den letzten jaren. Da wurde aufgekauft, fusioniert, ... Freescale ist jetzt nxp, atmel gehört microchip... Häufig sind nur die Namen übrig geblieben. Da muss dann halt irgend wann Mal das Portfolio aufgeräumt werden. Wieso 3 8bit, 2 16bit und 3 eigene 32bit Plattformen pflegen, ... Befehlssatz, Asics, Toolchain Entwicklung und Pflege kostet halt Geld. Beim Hersteller, als auch beim Kunden. Wieso als Kunde sich eine neue toolchain kaufen/einarbeiten, wenn es für den 2. Besten lösung für ein Problem das alles schon im Haus gibt? Früher hat allein ein Compiler Mal 3.000€ und mehr gekostet. Debugger kommt da dann noch mal extra dazu. Da war dann die mcu Platform Entscheidung schon fast eine strategische. Da hatte arm dann seine Vorteile und hat eine verdrängung der anderen Plattformen ausgelöst. Mittlerweile ist das dank GCC und Open source nicht mehr ganz so dramatisch, wenn die GCC Unterstützung brauchbare Leistung liefert. Nur wer kümmert sich bei "exoten" darum, das der GCC brauchbare Ergebnisse liefern? Compiler für alte Plattformen "müssen" auch weiter entwickelt werden. Die c/c++ Standards entwickeln sich auch weiter, ... blöd für den Entwickler, wenn er eine tolle Open source lieb nicht nutzen kann, weil die z.b c++17 verwendet, der Compiler aber nur 98 kann. Oder der Code der Kollegen von einem anderen Projekt.
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.
> 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. Das ist fuer die Entscheidungsfindung irrelevant. > 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. 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. Ich kenne einige Bauteile, ueber die ich hier wohl nicht sprechen darf, wo das genau so gelaufen ist weil man einen internen (oder auch 2-3) Proz in seinem Chip fuer die Ablaufsteuerung brauchte. > Mal gucken, was aus dem Gezänk da noch so wird. Ich bin auch sehr gespannt. :) Ich schaetze mal das ich in 5Jahren das erste mal einen Controller mir RISC-V irgendwo eindesignen werden wo er in Stueckzahlen laeuft. Der Anfang ist schwer, aber sobald erst einmal der erste da ist wird das Ratzfatz gehen. Und wie ich schon sagte, viele Hersteller nutzen derzeit irgendeinen zugekauften Core fuer interne Ablaufsteuerungen in komplexeren Chips, wenn die umstellen und man gerade diese spezielle Funktionalitaet braucht, dann hat man den RISC-V ploetzlich schneller in der Firma als man glaubt. .-) Olaf
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.