mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Shakti: Indiens erster RISC-V basierender Prozessor bootet Linux


Autor: Christoph B. (birki2k)
Datum:
Angehängte Dateien:

Bewertung
9 lesenswert
nicht lesenswert

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.

Weitere Informationen:


: Verschoben durch Admin
Autor: DraconiX (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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"

Autor: Christian S. (roehrenvorheizer)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Die Inder investieren viel Aufwand in die Ausbildung der jungen Talente, 
insbesondere im Bereich Elektronik. Sehr beachtlich!

mfG

Autor: Christoph B. (birki2k)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/

Autor: Vancouver (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
@ 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.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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 :)

Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 €...

Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ 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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Operator S. (smkr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Falle dess AMBA-Bus nicht, der ist lizenzfrei und wird z.B. auch in 
FPGAs  verwendet um Cores miteinander zu verbinden.

Autor: Arc N. (arc)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Beim67Bit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flachstecker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Vamcouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: EinGuterIngeneuer (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: EinGuterIngeneuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Bei Kühen weiß man wenigstens ziemlich sicher, dass sie tatsächlich
> existieren...

Ist Indien sowas wie Bielefeld in gross?

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :) ).

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ü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

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: honk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aktuelle Projektseite: (der link oben leitet noch automatisch um)
https://shakti.org.in

interessant:
"Close to 70 million machine instructions execute before the LINUX 
prompt shows up."

( Youtube-Video "India's indigenous SHAKTI C Class Microprocessor - LINUX Boot." )
( https://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computer )

Autor: klein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bego (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulf (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.