Nachdem sich der Mikrocontrollerzoo stark in Richtung Cortex homogensiert, fragt man sich was eigentlich danach kommt. Mit dem Kauf von Atmel durch Microchip, wird sich die Artenvielfalt dort auch deutlich ausdünnen. RISC-V scheint in den letzten Monaten viel Fahrt aufzunehmen: http://riscv.org/ White paper: http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf Dabei handelt es sich um eine Instruction-Set-Architecture, die komplett frei sein soll. So eine art open source-pendant zu ARM. Ansätze der Art gab es schon viele, aber keine hat richtig Fahrt aufgenommen. Das scheint jetzt anders zu sein. Wohl auch weil hinter dieser Initiative einer der RISC-Miterfinder steckt: David Patterson. Ist hier schon jemand mit RISC-V in Berührung gekommen? Wann kommen die ersten Microcontroller? Verschwindet damit der 8051 endlich? (Der steckt noch in vielen SOCs in versteckten Ecken, da lizenzfreier Core)
Tim . schrieb: > RISC-V scheint in den letzten Monaten viel Fahrt aufzunehmen: Das im Zusammenhang mit Deiner Frage > Wann kommen die ersten Microcontroller? lässt das "Fahrt aufnehmen" gleich in einem anderen Licht dastehen. > Verschwindet damit der 8051 endlich? Ganz sicher nicht. Wie Du selbst schreibst, der kost' nix, den kennen sehr viele Entwickler sehr gut, und Entwicklungssysteme sowie Codebibliotheken dafür sind ausgereift. So etwas (Wissen und Werkzeug) wirft niemand ohne Not weg, selbst wenn es eine schickedolleneue und ebenfalls günstige Alternative gibt. Die Diskussion ist allerdings müßig, selbst wenn es bereits reale Implementierungen von RISC-V gäbe und ein µC-Hersteller damit auf dem Markt präsent wäre, wird das in absehbarer Zeit keinerlei Verdrängungseffekte auswirken.
Rufus Τ. F. schrieb: > lässt das "Fahrt aufnehmen" gleich in einem anderen Licht dastehen. Damit beziehe ich mich hierauf: http://www.eetimes.com/document.asp?doc_id=1328561 Rufus Τ. F. schrieb: >> Verschwindet damit der 8051 endlich? > > Die Diskussion ist allerdings müßig, selbst wenn es bereits reale > Implementierungen von RISC-V gäbe und ein µC-Hersteller damit auf dem > Markt präsent wäre, wird das in absehbarer Zeit keinerlei > Verdrängungseffekte auswirken. Die Verdrängungseffekte entstehen ja beim Design-In von IP-Blöcken, nicht erst dann, wenn Microcontroller auf dem Markt sind. Wenn der Controller von außen nicht sichtbar ist (z.B. in Sensoren, Interface-SOCs), kann er relativ schnell ausgetauscht werden.
Tim . schrieb: > Wenn der > Controller von außen nicht sichtbar ist (z.B. in Sensoren, > Interface-SOCs), kann er relativ schnell ausgetauscht werden. Warum sollte das jemand tun? Langeweile? Change never a running system. Gruß Andreas
Tim . schrieb: > Wenn der Controller von außen nicht sichtbar ist (z.B. in Sensoren, > Interface-SOCs), kann er relativ schnell ausgetauscht werden. Kann er natürlich nicht, denn diejenigen, die den Code dafür schreiben, die werden ebensowenig mal eben ihr gesammeltes Wissen und ihre Entwicklungswerkzeuge wegwerfen. Erst wenn der Wechsel der Architektur wirklich massive Vorteile für den Anwender (das mag hier auch der Sensor- oder was-auch-immer-Hersteller sein) bringt, wird darüber nachgedacht, denn alles andere wäre wirtschaftlicher Unfug.
Rufus Τ. F. schrieb: > Tim . schrieb: >> Wenn der Controller von außen nicht sichtbar ist (z.B. in Sensoren, >> Interface-SOCs), kann er relativ schnell ausgetauscht werden. > > Kann er natürlich nicht, denn diejenigen, die den Code dafür schreiben, > die werden ebensowenig mal eben ihr gesammeltes Wissen und ihre > Entwicklungswerkzeuge wegwerfen. Die Peripherie war und ist bei Controllern das Problem beim Wechsel, aber das hängt schlicht davon ab, wer jetzt da einen Controller mit RISC-V-Kern baut. Ebenso könnte es sein, dass sich da ein Ökosystem aufbaut mit Standardperipherie, das über verschiedene Hersteller identisch ist. Werkzeuge: QEMU, Linux, gcc, gdb, llvm/clang alles vorhanden. > Erst wenn der Wechsel der Architektur wirklich massive Vorteile für den > Anwender (das mag hier auch der Sensor- oder was-auch-immer-Hersteller > sein) bringt, wird darüber nachgedacht, denn alles andere wäre > wirtschaftlicher Unfug. Eben das ist gerade der Vorteil (neben der besseren ISA und der optionalen Vektoreinheit) von RISC-V: Keine Lizenzgebühren an ARM, Intel, ImgTec/MIPS oder wen auch immer. Dazu das ganze unter der BSD-Lizenz und nicht, wie andere Versuche vorher, unter der GPL oder ähnlichen Lizenzen. http://riscv.org/download.html#tab_rocket_core mit einem Vergleich von Cortex A5 und einer 64-Bit RISC-V-Implementation (Rocket Core): Ohne Caches braucht RISC-V die halbe Fläche und schafft 10% mehr DMIPS/MHz oder wer das Teil im Browser Linux booten lassen will: http://riscv.org/angel/index.html
Na, ist doch gut, wenn man eine Alternative hat. Wenn die Wirtschaft Gründe findet, dies einzusetzen (oder eben nicht), dann wird das seinen Gang gehen. Wie war das noch mit VHS und Betamax ? :-)
Hallo, also erst sollte man doch mal den Bedarf was man an Performance braucht betrachten. Dann reicht in den meisten Fällen der 8051 aus. Dann wird sich Heute nur noch das durchsetzen, wo es eine IDE (Assembler/Compiler usw.) gibt und einen bezahlbaren Debugger. Bis das aber alles soweit geht, benutze ich noch meine ARMs und meinen JLINK. Auch die FPGA + IP CPU Geschichte ist viel zu teuer, jedenfalls für meine Anwendungen. Und dann immer erst das Errata sheet lesen, das meiste geht bei den neueren CPUs eh nicht, also was soll das? Lieber einen älteren Kontroller verwenden, der wenigstens ausgereift ist. Microchip muss man jedenfalls zu gute heißen, das es sehr wenig Abkündigungen gibt, wenn ich auch schon längers nichts neues damit entwickelt habe. Na ja das ändert sich ja nun da Atmel ja zu Microchip gehört. Übrigens halte ich die neuen Atmel Controller speziell der Cortex M7, Cortes A5 und auch der Cortes M0 als sehr gelungene Lösungen. Bei Freescale (jetzt NXP) ist es die Kinetis Cortex M0 (MKL) Serie. Gruß Sascha
Arc N. schrieb: > oder wer das Teil im Browser Linux booten lassen will: > http://riscv.org/angel/index.html Den hatte ich ganz übersehen. Echt beeindruckend - 15 MIPS im Emulator per Javascript im Browser.
SoftBank Group Nears Deal to Buy ARM Holdings http://www.nytimes.com/2016/07/18/business/dealbook/softbank-group-nears-deal-to-buy-arm-holdings.html Das sollte der Suche nach Alternativen Aufwind geben. ARM hat bisher eine sehr konservative Lizenzpolitik gefahren. Das könnte sich ändern, wenn ein Investor versucht an den Margen zu drehen...
Tim . schrieb: > Das sollte der Suche nach Alternativen Aufwind geben. Welche Alternativen mit einem ähnlichen Angebot gibt es überhaupt? Also mit einem Spektrum an Cores, die direkt bei den üblichen Fertigern einsetzbar sind.
Markus schrieb: > Ist Risc-V die VM von Oberon?: > > http://www.projectoberon.com/ Nein, der Name scheint nur zufällig ähnlich zu sein.
Und dann gibts immer noch MIPS. Die stecken in Settopboxen, LCD Fernsehern und sogar in Navis und werkeln meistens im Verborgenen. Von 'Homogenisierung' kann da sicher keine Rede sein.
>Und dann gibts immer noch MIPS. Ich vermute mal, dass MIPS nicht Open-Source ist. Das ist aber der große Gedanke hinter Risc-V. >> Ist Risc-V die VM von Oberon?: >> >Nein, der Name scheint nur zufällig ähnlich zu sein. Das ist natürlich eine ungünstige Namensverwirrung. Ist dieses Projekt nun der angesprochene RISC-V oder kommt es von Oberon: https://github.com/pulp-platform/pulpino/blob/master/doc/datasheet/datasheet.pdf Mit würde der Code für einen einfachen C-Simulator interessieren.
chris_ schrieb: > Ist dieses Projekt nun der angesprochene RISC-V oder kommt es von > Oberon: > > https://github.com/pulp-platform/pulpino/blob/master/doc/datasheet/datasheet.pdf Ja, das ist RISC-V. Oberon ist von 1994. Von da kommt nicht mehr viel.
Matthias S. schrieb: > Und dann gibts immer noch MIPS. Die stecken in Settopboxen, LCD Vor allem steckt MIPS in der Firma Imagination Technologies fest, die sich Momentan etwas auf dem absteigenden Ast befindet.
>Ja, das ist RISC-V. Oberon ist von 1994. Von da kommt nicht mehr viel.
Wobei das RISC-V instruction set von Oberon ziemlich minimalistisch ist,
was ich sehr liebe.
Der neue RISC-V scheint eher in Richtung High-Performance Computing zu
zielen. Sie reden zwar auch von einem kleinen 32-Bitter für IOT
Anwendungen, aber da scheint mir wieder das übliche Problem zu sein:
Wenn man etwas machen will, was für alles gut ist, ist es für nichts
optimal.
chris_ schrieb: > Mit würde der Code für einen einfachen C-Simulator interessieren. https://riscv.org/software-tools/risc-v-isa-simulator/ Und in Javascript: https://riscv.org/software-tools/riscv-angel/ (Bootet Linux im Browser)
Angehängte Dateien:
-
riscv-encoding.GIF
29 KB
chris_ schrieb: > Wobei das RISC-V instruction set von Oberon ziemlich minimalistisch ist, > was ich sehr liebe. Die Oberon-CPU scheint sich RISC5 zu schreiben. Dann gibt es auch keine Verwechselungen :) > Der neue RISC-V scheint eher in Richtung High-Performance Computing zu > zielen. Sie reden zwar auch von einem kleinen 32-Bitter für IOT > Anwendungen, aber da scheint mir wieder das übliche Problem zu sein: > Wenn man etwas machen will, was für alles gut ist, ist es für nichts > optimal. RISC-V berücksichtigt von vornerein einen skalierbaren Befehlssatz. Das kleinste Subset lässt sich auf 16 bit compressed instructions abbilden (ähnlich ARM thumb) und ist logisch auf >64 bit erweiterbar. Finde ich gut gemacht. Bei allen anderen Architekturen wurde so etwas hinterher dazu gebastelt.
chris_ schrieb: > Wenn man etwas machen will, was für alles gut ist, ist es für nichts > optimal. RISC V ist zunächst eine Architektur, die sich erkennbar für ein grosses Spektrum der Leistungsfähigkeit eignet. Also ARM sowohl im Markt des Cortex M0 als auch in dem des Cortex A72 ersetzen könnte. Für die Implementierung in Form von Cores gilt das jedoch nicht, d.h. dafür sind völlig verschiedene Cores erforderlich. Auch wenn ich persänlich ein Faible für Architekturen habe: Den Herstellern von Controllern und SoCs ist es einigermassen egal, wie der ADD Befehl codiert wird. Für die zählen völlig andere Kriterien. Neben direkten Kostenfragen über Lizenzen zählt auch, ob man überhaupt passende Cores im gesamten Einsatzspektrum kriegt und ob es eine Entwicklungsumgebung mit professionellem Anspruch gibt.
:
Bearbeitet durch User
A. K. schrieb: > Tim . schrieb: >> Das sollte der Suche nach Alternativen Aufwind geben. > > Welche Alternativen mit einem ähnlichen Angebot gibt es überhaupt? Also > mit einem Spektrum an Cores, die direkt bei den üblichen Fertigern > einsetzbar sind. Andescore deckt ein ähnliches Spektrum wie ARM ab: http://www.andestech.com/en/products/AndesCore.htm Ist allerdings nicht offen. Andes hat Patente auf einige ISA Features.
:
Bearbeitet durch User
ich persönlich glaube an den Erfolg der nächsten generation der Cortex-Ms auf basis der ARMv8 kerne. ARM lässt bereits mächtig die Werbetrommel schwingen.
@Ben W. (ben_w)
>ARM lässt bereits mächtig die Werbetrommel schwingen.
Früher (tm) wurde die Werbetrommel noch gerührt. So ändern sich die
Zeiten . . .
Hans schrieb: > Das dürfte spannend werden :) Weshalb? Befürchtungen, die werden alle ARMs einstampfen oder für $100 pro Stück lizenzieren, halte ich für unbegründet. Interessanter finde ich "Das Unternehmen hat bereits Schulden von über 100 Milliarden Dollar". Schon vor dem Kauf.
Moin, RISC-V ist pfiffig, aber wirklich neu ist an der Architektur ansich nix, IMHO nur eine verbesserte MIPS/MIPS16 und alles etwas homogener/konfigurierbarer, wobei ein Design in Verilog per se nicht so ne wahnsinns gute Nummer macht, was die einfache Konfigurierbarkeit angeht. Neu ist allerdings, dass doch einige Leute dran werkeln und die Sache auch unterhalten. Alle anderen cleveren Architekturen scheinen entweder die kritische Masse für laufend, breit unterhaltene OpenSource (mit zur Unterhaltung nötigen Geschäftsmodell) nicht so recht zu schaffen. Die Stolpersteine sind für die industrielle Anwendung schliesslich doch die Tools, wenn einer GCC mit Architektur XY will und das erst noch ein halbes Jahr dauert, bis alle Regresstests "passed" sind, fliegt das Ding in die Ecke. Wo es eine Menge robuster chinesischer/taiwanesischer MIPS-Derivate (teils lizenzfrei) gibt, sehe ich noch keinen umsatteln, und Europa wird lange noch an ARM festhalten, egal was passiert, da darf man auch von den Distributoren nicht zuviel an Agilität erwarten. Eher werden sich Distis aus einer mögl. Not heraus vermehrt diesen MIPS-Derivaten zuwenden und sie inkl. brauchbar übersetzter Doku der hiesigen Industrie schmackhaft machen. Alles andere geht noch Jahre.. Im uC-Segment (also Bereich stromsparend/billig/klein) sehe ich den Zweck von RISC-V gegenüber msp430 oder 8051 noch so gar nicht. Schlussendlich ist es dann die schlaue Peripherie, weswegen man Chip X einsetzt, und die Architektur ist marginal wichtig, sofern die Tools gut sind. Was Custom-Designs angeht, finden sich die irrsten Architekturen in den Chips wieder, wenn es schon ZPU auf Silicon gibt, dann auch sicher auch schon RISC-V. Aber das ist für den End-Entwickler kaum relevant. Grüsse, - Strubi
>Was kommt nach ARM? Wenn ich etwas zu sagen hätte, käme nach ARM der neue Typ namens: BEIN Bein ist die Abkürzung für: B edienfreundlich E rschwinglich I ndustrie-Einsatz tauglich N icht korrodierend Frei nach Rio Reiser: Das Alles -und noch viel mehr, würd' ich machen, wenn ich Schaltkreis-Hersteller wär'! https://www.youtube.com/watch?v=kxSbIhHQ320 MfG Paul :)
Proceedings des letzten RISC-V Workshops: https://riscv.org/2016/07/4th-risc-v-workshop-proceedings/ Es gibt ein paar interessante Beiträge. Nvidia will RISC-V für einen internen Controller verwenden: https://riscv.org/wp-content/uploads/2016/07/Tue1100_Nvidia_RISCV_Story_V2.pdf Debian port: https://content.riscv.org/wp-content/uploads/2016/07/Wed1115_Working_Towards_a_Debian_RISC-V_Port.pdf RISC-V Arduino port mitsamt FPGA core: https://riscv.org/wp-content/uploads/2016/07/Tue1600zec_fpgarduino_riscv_wsV2.pdf Den Core gibt es hier: https://github.com/f32c/f32c
Matthias schrieb: > Hurd auf RISC-V wird die Welt übernehmen. Ja direkt nach dem "Jahr des Linux Desktops". Kann also nicht mehr lange dauern....
Tim schrieb: > Proceedings des letzten RISC-V Workshops: Gähn. Ein halbes Jahr schon betreibst du diese plumpe Werbekampagne. Es wird langweilig.
Tja, und plötzlich springen die ersten größeren Firmen mit Produkten auf... Microsemi Offers First FPGA-Based RISC-V IP Core http://www.eetimes.com/document.asp?doc_id=1330851 Codasip and UltraSoC deliver advanced RISC-V SoC analysis and debug http://www.realwire.com/releases/Codasip-and-UltraSoC-deliver-advanced-RISC-V-SoC-analysis-and-debug Crowdfunding-Campagne für einen RISC-V Microcontroller. Hier geht es um echtes Silizium. The World's First Open Source RISC-V-based 32-bit μC https://www.crowdsupply.com/onchip/open-v
Tim . schrieb: > Mit dem Kauf > von Atmel durch Microchip, wird sich die Artenvielfalt dort auch > deutlich ausdünnen. So ein Quatsch. Auch der 8-Bit Markt wächst unaufhörlich weiter. Inzwischen sind die neuen Tiny 102/104, 417,814,816,817 hinzu gekommen und es sind schon die nächsten Typen in der Pipeline.
Tim . schrieb: > Crowdfunding-Campagne für einen RISC-V Microcontroller. Hier geht es um > echtes Silizium. > > The World's First Open Source RISC-V-based 32-bit μC Einzelstück für 49 $ (zzgl. Versand, zzgl. Zoll, zzgl. Einfuhrumsatzsteuer). Ein echtes Schnäppchen mithin.
Auch Samsung arbeitet angeblich an einem RISC-V SOC: http://www.androidauthority.com/samsung-risc-v-cpu-core-731670/
Immerhin läuft die Werbetrommel: http://www.golem.de/news/open-v-offene-risc-v-mcu-soll-arduino-kompatibel-werden-1611-124741.html
branadic schrieb: > http://www.golem.de/news/open-v-offene-risc-v-mcu-soll-arduino-kompatibel-werden-1611-124741.html >RISC-V-MCU soll Arduino-kompatibel werden So ein Unsinn. Seit wann werden CPUs "Arduino Kompatibel"? Einen Port der Arduino-Umgebung auf RISC-V gibt es übrigens schon länger.
:
Bearbeitet durch User
Hm.. Also zumindest gibt es jetzt ein Board im Arduino-Formfaktor, welches etwas professioneller aussieht: https://www.crowdsupply.com/sifive/hifive1 Den HDL Code gibt es gleich dazu. Ich hoffe, wir müssen nicht mehr lange auf die ersten China-Clones warten. Ist vielleicht ein sinnvolleres Ziel, als STM32 oder AVR nachzubauen?
Tim . schrieb: > Also zumindest gibt es jetzt ein Board im Arduino-Formfaktor, welches > etwas professioneller aussieht: naja, 16kB SRAM haut mich nicht um. 16kB instruction cache, ok, aber wenn ich das richtig lese, ist das Permanent-Flash (16MB) über SPI angebunden und off-chip. Und das alles für $59. Vergleich das mal mit dem H405 von Olimex (STM32 Cortex-M4): 192kB onchip-SRAM, 1MB onchip-Flashrom, von dem aus man Code direkt ausführen kann. Und das für 15 Euronen.
>naja, 16kB SRAM haut mich nicht um.
Vielleicht sind da die für ein Arduino Board etwas hohen 320MHz Sysclk
besser geeignet.
Markus schrieb: > Vielleicht sind da die für ein Arduino Board etwas hohen 320MHz Sysclk > besser geeignet. Nö. Denn was will man denn mit so hohem Takt, wenn man eh nichts Umfangreiches machen kann, weil der Speicher so klein ist? Und das nicht nur fürs RAM, sondern das ROM sieht auch mies aus. 16 MB, das ja, aber per SPI angebunden. Auf einmal real im Zugriff hat man nur 16 kB für Daten (SRAM) und weitere 16 kB für Code (den Icache). Welche dermaßen kleine Anwendung sollte denn 320 MHz brauchen? Drhystone reinladen und mit den hohen Zahlen angeben, viel mehr geht damit auch nicht. Das RISC-V-Konzept krankt bislang u.a. daran, daß es kein onchip-Flashrom im Direktzugriff gibt, bei keinem der bislang tatsächlich angegangenen Chips. Zum Rumspielen und Evaluieren ist das nicht so wichtig, aber tatsächlich brauchbar ist das nicht. Ob die AD/DA-Wandler taugen, davon gehe ich nicht aus, die werden ja nichtmal auf der Crowdfunding-Seite auch nur erwähnt. Falls sie überhaupt existieren. Vom Preis mal ganz zu schweigen - das Olimex-H405-Board bietet auch immerhin 168 MHz und kostet ein Viertel. Dann gibt es das H405 JETZT und in fertig. Bis dieses RISC-V-Board kommt, hat ST die M4-H7-Reihe nächstes Jahr raus, und dann reden wir über sowas wie 2 MB Flash-ROM, 16+16 kb Cache, 1 MB onchip-SRAM und 400 MHz. So, und dann muß man erstmal sehen, ob RISC-V auch dann noch mit dem Energieverbauch auftrumpfen kann, wenn sie ausstattungsmäßig gleichziehen. Im Moment ist das Ding ein nichtmal ansatzweise konkurrenzfähiger Chip.
Nop schrieb: > Im Moment ist das Ding ein nichtmal ansatzweise konkurrenzfähiger Chip. Ist leider vielen Open-Source Sachen so. Taugen meist nicht viel, aber immerhin OFFEN und KOSTENLOS und OFFEN! Diesmal fällt kostenlos allerdings auch noch weg, weil niemand aus den Quellen mal schnell selbst einen Controller erzeugen kann. Und wenn man mehr als 50$ pro Stück aufgerufen werden, muss man die Sinnhaftigkeit von Open-Source Hardware anzweifeln.
:
Bearbeitet durch User
Vielleicht ist es sinnvoll, sich zunächst einmal zu überlegen, was diese Firma überhaupt anbietet. HiFive bietet implementierungen der RISC-V ISA an, damit Andere diese in ihrem MCUs oder SOCs einsetzen können. Damit sind sie zunächst einmal mit ARM vergleichbar. ARM verkauft auch keine Microcontroller an kleine Bastlerbuden. Das machen die Kunden von ARM. Wie z.B. ST. Der Unterschied zwischen ARM und HiFive besteht darin, das ARM Patente auf deren ISA hat und damit die Lizenzierung und Nutzung ihrer Cores kontrolliert. Das geht so weit, dass es den Kunden von ARM nicht einmal erlaubt ist, den von ARM gelieferten Core zu modifizieren. Desweiteren sind die Lizenzgebühren nicht unerheblich. Deswegen ist ARM in der Industrie nicht unbedingt beliebt. Diese Beschränkungen fallen bei RISC-V dank der frei verfügbaren ISA weg. Das HiFive1 devkit ist nur ein Vehikel, um Kunden und Interessenten zu erlauben, den Core bereits zu Testen. Ich gehe nicht davon aus, das HiFive ST und Microchip konkurrenz machen will. Die Konkurrenz könnte vielmehr von MCU-Anbietern kommen, die statt eines ARM cores einen RISC-V Core einsetzen. Diese könnte relativ kurzfristig z.B. für chinesische Anbieter interessant sein, die keine ARM Lizenz verhandeln wollen und momenten auf 8051 u.Ä. setzen. (Davon gibt es viele!) Man denke an den ESP8266... Eine weite Verbreitung würde ich aber zuerst bei embedded controllern erwarten, die für Nutzer nicht sichtbar sind, und mit einer fixen Firmware arbeiten. Hier bereitet der Umstieg auf eine andere ISA am wenigsten Probleme und es gibt sofort Einsparungen und Vorteile durch weniger restrive Lizenzen.
:
Bearbeitet durch User
Tim . schrieb: > HiFive bietet implementierungen der RISC-V ISA an, damit Andere diese in > ihrem MCUs oder SOCs einsetzen können. Damit sind sie zunächst einmal > mit ARM vergleichbar. OK. Wenn HiFive keine Lizenzen verlangt, wie sieht dann ihr Geschäftsmodell aus? Arbeiten deren Angestellte für Licht und Liebe? Oder wird das mehr so dieses typisch Opensource-mäßige Hinschmeißen und "mach's im Ernstfall halt selber"? > Das geht so weit, dass es den Kunden von ARM nicht einmal > erlaubt ist, den von ARM gelieferten Core zu modifizieren. Das ist auch gut so, denn sonst hätte man sowas wie CMSIS und kompatible Compiler nicht, sondern jeder Chiphersteller würde im Versuch eines vendor-lock-in die ISA nach Art von Microsoft verändern: embrace, extend, destroy. > Diese Beschränkungen fallen bei > RISC-V dank der frei verfügbaren ISA weg. Die Folge: Die eigentlichen Chiphersteller können die ISA abändern, um zu nichts kompatibel zu sein. Vendor-lock-in olé. ST versucht diesen Move auf ARM ja mit der SPL/HAL auf Software-Ebene, ist damit aber wenig erfolgreich, weil man das Zeug ja nicht nutzen braucht. > Die Konkurrenz könnte vielmehr von MCU-Anbietern kommen, die statt eines > ARM cores einen RISC-V Core einsetzen. Dazu müßten die aber dann noch eine Menge Arbeit reinstecken, weil die ganzen Sachen, die bei RISC-V als Bastel-Uni-Projekt schlichtweg fehlen (siehe mein Vorposting) reinzukriegen. Da sie einfach fehlen, wird jeder MCU-Anbieter da sein eigenes Süppchen kochen und zu nichts kompatibel sein. Idealerweise wird auch die ISA noch etwas verfrickelt. > Hier bereitet der Umstieg auf eine andere ISA am > wenigsten Probleme Klar doch. Interrupt-Latenzen sind völlig anders, Zeitverhalten damit auch, man braucht nen anderen Compiler, und Test/Zertifizierung machen sich auch allesamt gratis. Alles wurscht, denn für Akademiker zählt allein die Schönheit der ISA. Das sind dieselben Nörgler, die an x86 den häßlichen Assembler auszusetzen haben und nicht verstehen, wieso jemand CPUs mit einem so häßlichen Assembler denn benutzen wollen sollte. Und wieso man nicht bei 68k geblieben ist - denn die hatten den alles entscheidenden Vorteil des viel hübscheren und orthogonalen Befehlssatzes. > Vorteile durch weniger restrive Lizenzen. Mit dem Nachteil durch den absehbaren vendor-lock-in, den man bei ARM so nicht hat, WEIL ARM das verhindert. Denn dies wäre zwar im Interesse der Chiphersteller, wäre aber ein pauschales Argument gegen ARM insgesamt. Sowas wie CMSIS wird es auf RISC-V schlichtweg nicht geben, dafür sorgen die Chiphersteller dann schon.
Tim . schrieb: > Vielleicht ist es sinnvoll, sich zunächst einmal zu überlegen, was diese > Firma überhaupt anbietet. Ich denke, das ist den meisten hier klar. Genauso klar dürfte sein, daß den meisten hier damit nicht geholfen ist. Was wir brauchen ist ein Produkt in Silizium. > Der Unterschied zwischen ARM und HiFive besteht darin, das ARM Patente > auf deren ISA hat und damit die Lizenzierung und Nutzung ihrer Cores > kontrolliert. Das geht so weit, dass es den Kunden von ARM nicht einmal > erlaubt ist, den von ARM gelieferten Core zu modifizieren. 1. sehe ich darin kein Problem und 2. ist das auch gut so (Kompatibilität) > Desweiteren sind die Lizenzgebühren nicht unerheblich. Wenn ich mir anschaue, für wie wenig Geld ST seine Cortex-M0 vertickt, dann können die Lizenzkosten nicht viel ausmachen. > Deswegen ist ARM in der Industrie nicht unbedingt beliebt. Definiere "Industrie". Aus meiner Sicht als Endverbraucher scheinen ARM Cores alles andere als unbeliebt zu sein. > Diese Beschränkungen fallen bei RISC-V dank der frei verfügbaren ISA weg. Ich kann darin erstmal keinen direkten Vorteil für mich erkennen. Im Gegenzug habe ich eine ganz neue Architektur. Kinderkrankheiten sowohl im Silizium als auch in der Toolchain müssen erst mal ausgemerzt sein. > Ich gehe nicht davon aus, das > HiFive ST und Microchip konkurrenz machen will. Sowieso nicht. Wenn überhaupt, dann ist ARM der Konkurrent. > Die Konkurrenz könnte vielmehr von MCU-Anbietern kommen, die statt > eines ARM cores einen RISC-V Core einsetzen. Nur zu. Das ist ja die Hauptbeschwerde aller Vorposter, daß es keine tauglichen Produkte gibt. Sagen wir mal das Äquivalent eines STM32F102 (bezüglich RAM/FLASH/IO) mit RISC-V Kern.
Tim . schrieb: > Der Unterschied zwischen ARM und HiFive besteht darin, das ARM Patente > auf deren ISA hat und damit die Lizenzierung und Nutzung ihrer Cores > kontrolliert. Das geht so weit, dass es den Kunden von ARM nicht einmal > erlaubt ist, den von ARM gelieferten Core zu modifizieren. Desweiteren > sind die Lizenzgebühren nicht unerheblich. Deswegen ist ARM in der > Industrie nicht unbedingt beliebt. Diese Beschränkungen fallen bei > RISC-V dank der frei verfügbaren ISA weg. Bin mir nicht sicher, ob da grade etwas Verwirrung geschaffen wird: Ist nicht SiFive die Firma, und HiFive nur das Kit? Es gibt noch einen weiteren Aspekt: Sicherheitsrelevante Entwicklungen. Da punktet der RISC-V auf jeden Fall gegenüber Intel, bei ARM kann man sich streiten. Ich würde mal behaupten, dass zumindest ARMv4 zu viele unabgedeckte Szenarien erlaubt. Jeder kann den Risc-V Core selbst verifizieren. Nop schrieb: > Und wieso man nicht bei 68k geblieben ist - denn die hatten den alles > entscheidenden Vorteil des viel hübscheren und orthogonalen > Befehlssatzes. Hübsch schon. Aber so richtig orthogonal? (moveb/movep, ...) An den Registern ist schon mal gar nix orthogonal. Auch die 68k Architektur hatte eine Menge undokumentierte/fehlerhafte Funktionalität. Kann man natürlich heutzutage besser durchverifizieren, aber dennoch bleibt eins: Die 68k-Logik ist nicht gerade kompakt, schnell und stromsparend zu realisieren. Dem RISC-V würde ich definitiv Chancen gegenüber ARM geben. Zum Thema Vendor-Lockin: Am Core/ISA rumzudrehen macht typischerweise kein Implementierer, nicht weil es ihm verboten ist, sondern weil er mit der Verifizierung und Anpassung der Tools mehr Geld rausschmeisst, als er mit der Sache schlussendlich verdient. Das bereits existierende "Lock-In" machen heute alle ARM-Backstuben über ihre eigene Peripherie. Die 8051-Derivate aus China sind ein gutes Beispiel. Fing mit dem "Chip for People" an, inzwischen gibt es unzählige Varianten, die etwas DSP-Logik rangeflanscht bekommen und immer noch mit dem SDCC funktionieren. Keiner ist da je auf den Gedanken gekommen, an der ISA rumzudrehen. Für Obfuscation, wenn gewollt, gibts Verschlüsselung. Kleine Modifikationen (Taktzyklen) sind vielleicht betr. speziellen Implementation (stromsparen) nötig. Und gewisse Slots für Befehlserweiterung gewollt. Da bin ich mir mein RISC-V noch nicht im Klaren, wie das in Zukunft abgehandelt werden soll.
Axel S. schrieb: > Wenn ich mir anschaue, für wie wenig Geld ST seine Cortex-M0 vertickt, > dann können die Lizenzkosten nicht viel ausmachen. M0 wird billiger sein als A73. Aber sie sind in dem Sinn fair, als alle vergleichbare Bedingungen haben dürften. ARM selbst tritt nicht in Konkurrenz mit Lizenznehmern. Das ist bei eingekauften proprietären Architekturen anders, bei denen ist der Lizenzgeber oft auch Konkurrent. Eigene Architekturen ersparen zwar Lizenzen, aber jene, die damit anfangen, tragen einen wesentlichen Teil der Infrastruktur-Supports auf eigenen Schultern. Ob die Architektur offen ist oder nicht erspart in diesem Stadium nicht wirklich viel. Jene, die auf den fahrenen Zug springen, haben es leichter.
Strubi schrieb: > Zum Thema Vendor-Lockin: Am Core/ISA rumzudrehen macht typischerweise > kein Implementierer, nicht weil es ihm verboten ist, sondern weil er mit > der Verifizierung und Anpassung der Tools mehr Geld rausschmeisst, als > er mit der Sache schlussendlich verdient. Beim Integer-Kern einer ISA weniger. Aber bei Fliesskomma-Support, insbesondere SIMD, halte ich die Wetten für offen. Da wäre die Versuchung gross, eigene Ideen einzubringen. Auch ARM selbst hat an dieser Stelle ein paar Iterationen inkompatibler ISAs hinter sich.
:
Bearbeitet durch User
A. K. schrieb: > > Beim Integer-Kern einer ISA weniger. Aber bei Fliesskomma-Support, > insbesondere SIMD, halte ich die Wetten für offen. Da wäre die > Versuchung gross, eigene Ideen einzubringen. Auch ARM selbst hat an > dieser Stelle ein paar Iterationen inkompatibler ISAs hinter sich. ARM geht da auch nicht mit bestem Beispiel voran, ich würde sogar sagen, da herrscht ein gewaltiger Wildwuchs. Das sieht beim MIPS besser aus. Ich denke mal, da haben sich die federführenden RISC-V-Köppe schon Gedanken gemacht. Gegen Erweiterungen ist ja ansich nichts einzuwenden. Wie sieht es denn mit vendor-spezifischen SIMD bei der RISC-V aus? Hat sich das mal jemand genauer angesehen?
Also gut wäre es wenn RISC-V unter die GPL gestellt werden würde. Bei ARM ist die ganze Entwicklung von einer Firma abhängig und dieses Monopol wird über lange Zeit nicht erwünscht sein vorallem dann wenn es nur noch ARM gibt.
arrrg schrieb: > Also gut wäre es wenn RISC-V unter die GPL gestellt werden würde. Ja, dann stirbt das Projekt garantiert.
NOP schrieb >Markus schrieb: >> Vielleicht sind da die für ein Arduino Board etwas hohen 320MHz Sysclk >> besser geeignet. > >Nö. Denn was will man denn mit so hohem Takt, wenn man eh nichts >Umfangreiches machen kann, weil der Speicher so klein ist? Und das nicht >nur fürs RAM, sondern das ROM sieht auch mies aus. 16 MB, das ja, aber >per SPI angebunden. Auf einmal real im Zugriff hat man nur 16 kB für >Daten (SRAM) und weitere 16 kB für Code (den Icache). Eine hohe Taktfrequenz ist ziemlich nützlich für Signalverabeitungsaufgaben. Außerdem dürfte der Prozessor ziemlich wenig Strom brauchen, wenn man ihn z.B. mit 1MHz betreibt. Der Speicher ist natürlich etwas klein. Aber nicht jede Anwendung braucht viel Speicher und er ist nur ein Gütekriterium bei der Auswahl einer MCU.
arrrg schrieb: > Also gut wäre es wenn RISC-V unter die GPL gestellt werden würde. > Geht gottseidank nicht mehr, aber da gibt es min. zwei Contras: - GPL greift bei HW nicht, mir ist keine wasserdichte Variante bekannt, die sich auf HDL anwenden lässt. Das hätte zudem nur nur abschreckende Wirkung. - Selbst wenn sie das wäre: Die grossen Chipfirmen sind sehr gut darin, die GPL stinkefrech zu verletzen und sich mit der FSF jahrelange Versteckspiele zu liefern. Das wäre weiter kontraproduktiv für den Nutzer. > Bei ARM ist die ganze Entwicklung von einer Firma abhängig und dieses > Monopol wird über lange Zeit nicht erwünscht sein vorallem dann wenn es > nur noch ARM gibt. Monopol? Es gibt noch MIPS, ARC, Xtensa, ...
Und was will man mit RISC-V ohne GPL? Dann nehmen sich die Chipfirmen das HDL als Ausgangspunkt, basteln dran rum, bauen Backdoors ein und produzieren dann. Das wird genauso closed wie das, was es jetzt auch schon gibt. Also kann man "das ist open" schonmal realistisch gesehen wegstreichen, denn das wird es nicht sein. Bleiben also die Lizenzkosten. Wird trotzdem teurer, weil die Opportunitätskosten des Umstiegs wie bei jedem Zuspätkommer die hohen STückzahlen verhindern, und dann hat man statt der Lizenzkosten eben höhere Stückkosten durch geringere Zahlen.
Nop schrieb: > Und was will man mit RISC-V ohne GPL? Dann nehmen sich die > Chipfirmen > das HDL als Ausgangspunkt, basteln dran rum, bauen Backdoors ein und > produzieren dann. Das wird genauso closed wie das, was es jetzt auch > schon gibt. > Und Du denkst, GPL macht da Sinn? Lies nochmal oben. Die kommerzielle Akzeptanz der GPL geht nach meiner Erfahrung gegen Epsilon und ist für HDL, geschweige Silizium, schon gar nicht klar definiert. Man stelle sich schon mal die Frage, ob GPL-Core und Flash-Technik auf demselben Die "legal" zu realisieren wäre... Es gibt einen entscheidenden Punkt beim offenen Design - jenseits von Lizenzdetails: Abweichungen vom Originaldesign sind relativ leicht aufzufinden, wenn man weiss, wonach man schauen muss. Intel darf sich mit entdeckten Backdoors blamieren, ein Newcomer eher nicht... > Also kann man "das ist open" schonmal realistisch gesehen wegstreichen, > denn das wird es nicht sein. > > Bleiben also die Lizenzkosten. Wird trotzdem teurer, weil die > Opportunitätskosten des Umstiegs wie bei jedem Zuspätkommer die hohen > STückzahlen verhindern, und dann hat man statt der Lizenzkosten eben > höhere Stückkosten durch geringere Zahlen. Rein spekulative Aussage. Aus dem ramp-up kann man nicht auf die Zukunft schliessen. Im Übrigen glaube ich nicht, dass SiFive nicht rechnen kann...
A. K. schrieb: > ARM selbst tritt nicht in Konkurrenz mit Lizenznehmern. Das ist > bei eingekauften proprietären Architekturen anders, bei denen ist der > Lizenzgeber oft auch Konkurrent. NOCH nicht... Denn nach der Übernahme durch SoftBank sieht das evtl. anders aus. SoftBank ist ja auch durchaus selber als Produktanbieter aktiv. https://techcrunch.com/2016/09/05/softbank-has-completed-its-24b-cash-acquisition-of-arm-holdings/ https://de.wikipedia.org/wiki/Softbank /regards
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.