Mit dem Shakti C-Class Prozessor ist den Forschern am Indian Institute of Technology Madras ein Erfolg beim ersten Anlauf geglückt. In Kooperation mit Western Digital und Intel entstand der Chip in 22nm FinFET-Technologie. Wenn es nach den Entwicklern geht, ist das jedoch erst der Beginn des Projektes.
RISC-V als offene Alternative zu patentierten Architekturen wie AMD64 oder ARM v8 steht derzeit noch in den Startlöchern, wobei die Unterstützung durch bekannte Softwareprojekte wie etwa binutils, GCC, Linux oder glibc stetig wächst. Deutlich geringer ist jedoch die Anzahl verfügbarer Prozessoren oder gar geeigneter Testhardware, um etwa ein Betriebssystem wie Linux zu nutzen.
Die Shakti C-Klasse Prozessoren stellen nicht nur Indiens ersten auf der RISC-V Architektur basierenden Prozessor dar, sondern ermöglichen bereits die Nutzung einer eigenen Linux-Variante. Dabei wird der 64-bit-Prozessor derzeit mit 400 MHz betrieben, wobei das Augenmerk bei der Entwicklung besonders auf den stromsparenden Betrieb gelegt wurde. Als Anwendungsszenario für die C-Klasse wird IoT genannt, dabei sind bereits weitere Prozessorreihen für Server und AI in Planung.
Das Projekt selbst ist quelloffen und steht unter einer BSD-Lizenz zur kostenlosen Nutzung bereit, die Universität möchte keine Patente anmelden. Neben dem Design werden auch die nötigen Daten zur Verfügung gestellt, um das Projekt mit einem FPGA zu testen.
Klingt interessant. Aber leider auf der Projektseite:
"Diese Website ist nicht erreichbar
Die Antwort von rise.cse.iitm.ac.in hat zu lange gedauert.
Auf Google nach rise cse iitm ac shakti suchen
ERR_CONNECTION_TIMED_OUT"
Bei mir lädt die Projektseite ab und an, es sieht aber nicht so aus, als
ob diese häufig gepflegt wird. Nähere Informationen zu dem aktuellen
Chip entnimmt man am Besten dem verlinkten Präsentationsfolien oben. Ein
Interview mit den Entwicklern hinter dem Projekt (Stand November 2017)
gibt einen guten Einblick in die Motivation und wo sie auf lange Sicht
hin wollen;
https://factordaily.com/india-chip-design-shakti-iit-madras/
Coole Sache. RISC-V Foundation, SciFive, EPI, Pulp, IIT... da ist im
Moment ein beachtlicher Schub hinter dem RISC-V Thema. Wenn das so
weitergeht, müssen sich einige Leute wARM anziehen (sorry, kleines
Wortspiel). Wird auch Zeit, technologische Monokulturen sind immer
Innovationsbremsen. Das sieht man in vielen Bereichen, wo es außer einem
"Marktführer" nichts nennenswertes gibt.
Ich schätze mal, das Ganze wird so ablaufen: Am Anfang will keiner
RISC-V haben, wegen fehlendem Ecosystem, Vorurteilen usw (aktueller
Zustand). Jetzt von einem ARM-Killer zu reden, ist noch etwas früh. Dann
werden die ersten kleinen und mittelständischen RISC-V für spezielle
Anwendungen einsetzen, weil es die einzige Alternative zu einer teuren
Eigentwicklung und zur Preis- und Lizenzpolitik vom ARM ist. Vielleicht
(hoffentlich) wird es mal einen Raspberry auf RISC-V-Basis geben, den
Anfangs nur die Freaks, später viele andere benutzen. Dadurch wird sich
die Toolchain weiterentwickeln und irgendwann tauchen die Teile in den
ersten Konsumerprodukten auf, ohne dass jemand etwas davon merkt. Das
ist dann der Durchbruch.
RISC-V ist jedenfalls das Beste, was in den letzten 20 Jahren aus den
USA rüber kam... Chapeau, Berkley :-)
Wenn es die Infrastruktur der Entwicklungs- und Debugwerkzeuge in
adäquater Qualität gibt, könnten die Hersteller von Mikrocontrollern und
von SOCs für Embedded Systems durchaus an RISC-V interessiert sein. Da
ist der Preisdruck recht hoch und es spart Lizenzkosten.
Beim RasPi in seinem ursprünglichen Ansatz, nämlich mit leistungsfähigem
Videoprozessor, ist das Problem freilich nicht der CPU-Core, sondern die
GPU. Und insbesondere deren Software-Unterstützung. Gibts da ein ebenso
freies und ausreichend leistungsfähiges Pendant wie beim CPU-Core?
@ Vancouver (Gast)
>RISC-V ist jedenfalls das Beste, was in den letzten 20 Jahren aus den>USA rüber kam... Chapeau, Berkley :-)
Was ist denn so gut und besonders an RISC-V, außer daß es Open Source
ist? Es mag ja sein, daß RISC-V zum Linux der Hardware werden könnte.
Schau mer mal.
Falk B. schrieb:> Was ist denn so gut und besonders an RISC-V
Es ist eine gut durchdachte und leistungsfähige ISA, die jeder verwenden
kann. Kein Bastelprojekt von einer handvoll Enthusiasten. Bis das ganze
konkurrenzfähig zu ARM wird, gibts noch einiges zu tun, aber wie gesagt,
die Sache läuft an.
@A.K. Spricht ja nichts dagegen, einen RISC-V SoC mit einer GPU
aufzuhübschen. Wobei ich persönlich den Eindruck habe, dass nur wenige
Raspi-Projekte tatsächlich die GPU verwenden. Aber da täusche ich mich
vielleicht.
Falk B. schrieb:> Was ist denn so gut und besonders an RISC-V, außer daß es Open Source> ist?
Das ist eine sauber definierte RISC-Architektur mit einigen
anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger.
Vorteil gegenüber ARM ist die Lizenzfreiheit, und die Freiheit, sie nach
eigenen Wünschen anpassen zu können.
Limitierungen bei der Übernahme als Quasi-Ersatz des ARM Cores könnten
im Uncore liegen. Debuggingmodule, Speicher- und Peripheriebusse etc.
Wenn man diese Räder neu erfinden muss, kommt auch etwas Arbeit hinzu.
Vancouver schrieb:> Wobei ich persönlich den Eindruck habe, dass nur wenige> Raspi-Projekte tatsächlich die GPU verwenden.
Allerdings ist die Sicht von Teilnehmer eines Mikrocontroller-Forums
vielleicht etwas einseitig. Ich kenne jedenfalls jemanden, der einen
RasPi als TV/Video-Lösung verwendet.
Vancouver schrieb:
Die Begeisterung in Ehren, aber
> Dann> werden die ersten kleinen und mittelständischen RISC-V für spezielle> Anwendungen einsetzen, weil es die einzige Alternative zu einer teuren> Eigentwicklung und zur Preis- und Lizenzpolitik vom ARM ist.
welcher kleine oder Mittelständler hat eine eigene ARM-Lizenz? Hier ist
keiner dabei:
https://de.wikipedia.org/wiki/ARM-Architektur#Lizenznehmer
Als kleiner oder Mittelständler kauft man vielmehr fertige Chips für
0,50 - 100€ von Chip-Herstellern, die eine Lizenz haben. Und in den 0,50
- 100€ sind die Lizenzkosten schon drin und da sehe ich nicht wie RISC V
signifikant günstiger sein soll.
Insofern sehe ich da preislich oder bzgl. Lizenzkosten keine Vorteile
und teuer ist ARM auch nicht.
Spaß macht es aber trotzdem der Entwicklung zu folgen :)
A. K. schrieb:> Falk B. schrieb:>> Was ist denn so gut und besonders an RISC-V, außer daß es Open Source>> ist?>> Das ist eine sauber definierte RISC-Architektur mit einigen> anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger.> Vorteil gegenüber ARM ist die Lizenzfreiheit, und die Freiheit, sie nach> eigenen Wünschen anpassen zu können.
Das scheint mir eine Scheinfreiheit zu sein. So wie einem niemand
verbieten kann, auf dem Mond herumzuspazieren, weil der keinem gehört.
Nur kommt man nicht einfach mal so dort hin.
Denn die Lizenzfreiheit und Anpassungsmöglichkeiten einer Architektur
spielen doch nur eine Rolle, wenn man eigene Chips bauen will und vor
allem kann. Dafür braucht man ein Projekt um Umfang von vielen Mio €...
@ A. K. (prx)
>> Was ist denn so gut und besonders an RISC-V, außer daß es Open Source>> ist?>Das ist eine sauber definierte RISC-Architektur mit einigen>anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger.
Sind die Architekturen von ARM & Co nicht sauber definiert?
Nikolaus S. schrieb:> Denn die Lizenzfreiheit und Anpassungsmöglichkeiten einer Architektur> spielen doch nur eine Rolle, wenn man eigene Chips bauen will und vor> allem kann.
Klar. Der Mittelständler wird das bleiben lassen.
> Dafür braucht man ein Projekt um Umfang von vielen Mio €...
Adressaten sind eher Hersteller von den hier bekannten Microcontrollern,
aber auch Broadcom mit seinen SOCs für Embedded. Atmel hat immerhin
AVR32 erfunden umd irgendwelchen Grenzen oder Lizenzen zu entgehen.
Falk B. schrieb:>>Das ist eine sauber definierte RISC-Architektur mit einigen>>anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger.>> Sind die Architekturen von ARM & Co nicht sauber definiert?
RISC-V ist eine sauber definierte RISC-Architektur mit einigen
anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger hatte
ich geschrieben. ;-)
Nicht jede Antwort ist eine Kritik an dem, was in ihr nicht gesagt
wurde.
@ A. K. (prx)
>aber auch Broadcom mit seinen SOCs für Embedded. Atmel hat immerhin>AVR32 erfunden umd irgendwelchen Grenzen oder Lizenzen zu entgehen.
Oder weil man es einfach mal selber machen wollte. Denn man bedenke, der
Zustand, daß es scheinbar nur noch ARM und Intel gibt, ist noch nicht
allzu alt. Es gab schon viele CPU-Architekturen auf dem Markt, auch wenn
die meisten wieder verschwunden sind bzw. nicht mehr expandieren. MIPS
etc.
Vancouver schrieb:> Vielleicht> (hoffentlich) wird es mal einen Raspberry auf RISC-V-Basis geben
Davon würde ich nicht ausgehen, wenn man die Wahl nach ihrem derzeitigen
SoC ansieht.
In der Frage nach dem Wenn und Aber zu Risc-V wäre Western Digital ein
Beispiel, der eine Eigenentwicklung gegenüber einer fertigen Arm Lösung
als wirtschaftlich ansieht.
https://www.computerbase.de/2017-11/western-digital-risc-v/
Operator S. schrieb:> Davon würde ich nicht ausgehen, wenn man die Wahl nach ihrem derzeitigen> SoC ansieht.
Naja ich meinte einen Klon. Selber Formfaktor, selbe Interfaces aber
eben ein RISC-V in der Mitte.
Vancouver schrieb:> Naja ich meinte einen Klon. Selber Formfaktor, selbe Interfaces aber> eben ein RISC-V in der Mitte.
Genau dann spielen die bisher zur Anbindung von internem Speicher und
Peripherie verwendeten Busse eine Rolle. Die werden bisher von ARM sein.
Und nun?
A. K. schrieb:> Die werden bisher von ARM sein.
Ja, AMBA vermutlich. Der Standard ist offen. Daran kannst Du SPI, I2C,
I2S, DDRx, UART, USB, SATA, HDMI... anschließen, nichts davon ist
ARM-spezifisch. Die Cores gibt es wie Sand am Meer, offen oder
prorietär, was Dir lieber ist. Oder was meinst Du?
Vancouver schrieb:> Ja, AMBA vermutlich. Der Standard ist offen. Daran kannst Du SPI, I2C,> I2S, DDRx, UART, USB, SATA, HDMI... anschließen, nichts davon ist> ARM-spezifisch. Die Cores gibt es wie Sand am Meer, offen oder> prorietär, was Dir lieber ist. Oder was meinst Du?
Ob man eine Lizenz benötigt um einen solchen von ARM definierten Bus
auch dann verwenden zu dürfen, wenn man keinen ARM-Core verwendet.
A. K. schrieb:> Falk B. schrieb:>>>Das ist eine sauber definierte RISC-Architektur mit einigen>>>anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger.>>>> Sind die Architekturen von ARM & Co nicht sauber definiert?>> RISC-V ist eine sauber definierte RISC-Architektur mit einigen> anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger hatte> ich geschrieben. ;-)
Über den Begriff sauber könnte gerade bei RISC-V gestritten werden...
Es gibt vier sog. Basismodule (drei für die unterschiedlichen
Adressbreiten 32, 64 und 128-Bit und ein abgespecktes für
Microcontroller, RV32E genannt) und z.Z. 13 Erweiterungen...
Es gibt zwei + n Befehlslängen: 32-Bit und 16-Bit komprimiert und
variabler Länge (Vielfache von 16-Bit).
RV32E ist deutlich abgespeckt: Statt 32 x 32-Bit Register nur noch 16,
andere Aufrufkonvention/ABI, unterstützt optional nur die Erweiterungen
M (Multiplikation/Division), A (atomare Zugriffe/Reihenfolge) und C
(komprimierter Befehlssatz). D.h. keine Bitmanipulationsbefehle (B),
keine Fließkommazahlen (F, D, Q), keine Dezimalzahlen nach IEEE (L),
keine User-Level-Interrupts (N) 1), keine SIMD (P), keine Vektorbefehle
(V) usw. usf.
Was fehlt noch? Bspw. Addition/Subtraktion mit Carry (lassen sich
allerdings auch ohne Sprünge nachbauen), ebenso ist nicht spezifiziert
wie sich Multiplikation oder Shifts verhalten (Single-Cycle, variabel
etc.). Schlecht für Kryptographie 2)
Aufgrund der herstellerspezifischen Erweiterungen dürfte es guten
Wildwuchs geben.
Was mir allerdings gefällt ist der optionale Vektorbefehlssatz...
1) "User-level interrupts are primarily intended to support
secure embedded systems with only M-mode and U-mode present,
but can also be supported in systems running Unix-like
operatingsystems to support user-level trap handling"
2)
https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/Prak1SLbys8
Falk B. schrieb:> Was ist denn so gut und besonders an RISC-V,> außer daß es Open Source ist?
Es ist eine kleine, sauber definierte ISA. Die aktuelle ARM-ISA ist ja
inzwischen jenseits von gut und böse (also ARMv8.3-A, nicht Cortex-M0).
Ansonsten kommt es auf die ISA nicht wirklich an. Relevant sind die
Implementierungen, und die kommen langsam in die Gänge, was ich gut
finde.
Falk B. schrieb:> Es gab schon viele CPU-Architekturen auf dem Markt,> auch wenn die meisten wieder verschwunden sind bzw.> nicht mehr expandieren. MIPS etc.
Hmm, MIPS ist etwas, was an vielen Stellen auftaucht und worüber man
nicht oft redet. Ein bisschen wie BSD, was man auch eher unerwartet
findet, weil darüber - im Gegensatz zu Linux - nicht geredet werden
muss.
Arc N. schrieb:> Über den Begriff sauber könnte gerade bei RISC-V gestritten werden...
Es gibt eine ziemliche Variationsbreite von Möglichkeiten, wobei die
meisten aber doch ziemlich irrelevant sind. Die meisten SoCs werden
vermutlich auf RV32E, RV32I/RV32G oder RV64G mit Erweiterungen setzen,
je nach Marktsegment.
Im Gegensatz zu MIPS darf man wenigstens keine Instruktionen weglassen,
d.h. wenn IM drinsteht, dann ist das auch vorhanden, und es lässt sich
zur Laufzeit abfragen. Das vereinfacht Betriebssysteme.
Es gibt halt noch keine dominierenden Standard-Cores. Die kommen mit der
ersten Massenfertigung und kosten dann Lizenzgebühren. :-)
Arc N. schrieb:> Aufgrund der herstellerspezifischen Erweiterungen dürfte es guten> Wildwuchs geben.
Glaube ich nicht. Die Entwicklung von schnellen Chips ist so teuer, dass
da nur wenige Firmen mitmischen. Und auch aktuelle langsamere Chips
werden mit Zusatzperipherie vollgestopft, um Varianten zu sparen, also
kommt es da auf ein paar Transistoren mehr oder weniger nicht so sehr
an.
Arc N. schrieb:> Was fehlt noch? Bspw. Addition/Subtraktion mit Carry
Flags sind trivial bei kleinen Cores, wie sie in Mikrocontrollern
verwendet werden. Aber bei Hochleistungsprozessoren sind sie
ausgesprochen hinderlich, hoher Aufwand bei wenig Ertrag.
> ebenso ist nicht spezifiziert> wie sich Multiplikation oder Shifts verhalten (Single-Cycle, variabel> etc.).
Das gehört auch nicht in eine Architekturdefinition, sondern ist eine
Sache der Implementierung.
> Aufgrund der herstellerspezifischen Erweiterungen dürfte es guten> Wildwuchs geben.
Das steht zu befürchten.
Arc N. schrieb:> Aufgrund der herstellerspezifischen Erweiterungen dürfte es guten> Wildwuchs geben.
Genau das gibt ARM auch als negativ an für potentielle RISC-V Kunden.
Aber ist es bei ARM nicht auch so? Wildwuchs ohne Ende?
Beim67Bit schrieb:> Aber ist es bei ARM nicht auch so? Wildwuchs ohne Ende?
Es gibt nur sehr wenige ARM-Cores, die nicht von ARM selbst stammen
(z.B. Qualcomm Kryo ein). Damit macht ARM den Wildwuchs ziemlich allein.
Was die SoCs und deren Peripherie angeht, die sind sowieso
herstellerspezifisch und daran wird sich mit RISC-V auch nichts ändern.
Vancouver schrieb:> @A.K. Spricht ja nichts dagegen, einen RISC-V SoC mit einer GPU> aufzuhübschen.
Dann war's das aber auch gleich wieder mit der freien und offenen
Architektur. Die GPUs sind ja noch vernagelter als die CPUs.
A. K. schrieb:> RISC-V ist eine sauber definierte RISC-Architektur mit einigen> anwendungsspezifischen Ausbaustufen. Nicht mehr und nicht weniger hatte> ich geschrieben. ;-)>> Nicht jede Antwort ist eine Kritik an dem, was in ihr nicht gesagt> wurde.
Dann passt die Antwort aber nicht zur Frage. Denn die war ja, was die
Besonderheit von RISC-V ist. Wenn die saubere Definition aber das ist,
was RISC-V so besonders macht, dann impliziert das ja, dass die
"herkömmlichen" Lösungen eben keine saubere Definition haben.
S. R. schrieb:> Beim67Bit schrieb:>> Aber ist es bei ARM nicht auch so? Wildwuchs ohne Ende?>> Es gibt nur sehr wenige ARM-Cores, die nicht von ARM selbst stammen> (z.B. Qualcomm Kryo ein). Damit macht ARM den Wildwuchs ziemlich allein.>> Was die SoCs und deren Peripherie angeht, die sind sowieso> herstellerspezifisch und daran wird sich mit RISC-V auch nichts ändern.
Samsung und Apple haben auch eigene Cores.
A. K. schrieb:> Arc N. schrieb:>> Was fehlt noch? Bspw. Addition/Subtraktion mit Carry>> Flags sind trivial bei kleinen Cores, wie sie in Mikrocontrollern> verwendet werden. Aber bei Hochleistungsprozessoren sind sie> ausgesprochen hinderlich, hoher Aufwand bei wenig Ertrag.
Ja, siehe zweiter Link oben. Wollte das Thema aber nicht sofort in den
Thread ziehen ;)
>> ebenso ist nicht spezifiziert>> wie sich Multiplikation oder Shifts verhalten (Single-Cycle, variabel>> etc.).>> Das gehört auch nicht in eine Architekturdefinition, sondern ist eine> Sache der Implementierung.
Hätte ich früher auch gesagt... U.a. aufgrund der div. Probleme, die es
dann bei kryptographischen Algorithmen geben kann, würde ich's heute
nicht mehr tun.
S. R. schrieb:> Es gibt nur sehr wenige ARM-Cores, die nicht von ARM selbst stammen> (z.B. Qualcomm Kryo ein). Damit macht ARM den Wildwuchs ziemlich allein.
Es gibt im Lizenzmodell von Arm auch eine Architekturlizenz mit der du
deine eigenen Cores entwickeln kannst. Machen nicht nur die bereits
erwähnten Äpfel und Samsungs.
Um auf die Frage von Falk zurückzukommen: Der Shakti hat für die
Indischen Studenten den Vorteil daß sie ihr Wissen in eigene
kommerzielle Projekte einfließen lassen können. Clever.
Arc N. schrieb:> Hätte ich früher auch gesagt... U.a. aufgrund der div. Probleme, die es> dann bei kryptographischen Algorithmen geben kann, würde ich's heute> nicht mehr tun.
Den für allgemeine Anwendungen konzipierten Integer-Teil einer
Universal-Architektur für längere Lebensdauer in Spezialanforderungen
für bestimmte Anwendungen einzuklemmen halte ich für problematisch. Mit
Tunnelblick aufgrund gerade aktueller Anforderungen eine allgemeine
Architektur zu bauen könnte zum Rohrkrepierer werden. Es steht zu
erwarten, dass man bei neu erkannten Anforderungen jedesmal die
Grundarchitektur umbauen muss.
Ich sehe solche sehr speziellen Anforderungen eher in separaten, ggf
optionalen Befehlen oder Befehlsvarianten, die explizit auf die
Anforderungen eingehen, auch wenn das zur Fragmentierung einläd. Dann
kann man beide Multiplikationen optimieren, die universelle und die
spezielle, ohne dass Restriktionen der Kryptobranche andere Anwendungen
ausbremsen. Denn eine Multiplikation mit konstanter Laufzeit kann je
nach Multiplier und Operanden langsamer sein als eine variable gleichen
Aufwands.
A. K. schrieb:> Arc N. schrieb:>> Hätte ich früher auch gesagt... U.a. aufgrund der div. Probleme, die es>> dann bei kryptographischen Algorithmen geben kann, würde ich's heute>> nicht mehr tun.>> Den für allgemeine Anwendungen konzipierten Integer-Teil einer> Universal-Architektur für längere Lebensdauer in Spezialanforderungen> für bestimmte Anwendungen einzuklemmen halte ich für problematisch.
Schon richtig, dass das nicht zur Spezifikation der Standardbefehle
gehören sollte. Etwas mehr Weitblick hätte aber nicht geschadet (die
Forschung dazu gibt's seit Mitte der 1990er 1)).
> Ich sehe solche sehr speziellen Anforderungen eher in separaten, ggf> optionalen Befehlen oder Befehlsvarianten, die explizit auf die> Anforderungen eingehen, auch wenn das zur Fragmentierung einläd.
Siehe bspw. 2) zu einer möglichen Befehlssatzerweiterung.
Z.Z. wird das nachgeholt (wenn man nicht andauernd alle Entwicklungen
mitverfolgt, verpasst man doch so einiges ;)):
Security Steering Committee und z.Z. zwei Arbeitsgruppen: uC TEE
(Trusted Execution Environment) und Krypto. 3) 4)
Zu "sehr speziell": Da könnte man sich streiten, ob das heute so
spezielle Anforderungen sind ;)
> Dann> kann man beide Multiplikationen optimieren, die universelle und die> spezielle, ohne dass Restriktionen der Kryptobranche andere Anwendungen> ausbremsen. Denn eine Multiplikation mit konstanter Laufzeit kann je> nach Multiplier und Operanden langsamer sein als eine variable gleichen> Aufwands.
Jetzt wird's aber OT ;)
1) http://www.cs.columbia.edu/~nahum/papers/hpcs95-crypto.pdf
2)
https://content.riscv.org/wp-content/uploads/2017/12/Wed-1418-RISCV-RichardNewell.pdf
(von Microsemi)
3)
https://riscv.org/2018/07/risc-v-foundation-announces-security-standing-committee-calls-industry-to-join-in-efforts/
4)
https://content.riscv.org/wp-content/uploads/2018/05/09.00-09.45-Security-Task-Group-8th-RV-Workshop-May-9-2018.pdf
Michael X. schrieb:> Machen nicht nur die bereits erwähnten Äpfel und Samsungs.
Dann nimm noch NVidia und Marvell dazu und du hast den Großteil der
recht kurzen Liste erschlagen.
Arc N. schrieb:> Zu "sehr speziell": Da könnte man sich streiten, ob das heute so> spezielle Anforderungen sind ;)
Krypto ist sehr speziell, denn es handelt sich nur um wenige (wichtige)
Algorithmen mit ziemlich eigenen Anforderungen. Aktuelle SoCs haben
dafür eine eigene, von der CPU unabhängige Engine. Dafür muss und sollte
man nicht am Befehlssatz rumturnen.
S. R. schrieb:> Krypto ist sehr speziell, denn es handelt sich nur um wenige (wichtige)> Algorithmen mit ziemlich eigenen Anforderungen. Aktuelle SoCs haben> dafür eine eigene, von der CPU unabhängige Engine. Dafür muss und sollte> man nicht am Befehlssatz rumturnen.
Spectre/Meltdown... (In Grenzen) Per Microcode patchbare Befehle haben
hin und wieder Vorteile ;)
Nikolaus S. schrieb:> welcher kleine oder Mittelständler hat eine eigene ARM-Lizenz? Hier ist> keiner dabei:
Tja, woran mag das wohl liegen? Hast Du mal versucht, als
10-Frau/Mann-Startup aus DE mit staatlicher Anschubfinanzierung eine
Core-Lizenz von ARM zu bekommen? Die gehen nicht mal ans Telefon, wenn
da nicht Apple oder Samsung auf dem Display steht.
Was die Architekturlizenzen angeht, gibt es kaum Unternehmen, die sich
diese Überhaupt leisten können. Anwendungsspezifische ISA-Erweiterungen
mit ARM gehören für die meisten Normalsterblichen ins Reich der Träume.
Wir arbeiten mit einigen kleinen Fabless-Firmen zusammen, die
händeringend nach einer embedded-CPU suchen, die sie in ihre eigenen
Chipdesigns einbauen können. Und da gibts momentan nix außer ARM. Also:
Weg vom eigenen SoC und den ganzen Kram mit fertigen Chips von der
(amerikanischen) Stange aufbauen, und was in Hardware nicht geht, wird
eben in Software nachgebastelt, nur halt und Faktor 100 langsamer als
bei Apple. So viel dann zum Thema Innovation aus Europa.
Jetzt komm bitte nicht mit dem Argument, dass es ja kaum Firmen in DE
gibt, die eigene Chipdesigns entwickeln. Davon gibt es mehr als genug
(was diese Information angeht, sitze ich an der Quelle), aber als
Endkunde sieht man die natürlich nicht.
Nikolaus S. schrieb:> Denn die Lizenzfreiheit und Anpassungsmöglichkeiten einer Architektur> spielen doch nur eine Rolle, wenn man eigene Chips bauen will und vor> allem kann. Dafür braucht man ein Projekt um Umfang von vielen Mio €...
Nein, dafür braucht man einen guten Ingeneur.
Christian S. schrieb:> Die Inder investieren viel Aufwand in die Ausbildung der jungen Talente,> insbesondere im Bereich Elektronik. Sehr beachtlich!
Dieser Aufwind kam wohl von Außen. Westliche Unternehmen haben in Indien
investiert nachdem sie gemerkt haben dass dort ein Programmierer um ein
vielfaches günstiger ist als hierzulande.
Für die Inder ist es ein Traumjob mit einer für ihre Verhältnisse super
Bezahlung.
Indien ist schon ein seltsames Land. Das Land vereint ärmste
rückständigste Mentalität mit klugen modernen Köpfen.
Das Land baut eigene Raketen und hat erfolgreiche Weltraumprojekte am
laufen, während Millionen Inder immer noch Kühe anbeten.
EinGuterIngeneuer schrieb:> während Millionen Inder immer noch Kühe anbeten.
Bei Kühen weiß man wenigstens ziemlich sicher, dass sie tatsächlich
existieren...
Was ich interessant finde ist, dass Software-Entwicklung und Support im
Consumer-Bereich in Indien geschieht, z.B. bei Anwendungsprozessoren
(Cortex-A) und WLAN-Modulen. Hierzulande versteht man sich nur auf die
ja viel einfacherern Mikrocontroller. Wieso ist das so, ist man hier zu
blöd für komplexere Systeme?
Dr. Sommer schrieb:> Was ich interessant finde ist, dass Software-Entwicklung und Support im> Consumer-Bereich in Indien geschieht, z.B. bei Anwendungsprozessoren> (Cortex-A) und WLAN-Modulen.
Inder sind billig und können Englisch, deswegen wird dahin gerne
ausgelagert. In einem mir bekannten Fall heißt das: Der Support für die
Neuentwicklungen sitzt in den USA (wo auch die Entwicklung stattfindet),
der Support für alles bereits auf dem Markt befindliche sitzt in Indien.
Die Qualität der Antworten ist extrem unterschiedlich.
Dr. Sommer schrieb:> Hierzulande versteht man sich nur auf die ja viel> einfacherern Mikrocontroller. Wieso ist das so,> ist man hier zu blöd für komplexere Systeme?
Du hast es schon genannt: Anwendungsprozessoren. Indien ist ein für
große Mengen zweitklassige Smartphones oder andere billige
Massentechnologie dankbarer Markt - der Westen weniger
(Markenbewusstsein, kleiner Markt). Deutschland macht traditionell
Automatisierung, da braucht man Controller statt Prozessoren. Außerdem
gibt es höhere gesetzliche Anforderungen und Löhne.
In Indien, China und Asien allgemein kann man relativ problemlos auf
viele Sicherheitsvorschriften (sowohl in Produktion und Produkt)
verzichten, solange man nicht in den Westen exportiert (oder privat
importieren lässt, siehe Aliexpress). Das verbilligt vieles und wäre
hier nichtmal möglich.
Die Mentalität in Asien (gemeinsames Nutzen von Informationen beliebiger
Quelle, sieht man hier z.B. an den Unis auch) führt außerdem dazu, dass
man einfach an notwendige Daten rankommt, was über offizielle Wege nicht
oder nur schwer möglich ist. Ergo gibt es die Chips hier nicht zu kaufen
oder nicht mit den passenden Datenblättern.
Is' scheiße, aber is' halt so.
Hmm, das ist aber sogar bei den TI Sitara Prozessoren so... die sind
eher nicht für Smartphones aber mehr für High End Industrie Steuerungen
da, und viel komplexer als die meisten Mikrocontroller. Dennoch kommen
Software und Support aus Indien (oder von Amerikanern mit indischen
Namen :) ).
> Über den Begriff sauber könnte gerade bei RISC-V gestritten werden...
Das neuere RISC-V ist auch eine sauberere Architektur als ARM, an dem
immer nochmal etwas drangeflickt wurde (auch wenn ARM wohl noch nicht so
schlimm wie x86 ist).
Man denke bei ARM an Befehle wie LDMIAEQ.
Ansonsten kann ich zu RISC-V den Vortrag
https://archive.fosdem.org/2018/schedule/event/riscv/ von der FOSDEM
2018 empfehlen (von SiFive, einem anderen Hersteller von RISC-V CPUs).
Philipp
Ein großes Problem des Shakti C ist, dass er die Erweiterung C des
RISC-V-Befehlssatzes nicht unterstützt, während die Linuxdistributionen
diese für RISC-V vorraussetzen.
Philipp
Vancouver schrieb:> irgendwann tauchen die Teile in den> ersten Konsumerprodukten auf, ohne dass jemand etwas davon merkt. Das> ist dann der Durchbruch.
"When they announced the OEM drives these are derived from, someone
asked if the new controller was RISC-V, and the response was that they
wouldn't have any RISC-V stuff ready until 2019."
(https://www.reddit.com/r/hardware/comments/8a0uf4/the_western_digital_wd_black_3d_nand_ssd_review/)
Klingt als könnte es schon nächstes jahr die ersten HDD/SSD mit
RISC-V-Controllern geben. Eine bessere Quelle habe ich leider auf die
Schnelle nicht gefunden.
Philipp
Philipp Klaus K. schrieb:> Das neuere RISC-V ist auch eine sauberere Architektur als ARM, an dem> immer nochmal etwas drangeflickt wurde (auch wenn ARM wohl noch nicht so> schlimm wie x86 ist).
Von ARM gibts effektiv 3,5 verschiedene Architekturen. Die klassische
32-Bit Architektur, Thumb und Thumb2, und dann die neue 64-Bit
Architektur. Letztere ist wieder sauber und (noch) kein Flickenteppich.
Philipp Klaus K. schrieb:> Man denke bei ARM an Befehle wie LDMIAEQ.
Das ist nur Mnemotechnik. Sieht kompliziert aus, weil Befehlsoperanden
und -Modi direkt im Namen reincodiert sind. Mit
LDM.EQ (r0)+
sähe das viel schöner aus. ;-)
Philipp Klaus K. schrieb:> Ein großes Problem des Shakti C ist, dass er die Erweiterung C des> RISC-V-Befehlssatzes nicht unterstützt, während die Linuxdistributionen> diese für RISC-V vorraussetzen.
Nein, das ist kein Problem.
Zum einen war zum Zeitpunkt der Entwicklung des Shakti die
Befehlssatzerweiterung RVC für Distributionen noch fakultativ - die Art
und Weise, wie das dann als obligatorisch für Linux-Distris erklärt
wurde, hat ja auch für Unmut gesorgt -, zum anderen geht es den Indern
ja im Wesentlichen darum, an fertigem Silizium zu testen und nicht nur
mit FPGAs rumzuspielen.
Im Übrigen ist es so, dass es zu jedem 16-Bit RVC Befehl ein
entsprechendes 32-Bit Pendant gibt. So ein krudes und Performance
fressendes Zustandswechsel-Gelumpe wie bei ARM mit Thumb gibt es da
nicht.
A. K. schrieb:> Von ARM gibts effektiv 3,5 verschiedene Architekturen. Die klassische> 32-Bit Architektur, Thumb und Thumb2, und dann die neue 64-Bit> Architektur. Letztere ist wieder sauber und (noch) kein Flickenteppich.
Dafür ist sie schon jetzt ziemlich massiv (mit solchen Juwelen wie
FJCVTZS: "Floating-point Javascript Convert to Signed fixed-point,
rounding toward Zero") seit ARMv8.3-A.
honk schrieb:> die Art und Weise, wie das dann als obligatorisch für Linux-Distris> erklärt wurde, hat ja auch für Unmut gesorgt
Kannst du das ein bisschen ausführen? An mir ist das leider
vorbeigelaufen.
Nikolaus S. schrieb:> Die Begeisterung in Ehren, aber> [...]> welcher kleine oder Mittelständler hat eine eigene ARM-Lizenz? Hier ist> keiner dabei..
Sind 300 Mitarbeiter klein genug? Nicht jeder Lizenznehmer steht auch
auf der Liste.
Wir experimentieren allerdings auch gerade mit 32 Bit Risc-V von
Opencores. Sehr vielversprechend. Im Vergleich mit dem Cortex-M4 braucht
der sich nicht zu verstecken.
Ich denke, Risc-V ist wie Tesla: Zuerst klein und belächelt, dann so
groß gehypet, dass aus z. B. ARM mal richtig Leistung gekitzelt wird,
aber schließlich wird es ohne viel Aufsehen verschwinden. So wird es,
wie Tesla, seinen Abdruck in der Geschichte hinterlassen.
Christoph B. schrieb:> die Universität möchte keine Patente> anmelden.
Kann sie auch nicht mehr:
1) Die Funktion ist Quelloffen, eine Nutzung erfordert die Zustimmung zu
den Lizensanforderungen und die besagen, dass der Code nicht okupiert
werden darf.
2) Die Umsetzung ist unter Mitteln der Universität und mutmasslich des
Herstellers gelungen und damit weder neu noch Uni-eigen.
3) Alles was darüber hinaus geht, gehört dem indischen Staat. Von dem,
was die Studenten oder andere Angestellte, die nicht dem Staat
unterstehen, beigetragen haben, dürfte es schon deshalb nicht mehr
patentierbar sein, weil es publiziert ist.
4) Bleibt der traurige Rest der Umsetzung den sich die Inder haben
selber einfallen lassen und der nicht von dem Chip-Hersteller kommt. Das
sind bei ASICs meistens trickreiche Stromversorgungen, IO-Pins und bei
Sensoren irgendwelche Auslese- und Ansteuerverfahren. Dürfte hier
ausfallen.
Was also sollten die anmelden?
Der Sachverhalt einen RISC Prozessor als solchen zum implementieren ist
jetzt auch eine so große Leistung nicht - das haben wir im
CADENCE-Praktikum vor 25 Jahren im Rahmen der Diplomarbeit gemacht.
Willkommen in der Moderne, Indien.
Kleiner Nachtrag: Damals was das ein 20um-Prozess. Ja, kein Tippfehler.
Es waren Mikrometer und verdrahtet wurde die Metallmaske. Full Custom
konnten wir damals mit einem ES2-Prozess (wurden später von ATMEL
gelauft) in 5um. Mehr lies die Lizenz von CADENCE und LASIK nicht zu.
Bin aber mal gespannt, was aus dem OS-Prozzi so wird. Ich denke, damit
macht am Ende der das Geschäft, der den billigsten Halbleiterprozess
hat. ATMEL sollte da nicht dazugehören, wenn ich das letzte Angebot zu
Rate ziehe, das bei mir auf dem Tisch liegt. Eher Intel oder Micron.
Bego schrieb:> Full Custom> konnten wir damals mit einem ES2-Prozess (wurden später von ATMEL> gelauft) in 5um.
Kam da dann sowas raus, wie im Bild?
Gab es verschiedene ES2-Prozesse?
Was für 'Bausteine' gab es da, die im Metallayer verbunden wurden? Nur
digitales oder auch analog?
Bego schrieb:> 1) Die Funktion ist Quelloffen, eine Nutzung erfordert die Zustimmung zu> den Lizensanforderungen und die besagen, dass der Code nicht okupiert> werden darf.
Patentiert wird nicht konkreter Code, sondern Ideen und Verfahren.
Dagegen wird nur der konkrete Code lizenziert und nicht das Verfahren.
Etwas, das quelloffen ist, kann durchaus patentiert werden. Microsoft
macht sowas z.B. in seinem .NET-Umfeld.
Thread beobachten
Seitenaufteilung abschalten