Seit vielen Jahren loten ARM-Lizenznehmer wie Qualcomm, Infineon, NXP und Bosch das Potenzial der offengelegten RISC-V-Befehlssatzarchitektur aus. Nun gründen die genannten Firmen gemeinsam mit Nordic Semiconductor ein noch unbenanntes gemeinsames Unternehmen in Deutschland, das die Verbreitung von RISC-V-Prozessoren zunächst vor allem für Anwendungen in Fahrzeugen (Automotive) beschleunigen soll. https://www.heise.de/news/Wichtige-ARM-Kunden-gruenden-RISC-V-Allianz-in-Deutschland-9235216.html
:
Verschoben durch Moderator
Da ARM massiv an der Lizenzschraube dreht und als Konkurrent zu seinen Lizenznehmern auftreten will, ist diese Entwicklung nur logisch. Durchaus vorstellbar ist jedoch, dass es sich dabei mindestens bei manchen Mitspielern um eine Drohkulisse gegenüber ARM handelt, es nicht zu sehr zu übertreiben.
Gerade die Tage ein paar Videos der RISC-V International und des RISC-V Summit Europe angesehen. Das Thema nimmt sicherlich Fahrt auf. Debian bietet einen passenden Port an, Hardware poppt allmählich auf. Braucht alles noch etwas, wird aber spannend.
Hallo, ich sage nur Qualcomm, sind auch keine Unschuldslämmer, selbst Schuld wenn man mit solchen ähnlichen Lizenzkonstrukten anfängt bezüglich seines Kunden Apple. Die Klagen sind ja schon legendär. Jetzt versucht es ARM in ähnlicher Weise bei Qualcomm. Aber egal, diese komischen Lizenzkonstrukte sind für mich schon immer unlogisch, wenn damit jeder Kunde in der Lieferkette alles doppelt und dreifach bezahlt. Bspw. zahlen Automobilhersteller auch Lizenzgebühren für Mobilfunk an den Ursprungshersteller für Produkte die sie vom Zulieferer fertig beziehen und der zahlt auch schon Lizenzgebühren. Kranke Welt. Das geht auch einfacher und durchsichtiger. Mich wundert nur das RISC-V bis heute, gibts ja schon seit paar Jahren, nicht fetter im Markt angekommen ist. SoCs fürs Handy auf Top Niveau hätte ich gedacht sollte schon möglich sein. Scheinbar nicht. Die RISC-V Entwicklung schreitet zwar stetig voran, aber irgendwie gefühlt zu langsam. Kurzum, RISC-V sollte mal langsam in die Pushen kommen. Bis dahin wird die ARM Kuh gemolken. Ich meine die RISC-V Klubmitglieder haben es eigentlich in der eigenen Hand. Je schneller sie RISC-V vorwärts bringen um so eher können sie sich von ARM lösen.
G. K. schrieb: > Nun gründen die genannten Firmen gemeinsam mit Nordic Semiconductor ein > noch unbenanntes gemeinsames Unternehmen in Deutschland Mich würde da nicht übermäßig wundern, wenn das Startup mit einem stattlichen staatlichen Betrag gefördert und letztlich im Sande verlaufen würde...
Wenn die Europäer halbwegs schlau sind - ich bereue schon jetzt den Satz begonnen zu haben - dann erkennen sie möglicherweise, das sich eine Chance ergibt hier in der Region zu entwickeln bzw. Prozessoren und µC ortsnah herzustellen. Da, nun hab' ich's gesagt… ;-)
Veit D. schrieb: > RISC-V sollte mal langsam in die Pushen kommen. Bis > dahin wird die ARM Kuh gemolken. Ich meine die RISC-V Klubmitglieder > haben es eigentlich in der eigenen Hand. Je schneller sie RISC-V > vorwärts bringen um so eher können sie sich von ARM lösen. RISC-V ist kein Selbtläufer. Da müssen sich auch mehrere Firmen dahinter klemmen und Entwicklungs- und Integrationsarbeit leisten. So ähnlich wie bei Linux. Nur weil der Standard offen ist und man sich den irgendwo runter laden kann, hat man noch lange kein fertiges Produkt, schon gar nicht in Hardware.
Und? Industrieallianzen werden gefühlt täglich gegründet. Von dem meisten hört man schnell nichts mehr und sie werden sang- und klanglos zugemacht oder im Dauerkoma gehalten. Erst mal ein paar Jahre abwarten und dann schauen ob diese Allianz was erreicht. Vorher lohnt sich der Aufwand sich mit so einem Laden zu beschäftigen nicht.
Falk B. schrieb: > RISC-V ist kein Selbtläufer. Da müssen sich auch mehrere Firmen dahinter > klemmen und Entwicklungs- und Integrationsarbeit leisten. Naja, ARM leistet dem ja kräftig Vorschub mit seinen Lizenzverweigerungen gegenüber chinesischen Firmen. Auf diese Weise werden diese ja praktisch gezwungen, statt ARM nun RISC-V zu machen. Mir sieht dieses Konsortium ein wenig danach aus, als wollte man den RISC-V-Kuchen nicht China allein überlassen wollen …
Falk B. schrieb: > Veit D. schrieb: >> RISC-V sollte mal langsam in die Pushen kommen. Bis >> dahin wird die ARM Kuh gemolken. Ich meine die RISC-V Klubmitglieder >> haben es eigentlich in der eigenen Hand. Je schneller sie RISC-V >> vorwärts bringen um so eher können sie sich von ARM lösen. > > RISC-V ist kein Selbstläufer. Da müssen sich auch mehrere Firmen dahinter > klemmen und Entwicklungs- und Integrationsarbeit leisten. So ähnlich wie > bei Linux. Nur weil der Standard offen ist und man sich den irgendwo > runter laden kann, hat man noch lange kein fertiges Produkt, schon gar > nicht in Hardware. Hallo Falk, ja. Laut meines Wissens zahlt man Mitgliedsbeiträge und darf damit an der Entwicklung teilnehmen und gleichzeitig frei nutzen. Meine Logik sagt mir oder würde mir als Hersteller folgendes sagen. Wenn ich weiß das ich absehbar mit ARM Lizenzgebühren und deren komischen Konstrukte Probleme bekomme bzw. mir das nicht gefällt oder weil allgemein zu teuer, dann versuche ich doch die Entwicklung voranzutreiben damit ich mich von ARM eher befreien kann. Das sollte im Interesse aller Klubmitglieder sein. Kann auch sein das ist eher Wunschdenken ohne Reibereien zwischen den Mitgliedern. Sind ja alles Konkurrenten. Im dümmsten Fall hat Lothar recht und es werden nur Fördermittel verjodelt. nvidia ist ja selbst Mitglied und wollte dennoch ARM kaufen. Auch das ist / war seltsam. Warum wurde der RISC-V Klub nochmal genau gegründet? Edit: Alle Bekannten und Unbekannten sind vertreten. https://riscv.org/members/ Ich hoffe nicht das zu viele Köche das Problem sind beim Entwickeln und Standardisieren.
:
Bearbeitet durch User
Norbert schrieb: > dann erkennen sie möglicherweise, das sich eine > Chance ergibt hier in der Region zu entwickeln bzw. Prozessoren und µC > ortsnah herzustellen. Eine Prozessorarchitektur zu entwickeln oder auch nur zu nutzen ist etwas komplett anderes als eine Halbleiterfertigung auf die Beine zu stellen.
Veit D. schrieb: > Ich hoffe nicht das zu viele Köche das Problem sind beim Entwickeln und > Standardisieren. Aber das schöne an Standards ist doch gerade das man soviele davon haben kann ;)
Harald K. schrieb: > Eine Prozessorarchitektur zu entwickeln oder auch nur zu nutzen ist > etwas komplett anderes als eine Halbleiterfertigung auf die Beine zu > stellen. Zumindest einige der Teilnehmer haben da aber durchaus schon auch regional was laufen (Infineon, Bosch – weiß gerade nicht, wo NXP aktuell fertigt).
Harald K. schrieb: > Eine Prozessorarchitektur zu entwickeln oder auch nur zu nutzen ist > etwas komplett anderes als eine Halbleiterfertigung auf die Beine zu > stellen. Ja wenn das so ist, dann lassen wir das besser … die anderen machen.
Jörg W. schrieb: > weiß gerade nicht, wo NXP aktuell > fertigt). Das liegt nun wirklich auf der Hand: https://www.youtube.com/watch?v=4UG87ZLB4AY
Beitrag #7470202 wurde von einem Moderator gelöscht.
Veit D. schrieb: > Mich wundert nur das RISC-V bis heute, gibts ja schon seit paar Jahren, > nicht fetter im Markt angekommen ist. SoCs fürs Handy auf Top Niveau > hätte ich gedacht sollte schon möglich sein. Scheinbar nicht. Die RISC-V > Entwicklung schreitet zwar stetig voran, aber irgendwie gefühlt zu > langsam. Kurzum, RISC-V sollte mal langsam in die Pushen kommen. Ich vermute es liegt am Absatzmarkt. Die Kunden nehmen das was sie kennen, also ARM. Für RISC-V müsste es dann schon einen Preisvorteil geben, was für die Hersteller am Anfang bei noch kleinen Stückzahlen aber schwierig ist. Ist halt das typische Monopolisierungsproblem. So ein Konsortium, aus Hersteller und Kunden, kann dann evtl. schon was reißen.
Wenn ich es recht weiß, ist RISC-V nur eine Architekturbeschreibung, die nichts über die Geschwindigkeit des Kerns (z.B. cycles per instruction) aussagt. Ich denke ARM bietet da noch mehr: vermutlich den komplett gerouteten Prozessorkern auf Sizilizumebene mit definierter Geschwindigkeit. Die Umsetzung der Architektur auf das Silizium ist vermutlich eine Dienstleistung, die ARM gleich mit anbietet.
Harald K. schrieb im Beitrag #7470202:
> Was soll das Gefurze? Verstehst Du den Unterschied nicht?
Kein Grund wie ein Prolet herum zu pöbeln.
Nebenbei, das Know-How wird in Europa wohl schon vorhanden sein.
Entwickelt wird schon, gefertigt wird auch schon.
Nur schließen wir anscheinend lieber Fabriken als sie weiter zu
entwickeln.
Norbert schrieb: > Nur schließen wir anscheinend lieber Fabriken als sie weiter zu > entwickeln. Wer sind "wir"? Unterliegen Wirtschaftsunternehmen irgendwelchen demokratischen Entscheidungsprozessen? Wurde vom sächsischen Landtag beschlossen, daß z.B. AMD die Fertigung in Dresden einzustellen hat, oder hat der bayerische Landtag bestimmt, daß Siemens seine Halbleiterfertigung als "Infineon" ausgründen und verhökern muss?
Entsteht hier wieder eine sinnlose Diskussion?
Georg M. schrieb: > Entsteht hier wieder eine sinnlose Diskussion? Ja, dass schweift jetzt langsam aber sicher vom Thema ab. Norbert schrieb: > Nebenbei, das Know-How wird in Europa wohl schon vorhanden sein. > Entwickelt wird schon, gefertigt wird auch schon. > Nur schließen wir anscheinend lieber Fabriken als sie weiter zu > entwickeln. Welche Fabrik wurde denn geschlossen?
:
Bearbeitet durch User
Bevor's vergessen geht. Risc-V ist nur die Hardware. Dazu gehoert auch noch etwas wie ein Entwicklungstool, resp Compiler. Wahrscheinlich sollte ein Entwicklungstool, dh Compiler, auch noch zertifiziert sein. Das ist auch ein nicht zu vernachlaessigender Aufwand.
ARM CM haben ja auch eine aufwändige debug Möglichkeit eingebaut, das CoreSight. Wie sieht das im RISC-V aus? Kann man CM auch als kleine Klitsche als Softcore lizensieren?
Purzel H. schrieb: > Dazu gehoert auch noch etwas wie ein Entwicklungstool, resp Compiler. GCC gibt's, IAR gibt's, vermutlich noch mehr.
Purzel H. >Bevor's vergessen geht. Risc-V ist nur die Hardware. Dazu gehoert auch >noch etwas wie ein Entwicklungstool, resp Compiler. Wahrscheinlich >sollte ein Entwicklungstool, dh Compiler, auch noch zertifiziert sein. >Das ist auch ein nicht zu vernachlaessigender Aufwand. Risc-V ist nicht die Hardware, sondern die Definition des Befehlssatzes eines Mikroprozessors:
1 | RISC-V ist eine Befehlssatzarchitektur (engl. instruction set architecture, ISA), die sich auf das Designprinzip des Reduced Instruction Set Computers (RISC) stützt. |
https://de.wikipedia.org/wiki/RISC-V Compiler und Tools gibt es dafür genug. Der Aufwand ist die Umsetzung in Silizium, wie ich es schon oben geschrieben habe.
Purzel H. schrieb: > Wahrscheinlich > sollte ein Entwicklungstool, dh Compiler, auch noch zertifiziert sein. Zertifiziert? Wofür und von wem? Denkst Du an sowas wie MISRA?
Ein Hardware project kommt erst in die Gaenge wenn auch die passende Software absehbar ist. Ein GCC ist nett fuer Entwickler und Bastler, da gehoert aber schon noch etwas dazu. Nein, nicht Eclipse. Und fuer gewisse (hochsicherheits-) Projekte will man einen zertifizierten Compiler, wo der Code ganz sicher das tut was er soll. zB ADA.
Purzel H. schrieb: Es gibt aber auch noch etwas anderes als > gewisse (hochsicherheits-) Projekte und die stellen die überwiegende Mehrheit der Projekte da draußen.
Purzel H. schrieb: > Ein GCC ist nett fuer Entwickler und Bastler Du wirst dich wundern, wo der überall eingesetzt wird. Ansonsten geht es hier ganz bestimmt nicht primär um irgendwelchen sicherheitsrelevanten Kram, sondern um CPUs für Handies und für allen möglichen Kleinkram. Dein Handy braucht keinen MISRA-Compiler.
Jörg W. schrieb: > sondern um CPUs für Handies und für allen > möglichen Kleinkram Nö, in diesem Trööt geht es um die Anwendung im Automotive-Umfeld. Ein Hersteller, der im verlinkten Heise-Artikel nicht erwähnt wird, aber mindestens ein interessantes Produkt auf dem Markt hat, ist Microchip mit seinem Polarfire SoC: https://www.microchip.com/en-us/products/fpgas-and-plds/system-on-chip-fpgas/polarfire-soc-fpgas
:
Bearbeitet durch User
Klaus schrieb: > Nö, in diesem Trööt geht es um die Anwendung im Automotive-Umfeld. Das ist Deine Interpretation. Von den im verlinkten Artikel genannten Herstellern ist nur einer primär im "Automotive"-Umfeld aktiv, die anderen sind deutlich universeller aufgestellt: "Qualcomm, Infineon, NXP und Bosch" Und wer "Automotive"-Kram nicht mit gcc übersetzen will, kann auch zu IAR greifen. Die interessieren sich auch für "functional safety": https://www.iar.com/products/requirements/functional-safety/iar-embedded-workbench-for-risc-v-functional-safety/ https://www.iar.com/products/requirements/functional-safety/iar-build-tools-for-linux-for-risc-v-functional-safety/
Arm hat ADIvX als Debuglösung, bei RiscV hat jeder Hersteller seine eigene Lösung. Was für ein Showstopper...
Harald K. schrieb: > Das ist Deine Interpretation Und geht aus aus dem Eingangsbeitrag hervor: G. K. schrieb: > das die Verbreitung von RISC-V-Prozessoren zunächst vor allem für > Anwendungen in Fahrzeugen (Automotive) beschleunigen soll.
Klaus schrieb: > Nö, in diesem Trööt geht es um die Anwendung im Automotive-Umfeld. Das steht in der Pressemeldung. Wenn du aber weißt, dass die Hersteller teilweise intern eigene CPU-Architekturen implementiert haben, weil ihnen für internen Kleinkram die Tantiemen für ARM einfach zu üppig sind, dann darfst du gut und gern davon ausgehen, dass die gesamte Allianz deutlich mehr im Blick hat. Außerdem wurde schon mehr als einmal geschrieben, dass es am Compiler sicher nicht liegen wird. Uwe B. schrieb: > Was für ein Showstopper. Genau so, wie es ein totaler Showstopper für AVR war, dass sie ihre völlig eigene Debuglösung haben, die sie noch dazu als Firmengeheimnis betrachten – nicht wahr?
Uwe B. schrieb: > Arm hat ADIvX als Debuglösung, bei RiscV hat jeder Hersteller seine > eigene Lösung. Was für ein Showstopper... Themen wie ebendieses dürfte bei RISC-V-Allianzen eine Rolle spielen. Damit eben nicht jeder seine eigene teure Insel-Infrastruktur aufbauen muss.
:
Bearbeitet durch User
Uwe B. schrieb: > Arm hat ADIvX als Debuglösung, bei RiscV hat jeder Hersteller seine > eigene Lösung. Was für ein Showstopper... Verstehe ich nicht. Otto-Normalentwickler in $FIRMA nimmt seinen Lauterbach mit passendem Dongle, und es ist ihm völlig schnuppe ob da ein PPC, Tricore, ARM, RISC-V oder sonstnochwas dahintersteckt.
Klaus schrieb: > Verstehe ich nicht. Otto-Normalentwickler in $FIRMA nimmt seinen > Lauterbach mit passendem Dongle, und es ist ihm völlig schnuppe ob da > ein PPC, Tricore, ARM, RISC-V oder sonstnochwas dahintersteckt. Dazu muss im Chip ein Gegenstück existieren, mit JTAG oder Sonstwas, sonst dongelt er ins Leere. Genau wie bei den ARM-Mikros muss auf den Chip ein Debug-Modul drauf, einer oder mehrere interne Busse etc. Der Uncore-Bereich, denn der Core alleine reicht nicht. Die RISC-V Architektur definiert das m.W. nicht.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Dazu muss im Chip ein Gegenstück existieren, JTAG oder Sonstwas, sonst > dongelt er ins Leere. Selbstverständlich. Und dieses Gegenstück gibt es auch bei Risc-V, sonst wäre so ein Chip quasi unverkäuflich.
Klaus schrieb: > Selbstverständlich. Und dieses Gegenstück gibt es auch bei Risc-V, sonst > wäre so ein Chip quasi unverkäuflich. RISC-V ist m.W. nur die Definition einer Instruction Set Archtitecture und ist nicht verkäuflich, sondern frei. Es sind die realen Chips, die es benötigen, und da hat es schon Vorteile für die Kundschaft, wenn nicht jede Chip-Klitsche solche Module individuell gestaltet.
:
Bearbeitet durch User
Purzel H. schrieb: > Nein, nicht Eclipse. > Und fuer gewisse (hochsicherheits-) Projekte will man einen > zertifizierten Compiler, wo der Code ganz sicher das tut was er soll. zB > ADA. Das Zeug ist ja auch schon alles da, z. B. RTOS für sichere Anwendungen gibts seit 3 Jahren: https://www.sysgo.com/press-releases/sysgo-adds-risc-v-support-to-its-pikeos-real-time-operating-system Die Lauterbach Tools untersützen Risc-V auch schon seit längerer Zeit: https://www.lauterbach.com/supported-platforms/architectures/risc-v GNAT Pro (Zertifizierter ADA Compiler) sogar schon seit 2019: https://www.adacore.com/press/adacore-joins-the-risc-v-foundation Es fehlen (weitestgehendst) die Chips für diese Anwendungsbereiche. Der PolarFire SoC von Microchip (Microsemi) ist da bisher eine Ausnahme. Sonst gibt es hauptsächlich Soft-Cores oder IPs für dein ASIC Design.
(prx) A. K. schrieb: > Dazu muss im Chip ein Gegenstück existieren, mit JTAG oder Sonstwas [...] Die RISC-V Architektur definiert das m.W. nicht. Doch doch, External Debug und Efficient Trace ist auch ratifiziert: https://wiki.riscv.org/display/HOME/RISC-V+Technical+Specifications
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.