Forum: FPGA, VHDL & Co. Mitstreiter für RISC-V Mikrocontrollers gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas K. (thok)


Lesenswert?

Hallo,

wer von euch hat Lust an der Entwicklung eines Multicore 
Mikrocontrollers basierend auf RISC-V in der Freizeit ;-) mit zu machen.

Zu folgenden Themen sollten die Interessenten Erfahrungen haben.
- Verilog mit Xilinx Vivado
- Verwendung des Batch Modus von Vivado
- Icarus Verilog für Simulation und Verifikation
- Erfahrungen beim Einsatz und Anpassen von RISC cores
- Erfahrungen mit weiteren Open Source EDA-Tools sind willkommen

Interessenten können gern per PM Kontakt mit mir aufnehmen.

: Verschoben durch User
von Dorian Grey (Gast)


Lesenswert?

Das wäre aus meiner Sicht ein interessantes Projekt, zu welchem ich mich 
aber gedrängt sehe, vorab einige Fragen zu erörtern:

1) Woher kommt die Prämisse mit Verilog zu arbeiten?
2) Wer ist die Supporter-Gruppe? Ich nehme an, US-Raum?
3) Wie sieht es mit den Rechten aus? Soll das open werden?
4) Was trete ich an Rechten der Verwertung ab, wenn ich dort beisteuere?
5) Welche RISC-Cores Architektur wird angestrebt?
6) Welches OS soll dann darauf laufen?

Die Frage der Fragen ist:

Ist Vermarktung angestrebt, möglich?

Ich habe in einer ähnliche Gruppe mitgewirkt und komme aus einem Projekt 
mit Inhalten, die sich damit überschneiden. Contributen könnte ich das 
einiges, muss aber sicherstellen, dass die V-Rechte nicht abwandern.

von Dorian Grey (Gast)


Lesenswert?

Und als appetizer hätte ich:

- 8fach-MCMCU auf ARM-Basis mit vereinfachtem Operanden-Satz
- MultiPipeLine für Commands und Data zwischen den MC-MCUs
- Controller für Core Balancing, Task Balancing, Thread Balancing
- MicroCodeInterpreter, - optimizer
- Taskmanager für embedded Linux-OS
- Cache-Strukturen, Fast-Access, Random-Access
- RAM-Manager, CACHE-Manager für Linux

.. und noch so ein bissl was. Die Sachen sind aber kompletto 
alteuropäisches VHDL aus früheren Tagen. Die RAM-Modelle und den 
Taskmanager gibt es in Verilog. Icarus kenne ich nur vom Namen, sollte 
aber kein Problem sein.

Eine Frage noch zu der o.g. Liste:

Für welche Anwendungen ist das angedacht?
Oder fragen wir, für welche Kunden und Branchen?

Dir ist schon klar, dass du/ihr damit einigen Gruppen Konkurrenz 
mach(s)t?

von Andreas Rückert (Gast)


Lesenswert?

Ein Kollege bastelt gerade an einem eigenen RISC Core, wo ich ein klein 
wenig mitbasteln darf. Ich hab mich mal an einer zpu Implementierung 
versucht, aber da klemmt es am Memory-Controller.

Ich frag mich, ob man mal so eine Diskussionsgruppen/forum starten 
könnte, wo man solche Themen diskutieren könnte und evtl auch gemeinsam 
Lösungen erarbeiten könnte?

Wobei Du mit Multicore RISC V wohl ein paar Ligen höher als wir zielst.

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Dorian Grey schrieb:
> alteuropäisches VHDL
Soso. Das DoD und der F-22 sind also alteuropäische Erfindungen...

https://slideplayer.com/slide/6644044/

Thomas K. schrieb:
> Entwicklung eines Multicore
Was soll das Ziel der Übung sein?
Was ist das für eine Anwendung die einen Multicore-Mikrocontroller 
benötigt?

Warum die Beschränkung auf Xilinx bzw. sogar auf Xilinx-Vivado?

Duke

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Duke Scarring schrieb:
> Was soll das Ziel der Übung sein?
> Was ist das für eine Anwendung die einen Multicore-Mikrocontroller
> benötigt?

Es kann sich eigentlich nur um Anwendungen handeln, die nicht als massiv 
paralleles System formulier, oder anwendbar ist und deshalb vom 
Betriebssystem zerpflückt / bedient werden muss, um sie in Teilen zu 
beschleunigen, also mehrere Prozesse auf einem Controller.

Im Kern eine nette Idee, dabei aber nicht verkannt werden, dass dann 
auch ein dafür angepasstes Betriebssystem benutzt werden muss, das die 
Controller unten drunter bedienen und verwalten kann und das bremst die 
Nutzung wieder aus. Ist eine Software nicht wenigstens in 3 gleiche 
Tasks unterteilt, die stark discontinuierlich arbeiten, bringt ein 
threading erstens keinen Vorteil und zweitens eine multi core CPU keine 
quantitative Verbesserung gegenüber einem single core. Im Gegenteil: 
Task switches zwischen den CPUs verlangsamen die Abarbeitung und das 
Blockieren gemeinsamer resources macht es am Ende schlechter als ein 
single Core.

Bringen kann das nur etwas bei einer großen Anzahl von Cores, die sehr 
langsam sind (was sie im FPGA ja sind) und einer gleichmäßig verteilen 
hohen Anzahl von threads, die nicht auf gemeinsame Resourcen gehen und 
da nehme ich dann lieber 4 parallele NIOSse und lasse sie über schmale 
Verbindungen miteinander reden.

von Thomas K. (thok)


Lesenswert?

Dorian Grey schrieb:
> Das wäre aus meiner Sicht ein interessantes Projekt, zu welchem ich mich
> aber gedrängt sehe, vorab einige Fragen zu erörtern:
>
> 1) Woher kommt die Prämisse mit Verilog zu arbeiten?
> 2) Wer ist die Supporter-Gruppe? Ich nehme an, US-Raum?
> 3) Wie sieht es mit den Rechten aus? Soll das open werden?
> 4) Was trete ich an Rechten der Verwertung ab, wenn ich dort beisteuere?
> 5) Welche RISC-Cores Architektur wird angestrebt?
> 6) Welches OS soll dann darauf laufen?

Hallo Dorian,

danke für deine Interessensbekundung an diesem Projekt. Deine Fragen 
möchte ich gern im Folgenden beantworten.

1) Die meisten verfügbaren RISC-V Implementierungen verwenden Verilog. 
Aus Zeitgründen habe ich nicht vor einen komplett eigenen RISC-V Core zu 
entwickeln, sondern nutze eine Open Source Variante.

2) Es kann durchaus sein, das es mal Unterstützung aus dem US-Raum geben 
wird, aber momentan gibt noch keine.

3) Ich kann mir vorstellen, das es mal Open Source wird. Aber ob das 
auch schon während der Entwicklung so sein wird, bin ich mir noch nicht 
sicher.

4) Auch bei Open Source hast du natürlich Rechte an deinem 
beigesteuerten Code und Anspruch auf Nennung deines Namens in den 
Sourcen. Zusätzlich besteht die Möglichkeit bei einer Vermarktung dieser 
Entwicklung zu partizipieren.

5) Wie gesagt geht es nur um einen Mikrocontroller und nicht um einen 
High Perfomance Server. Die Architektur ist angelehnt an das Konzept des 
Propeller von Parallax 
(https://www.parallax.com/downloads/propeller-p8x32a-documentation). Das 
bedeutet, das alle Cores mit dem gleichen Takt versorgt werden, aber 
nicht immer alle Cores gleichzeitg laufen, sondern nur, wenn sie für 
einen bestimmten Task gestartet werden.

6) Es ist kein spezielles OS vorgesehen, es ist nur ein Mirkocontroller. 
Es soll auf keinen Fall ein Standard Linux darauf laufen, da die 
Hardware Resourcen dafür unzureichend sind.

> Die Frage der Fragen ist:
>
> Ist Vermarktung angestrebt, möglich?

Möglich ist so was schon, wenn Kunden daran interessiert sind.

> Ich habe in einer ähnliche Gruppe mitgewirkt und komme aus einem Projekt
> mit Inhalten, die sich damit überschneiden. Contributen könnte ich das
> einiges, muss aber sicherstellen, dass die V-Rechte nicht abwandern.

Wir können das Thema gern in einem Telefonat besprechen. Im Forum ist 
das etwas umständlich. Schick mir einfach eine PM, wenn du möchtest.

Dorian Grey schrieb:
> Und als appetizer hätte ich:
>
> - 8fach-MCMCU auf ARM-Basis mit vereinfachtem Operanden-Satz
> - MultiPipeLine für Commands und Data zwischen den MC-MCUs
> - Controller für Core Balancing, Task Balancing, Thread Balancing
> - MicroCodeInterpreter, - optimizer
> - Taskmanager für embedded Linux-OS
> - Cache-Strukturen, Fast-Access, Random-Access
> - RAM-Manager, CACHE-Manager für Linux
>
> .. und noch so ein bissl was. Die Sachen sind aber kompletto
> alteuropäisches VHDL aus früheren Tagen. Die RAM-Modelle und den
> Taskmanager gibt es in Verilog. Icarus kenne ich nur vom Namen, sollte
> aber kein Problem sein.

Deine Erfahrungen mit Multicore Mikrocontrollern hast du damit 
jedenfalls belegt. ;-)
Da du bisher vorwiegend VHDL verwendet hast, hast du natürlich den 
Icarus noch nicht benötigt. Wenn du damit leben kannst, das im Projekt 
nur Verilog zum Einsatz kommt, sehe ich das nicht als Problem.

> Eine Frage noch zu der o.g. Liste:
>
> Für welche Anwendungen ist das angedacht?
> Oder fragen wir, für welche Kunden und Branchen?

Der Mirkocontroller kann für alles eingesetzt werden, wo andere 
Mikrocontroller auch verwendet werden. Aufgrund der Multicore 
Architektur ist der Einsatz für Anwendungen mit kurzen Latenzzeiten 
prädestiniert.

> Dir ist schon klar, dass du/ihr damit einigen Gruppen Konkurrenz
> mach(s)t?

Kann schon sein, dass es da außer Parallax noch andere gibt, aber die 
sind mir nicht bekannt. Wie sagt man: Konkurrenz belebt das Geschäft. 
;-)

von Andreas Rückert (Gast)


Lesenswert?

Gibt es schon eine Website zum Projekt, auf die man verlinken könnte?

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Wobei Du mit Multicore RISC V wohl ein paar Ligen höher als wir zielst.

Nicht unbedingt. Es gibt auch kleine RISC-V Cores, die z.B. für 
Wearables vorgesehen sind. Damit kann man natürlich auch Multicore 
Systeme bauen. Es muss nicht immer gleich ein Linux System darauf 
lauffähig sein.

Von daher bist du gern willkommen, deine Ideen ins Projekt einzubringen. 
Interesse an Mikrocontrollern und der RISC-V ISA sind von Vorteil. ;-)

von Thomas K. (thok)


Lesenswert?

Duke Scarring schrieb:
> Was soll das Ziel der Übung sein?
> Was ist das für eine Anwendung die einen Multicore-Mikrocontroller
> benötigt?

Es gibt zwar schon Mikrocontroller mit 2 oder mehr Cores, aber soweit 
ich weiss nicht mit RISC-V Cores.
Und es gibt Dual-Core Multicontroller und Multicore Mirkocontroller. 
Beide verwenden eine Grund verschiedene Architektur.
Eine spezielle Anwendung hatte ich nicht erwähnt, aber die Entwicklung 
von Anwendungen mit mehreren Sensoren für Multicore Mikrocontroller wie 
den Propeller von Parallax ist deutlich einfacher, als die Entwicklung 
für einen Mikrocontroller mit nur einem Core.

> Warum die Beschränkung auf Xilinx bzw. sogar auf Xilinx-Vivado?

Ich kenne mich mit Xilinx ganz gut aus. Ich hätte aber auch Microsemi 
nennen können.
Da es sich um ein nicht kommerzielles Projekt handelt, ist die 
kostenlose Vivado Webedition von Vorteil und unterstützt sehr viele 
Xilinx FPGAs.
Ein Tool ist besser, als für jeden FPGA Typ ein spezielles Tool zu 
verwenden.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Gibt es schon eine Website zum Projekt, auf die man verlinken könnte?

Nein, die gibt es noch nicht.

von Thomas K. (thok)


Lesenswert?

Weltbester FPGA-Pongo schrieb im Beitrag #5574696:
> Duke Scarring schrieb:
>> Was soll das Ziel der Übung sein?
>> Was ist das für eine Anwendung die einen Multicore-Mikrocontroller
>> benötigt?
>
> Es kann sich eigentlich nur um Anwendungen handeln, die nicht als massiv
> paralleles System formulier, oder anwendbar ist und deshalb vom
> Betriebssystem zerpflückt / bedient werden muss, um sie in Teilen zu
> beschleunigen, also mehrere Prozesse auf einem Controller.

Es bedarf nicht immer eines Betriebssystems, aber ansonsten passt deine 
Beschreibung.

> Im Kern eine nette Idee, dabei aber nicht verkannt werden, dass dann
> auch ein dafür angepasstes Betriebssystem benutzt werden muss, das die
> Controller unten drunter bedienen und verwalten kann und das bremst die
> Nutzung wieder aus. Ist eine Software nicht wenigstens in 3 gleiche
> Tasks unterteilt, die stark discontinuierlich arbeiten, bringt ein
> threading erstens keinen Vorteil und zweitens eine multi core CPU keine
> quantitative Verbesserung gegenüber einem single core. Im Gegenteil:
> Task switches zwischen den CPUs verlangsamen die Abarbeitung und das
> Blockieren gemeinsamer resources macht es am Ende schlechter als ein
> single Core.

Deine Beschreibung trifft auf die Architektur von gewöhnlich bekannten 
CPU's zu. Bei einem echten Multicore System kann es soviele Tasks geben, 
wie Cores im System vorhanden sind und das ohne Threading und Task 
switches.
Mit dem Zugriff auf gemeinsame Resourcen hast du recht. Aber das kann 
durch eine geeignete Architektur vermieden werden.
Von daher kann ich deiner Aussage insgesamt nicht zustimmen.

> Bringen kann das nur etwas bei einer großen Anzahl von Cores, die sehr
> langsam sind (was sie im FPGA ja sind) und einer gleichmäßig verteilen
> hohen Anzahl von threads, die nicht auf gemeinsame Resourcen gehen und
> da nehme ich dann lieber 4 parallele NIOSse und lasse sie über schmale
> Verbindungen miteinander reden.

Es geht hier nicht um die Entwicklung einer CPU, die für FPGAs verwendet 
werden soll, wie z.B. NIOS oder MicroBlaze. Der FPGA wird nur für die 
Entwicklung eines Mikrocontrollers genutzt, um dessen Funktionalität zu 
beweisen.

von donort (Gast)


Lesenswert?

Habe Interesse. Bin mit Verilog nur lesend vertraut, habe mir aber 
bereits semi-intensiv in meiner freien Zeit den PicoRV32 einverleibt. 
Ein Gitter-Chat mit privatem Gitlab-Repo wäre passend für den Anfang 
denke ich.

von J. S. (engineer) Benutzerseite


Lesenswert?

Thomas K. schrieb:
> Bei einem echten Multicore System kann es soviele Tasks geben,
> wie Cores im System vorhanden sind
Von wievielen Cores reden wir hier?

Thomas K. schrieb:
> Es geht hier nicht um die Entwicklung einer CPU, die für FPGAs verwendet
> werden soll, wie z.B. NIOS oder MicroBlaze. Der FPGA wird nur für die
> Entwicklung eines Mikrocontrollers genutzt, um dessen Funktionalität zu
> beweisen.
Soll das danach ein ASIC werden?

von V. Risc (Gast)


Lesenswert?

Thomas K. schrieb:
> Duke Scarring schrieb:
>> Was soll das Ziel der Übung sein?
>> Was ist das für eine Anwendung die einen Multicore-Mikrocontroller
>> benötigt?
>
> Es gibt zwar schon Mikrocontroller mit 2 oder mehr Cores, aber soweit
> ich weiss nicht mit RISC-V Cores.
> Und es gibt Dual-Core Multicontroller und Multicore Mirkocontroller.
> Beide verwenden eine Grund verschiedene Architektur.
> Eine spezielle Anwendung hatte ich nicht erwähnt, aber die Entwicklung
> von Anwendungen mit mehreren Sensoren für Multicore Mikrocontroller wie
> den Propeller von Parallax ist deutlich einfacher, als die Entwicklung
> für einen Mikrocontroller mit nur einem Core.


Gibt doch schon viele Ansätze und Implementierungen in der Forschung. 
Einfach mal die Literatur durchforsten.
Z.B.:
http://bjump.org/manycore/
https://pulp-platform.org/hero.html

Du solltest Dir nur die Frage stellen, ob nicht vielleicht ein etwas 
anwendungsbezogenerer Controller die sinnvollere Alternative ist, also 
ein RiscV mit Vektorprocessing- oder DNN-Erweiterungen.
Z.B.:
https://greenwaves-technologies.com/en/gap8-product/

von Thomas K. (thok)


Lesenswert?

donort schrieb:
> Habe Interesse. Bin mit Verilog nur lesend vertraut, habe mir aber
> bereits semi-intensiv in meiner freien Zeit den PicoRV32 einverleibt.
> Ein Gitter-Chat mit privatem Gitlab-Repo wäre passend für den Anfang
> denke ich.

Danke für dein Interesse an dem Projekt mit zu wirken. Sehr gut, dass du 
dich schon mit dem PicoRV32 bechäftigt hast.
Gitter-Chat kannte ich noch nicht, ist aber definitiv eine mögliche 
Plattform für die Kommunikation im Projekt. Privates Repo wäre auch 
angenehm.

Wie siehts mit deinen Erfahrung bei Xilinx FPGAs aus? Hast du 
Designerfahrungen mit VHDL?

von Thomas K. (thok)


Lesenswert?

Jürgen S. schrieb:
> Thomas K. schrieb:
>> Bei einem echten Multicore System kann es soviele Tasks geben,
>> wie Cores im System vorhanden sind
> Von wievielen Cores reden wir hier?

Für den Anfang sind 8 ausreichend.

> Thomas K. schrieb:
>> Es geht hier nicht um die Entwicklung einer CPU, die für FPGAs verwendet
>> werden soll, wie z.B. NIOS oder MicroBlaze. Der FPGA wird nur für die
>> Entwicklung eines Mikrocontrollers genutzt, um dessen Funktionalität zu
>> beweisen.
> Soll das danach ein ASIC werden?

Es wäre schon schön, wenn wir es bis zu einem Chip schaffen. Das das 
nicht gleich in 3 Monaten sein wird, sollte jedem klar sein.

von Thomas K. (thok)


Lesenswert?

V. Risc schrieb:
> Gibt doch schon viele Ansätze und Implementierungen in der Forschung.
> Einfach mal die Literatur durchforsten.
> Z.B.:
> http://bjump.org/manycore/
> https://pulp-platform.org/hero.html

Danke für die Links. Den Pulp kannte ich schon, aber den BaseJump kannte 
ich noch nicht. Beides sind aber keine Mikrocontroller, sondern 
spezielle Multicore Systeme zur Beschleunigung von bestimmten 
Berechnungen, beim BaseJump sogar ein vernetztes Multicore System. Die 
haben ihre Daseinsberechtigung, sind aber nicht das, was ich mir für 
einen Mikrocontroller vorstelle.

> Du solltest Dir nur die Frage stellen, ob nicht vielleicht ein etwas
> anwendungsbezogenerer Controller die sinnvollere Alternative ist, also
> ein RiscV mit Vektorprocessing- oder DNN-Erweiterungen.
> Z.B.:
> https://greenwaves-technologies.com/en/gap8-product/

Du hast völlig recht. Die Frage der Ausrichtung für bestimmte 
Anwendungen ist sehr wichtig und sollte sicher auch noch genauer im 
Projekt spezifiziert werden, damit jeder eine Vorstellung hat, wo es hin 
geht. Einen Vektorprozessor hatte ich aber nicht im Sinn. Trotzdem danke 
für diesen wichtigen Hinweis.

von mmacs (Gast)


Lesenswert?

Das Thema ist spannend (und ich habe das bereits auch mit einer 
Architektur 'durch'), aber es muesste etwas mehr Fleisch an den Knochen, 
irgendwas wie eine Vision solltest du schon 'pitchen'.
Dann: entweder komplett Opensource von Anfang an, oder besser alleine 
machen oder mit einem kommerziellen Hintergrund aufziehen. Laeuft sonst 
meist so, dass sich die Leute nicht einigen und die Projekte aufgrund 
Streitigkeiten den Bach runter gehn.
Die Probleme treten meist dann auf, wenn man nicht einfach nur Tasks auf 
Kerne verteilen muss, sondern den Kram debuggen, verifizieren, usw.
Da wuerde ich ich schon mal gar nicht auf Verilog vs. VHDL oder irgend 
eine Hersteller-Toolchain festlegen, sondern erst mal ueberlegen, wie 
das gesamte System als virtueller Chip aussehen koennte.

von Andreas R. (daybyter)


Lesenswert?

Also ich interessiere mich z.B. für Trading. Erweiterungen fürs 
FIX-Processing fände ich toll. Bzw. man sollte halt eigene Erweiterungen 
einbauen können.

von Thomas K. (thok)


Lesenswert?

mmacs schrieb:
> Das Thema ist spannend (und ich habe das bereits auch mit einer
> Architektur 'durch'), aber es muesste etwas mehr Fleisch an den Knochen,
> irgendwas wie eine Vision solltest du schon 'pitchen'.

Hallo mmacs, schön, dass du das Thema spannend findest. In einem Forum 
Thread verliert man leicht den Überblick auf die Details, deshalb hier 
noch mal eine Zusammenfassung der Vision mit weiteren Details für alle.

- Multicore Mikrocontoller mit 8 RISC-V Cores
- Basis Konzept entspricht dem Propeller (P1) von Parallax mit 
Modifikationen 
(https://www.parallax.com/downloads/propeller-p8x32a-documentation)
(https://www.parallax.com/microcontrollers/propeller-1-open-source)
- Bei Implementierung eines SPIN Interpreters/Compilers, könnten 
Anwender Code aus der vorhandenen Bibliothek 
(https://www.parallax.com/support/community/obex) ohne bzw. 
geringfügiger Änderung nutzen, solange kein Assembler verwendet wird
- Für die Anwender, die lieber C/C++ verwenden gibt es heute schon 
Unterstützung im GCC für den RISC-V, zumindest für einen Core (gibt's 
übrigens auch in der Arduino IDE -> HiFive1). Hier muss also auch noch 
was entwickelt werden.

> Dann: entweder komplett Opensource von Anfang an, oder besser alleine
> machen oder mit einem kommerziellen Hintergrund aufziehen. Laeuft sonst
> meist so, dass sich die Leute nicht einigen und die Projekte aufgrund
> Streitigkeiten den Bach runter gehn.

Ich denke es sollte schon Opensource werden, da das Projekt auch sehr 
stark von anderen Opensource Komponenten profitieren wird. Die Frage für 
mich ist nur, ob man vom ersten Tag an den aktuellen Entwicklungsstand 
veröffentlicht oder erst, wenn man das gestellte Ziel erreicht hat. Ich 
wäre für letzteres. Das es dann nach der Veröffentlichung immer noch 
Finetuning geben wird, ist selbstverständlich. Ich möchte nur vermeiden, 
das am Anfang zu viele Ideen zu Features aufkommen, die das Projekt 
nicht vorwärts bringen.

> Die Probleme treten meist dann auf, wenn man nicht einfach nur Tasks auf
> Kerne verteilen muss, sondern den Kram debuggen, verifizieren, usw.
> Da wuerde ich ich schon mal gar nicht auf Verilog vs. VHDL oder irgend
> eine Hersteller-Toolchain festlegen, sondern erst mal ueberlegen, wie
> das gesamte System als virtueller Chip aussehen koennte.

Wie es aussehen soll, ist schon bekannt siehe oben. Für den Anfang 
müssen nur die Cores durch RISC-V Cores ersetzt werden, anschließend 
kommen die Modifikationen. Von daher kann es gleich losgehen mit HDL. Um 
das Projekt einfach zu halten, ist eine Unterstützung für FPGAs eines 
bestimmten Herstellers notwendig. Daraus leitet sich natürlich auch die 
Toolchain ab.

von Thomas K. (thok)


Lesenswert?

Andreas R. schrieb:
> Also ich interessiere mich z.B. für Trading. Erweiterungen fürs
> FIX-Processing fände ich toll. Bzw. man sollte halt eigene Erweiterungen
> einbauen können.

Sorry Andreas, deine gewünschten Features werden nicht im Focus stehen. 
Eventuell kannst du das später selbst oder mit anderen gemeinsam 
hinzufügen.
Trotzdem danke für dein Interesse.

von Maier (Gast)


Lesenswert?

Thomas K. schrieb:
> - Basis Konzept entspricht dem Propeller (P1) von Parallax mit
> Modifikationen
Der Propeller war ja nicht soo erfolgreich. Was ich verstanden habe, war 
ein Problem dass je Prozessor ein eigener (kleiner) Arbeitsspeicher 
vorhanden war, wo der Programmcode reingeladen werden musste. D.h. 
groessere Programme koennen nicht am Stueck durchlaufen, es gibt 
Ladeverzoegerungen zwischendrin.
Ausserdem hat im Grunde alle Peripherie gefehlt, weil mans auch in 
Software machen kann.

Wie ist das hier angedacht, Speicherarchitektur, Zugriffssteuerung...?

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Thomas K. schrieb:
>> - Basis Konzept entspricht dem Propeller (P1) von Parallax mit
>> Modifikationen
> Der Propeller war ja nicht soo erfolgreich. Was ich verstanden habe, war
> ein Problem dass je Prozessor ein eigener (kleiner) Arbeitsspeicher
> vorhanden war, wo der Programmcode reingeladen werden musste. D.h.
> groessere Programme koennen nicht am Stueck durchlaufen, es gibt
> Ladeverzoegerungen zwischendrin.
> Ausserdem hat im Grunde alle Peripherie gefehlt, weil mans auch in
> Software machen kann.

Der Propeller war nicht so erfolgreich in Europa, im Rest der Welt 
schon. Ansonsten würde es nicht ein Nachfolgemodell, den P2, geben. Die 
Firma Parallax, die den Propeller erfunden hat, produziert und vertreibt 
hat dieses Jahr gerade ihr 25. Firmenjubiläum gefeiert. Da die Firma 
noch existiert, muss der Propeller wohl doch nicht so schlecht gelaufen 
sein im Vertrieb. Schließlich ist der Propeller das Hauptprodukt von 
Parallax.

Ja, der Programmspeicher beim P1 ist nur 2KiB pro Core, aber das ist 
ausreichend für Code, der nur für einen Task zuständig ist.
Für monolithischen Programmcode ist die Architektur nicht geeignet.
Zum Konzept des Propellers gehört auch, das man Peripherie in Software 
macht. Da mehr als ein Core zur Verfügung steht, hat das auch keine 
negativen Auswirkungen auf die Performance der Anwendung.

>
> Wie ist das hier angedacht, Speicherarchitektur, Zugriffssteuerung...?

Die Modifikationen betreffen vorallem die Speicherarchitektur. Der 
Main-RAM soll entfallen, der Cog-RAM vergrößert werden, mind. 16KiB pro 
Core. Der verfügbare RAM im Chip soll durch entsprechende Modi anderes 
verteilt werden können. Ein externer Speicherbus ist erstmal nicht 
geplant, aber könnte später eine Option sein, kostet aber sehr viele 
Pins. Entsprechende Konzepte für die Nutzung eines externen Speichers 
sind noch nicht vorhanden.

von Andreas Rückert (Gast)


Lesenswert?

Thomas K. schrieb:
> Sorry Andreas, deine gewünschten Features werden nicht im Focus stehen.
> Eventuell kannst du das später selbst oder mit anderen gemeinsam
> hinzufügen.
> Trotzdem danke für dein Interesse.

Ich verlang ja nicht, dass im Projekt gleich solche Funktionen mit rein 
kommen. Aber ich würde z.B. Opcodes frei lassen, wo man später selbst 
solche Funktionen nachrüsten kann.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Thomas K. schrieb:
>> Sorry Andreas, deine gewünschten Features werden nicht im Focus stehen.
>> Eventuell kannst du das später selbst oder mit anderen gemeinsam
>> hinzufügen.
>> Trotzdem danke für dein Interesse.
>
> Ich verlang ja nicht, dass im Projekt gleich solche Funktionen mit rein
> kommen. Aber ich würde z.B. Opcodes frei lassen, wo man später selbst
> solche Funktionen nachrüsten kann.

Ich glaube Opcodes für eigene Assemblerbefehle sind noch genügend frei 
in der RISC-V ISA. ;-)
Wichtig ist glaube ich, das du schon mal zu deinem speziellen Thema 
Informationen zusammen trägst, wie solche Berechnungen aussehen würden. 
Dann können auch andere Personen ihre Ideen für Lösungsansätze und 
Implementierung beisteuern, die sich nicht mit der Materie auskennen.

von Andreas Rückert (Gast)


Lesenswert?

Sind hauptsächlich Befehle für schnellen String Split, Replace und 
ähnliches. Aber vermutlich sind wir da eh schon komplett in verilog.

Ich wollte die CPU hauptsächlich für Hardware Initialisierung (Netzwerk, 
SD card etc) und danach z.B. Login bei Webseiten nehmen.

von (prx) A. K. (prx)


Lesenswert?

Thomas K. schrieb:
> Ansonsten würde es nicht ein Nachfolgemodell, den P2, geben.

Die Webseite deutet darauf hin, dass der P2 eher als Idee denn als 
reales Produkt existiert.

Die Grundidee des Propellers fand ich interessant - aber XMOS geht in 
die gleiche Richtung und wirkt auf mich überzeugender.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Sind hauptsächlich Befehle für schnellen String Split, Replace und
> ähnliches. Aber vermutlich sind wir da eh schon komplett in verilog.
>
> Ich wollte die CPU hauptsächlich für Hardware Initialisierung (Netzwerk,
> SD card etc) und danach z.B. Login bei Webseiten nehmen.

Hallo Andreas, String-Operationen sind keine Befehle, die eine CPU 
direkt ausführen kann. Solche Operationen werden erst durch hunderte 
oder gar tausende von Assemblerbefehlen möglich.
Eine Art von Computer lässt damit schon bauen, der auch Zugriff auf 
Netzwerk und Internet hat. Dazu ist aber entsprechende Peripherie 
notwendig, die dann durch Software benutzt werden kann.

von Thomas K. (thok)


Lesenswert?

A. K. schrieb:
> Thomas K. schrieb:
>> Ansonsten würde es nicht ein Nachfolgemodell, den P2, geben.
>
> Die Webseite deutet darauf hin, dass der P2 eher als Idee denn als
> reales Produkt existiert.

Aus einer Idee wird ein Produkt. Und er (P2) lebt doch. ;-)
https://youtu.be/x7-gGOBnk68

Wer mal einen Blick in die Doku des P2 und dessen Features werfen 
will...
Seite 2 Overview
https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/edit?usp=sharing

> Die Grundidee des Propellers fand ich interessant - aber XMOS geht in
> die gleiche Richtung und wirkt auf mich überzeugender.

Die einen sind Vegetarier und die anderen mögen lieber Fleisch. Das muss 
jeder selber entscheiden. ;-)

von Andreas Rückert (Gast)


Lesenswert?

Thomas K. schrieb:
> Hallo Andreas, String-Operationen sind keine Befehle, die eine CPU
> direkt ausführen kann. Solche Operationen werden erst durch hunderte
> oder gar tausende von Assemblerbefehlen möglich.

Ja, aber wenn Du nur paar ns hast, muss man da halt tricksen. Im Moment 
werden da gern MMX oder avx512 Befehle benutzt, aber die sind noch 
suboptimal.

> Eine Art von Computer lässt damit schon bauen, der auch Zugriff auf
> Netzwerk und Internet hat. Dazu ist aber entsprechende Peripherie
> notwendig, die dann durch Software benutzt werden kann.

Jo. Hab mir mal so einen w5500 Internet Shield geholt, den ich für den 
Anfang zum Testen benutzen wollte.

von donort (Gast)


Lesenswert?

Thomas K. schrieb:
> donort schrieb:
>> Habe Interesse. Bin mit Verilog nur lesend vertraut, habe mir aber
>> bereits semi-intensiv in meiner freien Zeit den PicoRV32 einverleibt.
>> Ein Gitter-Chat mit privatem Gitlab-Repo wäre passend für den Anfang
>> denke ich.
>
> Danke für dein Interesse an dem Projekt mit zu wirken. Sehr gut, dass du
> dich schon mit dem PicoRV32 bechäftigt hast.
> Gitter-Chat kannte ich noch nicht, ist aber definitiv eine mögliche
> Plattform für die Kommunikation im Projekt. Privates Repo wäre auch
> angenehm.
>
> Wie siehts mit deinen Erfahrung bei Xilinx FPGAs aus? Hast du
> Designerfahrungen mit VHDL?

Habe mit der 7er-Serie meinen FPGA-Beginn gehabt, bin aber inzwischen 
auf Intel/Lattice umgestiegen, da mich die abstrusen Preise abschrecken 
bzw. ich die hohe Performance in meinen Projekten nicht benötige. VHDL 
ist mein Steckenpferd, SystemVerilog lerne ich, wenn ich Zeit habe.

Wieso nicht von Anfang an ein Public-Development-Ansatz? Jedes offene 
Projekt profitiert von mehrstimmiger Diskussion, jeder hat eine andere 
Sichtweise. Solange es ein klares Ziel gibt, und die Use-Cases 
abgesteckt sind, hat man auch immer eine Erklärung parat, wieso man sich 
so und so entschieden hat.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Thomas K. schrieb:
>> Hallo Andreas, String-Operationen sind keine Befehle, die eine CPU
>> direkt ausführen kann. Solche Operationen werden erst durch hunderte
>> oder gar tausende von Assemblerbefehlen möglich.
>
> Ja, aber wenn Du nur paar ns hast, muss man da halt tricksen. Im Moment
> werden da gern MMX oder avx512 Befehle benutzt, aber die sind noch
> suboptimal.

Ah, verstehe. Wie du selber sagst, sind diese Befehle nicht optimal für 
deine Berechnungen. Deshalb muss man erstmal sehen, was da eigentlich 
berechnet werden soll, um das in einen Algorithmus für die CPU zu 
überführen.

>> Eine Art von Computer lässt damit schon bauen, der auch Zugriff auf
>> Netzwerk und Internet hat. Dazu ist aber entsprechende Peripherie
>> notwendig, die dann durch Software benutzt werden kann.
>
> Jo. Hab mir mal so einen w5500 Internet Shield geholt, den ich für den
> Anfang zum Testen benutzen wollte.

Ist eine gute Wahl. Der lässt sich vielfältig zum Einsatz bringen.

von Thomas K. (thok)


Lesenswert?

donort schrieb:
>> Wie siehts mit deinen Erfahrung bei Xilinx FPGAs aus? Hast du
>> Designerfahrungen mit VHDL?
>
> Habe mit der 7er-Serie meinen FPGA-Beginn gehabt, bin aber inzwischen
> auf Intel/Lattice umgestiegen, da mich die abstrusen Preise abschrecken
> bzw. ich die hohe Performance in meinen Projekten nicht benötige. VHDL
> ist mein Steckenpferd, SystemVerilog lerne ich, wenn ich Zeit habe.

Hört sich gut an, auch wenn du noch keine Implementierungserfahrung mit 
Verilog hast. Wenn du dich mit SystemVerilog beschäftigst ist es auch 
von Vorteil.

> Wieso nicht von Anfang an ein Public-Development-Ansatz? Jedes offene
> Projekt profitiert von mehrstimmiger Diskussion, jeder hat eine andere
> Sichtweise. Solange es ein klares Ziel gibt, und die Use-Cases
> abgesteckt sind, hat man auch immer eine Erklärung parat, wieso man sich
> so und so entschieden hat.

Ich habe nichts gegen weitere Ideen von anderen, die zum Fortschritt des 
Projekts betragen. Das Ziel habe ich heute schon konkretisiert benannt.
Beitrag "Re: Mitstreiter für RISC-V Mikrocontrollers gesucht"

Bis der erste Schritt umgesetzt ist, kann man natürlich auch schon Ideen 
"einsammeln". Aber man sollte nicht mit dem zweiten Schritt beginnen und 
sich "verzetteln", bevor man nicht den ersten begonnen hat.

von Andreas Rückert (Gast)


Lesenswert?

Also 2 Gebiete, wo mein Kumpel und ich uns gerade eher schwer tun, sind 
Mikrocode Design und RAM Controller. Da wären wir sicher an nem 
Erfahrungsaustausch interessiert.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Also 2 Gebiete, wo mein Kumpel und ich uns gerade eher schwer tun, sind
> Mikrocode Design und RAM Controller. Da wären wir sicher an nem
> Erfahrungsaustausch interessiert.

Alles klar, Andreas. Nicht das ich euch das Hardwaredesign nicht 
zutraue, aber wie sieht es denn mit C-Programmierung bei euch aus? Da 
ist ja auch Bedarf zur Anpassung der Entwickler-Tools.

von mmacs (Gast)


Lesenswert?

Hallo Thomas,

ok, mal etwas konkreter: 8 Kerne sind schon stattlich, das schreit schon 
mal auf mittelgrossen FPGAs nach Verstopfung. Kollege "Dorian" hat oben 
schon Cache erwaehnt, wie sollen die CPUs aneinander angebunden werden?
Nach meiner Erfahrung kommt man von dem klassischen Konzept mit zwei 
Cores und shared L2-Memory kaum weg, mehr macht nur Sinn, wenn die Cores 
komplett getrennte Wege gehen oder man ab und an einen Datenblock per 
DMA weiterschickt, dann kann man schon auf einen groesseren ECP5 z.B. 
zwei unabhaengige Dualcores draufpacken. Die Anwendungsbereiche von 
sowas wie dem Propeller erschliessen sich mir allerdings nur bedingt, 
auch wenn sich fuer die FPGA-Ansaetze davon einige safetyrelevante 
Anwendungen ergeben moegen, aber da muss man erst mal die Komplexitaet 
der CPU-Architektur in den Griff kriegen.
Und fuer speziell zugeschnittene Anwendungen ist m.E. die Kombination 
aus gut bewaehrter Architektur (mit GCC und Debugger-Support) und einem 
Coprozessor, der per DMA mit Daten gefuettert werden kann, zielführender 
als die eierlegende WMS.

Mit dem virtuellen Chip meinte ich eigentlich, dass eine Konzeptstudie 
in der virtuellen Maschine einigermassen laeuft, d.h. eine fuer alle 
benutzbare Simulationsumgebung vorliegt. Was kannst du da bereits 
vorweisen? Bei der Komplexitaet einer solchen Kooperative ist immens 
wichtig, dass ein Framework zum (Regress-)Testen vorliegt, wie zum 
Beispiel bei github ghdl/ghdl. Recht vorbildlich klappt das auch mit 
Python MyHDL.

von Andreas Rückert (Gast)


Lesenswert?

Thomas K. schrieb:
> Alles klar, Andreas. Nicht das ich euch das Hardwaredesign nicht
> zutraue, aber wie sieht es denn mit C-Programmierung bei euch aus? Da
> ist ja auch Bedarf zur Anpassung der Entwickler-Tools.

In C und Java schreib ich ja Bots usw. Das kann ich, aber freie Zeit ist 
ein Problem...

von Bego (Gast)


Lesenswert?

Leute, ihr seid viel zu spät mit euren Zeug. Die Inder sind schon 
fertig:
Beitrag "Shakti: Indiens erster RISC-V basierender Prozessor bootet Linux"

Jetzt mal im Ernst:

Eine Frage hätte ich an den TE: Hast du schon so etwas gebaut oder ist 
das eine neue Idee? Dir ist schon klar, dass bei der Umsetzung eines 
Schaltungskonzeptes, auch wenn es viel Software zu sein scheint, wie bei 
einem Prozzi, schon zu Beginn der Designphase auf die 
Implementierbarkeit Rücksicht genommen werden muss?

Es reicht bei Caches und RAM-Controllern nicht, nur einfach die Zugriffe 
als solche zu implementieren, es müssen auch Ansätze für reale Zeiten 
erfolgen, um Entscheidungen zu treffen, wo man an welcher Stelle wieviel 
Cache einsetzt, welche Register und welche fetching-Algorithmen man 
bemüht, weil die Response der RAMs und der Controller struktur- und 
technologieabhängig ist.

von Andreas Rückert (Gast)


Lesenswert?

Nur wenn man so ein Projekt selbst macht, kann man aber was dabei 
lernen?

von Thomas K. (thok)


Lesenswert?

mmacs schrieb:
> Hallo Thomas,
>
> ok, mal etwas konkreter: 8 Kerne sind schon stattlich, das schreit schon
> mal auf mittelgrossen FPGAs nach Verstopfung.

Bei der Entwicklung müssen nicht alle Cores immer generiert werden, es 
reicht einer. Das Design ist ja so ausgelegt, das die quasi parallel 
laufen und mit dem gleichen Takt versorgt werden. Ob du später mal den 
kompletten Mikrocontroller mit 8 Cores in den FPGA bekommst, hängt 
natürlich vom verwendeten FPGA ab.
Werf doch mal einen Blick in Doku des P1 oder in den Verilog Code.
Die Links dazu hatte ich hier gepostet.
Beitrag "Re: Mitstreiter für RISC-V Mikrocontrollers gesucht"

> Kollege "Dorian" hat oben
> schon Cache erwaehnt, wie sollen die CPUs aneinander angebunden werden?
> Nach meiner Erfahrung kommt man von dem klassischen Konzept mit zwei
> Cores und shared L2-Memory kaum weg, mehr macht nur Sinn, wenn die Cores
> komplett getrennte Wege gehen oder man ab und an einen Datenblock per
> DMA weiterschickt, dann kann man schon auf einen groesseren ECP5 z.B.
> zwei unabhaengige Dualcores draufpacken. Die Anwendungsbereiche von
> sowas wie dem Propeller erschliessen sich mir allerdings nur bedingt,
> auch wenn sich fuer die FPGA-Ansaetze davon einige safetyrelevante
> Anwendungen ergeben moegen, aber da muss man erst mal die Komplexitaet
> der CPU-Architektur in den Griff kriegen.

Jeder Core hat sein eignes RAM. Ein Cache ist nicht notwendig, da es 
keinen externen RAM-Bus gibt. Wenn du für diesen RAM dual-ported 
verwendest, kannst du auch noch andere Cores mit entsprechender Logik 
(round-robin) darauf zugreifen lassen, ohne den laufenden Core 
auszubremsen.

> Und fuer speziell zugeschnittene Anwendungen ist m.E. die Kombination
> aus gut bewaehrter Architektur (mit GCC und Debugger-Support) und einem
> Coprozessor, der per DMA mit Daten gefuettert werden kann, zielführender
> als die eierlegende WMS.

Im GCC gibt es schon seit 2017 Support für den RISC-V. Der Propeller ist 
nur ein kleiner Mikrocontroller mit einem netten Konzept für parallele 
Abarbeitung der Tasks deiner Anwendung, also keine eierlegende WMS.

> Mit dem virtuellen Chip meinte ich eigentlich, dass eine Konzeptstudie
> in der virtuellen Maschine einigermassen laeuft, d.h. eine fuer alle
> benutzbare Simulationsumgebung vorliegt. Was kannst du da bereits
> vorweisen? Bei der Komplexitaet einer solchen Kooperative ist immens
> wichtig, dass ein Framework zum (Regress-)Testen vorliegt, wie zum
> Beispiel bei github ghdl/ghdl. Recht vorbildlich klappt das auch mit
> Python MyHDL.

Das mit dem virtuellen Chip habe ich schon verstanden. Da das Konzept, 
welches hier zur Grundlage genommen wird, schon erprobt ist und als Chip 
mehr als 11 Jahre existiert, ist eine Konzeptstudie nicht erforderlich.
Man kann also gleich loslegen mit den HDL-Modifikationen.

von Thomas K. (thok)


Lesenswert?

Bego schrieb:
> Leute, ihr seid viel zu spät mit euren Zeug. Die Inder sind schon
> fertig:
> Beitrag "Shakti: Indiens erster RISC-V basierender Prozessor bootet Linux"

Ein Standard Linux wird auf dem geplanten Mikrocontroller nicht laufen, 
hatte ich auch nicht beabsichtigt.

> Jetzt mal im Ernst:
>
> Eine Frage hätte ich an den TE: Hast du schon so etwas gebaut oder ist
> das eine neue Idee? Dir ist schon klar, dass bei der Umsetzung eines
> Schaltungskonzeptes, auch wenn es viel Software zu sein scheint, wie bei
> einem Prozzi, schon zu Beginn der Designphase auf die
> Implementierbarkeit Rücksicht genommen werden muss?

Zur Implementierbarkeit habe ich mich schon in meinem vorherigen 
Kommentar geäußert. Das Konzept ist schon seit Jahren erprobt und als 
Chip verfügbar. Nur nicht mit RISC-V Cores. ;-)

> Es reicht bei Caches und RAM-Controllern nicht, nur einfach die Zugriffe
> als solche zu implementieren, es müssen auch Ansätze für reale Zeiten
> erfolgen, um Entscheidungen zu treffen, wo man an welcher Stelle wieviel
> Cache einsetzt, welche Register und welche fetching-Algorithmen man
> bemüht, weil die Response der RAMs und der Controller struktur- und
> technologieabhängig ist.

Leute, die meisten von euch denken zu kompliziert. Ihr vergleicht den 
kleinen Mikrocontroller anscheinend immer mit der von 64 bit Cores mit 
ARM-Architektur.
Vergleicht das lieber mit einem AVR, der hat auch nur internen RAM und 
benötigt deshalb keinen Cache. Natürlich gibt es auch bei solch einer 
Architektur limitierte Zugriffszeiten auf den RAM und andere Resourcen. 
Aber solch ein Design ist deutlicher einfacher zu handhaben, als mir 
DRAMs.

: Bearbeitet durch User
von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Thomas K. schrieb:
>> Alles klar, Andreas. Nicht das ich euch das Hardwaredesign nicht
>> zutraue, aber wie sieht es denn mit C-Programmierung bei euch aus? Da
>> ist ja auch Bedarf zur Anpassung der Entwickler-Tools.
>
> In C und Java schreib ich ja Bots usw. Das kann ich, aber freie Zeit ist
> ein Problem...

Deine Erfahrungen mit C und Java sind super. Das mit der freien Zeit 
musst du noch in den Griff bekommen. ;-)

von mmacs (Gast)


Lesenswert?

Wie gesagt sehe ich den Sinn des Parallax-Ansatzes nur bedingt, was ich 
mit Sicherheit sagen kann: Im Industriebereich ist die Akzeptanz dafuer 
recht gering. Also fehlt irgendwie noch ein schlagendes 
Verkaufsargument, was das ganze besser macht als existierende Loesungen.
Interessant waere es allenfalls fuer mich, wenn das ganze auf einer 
einfachen Stackmaschine beruht, wie J1 oder ZPU. Der Hauptgrund dafuer 
ist eine gewisse Verstopfung, die dann augenscheinlich wird, wenn 
Registerbanken a la MIPS im SRAM implementiert werden (und nicht in 
Logik). Die Stackmaschinen sind in mittelgrossen FPGA besser skalierbar.

Und was den virtuellen Chip angeht: es ist immer noch unklar, wie du das 
Multicoresystem in den Simulator stecken willst, und was ausser icarus 
so vorliegt. Bevor so ein Projekt gestartet wird, sollte ein Proof of 
Concept (und nicht nur das Concept) schon vorliegen. Seltenst finden 
sich Leute, die bereit sind, genau auf derselben Plattform wie du zu 
arbeiten.

Bevor das Ganze nun komplett totgequatscht wird, und nix bei rumkommt, 
wuerde ich einfach mal anfangen. Wenn du schon einen Teil geschafft 
hast, und es jemand gefaellt, findest du die Mitstreiter automatisch.

von Thomas K. (thok)


Lesenswert?

mmacs schrieb:
> Wie gesagt sehe ich den Sinn des Parallax-Ansatzes nur bedingt, was ich
> mit Sicherheit sagen kann: Im Industriebereich ist die Akzeptanz dafuer
> recht gering. Also fehlt irgendwie noch ein schlagendes
> Verkaufsargument, was das ganze besser macht als existierende Loesungen.
> Interessant waere es allenfalls fuer mich, wenn das ganze auf einer
> einfachen Stackmaschine beruht, wie J1 oder ZPU. Der Hauptgrund dafuer
> ist eine gewisse Verstopfung, die dann augenscheinlich wird, wenn
> Registerbanken a la MIPS im SRAM implementiert werden (und nicht in
> Logik). Die Stackmaschinen sind in mittelgrossen FPGA besser skalierbar.

Ok, das ist deine Meinung und die akzeptiere ich so. Wie schon öfter 
hier erwähnt soll es keine CPU für einen FPGA werden, sondern ein 
eigener Chip. Der FPGA ist nur ein Werkzeug, um das Ziel erreichen.

> Und was den virtuellen Chip angeht: es ist immer noch unklar, wie du das
> Multicoresystem in den Simulator stecken willst, und was ausser icarus
> so vorliegt. Bevor so ein Projekt gestartet wird, sollte ein Proof of
> Concept (und nicht nur das Concept) schon vorliegen. Seltenst finden
> sich Leute, die bereit sind, genau auf derselben Plattform wie du zu
> arbeiten.

Die Cores sind alle identisch. Ich muss also nicht alle Cores im 
Simulator haben, einer reicht. Das es bisher noch keine große Auswahl an 
RISC-V Cores in VHDL gibt, dafür kann ich nichts. Aber ich werde nicht 
das Rad neu erfinden, wenn ich schon eins habe, was rund läuft.
Deine Einwände bzgl. fehlendem Proof of Concept kann ich nicht teilen. 
Ich dachte, das hatte ich zwei Kommentare zuvor schon aus der Welt 
geräumt.

> Bevor das Ganze nun komplett totgequatscht wird, und nix bei rumkommt,
> wuerde ich einfach mal anfangen. Wenn du schon einen Teil geschafft
> hast, und es jemand gefaellt, findest du die Mitstreiter automatisch.

Danke für deine aufmunternden Worte. ;-)

von Andreas Rückert (Gast)


Lesenswert?

Also ich hab an FPGA Boards bisher ein de0 nano, ein ep2c5t144 und ein 
Lattice Board.
Ich hab meist die 13.0sp1 Quartus2 Software benutzt, die man ggf. aber 
auch in der Shell z.B. über ein Makefile starten kann. Geht das mit 
Vivado auch? Dann könnte man ja die Tools über Variablen aufrufen, und 
so die Sache quasi portabel bekommen? Schwierig wird es halt bei Sachen 
wie etwa dem sdram Controller auf dem de0 Board. Müsste man dann in 
system-abhängige Module auslagern.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Also ich hab an FPGA Boards bisher ein de0 nano, ein ep2c5t144 und ein
> Lattice Board.
> Ich hab meist die 13.0sp1 Quartus2 Software benutzt, die man ggf. aber
> auch in der Shell z.B. über ein Makefile starten kann. Geht das mit
> Vivado auch? Dann könnte man ja die Tools über Variablen aufrufen, und
> so die Sache quasi portabel bekommen? Schwierig wird es halt bei Sachen
> wie etwa dem sdram Controller auf dem de0 Board. Müsste man dann in
> system-abhängige Module auslagern.

Hallo Andreas, ja, bei Vivado kann man auch per Kommandozeile diverse 
Tools benutzen.
Wenn du ein DE0-Nano hast, kannst du dir den Propeller mit allen 8 Cores 
in deinen FPGA schießen und tiefer in die Materie eintauchen.
Du brauchst natürlich etwas Zeit dafür. ;-)
https://www.parallax.com/microcontrollers/propeller-1-open-source

: Bearbeitet durch User
von Andreas Rückert (Gast)


Lesenswert?

Ehrlich gesagt hab ich mit dem de0 nano bisher weniger gemacht als mit 
dem 15,- cyclone 2 Board.
Ich hab das de0 hauptsächlich gekauft, weil ich es gerade günstig 
gebraucht bekommen hab.
Mit ep2 Board hab ich die Hoffnung ein paar Mitstreiter für so kleine 
CPU Projekte zu finden, weil es einfach so billig ist, dass jemand mal 
20,- investiert in der Hoffnung Husserl Spass zu haben und noch was 
dabei zu lernen. Ich wollte da so eine kleine Serie von Tutorials 
machen. Hier ist mal der Anfang:

https://www.forum64.de/index.php?thread/83766-fpgas/

Einen Mitstreiter hab ich mal gefunden und wir basteln nun zusammen an 2 
CPUs. Ich glaub, er ist sogar eher in Deiner Richtung unterwegs, weil er 
auch RISC macht, Icarus benutzt (welches schon einfache Fehler 
übersieht, wie wir inzwischen wissen) und lieber die Kommandozeile 
benutzt.

Generell find ich es schwierig Infos aus der FPGA Szene zu finden, 
weshalb wir das nun auf ner eigenen HTML Seite (bislang nur für uns) 
machen, damit uns die Links nicht verloren gehen.

von Thomas K. (thok)


Lesenswert?

Andreas Rückert schrieb:
> Ehrlich gesagt hab ich mit dem de0 nano bisher weniger gemacht als mit
> dem 15,- cyclone 2 Board.
> Ich hab das de0 hauptsächlich gekauft, weil ich es gerade günstig
> gebraucht bekommen hab.

Du musst dich nicht dafür entschuldigen, dass du mit dem Nano bisher 
eher weniger Erfahrungen hast. Wenn dir das EP2 erstmal ausreicht, ist 
das ok.

> Mit ep2 Board hab ich die Hoffnung ein paar Mitstreiter für so kleine
> CPU Projekte zu finden, weil es einfach so billig ist, dass jemand mal
> 20,- investiert in der Hoffnung Husserl Spass zu haben und noch was
> dabei zu lernen. Ich wollte da so eine kleine Serie von Tutorials
> machen. Hier ist mal der Anfang:
>
> https://www.forum64.de/index.php?thread/83766-fpgas/

Das find ich super! So kannst du anderen die Einstiegshürde für FPGAs 
nehmen.

> Einen Mitstreiter hab ich mal gefunden und wir basteln nun zusammen an 2
> CPUs. Ich glaub, er ist sogar eher in Deiner Richtung unterwegs, weil er
> auch RISC macht, Icarus benutzt (welches schon einfache Fehler
> übersieht, wie wir inzwischen wissen) und lieber die Kommandozeile
> benutzt.

Hat den Mitstreiter nicht Interesse in dem Projekt hier mit zu machen? 
Zumal er sich anscheinend schon mit einem ähnlichen Thema beschäftigt.

> Generell find ich es schwierig Infos aus der FPGA Szene zu finden,
> weshalb wir das nun auf ner eigenen HTML Seite (bislang nur für uns)
> machen, damit uns die Links nicht verloren gehen.

Das was es im Internet gibt ist meist in englisch, aber davon gibt es 
ganz viel. ;-)
Wenn du mit englisch klar kommst, sollte das kein Problem sein.

von mmacs (Gast)


Lesenswert?

Thomas K. schrieb:
> Ok, das ist deine Meinung und die akzeptiere ich so. Wie schon öfter
> hier erwähnt soll es keine CPU für einen FPGA werden, sondern ein
> eigener Chip. Der FPGA ist nur ein Werkzeug, um das Ziel erreichen.

Mal ganz davon abgesehen, ob sich ein Alleinstellungsmerkmal gegenueber 
gap8 oder den Parallela-Designs ergibt:

Heisst das, dass du Finanzmittel anzapfen koenntest, um:
- 1-2 Mannjahre Entwicklungskosten externer Partner/Fertiger oder die 
passenden Tools zu finanzieren
- IP-Cores (vom Fertiger) zukaufen zu koennen
- Einen funktionierenden Tapeout hinzulegen

Wenn das geschafft ist, geht es erst richtig los.

Ich habe schon fuer einige Fabless-Firmen gearbeitet und sehe das 
womoeglich viel weniger optimistisch (realistisch...). Solche 
hochgesteckten Ziele beissen sich stark mit dem Ansatz "Freiwilliger 
Einzelkaempfer", das Risiko der Bauchlandung ist schon fuer erfahrene 
Firmen recht hoch (been there).

von Thomas K. (thok)


Lesenswert?

mmacs schrieb:
> Thomas K. schrieb:
>> Ok, das ist deine Meinung und die akzeptiere ich so. Wie schon öfter
>> hier erwähnt soll es keine CPU für einen FPGA werden, sondern ein
>> eigener Chip. Der FPGA ist nur ein Werkzeug, um das Ziel erreichen.
>
> Mal ganz davon abgesehen, ob sich ein Alleinstellungsmerkmal gegenueber
> gap8 oder den Parallela-Designs ergibt:
>
> Heisst das, dass du Finanzmittel anzapfen koenntest, um:
> - 1-2 Mannjahre Entwicklungskosten externer Partner/Fertiger oder die
> passenden Tools zu finanzieren
> - IP-Cores (vom Fertiger) zukaufen zu koennen
> - Einen funktionierenden Tapeout hinzulegen

Wer den ersten Schritt nicht wagt, weil er denkt, das er hinfallen 
könnte, wird nie laufen lernen.
Machmal muss man einfach auch mal spinnen und hoffen, das es noch 
weitere Unterstützer für ein Projekt gibt.
https://www.sifive.com/press

> Wenn das geschafft ist, geht es erst richtig los.

Bist du dabei?

von Dorian Grey (Gast)


Lesenswert?

Duke Scarring schrieb:
> Dorian Grey schrieb:
>> alteuropäisches VHDL
> Soso. Das DoD und der F-22 sind also alteuropäische Erfindungen...

Mit alt / europäisch meinte ich den Sachverhalt, dass

a) in Europa vornämlich VHDL zur Anwendung kommt
b) ich beides hinter mir gelassen habe

was aber ...

c) nicht impliziert, dass ich Verilog für ein solches Projekt 
favorisieren würde

Die Festlegung auf Verilog hingegen sorgt

d) durchaus dafür, dass es wenige potenzielle Beteiliger aus Foren in EU 
geben könnte


Thomas K. schrieb:
> Da du bisher vorwiegend VHDL verwendet hast, hast du natürlich den
> Icarus noch nicht benötigt.
Durchaus nicht. Nur die Sourcen sind eben VHDL.

> Aufgrund der Multicore
> Architektur ist der Einsatz für Anwendungen mit kurzen Latenzzeiten
> prädestiniert.
Diese Schlussfolgerung ist eine gerne gezogene, stimmt aber überwiegend 
nicht.

von Dorian Grey (Gast)


Lesenswert?

Thomas K. schrieb:
> Wie schon öfter
> hier erwähnt soll es keine CPU für einen FPGA werden, sondern ein
> eigener Chip.

Es wird aber für eine sehr lange Zeit eine Lösung im FPGA sein müssen 
und zwar ...

... eine, die in mehreren Instanzen arbeitet und ...
... die, mit diesen zusammen arbeitet ...
... gut zusammenarbeitet
... und einen Vorteil bringt gegenüber echten parallelen Instanzen

Das muss sowas von sehr gut funktionieren, dass sich ein Hersteller 
findet, der das design kauft und produziert. Alles andere ist utopisch.


>Der FPGA ist nur ein Werkzeug, um das Ziel erreichen.
Ja, genau und das muss überzeugend sein und das geht nur mit einem guten 
Demonstrator, den man mit Faktor 10 gedanklich hochskalieren kann, wenn 
man die 1GHz unterstellt mit denen man das betreiben kann und es mit den 
100MHz vergleicht auf denen der FPGA läuft.

> Die Cores sind alle identisch. Ich muss also nicht alle Cores im
> Simulator haben, einer reicht.
Wie möchtest du das eigentliche, also das miteinander reden, testen?

>> Bevor das Ganze nun komplett totgequatscht wird, und nix bei rumkommt,
>> wuerde ich einfach mal anfangen.
Ich sehe es eher so, dass ein Projekt gut durchdacht sein muss, weil es 
sonst nach viel Arbeit in der Pampa verschwindet, weil man sich 
verrennt, zerstreitet und sich nach und nach die Mitstreiter 
verabschieden.

Ich z.B. habe keine Lust, Zeit in sowas zu investieren, meine Beiträge 
in den pool zu werfen, wenn andere nur profitieren um dabei zu lernen.

von Thomas K. (thok)


Lesenswert?

Dorian Grey schrieb:
> Duke Scarring schrieb:
>> Dorian Grey schrieb:
>>> alteuropäisches VHDL
>> Soso. Das DoD und der F-22 sind also alteuropäische Erfindungen...
>
> Mit alt / europäisch meinte ich den Sachverhalt, dass
>
> a) in Europa vornämlich VHDL zur Anwendung kommt
> b) ich beides hinter mir gelassen habe
>
> was aber ...
>
> c) nicht impliziert, dass ich Verilog für ein solches Projekt
> favorisieren würde
>
> Die Festlegung auf Verilog hingegen sorgt
>
> d) durchaus dafür, dass es wenige potenzielle Beteiliger aus Foren in EU
> geben könnte

Dessen war ich mir von Anfang an bewußt. Aber wie schon erwähnt, es ist 
nun mal so, das mehr RISC-V Cores in Verilog als Open Source zur 
Verfügung stehen.

> Thomas K. schrieb:
>> Da du bisher vorwiegend VHDL verwendet hast, hast du natürlich den
>> Icarus noch nicht benötigt.
> Durchaus nicht. Nur die Sourcen sind eben VHDL.

Auch gut, dann hast du zumindest Erfahrungen mit Icarus.

>> Aufgrund der Multicore
>> Architektur ist der Einsatz für Anwendungen mit kurzen Latenzzeiten
>> prädestiniert.
> Diese Schlussfolgerung ist eine gerne gezogene, stimmt aber überwiegend
> nicht.

Ich lerne gern dazu. Hast du dafür ein Beispiel bzw. eine Erklärung?

von Thomas K. (thok)


Lesenswert?

Dorian Grey schrieb:
> Thomas K. schrieb:
>> Wie schon öfter
>> hier erwähnt soll es keine CPU für einen FPGA werden, sondern ein
>> eigener Chip.
>
> Es wird aber für eine sehr lange Zeit eine Lösung im FPGA sein müssen
> und zwar ...
>
> ... eine, die in mehreren Instanzen arbeitet und ...
> ... die, mit diesen zusammen arbeitet ...
> ... gut zusammenarbeitet
> ... und einen Vorteil bringt gegenüber echten parallelen Instanzen
>
> Das muss sowas von sehr gut funktionieren, dass sich ein Hersteller
> findet, der das design kauft und produziert. Alles andere ist utopisch.

Da hast du recht. Wann starten wir gemeinsam?

>>Der FPGA ist nur ein Werkzeug, um das Ziel erreichen.
> Ja, genau und das muss überzeugend sein und das geht nur mit einem guten
> Demonstrator, den man mit Faktor 10 gedanklich hochskalieren kann, wenn
> man die 1GHz unterstellt mit denen man das betreiben kann und es mit den
> 100MHz vergleicht auf denen der FPGA läuft.

Da stimme ich dir zu. Ob es gleich 1 GHz sein muss, sei noch dahin 
gestellt. Die Hälfte davon würde mir schon reichen.

>> Die Cores sind alle identisch. Ich muss also nicht alle Cores im
>> Simulator haben, einer reicht.
> Wie möchtest du das eigentliche, also das miteinander reden, testen?

Ok, wenn ein Core soweit getestet und alles funzt, brauche man 
vielleicht auch mal zwei Cores im Simulator. Aber eventuell kann man 
darauf verzichten, wenn beide RAM Ports mit einem Core getestet sind.
Ansonsten können die Cores auch durch Software über ein shared 
(dual-ported) RAM kommunizieren.

>>> Bevor das Ganze nun komplett totgequatscht wird, und nix bei rumkommt,
>>> wuerde ich einfach mal anfangen.
> Ich sehe es eher so, dass ein Projekt gut durchdacht sein muss, weil es
> sonst nach viel Arbeit in der Pampa verschwindet, weil man sich
> verrennt, zerstreitet und sich nach und nach die Mitstreiter
> verabschieden.
> Ich z.B. habe keine Lust, Zeit in sowas zu investieren, meine Beiträge
> in den pool zu werfen, wenn andere nur profitieren um dabei zu lernen.

Schade! Ich glaube du wärst ein guter Mann im Team.

: Bearbeitet durch User
von saalfelder (Gast)


Lesenswert?

Es gibt bereits einen MIPS Softcore, der alle MIPS 1 Befehle ausführen 
kann. Zu MIPS gibt es viel akademische Literatur. Da haste gleich die 
GNU Toolchain am Laufen und die ist seit Jahren getestet. Die Risc-V 
Sachen, egal wo ich hinstoße sind noch im entstehen und haben 
Krankheiten oder es sind nicht alle Befehle umgesetzt, dann musst du den 
Compiler abwürgen usw.

Schau mal dir mal den an.
http://www.dossmatik.de/mais-cpu.html

von Thomas K. (thok)


Lesenswert?

saalfelder schrieb:
> Es gibt bereits einen MIPS Softcore, der alle MIPS 1 Befehle ausführen
> kann. Zu MIPS gibt es viel akademische Literatur. Da haste gleich die
> GNU Toolchain am Laufen und die ist seit Jahren getestet. Die Risc-V
> Sachen, egal wo ich hinstoße sind noch im entstehen und haben
> Krankheiten oder es sind nicht alle Befehle umgesetzt, dann musst du den
> Compiler abwürgen usw.
>
> Schau mal dir mal den an.
> http://www.dossmatik.de/mais-cpu.html

Schön das du den Link auch gefunden hast. Ich könnte dir auch noch ein 
paar Links zu MIPS Cores geben. ;-)

Du kennst schon den Unterschied zwischen MIPS und RISC-V?

Welche GNU Toolchain hast du mit einem RISC-V Core getestet?

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Die Entwicklung der Cores ist zwar wichtig, aber nur ein winziger Anteil 
des gesamten Microcontrollers. Einer der Gründe für den eingeschränkten 
Erfolg von Parallal Propeller besteht ja darin, dass versucht wurde, die 
gesamte Peripherie in Software zu realisieren. Das mag für einige 
Protokolle (I2C, SPI, UART, vielleicht auch USB) der richtige Weg sein, 
aber schon bei Ethernet reicht die Rechenleistung nicht mehr aus.

Daher sehe ich eine besondere Herausforderung darin, geeignete 
Hardwareblöcke vorzusehen, die sowohl gewöhnliche Protokolle 
unterstützen als auch für Erweiterungen offen sind. Da Du ja Wearables 
als einen der Zielmärkte angibst, ist also eine Minimierung der 
elektrischen Leistungsaufnahme höchstgradig wichtig. Aus diesem Grunde 
kann es interessant werden, z.B. blockierende Zugriffe auf 
Peripherieregister zu implementieren, d.h. ein Core wird wirklich 
angehalten, bis ein bestimmtes Ereignis des Peripherieblocks eintritt. 
So etwas kann möglicherweise gegenüber Interrupts o.ä. ordentlich 
aktive Taktzyklen einsparen und damit den Energiebedard minimieren. 
Entsprechende Ansätze hierfür gab es z.B. schon bei den asynchronen 
(self-clocked) ARM-Kernen wie Amulet 3, aber sie sind wieder in der 
Versenkung verschwunden.

Mittlerweile sind ja auch sehr schnelle serielle Protokolle verbreitet, 
und für eine neue halbwegs zukunftsfähige Microcontrollerfamilie muss es 
Möglichkeiten geben, z.B. USB 3.x, HDMI, DisplayPort, 1000-BaseX, SATA 
usw. zu unterstützen. Und dann auch noch etliche Drahtlosprotokolle.

von (prx) A. K. (prx)


Lesenswert?

Eine Falle bei Parallax ist die fehlende Skalierung. Die vom Mainstream 
stark abweichende Struktur des Propellers führt zu Lösungen, die auf 
andere Plattformen nur aufwändig portierbar sind. Wird der Propeller zu 
klein, hat man aber genau dies an der Backe.

Andreas S. schrieb:
> aber schon bei Ethernet reicht die Rechenleistung nicht mehr aus.

Bei XMOS ist es gelungen, Gbit-Ethernet auf Software-Basis zu 
implementieren, nur ein PHY wird benötigt. Der Aufwand ist aber 
beträchtlich und die Lösung damit recht ineffizient.

von Saalfelder (Gast)


Lesenswert?

Thomas K. schrieb:
> Du kennst schon den Unterschied zwischen MIPS und RISC-V?

Ich kenne keinen Unterschied. Die Opcodes sehen sehr ähnlich aus. Ich 
wüsste nicht, was der besondere Knaller ist. Da bin ich jetzt wirklich 
gespannt. Wenn du mich aufklären könntest, danke ich dir schon mal.



> Welche GNU Toolchain hast du mit einem RISC-V Core getestet?
Die GNU Version weiss ich nicht mehr. Es war unter Linux. Der RISC-V war 
von einer Uni hochgelobt und den wollte ich testen. Da ging nicht viel. 
Das war vor ca. 2Jahren. Das war mein letzter RISC-V Kontakt.

>Schön das du den Link auch gefunden hast. Ich könnte dir auch noch ein
>paar Links zu MIPS Cores geben. ;-)
Die den kompletten MIPS I OPcode abdecken und auch in C programmierbar 
sind.
n

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Die Entwicklung der Cores ist zwar wichtig, aber nur ein winziger Anteil
> des gesamten Microcontrollers. Einer der Gründe für den eingeschränkten
> Erfolg von Parallal Propeller besteht ja darin, dass versucht wurde, die
> gesamte Peripherie in Software zu realisieren. Das mag für einige
> Protokolle (I2C, SPI, UART, vielleicht auch USB) der richtige Weg sein,
> aber schon bei Ethernet reicht die Rechenleistung nicht mehr aus.

Welcher Mirkocontroller besitzt einen eigenen Ethernet Core?
Stattdessen kann man getrost SPI basierte Ethernet-Controller 
anschließen.

Ansonsten kann man sich da natürlich noch austoben und sinnvolle 
Peripherie hinzufügen. Aber das kommt später...

> Daher sehe ich eine besondere Herausforderung darin, geeignete
> Hardwareblöcke vorzusehen, die sowohl gewöhnliche Protokolle
> unterstützen als auch für Erweiterungen offen sind. Da Du ja Wearables
> als einen der Zielmärkte angibst, ist also eine Minimierung der
> elektrischen Leistungsaufnahme höchstgradig wichtig.

Da musst du was missverstanden haben. Ein Mikrocontroller für Wearables 
war nicht mein Ziel.

> Aus diesem Grunde
> kann es interessant werden, z.B. blockierende Zugriffe auf
> Peripherieregister zu implementieren, d.h. ein Core wird wirklich
> angehalten, bis ein bestimmtes Ereignis des Peripherieblocks eintritt.

Tolle Idee, kann der Propeller aber schon. Muss also nicht neu erfunden 
werden.

> So etwas kann möglicherweise gegenüber Interrupts o.ä. ordentlich
> aktive Taktzyklen einsparen und damit den Energiebedard minimieren.
> Entsprechende Ansätze hierfür gab es z.B. schon bei den asynchronen
> (self-clocked) ARM-Kernen wie Amulet 3, aber sie sind wieder in der
> Versenkung verschwunden.

Völlig richtig.

> Mittlerweile sind ja auch sehr schnelle serielle Protokolle verbreitet,
> und für eine neue halbwegs zukunftsfähige Microcontrollerfamilie muss es
> Möglichkeiten geben, z.B. USB 3.x, HDMI, DisplayPort, 1000-BaseX, SATA
> usw. zu unterstützen. Und dann auch noch etliche Drahtlosprotokolle.

Einige davon könnte man unterstützen, aber sicher nicht alle.

von Thomas K. (thok)


Lesenswert?

A. K. schrieb:
> Eine Falle bei Parallax ist die fehlende Skalierung. Die vom Mainstream
> stark abweichende Struktur des Propellers führt zu Lösungen, die auf
> andere Plattformen nur aufwändig portierbar sind. Wird der Propeller zu
> klein, hat man aber genau dies an der Backe.

Warum sollte ich eine Anwendung, die auf dem Propeller läuft, auf einen 
Single Core Mirkocontroller portieren?

Warum wird der Propeller zu klein? Das kann nur am Speicher liegen und 
davon soll es jetzt mehr geben, damit man den auch richtig mit C 
entwickeln kann.

von Thomas K. (thok)


Lesenswert?

Saalfelder schrieb:
> Thomas K. schrieb:
>> Du kennst schon den Unterschied zwischen MIPS und RISC-V?
>
> Ich kenne keinen Unterschied. Die Opcodes sehen sehr ähnlich aus. Ich
> wüsste nicht, was der besondere Knaller ist. Da bin ich jetzt wirklich
> gespannt. Wenn du mich aufklären könntest, danke ich dir schon mal.

Ein wichtiger Unterschied ist, das die verfügbaren Befehle durch die 
RISC-V Spezifikation standardisiert wurde, egal ob der Core 32, 64 oder 
128 bit hat.
Der entscheidendste Unterschied ist jedoch, das du die RISC-V ISA ohne 
Lizenzkosten in deinen eigenen Cores verwenden kannst. Du musst also 
nicht deine eigene Toolchain bauen.
Aber das hast du sicherlich auch schon selbst gewusst. ;-)

>> Welche GNU Toolchain hast du mit einem RISC-V Core getestet?
> Die GNU Version weiss ich nicht mehr. Es war unter Linux. Der RISC-V war
> von einer Uni hochgelobt und den wollte ich testen. Da ging nicht viel.
> Das war vor ca. 2Jahren. Das war mein letzter RISC-V Kontakt.

Dann war das sicherlich eine sehr früher Version der GNU Toolchain. Aber 
das war beim hinzufügen der Unterstützung für andere Prozessoren auch 
nicht anders. Mittlerweile sollten die Kinderkrankheiten beseitigt sein.

von Maier (Gast)


Lesenswert?

Thomas K. schrieb:
> Maier schrieb:
>> Wie ist das hier angedacht, Speicherarchitektur, Zugriffssteuerung...?
> Die Modifikationen betreffen vorallem die Speicherarchitektur. Der
> Main-RAM soll entfallen, der Cog-RAM vergrößert werden, mind. 16KiB pro
> Core. Der verfügbare RAM im Chip soll durch entsprechende Modi anderes
> verteilt werden können. Ein externer Speicherbus ist erstmal nicht
> geplant, aber könnte später eine Option sein, kostet aber sehr viele
> Pins. Entsprechende Konzepte für die Nutzung eines externen Speichers
> sind noch nicht vorhanden.
Ich muss da doch nochmal darauf zurück kommen. Meiner Meinung nach 
verkompliziert eine solche Architektur (d.h. mit verteilten Speichern) 
die Programmierung, also Nutzung, des Chips. Ideal wäre ein großer 
Speicher, von dem alle Cores "leben". Man bliebe in einem Adressraum, 
kann den Instruction Pointer eines beliebigen Kerns auf eine Adresse 
setzen und den Kern starten. Die Toolchain müsste also gar nicht 
'wissen', dass es ein Mehrkerner ist. Auch fiele ein Bibliotheksoverhead 
nur einmal an für alle Kerne.

Ich kann mir schon vorstellen, dass das den Entwurf selbst 
verkompliziert, oder mit konkurenzfähiger Taktung gar nicht möglich ist, 
alle Cores aus einem Speicher zu versorgen. Aber sollte man das nicht 
zumindest andenken/untersuchen?

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Thomas K. schrieb:
> Welcher Mirkocontroller besitzt einen eigenen Ethernet Core?

Es gibt schon seit vielen Jahren Microcontroller mit Ethernet:

- STM32F217, etliche STM32H7
- LPC175x, LPC176x

Schon der deutlich über 10 Jahre alten LPC2368 hatte Ethernet.

> Stattdessen kann man getrost SPI basierte Ethernet-Controller
> anschließen.

Also muss man wieder Statusregister pollen, selbst wenn es eine 
dedizierte Interruptstrippe gibt.

> Ansonsten kann man sich da natürlich noch austoben und _sinnvolle_
> Peripherie hinzufügen. Aber das kommt später...

Ohne ein von vornherein ausgiebig durchdachtes Peripheriekonzept sehe 
ich keinen allzu großen Bedarf. Dann kann man auch gleich einen bo8 
einsetzen.

> Da musst du was missverstanden haben. Ein Mikrocontroller für Wearables
> war nicht mein Ziel.

Komisch. Die folgende Nachricht legt dies aber nahe:

Thomas K. schrieb:
> Andreas Rückert schrieb:
>> Wobei Du mit Multicore RISC V wohl ein paar Ligen höher als wir zielst.
>
> Nicht unbedingt. Es gibt auch kleine RISC-V Cores, die z.B. für
> Wearables vorgesehen sind. Damit kann man natürlich auch Multicore
> Systeme bauen. Es muss nicht immer gleich ein Linux System darauf
> lauffähig sein.
>
> Von daher bist du gern willkommen, deine Ideen ins Projekt einzubringen.
> Interesse an Mikrocontrollern und der RISC-V ISA sind von Vorteil. ;-)


> Tolle Idee, kann der Propeller aber schon. Muss also nicht neu erfunden
> werden.

Das muss nicht neu erfunden werden, aber sind derartige Mechanismen, die 
sehr tief in der Prozessorkern eingreifen, bei RISC-V vorgesehen? Gibt 
es die Möglichkeit, über Flags zu entscheiden, ob Zugriffe blockierend 
sein sollen? Oder über den verwendeten Speicherbereich?

Das sind alles Überlegungen, die man vor Beginn der Core-Entwicklung 
anstellen muss.

> Einige davon könnte man unterstützen, aber sicher nicht alle.

Wenn man das Design an einen Halbleiterhersteller oder IP-Anbieter 
verkaufen will, wird er natürlich den vorgelegten Entwicklungsstand 
anschauen, um einzuschätzen, ob er funktionsfähig ist. Und als nächstes 
will er eine Roadmap für die nächsten fünf bis zehn Jahre sehen. Und die 
in dieser Roadmap aufgeführten Leistungsmerkmale müssen die 
Anforderungen abdecken, von denen man annimmt, dass sie während der 
Produktlebensdauer relevant sein werden. Als neuer Anbieter muss man 
sich da irgendwie von den vorhandenen unterscheiden können, z.B. indem 
man plausibel nachweisen kann, dass das eigene Konzept es ermöglicht, 
schneller oder mit weniger Aufwand neue funktionsfähige(!) Peripherie zu 
realisieren.

Geht man jedoch von vornherein davon aus, Peripherie per SPI o.ä. 
anschließen zu müssen, bedeutet das eine Mehrchiplösung.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Maier schrieb:
> Ideal wäre ein großer Speicher, von dem alle Cores "leben".

Mittlerweile sind wir dank Pipelining usw. an einem Punkt angekommen, an 
dem der Durchsatz eines Prozessorkerns überwiegend durch die 
Speicherbandbreite und nicht mehr nur durch dessen Takt bestimmt wird. 
Dual-Ported-RAMs kann man noch mit vertretbarem Aufwand herstellen, aber 
bei einer größeren Anzahl benötigter Ports explodiert der Aufwand. Bei 
den "großen" x64-Prozessoren besitzt daher jeder Kern eigene(n) 
L1-Cache(s), welches einen ganz erheblichen Anteil an der Chipfläche 
ausmachen. Für kostengünstige Microcontroller mit vielen Kernen ist dies 
unpraktikabel. Man könnte höchstens darüber nachdenken, jeweils zwei 
Kerne mit einem DPRAM zu versehen und die Kerne in noch zu bestimmender 
Topologie zu verbinden.

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Thomas K. schrieb:
>> Maier schrieb:
>>> Wie ist das hier angedacht, Speicherarchitektur, Zugriffssteuerung...?
>> Die Modifikationen betreffen vorallem die Speicherarchitektur. Der
>> Main-RAM soll entfallen, der Cog-RAM vergrößert werden, mind. 16KiB pro
>> Core. Der verfügbare RAM im Chip soll durch entsprechende Modi anderes
>> verteilt werden können. Ein externer Speicherbus ist erstmal nicht
>> geplant, aber könnte später eine Option sein, kostet aber sehr viele
>> Pins. Entsprechende Konzepte für die Nutzung eines externen Speichers
>> sind noch nicht vorhanden.
> Ich muss da doch nochmal darauf zurück kommen. Meiner Meinung nach
> verkompliziert eine solche Architektur (d.h. mit verteilten Speichern)
> die Programmierung, also Nutzung, des Chips.

Danke für deine konstruktiven Hinweise.

Beim aktuellen Propeller sieht das so aus. Beim Programmieren musst du 
auf die verschiedenen Speicher keine Rücksicht nehmen. Darum kümmert 
sich die Toolchain. Die überwacht, das deine Codeschnipsel später auch 
in den Speicher eines Cores passen.
Du startest in deinem Code einen neuen Core und übergibst dem eine 
Speicheradresse, die auf den Code für deinen Task zeigt.

Das vom Compiler generierte Image, was den kompletten Code deiner 
Anwendung enthält, wird beim Starten des Propellers aus dem EEPROM in 
den Main RAM (32KiB) geladen. Deine Anwendung wird automatisch im ersten 
Core am Eintrittspunkt gestartet.

Wenn dein Hauptprogramm jetzt zur der Stelle im Code kommt, wo der neue 
Core gestartet wird, dann lädt der Propeller den Code ab der 
spezifizierten Adresse aus dem Main RAM in den Speicher des zu 
startenden Cores. Das sind immer 2KiB, egal wie groß dein Code 
eigentlich ist, der in dem Core laufen soll.

Jetzt zur Beantwortung deiner Frage.
Wie du an meiner Beschreibung erkennen kannst, verkommpliziert sich 
nicht die Programmierung durch die verwendete Architektur.

> Ideal wäre ein großer
> Speicher, von dem alle Cores "leben". Man bliebe in einem Adressraum,
> kann den Instruction Pointer eines beliebigen Kerns auf eine Adresse
> setzen und den Kern starten.
>
> Ich kann mir schon vorstellen, dass das den Entwurf selbst
> verkompliziert, oder mit konkurenzfähiger Taktung gar nicht möglich ist,
> alle Cores aus einem Speicher zu versorgen. Aber sollte man das nicht
> zumindest andenken/untersuchen?

So ähnlich funktioniert es ja beim Propeller, nur das der Code aus dem 
großen Speicher in den kleinen Speicher des Cores geladen wird, bevor 
der Core mit der Abarbeitung des Codes beginnt.
Damit umgeht man das Problem mit dem Speicherzugriff, wenn mehrere Cores 
nur einen Speicher verwenden würden. Die Cores müssten dafür 
ausgebremst werden, damit jeder Core nacheinander auf den Speicher 
zugreifen kann. Damit wäre die Performance des Multicore Systems dahin.

Wenn du neue Ideen hast, um das Problem mit den Speicherzugriffen zu 
lösen, nur zu.

> Die Toolchain müsste also gar nicht
> 'wissen', dass es ein Mehrkerner ist. Auch fiele ein Bibliotheksoverhead
> nur einmal an für alle Kerne.

Mit dem Bibliotheksoverhead hast du natürlich recht. Das Problem tritt 
auf, wenn man mit C/C++ programmiert. Das Problem läßt sich aber nicht 
einfach mit einem gemeinsamen Speicher lösen, wie oben von mir 
beschrieben. Deshalb muss man damit leben, das der Code für jeden Core 
quasi statisch mit den verwendeten Libs gelinkt ist.

Als Alternative bieten sich andere Programmiersprachen (Spin oder 
Assembler) an, die aber nicht jeder erlernen möchte.

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Thomas K. schrieb:
>> Welcher Mirkocontroller besitzt einen eigenen Ethernet Core?
>
> Es gibt schon seit vielen Jahren Microcontroller mit Ethernet:
>
> - STM32F217, etliche STM32H7
> - LPC175x, LPC176x
>
> Schon der deutlich über 10 Jahre alten LPC2368 hatte Ethernet.

Prima, wußte ich nicht, wieder was gelernt.

>> Ansonsten kann man sich da natürlich noch austoben und _sinnvolle_
>> Peripherie hinzufügen. Aber das kommt später...
>
> Ohne ein von vornherein ausgiebig durchdachtes Peripheriekonzept sehe
> ich keinen allzu großen Bedarf. Dann kann man auch gleich einen bo8
> einsetzen.
>

Da magst du recht haben, das man sich da noch was einfallen lassen muss.

>> Da musst du was missverstanden haben. Ein Mikrocontroller für Wearables
>> war nicht mein Ziel.
>
> Komisch. Die folgende Nachricht legt dies aber nahe:
>
> Thomas K. schrieb:
>> Andreas Rückert schrieb:
>>> Wobei Du mit Multicore RISC V wohl ein paar Ligen höher als wir zielst.
>>
>> Nicht unbedingt. Es gibt auch kleine RISC-V Cores, die z.B. für
>> Wearables vorgesehen sind. Damit kann man natürlich auch Multicore
>> Systeme bauen. Es muss nicht immer gleich ein Linux System darauf
>> lauffähig sein.
>>
>> Von daher bist du gern willkommen, deine Ideen ins Projekt einzubringen.
>> Interesse an Mikrocontrollern und der RISC-V ISA sind von Vorteil. ;-)

Es war nur eine Klarstellung, das RISC auch was Kleines sein kann.

>> Tolle Idee, kann der Propeller aber schon. Muss also nicht neu erfunden
>> werden.
>
> Das muss nicht neu erfunden werden, aber sind derartige Mechanismen, die
> sehr tief in der Prozessorkern eingreifen, bei RISC-V vorgesehen? Gibt
> es die Möglichkeit, über Flags zu entscheiden, ob Zugriffe blockierend
> sein sollen? Oder über den verwendeten Speicherbereich?
>
> Das sind alles Überlegungen, die man vor Beginn der Core-Entwicklung
> anstellen muss.

Da hast du natürlich recht, dass das geprüft werden muss. Wie gesagt, es 
sollte kein neuer Core entwickelt werden, sondern ein vorhandener 
genutzt werden.

>> Einige davon könnte man unterstützen, aber sicher nicht alle.
>
> Wenn man das Design an einen Halbleiterhersteller oder IP-Anbieter
> verkaufen will, wird er natürlich den vorgelegten Entwicklungsstand
> anschauen, um einzuschätzen, ob er funktionsfähig ist. Und als nächstes
> will er eine Roadmap für die nächsten fünf bis zehn Jahre sehen. Und die
> in dieser Roadmap aufgeführten Leistungsmerkmale müssen die
> Anforderungen abdecken, von denen man annimmt, dass sie während der
> Produktlebensdauer relevant sein werden. Als neuer Anbieter muss man
> sich da irgendwie von den vorhandenen unterscheiden können, z.B. indem
> man plausibel nachweisen kann, dass das eigene Konzept es ermöglicht,
> schneller oder mit weniger Aufwand neue funktionsfähige(!) Peripherie zu
> realisieren.

Das ist alles richtig was du sagst, aber trifft eher zu, wenn man schon 
was vorweisen kann. Ich glaube, das muss man beim Start eines Freizeit 
Projektes noch nicht in der Planung haben.

> Geht man jedoch von vornherein davon aus, Peripherie per SPI o.ä.
> anschließen zu müssen, bedeutet das eine Mehrchiplösung.

Hat das Arduino Projekt auch nicht vom Erfolg abgehalten.

Trotzdem, vielen Dank für deine Überlegungen und Hinweise.

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Maier schrieb:
>> Ideal wäre ein großer Speicher, von dem alle Cores "leben".
>
> Mittlerweile sind wir dank Pipelining usw. an einem Punkt angekommen, an
> dem der Durchsatz eines Prozessorkerns überwiegend durch die
> Speicherbandbreite und nicht mehr nur durch dessen Takt bestimmt wird.
> Dual-Ported-RAMs kann man noch mit vertretbarem Aufwand herstellen, aber
> bei einer größeren Anzahl benötigter Ports explodiert der Aufwand. Bei
> den "großen" x64-Prozessoren besitzt daher jeder Kern eigene(n)
> L1-Cache(s), welches einen ganz erheblichen Anteil an der Chipfläche
> ausmachen. Für kostengünstige Microcontroller mit vielen Kernen ist dies
> unpraktikabel. Man könnte höchstens darüber nachdenken, jeweils zwei
> Kerne mit einem DPRAM zu versehen und die Kerne in noch zu bestimmender
> Topologie zu verbinden.

Gute Idee. Das soll in einem neuen Modus so konfigurierbar sein. 1+

: Bearbeitet durch User
von Maier (Gast)


Lesenswert?

Thomas K. schrieb:
> Beim aktuellen Propeller sieht das so aus. Beim Programmieren musst du
> auf die verschiedenen Speicher keine Rücksicht nehmen. Darum kümmert
> sich die Toolchain. Die überwacht, das deine Codeschnipsel später auch
> in den Speicher eines Cores passen.
> Du startest in deinem Code einen neuen Core und übergibst dem eine
> Speicheradresse, die auf den Code für deinen Task zeigt.
Vor vielleicht 10 Jahren hab ich mich in den Propeller etwas eingelesen, 
hab ihn dann aber nicht eingesetzt. Meines Wissens nach gabs die
Alternative 1: Assembler:
 Der Code muss in den 2K-Ram passen, nachladen ist nicht vorgesehen, 
zumindest nicht automatisch.
Alternative 2: Spin:
 Das ist eine interpretierte Sprache, die lädt nach was gebraucht wird. 
Dadurch entsteht aber ein Timingproblem, da das Programm durch Nachladen 
unterbrochen werden kann, außerdem ist der Interpreter sowieso recht 
langsam.

So hab ich das zumindest noch im Kopf, wie gesagt, ist 10 Jahre her. 
Aber offensichtlich war C als Standardsprache nicht geeignet.

Wenn man bei einem neuen Konzept größere Einzel-RAMs hat, sieht es 
vermutlich anders aus, dann kompiliert man einfach für jeden Kern seinen 
eigenen Code, aus C oder was auch immer. Nur sind 16k auch nicht arg 
viel. Zumindest einer der Kerne sollte m.E. schon besser ausgestattet 
sein, die Aufgaben lassen sich ja nicht immer schön gleichmäßig 
verteilen.


> So ähnlich funktioniert es ja beim Propeller, nur das der Code aus dem
> großen Speicher in den kleinen Speicher des Cores geladen wird, bevor
> der Core mit der Abarbeitung des Codes beginnt.
> Damit umgeht man das Problem mit dem Speicherzugriff, wenn mehrere Cores
> nur einen Speicher verwenden würden. Die Cores müssten dafür
> ausgebremst werden, damit jeder Core nacheinander auf den Speicher
> zugreifen kann. Damit wäre die Performance des Multicore Systems dahin.
Das Umladen ist halt fast ein Nogo, wenn es zur Laufzeit zum Nachladen 
kommt weil der Speicher nicht reicht. Konsequenz wäre einfach die 
Core-Speicher zu vergrößern, aber man kann auch nicht einfach jedem Core 
einen großen Speicher spendieren, aus Platz- und Kostengründen.
Das ist ein Zielkonflikt.

Vielleicht kann man die Speicherbandbreite durch höhergetakteten 
Speicher erhöhen, die Prozessoren müssen vielleicht gar nicht so schnell 
laufen. Vielleicht hilft es auch Daten und Code in getrennten Speichern 
zu halten, um schnellen Datenzugriff zu ermöglichen.


Andreas S. schrieb:
> den "großen" x64-Prozessoren besitzt daher jeder Kern eigene(n)
> L1-Cache(s), welches einen ganz erheblichen Anteil an der Chipfläche
> ausmachen. Für kostengünstige Microcontroller mit vielen Kernen ist dies
> unpraktikabel.
Das spricht eben gleichzeitig auch gegen getrennten RAM, weil jeder Kern 
dann seine Mindestgröße braucht.

> Man könnte höchstens darüber nachdenken, jeweils zwei
> Kerne mit einem DPRAM zu versehen und die Kerne in noch zu bestimmender
> Topologie zu verbinden.
Wenn man den RAM dann noch mit doppelter Rate taktet, kann man 
vielleicht schon 4 Kerne bedienen.

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Thomas K. schrieb:
>> Beim aktuellen Propeller sieht das so aus. Beim Programmieren musst du
>> auf die verschiedenen Speicher keine Rücksicht nehmen. Darum kümmert
>> sich die Toolchain. Die überwacht, das deine Codeschnipsel später auch
>> in den Speicher eines Cores passen.
>> Du startest in deinem Code einen neuen Core und übergibst dem eine
>> Speicheradresse, die auf den Code für deinen Task zeigt.
> Vor vielleicht 10 Jahren hab ich mich in den Propeller etwas eingelesen,
> hab ihn dann aber nicht eingesetzt. Meines Wissens nach gabs die
> Alternative 1: Assembler:
>  Der Code muss in den 2K-Ram passen, nachladen ist nicht vorgesehen,
> zumindest nicht automatisch.
> Alternative 2: Spin:
>  Das ist eine interpretierte Sprache, die lädt nach was gebraucht wird.
> Dadurch entsteht aber ein Timingproblem, da das Programm durch Nachladen
> unterbrochen werden kann, außerdem ist der Interpreter sowieso recht
> langsam.
>
> So hab ich das zumindest noch im Kopf, wie gesagt, ist 10 Jahre her.

Für Assembler korrekt.

Bei Spin läuft ein Interpreter in einem Core, der ist also *nur 2 KiB 
groß*, aber trotzdem erstaunlich leistungsfähig. Im Main RAM liegt der 
Bytecode für Spin, der durch den Interpreter abgearbeitet wird.
Nachgeladen wird nur ein neuer Spin Interpreter in einem weiteren Core, 
wenn man einem neuen Task startet.
Letztendlich können bis zu 8 Spin Interpreter laufen, um verschiedene 
oder auch gleiche Codeteile aus dem Main RAM abzuarbeiten.
Da die Speicherzugriffe auf den Main RAM im round-robin Verfahren an 
Cores vergeben werden, ist die Verarbeitungsgeschwindigkeit, abgesehen 
davon, das es ein Interpreter ist, begrenzt.

Die maximale Reaktionszeit für IOs ist natürlich deutlich geringer, als 
wenn Assembler verwendet wird. Aber solange der Task nicht ständig 
beendet und wieder neu gestartet wird, gibt es auch keine 
Timingprobleme, die durch das Starten eine Cores bedingt sind.

> Aber offensichtlich war C als Standardsprache nicht geeignet.

Am Anfang gab es nur Spin und Assembler. Eine Entwicklungsumgebung für C 
wurde 2008 oder 2009 durch eine Drittfirma angeboten. Mittlerweile ist 
diese IDE von Parallax durch eine von der Community erstellte IDE 
ersetzt worden.
Ein Vorteil bei Parallax ist, das die Entwicklertools für 4 
Betriebssysteme zur Verfügung stehen. So kann sich eigentlich jeder in 
den Propeller einarbeiten und Software entwickeln.
https://www.parallax.com/downloads/propeller-p8x32a-software

> Wenn man bei einem neuen Konzept größere Einzel-RAMs hat, sieht es
> vermutlich anders aus, dann kompiliert man einfach für jeden Kern seinen
> eigenen Code, aus C oder was auch immer. Nur sind 16k auch nicht arg
> viel. Zumindest einer der Kerne sollte m.E. schon besser ausgestattet
> sein, die Aufgaben lassen sich ja nicht immer schön gleichmäßig
> verteilen.

Genau, die 16KiB, die ich als Mindest RAM Größe genannt hatte, helfen 
dabei schon etwas, mehr Code per Core zu verwenden.
Wenn dieser Speicherplatz auch nicht ausreichend sein sollte, soll es 
die Möglichkeit geben, den Speicher der Cores anders aufzuteilen.
Z.B. können die Speicher von 2 Cores zusammen gemappt werden, so dass 
beide Cores mit doppelt soviel Speicher arbeiten können. Es kann 
natürlich auch nur ein Core den doppelten Speicher nutzen und der andere 
Core wird gar nicht verwendet.
Da die Cores dual-ported RAM haben werden, können also beide Cores ohne 
Verzögerung gleichzeitig auf den RAM zugreifen.

Diese Idee hatte vorhin Andreas S. auch gepostet. Siehe unten im 
Kommentar.

>> So ähnlich funktioniert es ja beim Propeller, nur das der Code aus dem
>> großen Speicher in den kleinen Speicher des Cores geladen wird, bevor
>> der Core mit der Abarbeitung des Codes beginnt.
>> Damit umgeht man das Problem mit dem Speicherzugriff, wenn mehrere Cores
>> nur einen Speicher verwenden würden. Die Cores müssten dafür
>> ausgebremst werden, damit jeder Core nacheinander auf den Speicher
>> zugreifen kann. Damit wäre die Performance des Multicore Systems dahin.
> Das Umladen ist halt fast ein Nogo, wenn es zur Laufzeit zum Nachladen
> kommt weil der Speicher nicht reicht. Konsequenz wäre einfach die
> Core-Speicher zu vergrößern, aber man kann auch nicht einfach jedem Core
> einen großen Speicher spendieren, aus Platz- und Kostengründen.
> Das ist ein Zielkonflikt.

Genau. Deshalb soll es verschiedene Modi (bisher 3 geplant) geben, mit 
denen der Entwickler selbst entscheiden kann, welches Speichermodell für 
seine Anwendung am geeignetsten ist.

> Vielleicht kann man die Speicherbandbreite durch höhergetakteten
> Speicher erhöhen, die Prozessoren müssen vielleicht gar nicht so schnell
> laufen. Vielleicht hilft es auch Daten und Code in getrennten Speichern
> zu halten, um schnellen Datenzugriff zu ermöglichen.

Das sind natürlich auch mögliche Alternativen, die man evaluieren kann.

> Andreas S. schrieb:
>> den "großen" x64-Prozessoren besitzt daher jeder Kern eigene(n)
>> L1-Cache(s), welches einen ganz erheblichen Anteil an der Chipfläche
>> ausmachen. Für kostengünstige Microcontroller mit vielen Kernen ist dies
>> unpraktikabel.
> Das spricht eben gleichzeitig auch gegen getrennten RAM, weil jeder Kern
> dann seine Mindestgröße braucht.
>
>> Man könnte höchstens darüber nachdenken, jeweils zwei
>> Kerne mit einem DPRAM zu versehen und die Kerne in noch zu bestimmender
>> Topologie zu verbinden.
> Wenn man den RAM dann noch mit doppelter Rate taktet, kann man
> vielleicht schon 4 Kerne bedienen.

Man sollte es nicht mit dem RAM Takt übertreiben, nur um noch mehr Kerne 
auf ein gemeinsames RAM zugreifen zu lassen. Schließlich sollten die 
Cores auch mit einer Pipeline arbeiten, um die RAM Bandbreite optimal 
aus zu nutzen.

: Bearbeitet durch User
von mmacs (Gast)


Lesenswert?

Maier schrieb:
> Ich kann mir schon vorstellen, dass das den Entwurf selbst
> verkompliziert, oder mit konkurenzfähiger Taktung gar nicht möglich ist,
> alle Cores aus einem Speicher zu versorgen. Aber sollte man das nicht
> zumindest andenken/untersuchen?

Wenn man die Cores nicht mit Wartezyklen ausbremsen will, ist mit 
Dualport-RAM eben spaetestens bei zwei Cores Schluss.
Ich kann zu dem Zweck empfehlen, sich den Blackfin BF561 mal anzusehen. 
Da werden die Programmteile per Linker-Script in die Core-spezifischen 
L1-SRAMs geladen, Core A startet dann Core B. Zudem haben die beiden 
Cores ein L2 shared RAM.

Das Konzept der software-implementierten Peripherie des Parallax wie 
auch die angehaltenen ARM-Amulet ist eigentlich mit einem sauberen DMA 
meiner Meinung nach hinfaellig.

Zu dem Thema: Schon vor über 10J konnte man mit dem BF537 und dem 
eingebauten EMAC per DMA gut am 100M-Limit ueber Ethernet Daten 
streamen. Das geht auch bei einigen Implementierungen auf dem FPGA, wie 
z.b. hier dokumentiert:
https://section5.ch/index.php/2017/05/10/dma-autobuffering-techniques/

Fuer die interne Kommunikation der Cores ist bei deren System soweit ich 
sehe auch der DMA zustaendig.

von Thomas K. (thok)


Angehängte Dateien:

Lesenswert?

mmacs schrieb:
> Maier schrieb:
>> Ich kann mir schon vorstellen, dass das den Entwurf selbst
>> verkompliziert, oder mit konkurenzfähiger Taktung gar nicht möglich ist,
>> alle Cores aus einem Speicher zu versorgen. Aber sollte man das nicht
>> zumindest andenken/untersuchen?
>
> Wenn man die Cores nicht mit Wartezyklen ausbremsen will, ist mit
> Dualport-RAM eben spaetestens bei zwei Cores Schluss.
> Ich kann zu dem Zweck empfehlen, sich den Blackfin BF561 mal anzusehen.
> Da werden die Programmteile per Linker-Script in die Core-spezifischen
> L1-SRAMs geladen, Core A startet dann Core B. Zudem haben die beiden
> Cores ein L2 shared RAM.

Danke für den Tipp, werde ich mir mal anschauen, da ich den nicht kenne.

> Fuer die interne Kommunikation der Cores ist bei deren System soweit ich
> sehe auch der DMA zustaendig.

Das war auch meine Idee.
Da ich nun schon alle meine angedachten Modifikationen in diversen 
Kommentaren heute angesprochen habe, gibts jetzt mal ein Dokument zum 
lesen.

Ich bin für Anregungen und Kommentare von euch offen.

von Saalfelder (Gast)


Lesenswert?

Thomas K. schrieb:
> Ein wichtiger Unterschied ist, das die verfügbaren Befehle durch die
> RISC-V Spezifikation standardisiert wurde, egal ob der Core 32, 64 oder
> 128 bit hat.
Ist bei MIPS auch spezifiziert.
(Bei so vielen Kernen wird dir der Platz ausgehen, dass du dich mit 
32bit begnügen solltest)

> Der entscheidendste Unterschied ist jedoch, das du die RISC-V ISA ohne
> Lizenzkosten in deinen eigenen Cores verwenden kannst. Du musst also
> nicht deine eigene Toolchain bauen.
> Aber das hast du sicherlich auch schon selbst gewusst. ;-)

So viel ich weiss ging es immer um Patente. Nun ist die MIPS I so alt, 
dass die Patente abgelaufen sind.

Ohne Peripherie ist den Rechner wertlos. Deshalb musst du mal sagen was 
dein Standard nach außen sein wird. Wishbone, AMBA, AXI, Avalon.
Oder auch was neues?

Was auch immer das Problem ist, ist die Stackverwaltung. Wie willst du 
die organisieren?

von Thomas K. (thok)


Lesenswert?

Saalfelder schrieb:
> Thomas K. schrieb:
>> Ein wichtiger Unterschied ist, das die verfügbaren Befehle durch die
>> RISC-V Spezifikation standardisiert wurde, egal ob der Core 32, 64 oder
>> 128 bit hat.
> Ist bei MIPS auch spezifiziert.
> (Bei so vielen Kernen wird dir der Platz ausgehen, dass du dich mit
> 32bit begnügen solltest)

Es sollen auch nur 32bit Cores verwendet werden. ;-)

> Ohne Peripherie ist den Rechner wertlos. Deshalb musst du mal sagen was
> dein Standard nach außen sein wird. Wishbone, AMBA, AXI, Avalon.
> Oder auch was neues?

Du willst es aber auch genau wissen. Da habe ich mich, ehrlich gesagt, 
noch nicht festgelegt, da dieses Thema weiter unten auf der ToDo Liste 
steht.
Ich bin also für Vorschläge von euch offen.

> Was auch immer das Problem ist, ist die Stackverwaltung. Wie willst du
> die organisieren?

Der Stack wird normalerweise immer von der höchsten Speicheradresse 
abwärts angelegt. Da der Code jeweils in einem separaten Core läuft, 
gibt es also in jedem Corespeicher einen eigenen Stack.
Für die Modi, wo sich mehr als zwei Cores den gleichen RAM teilen und 
man auch alle diese Cores verwenden will, könnte man jeweils eine 
maximale Stackgröße im Code spezifizieren, damit die Stacks sich gleich 
an den Variablenbereich anschließen. Die dadurch entstehenden freien 
Speicherbereiche können dann von dem Core verwendet werden, der den 
gesamten Speicherbereich sieht.
Die Toolchain kann die Verwendung dieser Speicherbereiche dann 
überwachen und den Code automatisch verteilen.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

mmacs schrieb:
> Das Konzept der software-implementierten Peripherie des Parallax wie
> auch die angehaltenen ARM-Amulet ist eigentlich mit einem sauberen DMA
> meiner Meinung nach hinfaellig.

Der Trend geht doch in vielen Bereichen in die Richtung Software Defined 
XYZ. Sicherlich gibt es etliche Schnittstellen, deren Entwicklung man 
als abgeschlossen betrachten kann, aber interessant wird das sowohl bei 
schnellen drahtgebundenen Multimediaschnittstellen als auch bei 
Funkschnittellen. Bei letzteren dürften auch langfristig relevant sein:

- WLAN (in zig Protokollvarianten)
- Bluetooth (in einigen Protokollvarianten)
- LTE (während des Produktlebenszyklus vermulich in sehr,
  sehr vielen Varianten)
- WPAN (IEEE 802.15.4, Zigbee und sehr viele proprietäre Funksysteme)
- LoRa
- etliche proprietäre im 434 MHz- und 868 MHz-Bereich
- vielleicht DECT

Wer eine universelle Microcontrollerfamilie neu herausbringt, ohne 
einige dieser Schnittstellen extrem energiesparend zu unterstützen, muss 
dafür sehr gute Gründe haben.

Thomas K. schrieb:
> Das ist alles richtig was du sagst, aber trifft eher zu, wenn man schon
> was vorweisen kann. Ich glaube, das muss man beim Start eines Freizeit
> Projektes noch nicht in der Planung haben.

Freizeitprojekt und ASIC passt nicht zusammen. Es mag sicherlich 
Privatleute geben, die bereit sind, einige zig Kiloeuro oder so 
auszugeben, um ihren eigenen Chip in der Hand zu halten. Für das Geld 
findet man durchaus Unternehmen, die einem ein sehr kleines ASIC 
herstellen, bei dem nur eine kundenspezifische Metallisierunglage 
erzeugt wird. Für einen mittelschweren Microcontroller muss man aber 
durchaus ein, zwei Euro mehr in die Hand nehmen.

Um jedoch ein Projekt mit mehrerer Teilnehmern hochzuziehen, die viel 
Arbeitsleistung einbringen sollen, kann man sich nicht hinstellen und 
sagen: "Ach, wenn wir halbwegs fertig sind, schlachtet jeder sein 
Sparschwein, und dann schauen wir mal, ob das Geld für ein ASIC reicht."

von Andreas R. (daybyter)


Lesenswert?

Meinst, die Controller Idee hat im Trading Bereich mehr Chancen? Dort 
setzt man ja aus anderen Gründen oft auf FPGA.

von S. R. (svenska)


Lesenswert?

Andreas S. schrieb:
> Der Trend geht doch in vielen Bereichen in die
> Richtung Software Defined XYZ.

Wobei die aufwändige Verarbeitung (Modulation, Codierung) trotzdem in 
dedizierter Hardware durchgeführt werden. Software ist dabei nur die 
flexible Ansteuerung dieser Blöcke. Zumindest, wenn man Energieeffizienz 
für halbwegs potente Protokolle haben will, führt da kein Weg dran 
vorbei.

Andreas S. schrieb:
> Um jedoch ein Projekt mit mehrerer Teilnehmern hochzuziehen, die viel
> Arbeitsleistung einbringen sollen, kann man sich nicht hinstellen und
> sagen: "Ach, wenn wir halbwegs fertig sind, schlachtet jeder sein
> Sparschwein, und dann schauen wir mal, ob das Geld für ein ASIC reicht."

Ich fand das Projekt ganz am Anfang durchaus interessant, erfülle 
allerdings die Vorgaben nicht (VHDL statt Verilog, ISE statt Vivado, 
etc.). Im Laufe der Diskussion verdichtete sich das Thema auf "ich will 
einen Parallax mit RISC-V nachbauen", was mich überhaupt nicht mehr 
interessiert. Irgendwie fehlt mir da eine Vision, wo man so ein Dingens 
sinnvoll einsetzen wollen würde.

Für ein Lern-, Bastel- oder Hobbyprojekt sucht man keine Mitstreiter mit 
möglichst viel Erfahrung. Für ein ASIC-Projekt muss man für gute 
Ergebnisse anders designen als für einen FPGA. Und wenn man tatsächlich 
kommerziell werden will, dann sollte man das nicht als Hobby 
deklarieren. :-)

von Computer-Ex-Perte (Gast)


Lesenswert?

Andreas S. schrieb:
> Ach, wenn wir halbwegs fertig sind, schlachtet jeder sein
> Sparschwein, und dann schauen wir mal, ob das Geld für ein ASIC reicht."

Vollkommen utopisch. Das kriegen ja viele Universitäten nicht hin, Geld 
für ASICs locker zu machen. Die ASICs werden dort in den Design Centern 
entwickelt und layoutet, simuliert und verifiziert, aber nie gebaut. 
Kein Mensch baut sowas, weil da Vieles nicht passt und minderwertig ist. 
Zu einem Chip zu kommen, erfordert, das design in Verilog zu übergeben, 
ein Projekt mit dem Hersteller aufzusetzen und es dann von denen umbauen 
zu lassen, dass es fertigbar wird.

Sowas kostet mindestens 20,000 Euro, dass dort mal 2 Leute 2 Wochen 
übers Design schauen und einen Kostenvoranschlag machen. Der eigene ASIC 
kommt dann auch so einen Kombi-ASIC mit anderen Kunden, was die 
Abnahmemenge auf Stückzahlen bringt, um unter die 50,- Euro Grenze zu 
kommen.

Für einen uC dieser Art müsste man wenigsten für 60k validieren und 120k 
produzieren. Dann müsste man 100.000 Stück abnehmen um auf unter 3,- 
Euro zu kommen. Mit allen Kosten wären das dann etwa 4,-. Das wären 
unsere Kosten für ein solches Projekt. Alternative Zahlen waren 12,- für 
40.000, 45,- für 10.000.

Viel Spass!

von Thomas K. (thok)


Lesenswert?

Computer-Ex-Perte schrieb:
> Andreas S. schrieb:
>> Ach, wenn wir halbwegs fertig sind, schlachtet jeder sein
>> Sparschwein, und dann schauen wir mal, ob das Geld für ein ASIC reicht."
>
> Vollkommen utopisch. Das kriegen ja viele Universitäten nicht hin, Geld
> für ASICs locker zu machen. Die ASICs werden dort in den Design Centern
> entwickelt und layoutet, simuliert und verifiziert, aber nie gebaut.
> Kein Mensch baut sowas, weil da Vieles nicht passt und minderwertig ist.
> Zu einem Chip zu kommen, erfordert, das design in Verilog zu übergeben,
> ein Projekt mit dem Hersteller aufzusetzen und es dann von denen umbauen
> zu lassen, dass es fertigbar wird.

Anstatt einen konstruktiven Beitrag zum Projekt zu liefern, trollst du 
schon in deinem ersten Kommentar. Warum hast du nicht die 
Universitätsprojekte verlinkt, die schon ein RISC-V ASIC hergestellt 
haben?

Das nicht jede Universität die Finanzmittel für einen eigenen Chip hat, 
ist völlig normal. Schließlich kann sich auch nicht jeder einen Porsche 
leisten, aber viele möchten so einen fahren.

Dein Username reflektiert perfekt deine Denkweise.

von Gustl B. (-gb-)


Lesenswert?

Ich lese hier nur interessiert mit, kann leider auch nur etwas VHDL.
Ich verstehe nur nicht was das werden soll, vorallem wie es hier 
angegangen wird. Wieso nur Verilog? Ich vermute die Mehrheit hier kann 
besser VHDL. Ich verstehe das nicht. Man nimmt üblicherweise die 
Werkzeuge mit denen die Entwickler am besten umgehen können.

Computer-Ex-Perte hat die Machbarkeit angezweifelt. Und zwar völlig zu 
Recht. Ja, manche Unis können sich das leisten, aber manche auch nicht. 
Was bedeutet das? Die Frage ist eigentlich:
Wieso glaubt Thomas K. das das Projekt erfolgreich einen ASIC 
hervorbringen wird, wenn sogar einige Unis das nicht bezahlen können. Er 
hat das mit einem Porsche verglichen, wieso glaubt er dass sich dieses 
Projekt den Porsche leisten können wird?

Aus meiner Sicht sind das Fragen die auf jeden Fall geklärt werden 
sollten weil sonst nur Lebenszeit verbrannt wird. Klar, es kann auch 
ohne Produkt am Ende lehrreich sein, es ist sogar sehr lehrreich etwas 
nicht zu schaffen von dem man glaubte es zu können. Das ist aber auch 
frustrierend.

von Astronaut (Gast)


Lesenswert?

Bei den Kosten hat er der Ex-Perte nicht ganz unrecht.
Wenn das Ziel ein ASIC ist, sollte man durchaus sehr früh überlegen ob 
man das irgendwie finanzieren kann und was eigentlich mögliche 
Zielanwendungen wären, die nicht schon mit bestehenden Lösungen ähnlich 
gut umgesetzt werden können.

Es dürfte für Open Source Hardware eher schwer werden Investoren zu 
finden.
Das SiFive Finanzmittel auftreiben konnte liegt natürlich auch daran, 
dass das die Leute sind die die Architektur überhaupt entwickelt haben 
und weiterentwickeln und großes Interesse von diversen Chipherstellern 
an den Cores besteht um eine kostengünstigere Alternative zu ARM zu 
haben.

von Lars R. (lrs)


Lesenswert?

Es gibt noch keinen RV64, der optimiert wurde für:
. FPGA
. minimale Ressourcen
. das große Linux

Bisherige RV64-Kerne können zwar auf dem FPGA laufen, sind aber für ASIC 
designed und nicht für FPGA.

Dazu das SoC (möglichst wenig, dh SPI, UART, ULIP) samt Kernel-Treiber.

Und selbstverständlich Hersteller-unabhängig. Hersteller-abhängig kann 
man auch gleich einen Xilinx/Intel-FPGA (oder mehrere) mit ARM (single, 
dual) und Hersteller device tree nehmen.


Neue Highspeed Interface IPs sind bereits für sich komplex genug.

: Bearbeitet durch User
von Thomas K. (thok)


Lesenswert?

Gustl B. schrieb:
> Ich lese hier nur interessiert mit, kann leider auch nur etwas VHDL.
> Ich verstehe nur nicht was das werden soll, vorallem wie es hier
> angegangen wird. Wieso nur Verilog? Ich vermute die Mehrheit hier kann
> besser VHDL. Ich verstehe das nicht. Man nimmt üblicherweise die
> Werkzeuge mit denen die Entwickler am besten umgehen können.

Die Gründe für Verilog wurden schon weiter oben erläutert.
Beitrag "Re: Mitstreiter für RISC-V Mikrocontrollers gesucht"

von Gustl B. (-gb-)


Lesenswert?

Also die meisten Herstellertools können Verilog und VHDL mischen. Dann 
nimmt man eben Verilog dort wo es schon was Fertiges gibt oder wo nur 
leicht modifiziert werden muss und wenn etwas neu gebaut wird schreibt 
man es in VHDL.

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Freizeitprojekt und ASIC passt nicht zusammen. Es mag sicherlich
> Privatleute geben, die bereit sind, einige zig Kiloeuro oder so
> auszugeben, um ihren eigenen Chip in der Hand zu halten. Für das Geld
> findet man durchaus Unternehmen, die einem ein sehr kleines ASIC
> herstellen, bei dem nur eine kundenspezifische Metallisierunglage
> erzeugt wird. Für einen mittelschweren Microcontroller muss man aber
> durchaus ein, zwei Euro mehr in die Hand nehmen.
>
> Um jedoch ein Projekt mit mehrerer Teilnehmern hochzuziehen, die viel
> Arbeitsleistung einbringen sollen, kann man sich nicht hinstellen und
> sagen: "Ach, wenn wir halbwegs fertig sind, schlachtet jeder sein
> Sparschwein, und dann schauen wir mal, ob das Geld für ein ASIC reicht."

Ich habe von Anfang an mit offen Karten gespielt. Das ist, denke ich, 
ehrlicher, als wenn ich das erst während der Entwicklung erwähnt hätte.

Das ein Freizeitprojekt und ASIC zusammen passt, ist anscheinend für die 
meisten hier nicht vorstellbar. Ich habe aber auch nicht verlangt, das 
jemand sein Sparschwein schlachten muss, um an dem Projekt mit zu 
machen.

von Thomas K. (thok)


Lesenswert?

Gustl B. schrieb:
> Also die meisten Herstellertools können Verilog und VHDL mischen. Dann
> nimmt man eben Verilog dort wo es schon was Fertiges gibt oder wo nur
> leicht modifiziert werden muss und wenn etwas neu gebaut wird schreibt
> man es in VHDL.

Lies dir bitte erst den Thread genau durch. Es gibt noch weiteren 
bestehenden Verilog Code, der als Mikrocontoller Basis verwendet werden 
sollte.

von S. R. (svenska)


Lesenswert?

Thomas K. schrieb:
> Ich habe von Anfang an mit offen Karten gespielt. Das ist, denke ich,
> ehrlicher, als wenn ich das erst während der Entwicklung erwähnt hätte.

Alles andere wäre auch eine absolute Sauerei gewesen. Erst kostenlose 
Entwicklungs- und Lebenszeit abstauben und dann mit "schönen Dank auch, 
ab hier mach ich dann selbst weiter" abhauen. Nee, die offenen Karten 
sind schon in Ordnung.

Ich - und offensichtlich auch die meisten anderen hier - kann aber mit 
dem gezeigten Blatt nichts anfangen.

Thomas K. schrieb:
> Das ein Freizeitprojekt und ASIC zusammen passt, ist anscheinend für die
> meisten hier nicht vorstellbar.

Dann erklär mal. Wie stellst du dir das denn vor?

Mir sind keine ASIC-Projekte bekannt, bei denen nicht die eine oder 
andere Firma ihre Finger sehr tief im Projekt drin hatte. Ich gehe mal 
aus, dass das bei dir vorerst nicht der Fall ist.

Also, wie soll der ASIC finanziert werden und wo soll er eingesetzt 
werden? Oder willst du, wenn die Entwicklung einigermaßen durch ist, 
daraus ein Produkt und eine Firma machen?

von Thomas K. (thok)


Lesenswert?

S. R. schrieb:
> Thomas K. schrieb:
>> Ich habe von Anfang an mit offen Karten gespielt. Das ist, denke ich,
>> ehrlicher, als wenn ich das erst während der Entwicklung erwähnt hätte.
>
> Alles andere wäre auch eine absolute Sauerei gewesen. Erst kostenlose
> Entwicklungs- und Lebenszeit abstauben und dann mit "schönen Dank auch,
> ab hier mach ich dann selbst weiter" abhauen. Nee, die offenen Karten
> sind schon in Ordnung.
>
> Ich - und offensichtlich auch die meisten anderen hier - kann aber mit
> dem gezeigten Blatt nichts anfangen.

Das du damit nichts anfangen kannst, hattest du schon in deinem ersten 
Post deutlich zum Ausdruck gebracht. ;-)

S. R. schrieb:
> Im Laufe der Diskussion verdichtete sich das Thema auf "ich will
> einen Parallax mit RISC-V nachbauen", was mich überhaupt nicht mehr
> interessiert. Irgendwie fehlt mir da eine Vision, wo man so ein Dingens
> sinnvoll einsetzen wollen würde.

Es sieht so aus, als wenn die Kombination, Propeller mit RISC-V, nicht 
auf ausreichend Resonanz bei den Mitgliedern des Forums gestoßen ist, da 
bisher kein Feedback auf mein veröffentlichtes Dokument gekommen ist.
Deshalb werde ich mich anderweitig nach Interessenten und Unterstützern 
für mein Projekt auf die Suche begeben.

von Andreas R. (daybyter)


Lesenswert?

Vielleicht wäre es geschickter, es anders herum anzugehen? Also erstmal 
einen Anwendungsfall zu definieren und dann zu schauen, welche Art CPU 
diese Anwendung benötigt?

Ich denke, ein fertiges Asic wird doch auf jeden Fall begleitende 
Module/Erweiterungen benötigen (Netzwerk, WLan, SPI, was auch immer).

Wenn man hier ein attraktives Paket anbieten könnte, würde sicher die 
ein oder andere Firma drauf hüpfen und das Design in Hardware giessen?

von Thomas K. (thok)


Lesenswert?

Lars R. schrieb:
> Es gibt noch keinen RV64, der optimiert wurde für:
> . FPGA
> . minimale Ressourcen
> . das große Linux
>
> Bisherige RV64-Kerne können zwar auf dem FPGA laufen, sind aber für ASIC
> designed und nicht für FPGA.
>
> Dazu das SoC (möglichst wenig, dh SPI, UART, ULIP) samt Kernel-Treiber.
>
> Und selbstverständlich Hersteller-unabhängig. Hersteller-abhängig kann
> man auch gleich einen Xilinx/Intel-FPGA (oder mehrere) mit ARM (single,
> dual) und Hersteller device tree nehmen.
>
>
> Neue Highspeed Interface IPs sind bereits für sich komplex genug.

RISC-V Cores sollen jetzt auch in Europa Einzug halten, zumindest im 
HPC-Bereich. Geld ist reichlich vorhanden. Fehlen nur noch die Leute, 
die die entsprechenden Chips erstellen.
Experten dafür, wirst du hier einige finden, um ein Projekt auf die 
Beine zu stellen.
https://www.top500.org/news/europeans-budget-14-billion-euros-to-build-next-generation-supercomputers/

: Bearbeitet durch User
von Lars R. (lrs)


Lesenswert?

Thomas K. schrieb:
> Lars R. schrieb:
>> Bisherige RV64-Kerne können zwar auf dem FPGA laufen, sind aber für ASIC
>> designed und nicht für FPGA.
>
> RISC-V Cores sollen jetzt auch in Europa Einzug halten, zumindest im
> HPC-Bereich. Geld ist reichlich vorhanden. Fehlen nur noch die Leute,
> die die entsprechenden Chips erstellen. [...]
> 
https://www.top500.org/news/europeans-budget-14-billion-euros-to-build-next-generation-supercomputers/

Eben. Das von Dir Gepostete ist nicht für den FPGA. Firmen werden das 
schon einmal nicht machen mangels Business-Modell.

Als ASIC ist RV64 erst einmal ein Vorteil für Chip-Hersteller 
(kostenlose ISA und gcc usw) und nicht für den Endnutzer (absolut 
sichere CPU mit Desktop-Linux für jedermann).

Mein Post war nur ein Vorschlag zur Ideenfindung bzgl. etwas, dass 
tatsächlich nützlich ist. Erst später habe gesehen habe, dass Du das 
weiter oben bereits ausgeschlossen hattest...

von (prx) A. K. (prx)


Lesenswert?

Lars R. schrieb:
> absolut sichere CPU

Du bist genügsam genug, auch nur eine CPU ohne bereits bekanntes 
Potential für Sicherheitsprobleme auf Desktop-PCs tatsächlich verwenden 
zu wollen? Ein RISC V Core mit adäquater Performance wird dahingehend 
auch Probleme haben.

: Bearbeitet durch User
von Lars R. (lrs)


Lesenswert?

A. K. schrieb:
> Lars R. schrieb:
>> absolut sichere CPU
>
> Du bist genügsam genug, auch nur eine CPU ohne bereits bekanntes
> Potential für Sicherheitsprobleme auf Desktop-PCs tatsächlich verwenden
> zu wollen?

Ja. Sicherheitsprobleme werden nicht in der ISA liegen, sondern in der 
Implementierung. Und die CPU-Implementierung kann man dann so einfach 
patchen wie  den Kernel; vielleicht sogar einfacher.

Trojaner im Silizium kann man ausschliessen.

Und ich würde mich dann wahrscheinlich auch mal einarbeiten zwecks 
Flexibilisierung und Anbindung von Komponenten. Macht man das heute, ist 
es a. häufig nicht genügend offen und b. nach ein paar Jahren alles 
wieder anders.

Ein paar 100MHz fände ich schon ganz gut. Dauert eben das Booten etwas 
länger. Vielleicht schafft man später 500MHz+. Viel schneller braucht es 
nicht. Dann eben mehr Kerne.

von Andreas R. (daybyter)


Lesenswert?

Also mit paar hundert MHz kannst Du z.B. das UI eines Smart TV oder 
eines Sat Receivers schon darstellen. Das wäre dann mal ein 
Anwendungsfall.

von (prx) A. K. (prx)


Lesenswert?

Lars R. schrieb:
> Und die CPU-Implementierung kann man dann so einfach
> patchen wie  den Kernel; vielleicht sogar einfacher.

Seit letztem Jahr, veröffentlicht Anfang diesen Jahres, darf per 
Gerneralverdacht jede Out-Of-Order Implementierung als 
verfahrensbedingt unsicher gelten. Sämtliche x86 Implementierungen, die 
man in aktuellen PCs und Tablets findet. In Smartphones alles oberhalb 
der Midrange-CPUs Cortex A53/A55. Ebenso IBMs Power- und 
Mainframe-Prozessoren, die SPARC-CPUs usw. OOO RISC-V Implementierungen 
wahrscheinlich ebenso. Weil der Teufel nicht im Detail steckt, sondern 
in den bisher üblichen OOO Verfahren selbst, Meltdown ausgenommen.

Bis jetzt bestehen m.W. keine inhärent sicheren Alternativen jenseits 
der In-Order Arbeitsweise. Die einen erheblichen Einbruch an 
Leistungsfähigkeit darstellt.

: Bearbeitet durch User
von TriHexagon (Gast)


Lesenswert?

A. K. schrieb:
> Bis jetzt bestehen m.W. keine inhärent sicheren Alternativen jenseits
> der In-Order Arbeitsweise. Die einen erheblichen Einbruch an
> Leistungsfähigkeit darstellt.

Ist schon länger her, aber liegt das Problem nicht an der Kombination 
aus OOO und spekulativer Ausführung? Man kann doch auch eine OOO ohne 
spekulativer Ausführung machen, beschränkt natürlich die Möglichkeiten 
von OOO enorm (und der Performanz), aber es müsste gehen, oder?

von (prx) A. K. (prx)


Lesenswert?

TriHexagon schrieb:
> Man kann doch auch eine OOO ohne
> spekulativer Ausführung machen, beschränkt natürlich die Möglichkeiten
> von OOO enorm (und der Performanz), aber es müsste gehen, oder?

Um OOO Cores die Spekulation vollständig auszutreiben, musst du alle 
Befehle serialisierend gestalten, die spekulieren. Das sind nicht nur 
Sprünge, sondern schliesst alle Befehle ein, die auf eine Exception 
laufen können. Also auch sämtliche Speicheroperation.

Ob sich dann der doch erhebliche Aufwand für OOO wirklich noch lohnt? 
Der frisst ja nicht nur Fläche, sondern auch deutlich Strom.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Computer-Ex-Perte hat die Machbarkeit angezweifelt. Und zwar völlig zu
> Recht.

Nicht Computer-Ex-Perte hat die Machbarkeit angezweifelt, sondern meine 
vorherige Aussage durch das Unterschlagen eines "nicht" sinnentstellend 
zitiert. Es ist mal wieder sehr schön, dass auch hier ein Plagiateur für 
seine großartigen Ideen gelobt wird.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

A. K. schrieb:
> Um OOO Cores die Spekulation vollständig auszutreiben, musst du /alle/
> Befehle serialisierend gestalten, die spekulieren. Das sind nicht nur
> Sprünge, sondern schliesst alle Befehle ein, die auf eine Exception
> laufen können. Also auch sämtliche Speicheroperation.

Selbst das wäre noch nicht einmal eine hinreichend starke Einschränkung, 
da noch hinreichend viele Seitenkanalangriffe auf dem unterschiedlichen 
Timing von Cache Hits und Cache Misses basieren, ohne dass dabei 
Exceptions ausgelöst werden.

> Ob sich dann der doch erhebliche Aufwand für OOO wirklich noch lohnt?
> Der frisst ja nicht nur Fläche, sondern auch deutlich Strom.

Das hängt vom Anwendungsfall ab. Bei Mobilgeräten gibt es ganz andere 
Anforderungen als im HPC-Bereich, auch wenn mittlerweile sehr viele 
Benchmarks und Rechenwettbewerbe auch Leistungsangaben in OPS/Watt 
machen. Vermeintliche Stromsparprozessoren, d.h. viele sehr kleine 
Microcontroller mit absoluten Leistungsaufnahmen von nur wenigen Mikro- 
oder Milliwatt, haben hierbei allerdings eine wesentlich schlechtere 
Effizienz als vermeintliche Energiefresser mit zig Watt 
Leistungsaufnahme.

von Gustl B. (-gb-)


Lesenswert?

Andreas S. schrieb:
> Gustl B. schrieb:
>> Computer-Ex-Perte hat die Machbarkeit angezweifelt. Und zwar völlig zu
>> Recht.
>
> Nicht Computer-Ex-Perte hat die Machbarkeit angezweifelt, sondern meine
> vorherige Aussage durch das Unterschlagen eines "nicht" sinnentstellend
> zitiert. Es ist mal wieder sehr schön, dass auch hier ein Plagiateur für
> seine großartigen Ideen gelobt wird.

Doch, er hat die Machbarkeit angezweifelt. Das hat du auch, sogar 
vorher, aber das ist hier egal. Mir ging es um den Teil mit den Unis den 
Thomas K. (thok) dann aufgegriffen hat und zwar völlig aus meiner Sicht 
völlig unverstanden. Aber gut, ich zitiere die Teile nochmal:

Computer-Ex-Perte schrieb:
> Das kriegen ja viele Universitäten nicht hin, Geld
> für ASICs locker zu machen.

Thomas K. schrieb:
> Das nicht jede Universität die Finanzmittel für einen eigenen Chip hat,
> ist völlig normal. Schließlich kann sich auch nicht jeder einen Porsche
> leisten, aber viele möchten so einen fahren.

Es gibt also Unis die sich das leisten können. Manche Leute können sich 
auch einen Porsche leisten. Er glaubt also irgendwie soviel Geld 
auftreiben zu können wie eben diese Unis oder zumindest mehr Geld wie 
die vielen Unis die das nicht hinkriegen.

von Lars R. (lrs)


Lesenswert?

zu OOO: Diesbezüglich habe ich Ideen. Aber darum ging es mir bei dem 
vorgeschlagenen Ansatz nicht. Ich möchte nicht ein spezielles Problem 
lösen, sondern alle.

Ginge es nur um die OOO-Sicherheitsrisiken, so bräuchte man gar nichts 
machen. Diesbezüglich werden in absehbarer Zeit bestmögliche Lösungen 
realisiert. Wenn man jetzt ein neues Projekt anfinge, so wäre man auch 
nicht schneller.

von Andi (Gast)


Lesenswert?

Natürlich gibt es Unis, die sich das leisten.
Die ETH Zürich arbeitet seit Jahren zusammen mit der Uni Bologna, am 
PULP Projekt, eben genau so einem RISC-V Multicore Chip. Dabei sind 
einige reale Chips entstanden, die aber nicht für die Allgemeinheit zur 
Verfügung stehen.

Die französische Firma Greenwaves hat mit Hilfe von PULP aber einen 
käuflichen Chip namens GAP8 entwickelt, der ja oben schon mehrmals 
erwähnt wurde.
Dieser hat 9 Risc-V Cores, relativ viel RAM und ist erstaunlich 
stromsparend, im Vergleich zur Leistung.

Greenwaves wurde vom französischen Staat unterstützt, und anscheinend 
glaubt der OP, dass man mit einer Freizeitgruppe, die einen Risc-V 
Multicore entwickelt auch an solche Forschungsgelder herankommt, was 
natürlich völlig illusorisch ist.

von Gustl B. (-gb-)


Lesenswert?

Andi schrieb:
> Natürlich gibt es Unis, die sich das leisten.

Hatte niemand angezweifelt.

Andi schrieb:
> [...] anscheinend
> glaubt der OP, dass man mit einer Freizeitgruppe, die einen Risc-V
> Multicore entwickelt auch an solche Forschungsgelder herankommt, was
> natürlich völlig illusorisch ist.

Exakt das meinte ich. Wenn er darlegen kann wie er das machen will 
finden sich vielleicht auch Leute die dann ihre Zeit in das Projekt 
einbringen. Zusätzlich wäre es natürlich nett zu wissen was der TO schon 
selber so alles gestemmt hat oder ob das jetzt das erste Projekt ist.

von Oliver Twist (Gast)


Lesenswert?

Andi schrieb:
> anscheinend
> glaubt der OP, dass man mit einer Freizeitgruppe, die einen Risc-V
> Multicore entwickelt auch an solche Forschungsgelder herankommt, was
> natürlich völlig illusorisch ist.

Ich glaube eher, der OP denkt, dass er so an kostenloses Knowhow für 
MultiCore-Architektur-Design kommt

von J. S. (engineer) Benutzerseite


Lesenswert?

Andi schrieb:
> Die ETH Zürich arbeitet seit Jahren zusammen mit der Uni Bologna, am
> PULP Projekt, eben genau so einem RISC-V Multicore Chip. Dabei sind
> einige reale Chips entstanden, die aber nicht für die Allgemeinheit zur
> Verfügung stehen.
Du weisst nicht zufällig, wo die eingesetzt werden?

von Vancouver (Gast)


Lesenswert?

Unter anderem in einem Medizintechnikprojekt. Das sind alles 
anwendungsspezifische SoCs, aber die Grundarchitektur ist open source 
ohne die "Spezialeinheiten".  Mit ein paar Anpassungen  läuft das ganze 
auch auf einem FPGA z.B. auf einem Artix7-Board von Digilent und einem 
Zynq. Es gibt ein halbwegs brauchbares SDK und einen gepatchten GCC, der 
die PULP-spezifischen Befehle unterstützt, z.B. Hardware-Loops. Die 
Jungs von der Unibo haben ein beachtliches Stück Arbeit geleistet. Von 
allen RV-Opensource-Implementierungen die ich kenne definitiv am 
ausgereiftesten.

von Andi (Gast)


Lesenswert?

Jürgen S. schrieb:
> Andi schrieb:
>> Die ETH Zürich arbeitet seit Jahren zusammen mit der Uni Bologna, am
>> PULP Projekt, eben genau so einem RISC-V Multicore Chip. Dabei sind
>> einige reale Chips entstanden, die aber nicht für die Allgemeinheit zur
>> Verfügung stehen.
> Du weisst nicht zufällig, wo die eingesetzt werden?

Die, die ich meine werden nirgends eingesetzt, sondern entstehen im 
Rahmen eines Studiums als praktische Arbeit. Laut dieser Seite werden 
jedes Jahr 10 bis 20 Chips designt: 
http://www.iis.ee.ethz.ch/research/chip-gallery.html

Hier ist ein Beispiel eines RISC-V PULP Processors:
http://asic.ethz.ch/2018/Scarabaeus.html
Mehr findest du wenn du die Chips der Gallerie nach "Application" 
listest und dann PULP suchst.

Ich weiss nicht was die Studenten mit diesen Chips machen, eigentlich 
wäre es doch sinnvoll das Design gleich so zu machen, dass die Masken 
später zur Herstellung kommerzieller Chips verwendet werden können.
Aber ich denke die Uni bekommt Spezialpreise bei der Maskenherstellung 
und da wird wohl die kommerzielle Verwendung verboten sein. Ist aber nur 
eine Vermutung.

von Pandur S. (jetztnicht)


Lesenswert?

Es ist zwar schon einige Zeit her, dass ich mit ASIC zu tun hatte. Es 
hat sich viel geaendert, und die Anforderungen haben's den Fortschritt 
gleich wieder aufgefressen. Jetzt sind's einfach ein paar Layers mehr, 
ein paar Masken mehr, die Strukturbreiten gehen runter, wie die Anzahl 
Transitoren rauf gehen.

Ein Maskensatz ist derart teuer, dass alles N-fach durchsimuliert wird 
bis man von der Fehlerfreiheit ueberzeugt ist. Es gibt trotzdem immer 
Fehler, daher bedeutet das auch mehrere Maskenrunden. Eine halbe bis 
ganze Million ist schnell weg. Moeglicherweise hat der Poster einen 
reichen Onkel, und zieht das aus der Portokasse.
Mit ein bisschen Hobby ist da nichts. Mit ein Wenig : einen Opensource 
Core anpassen - ist man nicht wirklich dabei. Nur schon die 
nebenlaeufige Projektplanung wird eine Vollzeitstelle sein.

Vergesst's.

von Meckerzeige (Gast)


Lesenswert?

Zitronen F. schrieb:
> Ein Maskensatz ist derart teuer, dass alles N-fach durchsimuliert wird
> bis man von der Fehlerfreiheit ueberzeugt ist. Es gibt trotzdem immer
> Fehler, daher bedeutet das auch mehrere Maskenrunden.

Wo passieren denn dann genau die Fehler, wenn schon alles erfolgreich 
durchsimuliert wurde? Wenn seitens des Kunden alles stimmt, ist das doch 
ein Umsetzungproblem.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Meckerzeige schrieb:
> Wo passieren denn dann genau die Fehler, wenn schon alles erfolgreich
> durchsimuliert wurde? Wenn seitens des Kunden alles stimmt, ist das doch
> ein Umsetzungproblem.

Die Qualität der Simulation hängt natürlich gewaltig von der 
Testabdeckung und Qualität der Testfälle ab. Zudem nimmt der 
Rechenleistungsbedarf für eine vollständige Simulation exponentiell mit 
der Anzahl der internen Zustände zu, so dass man heutzutage nur noch 
einen winzigen Bruchteil aller möglichen Zustände überhaupt abdecken 
kann und sich darauf verlassen muss, dass die verschiedenen 
Zustandsautomaten usw. hinreichend gut voneinader isoliert bzw. 
vorhersagbar gekoppelt sind.

Mit einer reinen Simulation auf RTL-Ebene ist es aber nicht getan, 
sondern man muss natürlich das zeitliche Verhalten auch auf 
verschiedenen physikalischen Abstraktionen simulieren. Und auch hier 
muss natürlich der Simulator die Physik des Bausteins hinreichend 
präzise darstellen.

Und letztendlich können natürlich auch immer noch Fehler in irgendeinem 
Stück Software auf dem langen Weg von der HDL bis zum fertigen Baustein 
auftreten. Bei den aktuellen Strukturgrößen muss man sich z.B. bei der 
Maskenbelichtung der sog. Inversen Lithographie bedienen, d.h. die Maske 
stellt nicht mehr ein (größenskaliertes) Abbild der gewünschten Struktur 
dar, sondern ein Beugungsmuster mit Amplituden- und Phaseninformationen 
dar. Dies setzt aber voraus, dass der physikalische Maskenherstellungs- 
und spätere Belichtungsvorgang genau so stattfinden, wie im 
Berechnungsmodell beschrieben. Außerdem ist das ganze extremst 
rechenaufwändig, d.h. zu jedem Maskenbelichter gehört ein eigener 
gewaltiger Rechencluster.

Allmählich kommen wir bei den Halbleiterstrukturen auch in Bereiche, in 
denen quantenmechanische Effekte auftreten.

: Bearbeitet durch User
von Purzel H. (hacky)


Lesenswert?

Erstaunlich wieviele auf den Troll hereigefallen sind. Die Diskussion 
war trotzdem spannend. Bisher konnte kein herausragendes Feature, das 
den Traum von der Wirklichkeit abhebt, und den Aufwand rechtfertigt, 
gefunden werden.

Bei jeder Runde wurden die Moeglichkeiten eingeschraenkt, die Zahl der 
moeglichen Helfer reduziert.

von T.U.Darmstadt (Gast)


Lesenswert?

Jetzt ist G. schrieb:
> Erstaunlich wieviele auf den Troll hereigefallen sind.

Eine gewagte Hypthese bei jemandem, der seit 3 Jahren im Forum 
angemeldet ist. Ich habe die Diskussion verfolgt: Der Ansatz an sich ist 
interessant, nur muss auch ich dem TE bescheinigen, dass ohne ein 
konkret umsetzbares Ziel wohl kaum etwas erreichbar sein wird.

Die, die können, werden sich nicht beteiligen, ohne einen Benefit zu 
sehen.

von Thomas K. (thok)


Lesenswert?

Jetzt ist G. schrieb:
> Erstaunlich wieviele auf den Troll hereigefallen sind. Die Diskussion
> war trotzdem spannend. Bisher konnte kein herausragendes Feature, das
> den Traum von der Wirklichkeit abhebt, und den Aufwand rechtfertigt,
> gefunden werden.
>
> Bei jeder Runde wurden die Moeglichkeiten eingeschraenkt, die Zahl der
> moeglichen Helfer reduziert.

Schön, dass du die bisherige Diskussion spannend fandest. Das Ergebnis 
liegt weniger an mir. Ja, es gab von mir sehr genaue Vorgaben zu den zu 
verwendenden Sprachen und Entwicklungstools für das Projekt, die aus 
schon genannten Gründen gerechtfertigt sind. Aber leider wurden auch nur 
sehr wenig sinnvolle Vorschläge in die Diskussion eingebracht.

Vielleicht hast du ja einen guten Vorschlag, hast dich bisher aber nur 
nicht getraut, weil es hier Trolle geben soll. Ja, nächste Woche ist 
schon Halloween.

von Thomas K. (thok)


Lesenswert?

Thomas U. schrieb:
> Jetzt ist G. schrieb:
>> Erstaunlich wieviele auf den Troll hereigefallen sind.
>
> Eine gewagte Hypthese bei jemandem, der seit 3 Jahren im Forum
> angemeldet ist.

Anscheinend bist du ein Hellseher, wenn du am Anmeldedatum im Forum 
erkennen kannst, welche Erfahrungen ein Mitglied hat.

> Ich habe die Diskussion verfolgt: Der Ansatz an sich ist
> interessant, nur muss auch ich dem TE bescheinigen, dass ohne ein
> konkret umsetzbares Ziel wohl kaum etwas erreichbar sein wird.

Ein Ziel war vorgegeben, aber anscheinend zu ehrlich und zu hoch für 
dieses Forum. Vielleicht hat sich aber auch eine Mehrheit von 
Interessenten an diesem Projekt nur nicht getraut, ihre Ideen bei zu 
steuern. Die Gründe dafür, wissen nur diejenigen selbst.

> Die, die können, werden sich nicht beteiligen, ohne einen Benefit zu
> sehen.

Zu welchen zählst du?
Ein Nutzen könnte sein, das man sich bei einem Projekt nicht nur ein 
bringt, sondern dabei auch viel lernen kann, vorallem im Austausch mit 
anderen Projektbeteiligten.

Apropos lernen, ich habe heute keinen von euch bei der VSDOpen 
angetroffen. Wahrscheinlich lag es daran, dass VHDL dort keine Rolle 
gespielt hat. Aber zum Kennenlernen des fortschreitenden Wandels bei der 
Entwicklung von Hardware waren genügend andere Vorträge dabei gewesen, 
von denen jeder Teilnehmer nur profitieren kann.

: Bearbeitet durch User
von Strubi (Gast)


Lesenswert?

Thomas K. schrieb:
> Ein Ziel war vorgegeben, aber anscheinend zu ehrlich und zu hoch für
> dieses Forum. Vielleicht hat sich aber auch eine Mehrheit von
> Interessenten an diesem Projekt nur nicht getraut, ihre Ideen bei zu
> steuern. Die Gründe dafür, wissen nur diejenigen selbst.

TL;DR (zumindest das meiste), aber das war ich eben aufschnappen konnte, 
ist eher, dass du auf einige Hinweise erfahrener Nutzer offenbar nicht 
eingehst.
Fang doch mal klein an, und MACH was, viel Blabla ermüdet nur alle 
beteiligten, ob Trollversuch oder nicht. Erst DANN findest du ev. die 
Partner, die dir mit den Dollartools zur Seite stehen können.

Für mich wäre es interessant, wenn es sich nicht um gehypten 
RISCV-Aufwasch und MyHDL gehandelt hätte. Die Frage ist vor allem: 
Welches Problem willst du damit lösen, was soll daran neu sein?

Nach >100 Beiträgen Blabla ist wohl noch nix bei rumgekommen.

Thomas K. schrieb:
> Apropos lernen, ich habe heute keinen von euch bei der VSDOpen
> angetroffen.

Ich habe mir das mit den Konferenzen abgewöhnt, u.a. wegen zuviel 
Blabla. Aber gut, den Patterson kann man schon mal anhören.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Thomas K. schrieb:
> Ein Ziel war vorgegeben, aber anscheinend zu ehrlich und zu hoch für
> dieses Forum. Vielleicht hat sich aber auch eine Mehrheit von
> Interessenten an diesem Projekt nur nicht getraut, ihre Ideen bei zu
> steuern. Die Gründe dafür, wissen nur diejenigen selbst.

Du hast immer noch nicht schlüssig dargelegt, wie Du den wichtigen 
Meilenstein "ASIC" finanzieren willst. Entweder handelt es sich um ein 
reines Spaß- und Lernprojekt, in dessen Verlauf etliche Beteiligte u.a. 
ihr Sparschwein leeren müssen, oder eben um ein kommerzielles Projekt, 
dessen (spätere) Finanziers eben andere Dinge sehen wollen als hier 
bisher diskutiert. Ich hatte diese Thematik ja schon vor einiger Zeit 
angesprochen.

>> Die, die können, werden sich nicht beteiligen, ohne einen Benefit zu
>> sehen.
>
> Zu welchen zählst du?
> Ein Nutzen könnte sein, das man sich bei einem Projekt nicht nur ein
> bringt, sondern dabei auch viel lernen kann, vorallem im Austausch mit
> anderen Projektbeteiligten.

Mir kommt aber mehr und mehr der Verdacht, dass es sich um ein als 
Spaßprojekt getarntes kommerzielles Projekt handelt, bei dem nur Du 
irgendwann eine Vergütung erwarten kannst. Und damit wärst Du nicht der 
Erste, der mit so etwas sogar Erfolg hätte. Die von Dir behauptete 
Ehrlichkeit ist vermutlich nur vorgeschoben. Ehrlich wäre die folgende 
Ausschreibung: "Wir suchen dringend hochqualifizierte ASIC-Entwickler 
mit langjähriger Projekterfahrung für ein mehrjähriges unbezahltes 
Praktikum."

Oder eben als kommerzielle Projektausschreibung bzw. Stellenangebot. 
Aber das kostet ja Geld, und Du müsstest womöglich persönlich haften.

von S. R. (svenska)


Lesenswert?

Thomas K. schrieb:
> Ein Ziel war vorgegeben, aber anscheinend zu ehrlich und zu hoch für
> dieses Forum. Vielleicht hat sich aber auch eine Mehrheit von
> Interessenten an diesem Projekt nur nicht getraut, ihre Ideen bei zu
> steuern. Die Gründe dafür, wissen nur diejenigen selbst.

Das Ziel war vorgegeben, aber zu speziell und zu unflexibel für dieses 
Forum. Vielleicht hat sich aber der Projektleiter auch nur nicht 
getraut, auf die Ideen und Vorbehalte der Interessenten einzugehen. Die 
Gründe dafür, weiß nur derjenige selbst.

Thomas K. schrieb:
> Ein Nutzen könnte sein, das man sich bei einem Projekt nicht nur ein
> bringt, sondern dabei auch viel lernen kann, vorallem im Austausch mit
> anderen Projektbeteiligten.

Ja, das wird ähnlich wie am Arbeitsplatz sein. Lernen findet vor allem 
dadurch statt, dass man ein Projekt hochzieht, dessen Umfang und 
Abgabetermin bereits vor Beginn feststehen. Wenn man stecken bleibt, 
kann man (hoffentlich) erfahrenere Kollegen fragen, um das Projekt 
weiter voranzubringen und als netten Nebeneffekt lernt man, wie man das 
beim nächsten Mal besser macht.

Thomas K. schrieb:
> Apropos lernen, ich habe heute keinen von euch bei der VSDOpen
> angetroffen. Wahrscheinlich lag es daran, dass VHDL dort keine Rolle
> gespielt hat.

Dazu sag ich jetzt mal nix. Andreas hat offensichtlich recht.

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Thomas K. schrieb:
>> Ein Ziel war vorgegeben, aber anscheinend zu ehrlich und zu hoch für
>> dieses Forum. Vielleicht hat sich aber auch eine Mehrheit von
>> Interessenten an diesem Projekt nur nicht getraut, ihre Ideen bei zu
>> steuern. Die Gründe dafür, wissen nur diejenigen selbst.
>
> Du hast immer noch nicht schlüssig dargelegt, wie Du den wichtigen
> Meilenstein "ASIC" finanzieren willst. Entweder handelt es sich um ein
> reines Spaß- und Lernprojekt, in dessen Verlauf etliche Beteiligte u.a.
> ihr Sparschwein leeren müssen, oder eben um ein kommerzielles Projekt,
> dessen (spätere) Finanziers eben andere Dinge sehen wollen als hier
> bisher diskutiert. Ich hatte diese Thematik ja schon vor einiger Zeit
> angesprochen.

Bisher ist es nur eine Idee, das man davon auch einen ASIC erstellen 
könnte. So hatte ich das auch auf die konkrete Frage dazu geäußert.

Hier nochmal mein Kommentar dazu.
>Jürgen S. schrieb:
>> Soll das danach ein ASIC werden?
>
>Thomas K. schrieb:
>Es wäre schon schön, wenn wir es bis zu einem Chip schaffen. Das das
>nicht gleich in 3 Monaten sein wird, sollte jedem klar sein.

Für eine Finanzierung des ASICs könnte es mehrere Möglichkeiten geben. 
Ich nenne hier nur mal zwei, die mir so einfallen.
a) Während der Entwicklung gibt es Interesse von potentiellen Kunden, 
die solch einen Chip, eventuell auch mit Erweiterungen, einsetzen 
möchten.

b) Eventuell ist auch SiFive an solch einem Multicore Chip interessiert 
und würde das Projekt entsprechend unterstützen.

Da ich bisher, vorallem wegen unklarer Resourcenlage, nicht mal einen 
genauen Fertigstellungstermin für eine lauffähige FPGA Version samt 
notwendiger Toolunterstützung nennen kann, stand eine konkrete 
Finanzierung eines ASICs für mich bisher nicht mit hoher Priorität auf 
der ToDo-Liste. Aber fairer Weise hatte ich es mit als Ziel genannt, da 
es nicht für eine reine FPGA Lösung geeignet ist.

>>> Die, die können, werden sich nicht beteiligen, ohne einen Benefit zu
>>> sehen.
>>
>> Zu welchen zählst du?
>> Ein Nutzen könnte sein, das man sich bei einem Projekt nicht nur ein
>> bringt, sondern dabei auch viel lernen kann, vorallem im Austausch mit
>> anderen Projektbeteiligten.
>
> Mir kommt aber mehr und mehr der Verdacht, dass es sich um ein als
> Spaßprojekt getarntes kommerzielles Projekt handelt, bei dem nur Du
> irgendwann eine Vergütung erwarten kannst. Und damit wärst Du nicht der
> Erste, der mit so etwas sogar Erfolg hätte. Die von Dir behauptete
> Ehrlichkeit ist vermutlich nur vorgeschoben.

Es ist in der Tat nur ein Spaßprojekt und die Idee einer einzelnen 
Person.
Warum sollte nur ich davon profitieren, wenn es ein Projekt mit mehreren 
Mitgliedern ist, welches auch als Open Source öffentlich zur Verfügung 
steht?

Ich kann deinen Verdacht nachvollziehen, denn aufgrund des genannten 
ASIC Ziels kann dies durchaus den Eindruck erwecken. Dem ist aber 
definitiv nicht so.

Als reine FPGA Version wäre es, denke ich, keine gute Lösung, da der 
Resourcenbedarf im FPGA relativ groß ist und die Kosten für einen 
geeigneten FPGA auch zu hoch wären.

von Thomas K. (thok)


Lesenswert?

S. R. schrieb:
> Thomas K. schrieb:
>> Ein Nutzen könnte sein, das man sich bei einem Projekt nicht nur ein
>> bringt, sondern dabei auch viel lernen kann, vorallem im Austausch mit
>> anderen Projektbeteiligten.
>
> Ja, das wird ähnlich wie am Arbeitsplatz sein. Lernen findet vor allem
> dadurch statt, dass man ein Projekt hochzieht, dessen Umfang und
> Abgabetermin bereits vor Beginn feststehen. Wenn man stecken bleibt,
> kann man (hoffentlich) erfahrenere Kollegen fragen, um das Projekt
> weiter voranzubringen und als netten Nebeneffekt lernt man, wie man das
> beim nächsten Mal besser macht.

Ich finde es schade, dass hier im Forum einige mit eher negativer 
Einstellung Kommentare verfassen und Verdächtigungen in der Raum werfen, 
ohne dafür einen konkreten Grund oder Beweis zu haben.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Du widersprichst Dir doch selbst immer wieder...

Auf der einen Seite stellst Du ein ASIC nur als unverbindliche Idee dar. 
Auf der anderen Seite siehst Du ganz klar ein ASIC als Ziel des 
Projektes.

Dann behauptest Du, das ganze sei nur ein Hobbyprojekt, willst es aber 
trotzdem an potentielle Investoren verkaufen.

Ich hatte schon zuvor haarklein erläutert, dass einen potentiellen 
Investor nicht interessiert, was ein paar Hobbyisten zusammenfrickeln, 
denn sonst müssten sie ja auch bei Josef bo8 schon in der Schlange 
stehen. Investoren interessieren sich ausschließlich dafür, welche 
Märkte zu welchen Zeitpunkten damit bedient werden können und wo die 
Vorteile bzw. Alleinstellungsmerkmale gegenüber etablierten Lösungen 
liegen. Außerdem wollen sie das ganze mit Patenten und anderen 
Schutzrechten absichern bis der Anwalt kommt! Und das steht in 
erheblichem Gegensatz zu einem Open-Source-Ansatz.

Ansonsten gibt es auch kein Geld für ein ASIC. Keine Arme, keine Kekse.

von versteht open source (Gast)


Lesenswert?

>Und das steht in erheblichem Gegensatz zu einem Open-Source-Ansatz.

Wofür hat IBM dann heute 30 Milliarden bezahlt?

von S. R. (svenska)


Lesenswert?

Thomas K. schrieb:
> Ich finde es schade, dass hier im Forum einige mit eher negativer
> Einstellung Kommentare verfassen und Verdächtigungen in der Raum werfen,
> ohne dafür einen konkreten Grund oder Beweis zu haben.

Solange du die Vorbehalte nicht entkräftest - und das tust du nicht - 
befeuerst du sie. Der Rest ist Logik.

Ein FPGA-Design unterscheidet sich von einem ASIC-Design. Da du FPGAs 
als Endziel explizit ausgeschlossen hast - eben wieder - hast du also 
ein ASIC als Endziel. Und damit landest du direkt wieder bei der 
Finanzierungsfrage.

Wenn mir klar ist, dass ich kein ASIC hinbekomme, dann entwickle ich 
nicht auf ein ASIC hin. Und wenn ich auf potentielle Auftragnehmer und 
Geldgeber spekuliere, dann habe ich ganz bestimmte Auftragnehmer und 
Geldgeber im Hinterkopf. Und damit landest du direkt wieder bei der 
Frage nach kommerzieller Entwicklung.

Thomas K. schrieb:
> Warum sollte nur ich davon profitieren, wenn es ein Projekt
> mit mehreren Mitgliedern ist, welches auch als Open Source
> öffentlich zur Verfügung steht?

Weil dieses "Open Source Projekt mit mehreren Mitgliedern" (was es nicht 
ist, denn du möchtest es führen) niemals einen ASIC fertigen lassen 
wird. Du hingegen schon.

Und es hindert dich niemand daran, einen IP-Block mit deiner 
proprietären Magie in einen Fork einzubauen, daraus einen ASIC zu 
fertigen und den dann zu verkaufen. Niemand außer dir (und deinen 
Geldgebern) hätte davon etwas.

Deine Vorstellungen und Aussagen sind hinreichend konkret... du weißt 
ziemlich genau, wo du hin willst. Tu nicht so naiv.

von S. R. (svenska)


Lesenswert?

Nachtrag, da du SiFive erwähnt hast. Ich hab die mal auf einer Konferenz 
persönlich getroffen und hatte nicht gerade das Gefühl, dass die an 
einem RISC-V-Propeller interessiert wären, ganz im Gegenteil. Deine 
Aussage ist also entweder Unkenntnis oder eine Nebelkerze.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

versteht open source schrieb:
>>Und das steht in erheblichem Gegensatz zu einem Open-Source-Ansatz.
>
> Wofür hat IBM dann heute 30 Milliarden bezahlt?

IBM hat nicht 30 G$ für einen Haufen Open-Source-Software bezahlt, 
sondern für ein Unternehmen, das einen Haufen an Dienstleistungen rund 
um Linux anbietet. Zudem geht es um Markenrechte und auch Programme, die 
nicht als Open Source verfügbar sind.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

S. R. schrieb:
> Nachtrag, da du SiFive erwähnt hast. Ich hab die mal auf einer Konferenz
> persönlich getroffen und hatte nicht gerade das Gefühl, dass die an
> einem RISC-V-Propeller interessiert wären, ganz im Gegenteil. Deine
> Aussage ist also entweder Unkenntnis oder eine Nebelkerze.

Wen bei SiFive hast Du denn dort getroffen? Vermutlich wären diese 
Aussagen sehr unterschiedlich ausgefallen, je nachdem ob Du mit der 
Geschäftsführung, dem Vertrieb, Produktmarketing oder Entwicklung 
gesprochen hättest.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

S. R. schrieb:
> Weil dieses "Open Source Projekt mit mehreren Mitgliedern" (was es nicht
> ist, denn du möchtest es führen) niemals einen ASIC fertigen lassen
> wird. Du hingegen schon.

Und weil es sich eben um ein Open-Source-Projekt handelt, muss er auch 
keinen Cent oder sonstige Vergütungen an die anderen Entwickler abgeben.

> Und es hindert dich niemand daran, einen IP-Block mit deiner
> proprietären Magie in einen Fork einzubauen, daraus einen ASIC zu
> fertigen und den dann zu verkaufen. Niemand außer dir (und deinen
> Geldgebern) hätte davon etwas.

Der Geldgeber müsste aber befürchten, dass er den Prozessor nicht 
alleine weiterentwickeln kann, sondern dafür die Unterstützung einiger 
oder aller anderen Projektbeteiligten benötigt. Dies birgt für ihn 
erhebliche rechtliche und finanazielle Risiken. Etliche Entwickler 
werden durch ihre Arbeitsverträge gehindert sein, für den Geldgeber ein 
ASIC (weiter-)zuentwickeln. Oder sie haben keine Zeit oder Lust dazu.

> Deine Vorstellungen und Aussagen sind hinreichend konkret... du weißt
> ziemlich genau, wo du hin willst. Tu nicht so naiv.

Diesen Eindruck habe ich auch.

von Maier (Gast)


Lesenswert?

Jetzt ist halt die Zeit der "eigenen Mikrocontroller", zu Luthers Zeiten 
war das die Bibeluebersetzung. Der eine oder andere wird Erfolg damit 
haben.
In diesem Kontext sehe ich die Anfrage. Ein solches Unterfangen ist 
heute moeglich, gleichzeitig natuerlich nicht einfach.

Fuer ein solches wachsendes Projekt halte ich die Propelleridee schon 
fuer eine gute Basis, weil man zunaechst auf viel Peripherie in Hardware 
verzichten kann und durch Software trotzdem auf volle Funktionalitaet 
kommt. Und so kann man dann Stueck fuer Stueck die Peripherie in 
Hardware ausbauen. Hier gibts natuerlich durch die hohe ASIC-Huerde 
schon ein Motivationsproblem.

Und das Problem, dass man mit der Architektur kein 
Alleinstellungsmerkmal hat, bleibt irgendwie schon. Vielleicht dass es 
open-source ist, waere noch eine Besonderheit. Ein chinesischer 
Hersteller koennte in ferner Zukunft den Chip auf den Markt werfen. Zum 
Preis eines AVR waere das vielleicht was besonderes. Wie die 
SRAM-Diskussion gezeigt hat, hat man aber bei einem Multicore auch mit 
besonderen Unwegbarkeiten zu kaempfen, bzw. hat am Ende doch wieder eine 
komplizierte Architektur, sodass der Multicore uninteressant wird.

Ob die Entwickler kostenlos arbeiten moechten mit der blosen Hoffnung, 
dass vielleicht irgendwann ein  Dritter einen ASIC auf den Markt wirft?

von S. R. (svenska)


Lesenswert?

Andreas S. schrieb:
> Wen bei SiFive hast Du denn dort getroffen?

Einige, aber das war eigentlich noch vor SiFive (ISCA 2016). Zumindest 
sind sie da als Doktoranden von Berkeley aufgetreten. Sehr angenehme 
Menschen.

von Thomas K. (thok)


Lesenswert?

Andreas S. schrieb:
> Du widersprichst Dir doch selbst immer wieder...
>
> Auf der einen Seite stellst Du ein ASIC nur als unverbindliche Idee dar.
> Auf der anderen Seite siehst Du ganz klar ein ASIC als Ziel des
> Projektes.

Ich sehe da keinen Widerspruch. Irgendeinen Anreiz muss ich euch ja 
geben, wenn es nicht als reine FPGA-Lösung taugt. ;-)

> Dann behauptest Du, das ganze sei nur ein Hobbyprojekt, willst es aber
> trotzdem an potentielle Investoren verkaufen.

Warum sollte man es nicht verkaufen, wenn dir jemand für die investierte 
Zeit ein gutes Angebot macht, auch wenn es nur als Hobbyprojekt 
gestartet wurde?
Verkauf kann ja auch bedeuten, das dein Know-How auch weiterhin im 
Projekt gefragt ist, nur gegen Bezahlung, damit du für einen bestimmten 
Kunden Anpassungen machst. Es heißt ja nicht, das du es komplett aus den 
Händen geben musst.

Da es ja ohnehin Open Source sein soll, kannst du es natürlich nicht 
verhindern, das Dritte es sich nehmen und selbst nach ihren Wünschen 
abwandeln.

von Thomas K. (thok)


Lesenswert?

S. R. schrieb:
> Thomas K. schrieb:
>> Ich finde es schade, dass hier im Forum einige mit eher negativer
>> Einstellung Kommentare verfassen und Verdächtigungen in der Raum werfen,
>> ohne dafür einen konkreten Grund oder Beweis zu haben.
>
> Solange du die Vorbehalte nicht entkräftest - und das tust du nicht -
> befeuerst du sie. Der Rest ist Logik.
>
> Ein FPGA-Design unterscheidet sich von einem ASIC-Design. Da du FPGAs
> als Endziel explizit ausgeschlossen hast - eben wieder - hast du also
> ein ASIC als Endziel. Und damit landest du direkt wieder bei der
> Finanzierungsfrage.
>
> Wenn mir klar ist, dass ich kein ASIC hinbekomme, dann entwickle ich
> nicht auf ein ASIC hin. Und wenn ich auf potentielle Auftragnehmer und
> Geldgeber spekuliere, dann habe ich ganz bestimmte Auftragnehmer und
> Geldgeber im Hinterkopf. Und damit landest du direkt wieder bei der
> Frage nach kommerzieller Entwicklung.

Ich kann nur immer wieder sagen, das ich bisher mit keinem potentiellen 
Auftraggeber in Verhandlung stehe. Deshalb wird es auch als Hobbyprojekt 
an den Start gehen bzw. läuft schon, durch mich alleine.

Manchmal ergeben sich aber durchaus Synergien, wenn man an einem Projekt 
tätig ist und andere darauf aufmerksam werden.

> Thomas K. schrieb:
>> Warum sollte nur ich davon profitieren, wenn es ein Projekt
>> mit mehreren Mitgliedern ist, welches auch als Open Source
>> öffentlich zur Verfügung steht?
>
> Weil dieses "Open Source Projekt mit mehreren Mitgliedern" (was es nicht
> ist, denn du möchtest es führen) niemals einen ASIC fertigen lassen
> wird. Du hingegen schon.

Ich habe meine Idee hier kund getan und nach Interessenten für dieses 
RISC-V Projekt gefragt. Da ich die Idee hier ein gebracht habe, ist es 
für mich selbst verständlich, auch die Richtung für das Projekt 
vorzugeben.
Ob und wann es einen ASIC geben wird, kann ich nicht vorher sagen. Wenn 
es keinen gibt, gibt es eben nur einen weiteren Open Source RISC-V 
Mikrocontroller.

> Und es hindert dich niemand daran, einen IP-Block mit deiner
> proprietären Magie in einen Fork einzubauen, daraus einen ASIC zu
> fertigen und den dann zu verkaufen. Niemand außer dir (und deinen
> Geldgebern) hätte davon etwas.
>
> Deine Vorstellungen und Aussagen sind hinreichend konkret... du weißt
> ziemlich genau, wo du hin willst. Tu nicht so naiv.

Ja, ich weiß, was ich will und daran werde ich auch weiter festhalten 
und es versuchen umzusetzen.

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Jetzt ist halt die Zeit der "eigenen Mikrocontroller", zu Luthers Zeiten
> war das die Bibeluebersetzung. Der eine oder andere wird Erfolg damit
> haben.
> In diesem Kontext sehe ich die Anfrage. Ein solches Unterfangen ist
> heute moeglich, gleichzeitig natuerlich nicht einfach.
>
> Fuer ein solches wachsendes Projekt halte ich die Propelleridee schon
> fuer eine gute Basis, weil man zunaechst auf viel Peripherie in Hardware
> verzichten kann und durch Software trotzdem auf volle Funktionalitaet
> kommt. Und so kann man dann Stueck fuer Stueck die Peripherie in
> Hardware ausbauen.

Danke für deinen Kommentar, der mein geplantes Vorgehen komplett 
widerspiegelt. Welche spezielle Peripherie man später dann als Hardware 
hinzufügt, wird sich zeigen. Hierzu habe ich auch keine Vorgaben 
gemacht, denn das wird sehr stark vom individuellen Einsatzgebiet 
abhängen, über welches man sich im Projekt noch Gedanken machen kann.

> Hier gibts natuerlich durch die hohe ASIC-Huerde
> schon ein Motivationsproblem.

Kannst du das bitte erläutern, wie du das meinst? Sprichst du damit auch 
die notwendigen finanziellen Mittel für einen ASIC an?

> Und das Problem, dass man mit der Architektur kein
> Alleinstellungsmerkmal hat, bleibt irgendwie schon. Vielleicht dass es
> open-source ist, waere noch eine Besonderheit.

Ich meine, die geplante Architektur ist schon ein 
Alleinstellungsmerkmal, da es sowas bisher noch nicht gibt. Die 
unterscheidet sich komplett vom Propeller. Die einzige Gemeinsamkeit 
ist, das es RAM pro Core gibt.

> Ein chinesischer
> Hersteller koennte in ferner Zukunft den Chip auf den Markt werfen. Zum
> Preis eines AVR waere das vielleicht was besonderes. Wie die
> SRAM-Diskussion gezeigt hat, hat man aber bei einem Multicore auch mit
> besonderen Unwegbarkeiten zu kaempfen, bzw. hat am Ende doch wieder eine
> komplizierte Architektur, sodass der Multicore uninteressant wird.

Ob die vorgeschlagenen Konzepte schon die Endlösung darstellen, sollte 
man durch entsprechende Simulation evaluieren, bevor man zur 
Hardwareimplementierung übergeht.

> Ob die Entwickler kostenlos arbeiten moechten mit der blosen Hoffnung,
> dass vielleicht irgendwann ein  Dritter einen ASIC auf den Markt wirft?

Damit wird man wohl leben müssen, wenn man es als Open Source 
veröffentlichen will.
Nenn mir eine alternative Motivation für die Entwickler, wenn man keinen 
ASIC als Ziel hätte?

von Maier (Gast)


Lesenswert?

Thomas K. schrieb:
> Maier schrieb:
>> Und so kann man dann Stueck fuer Stueck die Peripherie in
>> Hardware ausbauen.
> [...]
>> Hier gibts natuerlich durch die hohe ASIC-Huerde
>> schon ein Motivationsproblem.
> Kannst du das bitte erläutern, wie du das meinst? Sprichst du damit auch
> die notwendigen finanziellen Mittel für einen ASIC an?
Ich mein das so, dass es im Zustand der fehlenden Peripherie sehr 
unwahrscheinlich ist, einen ASIC umsetzen zu können. Das heißt alle 
Entwicklungen sind zu diesem Zeitpunkt halt nur auf dem Papier oder in 
Teilen auf dem FPGA. Es ist nicht so wie bei einer Software, die schon 
relativ schnell produktiv eingesetzt werden kann, auch wenn ein Großteil 
der Funktionalitäten noch fehlt. Da seh ich eben das Motivationsproblem, 
für einen selber, aber auch darin weitere Entwickler im Laufe des 
Projekts dazu zu gewinnen.

> Ich meine, die geplante Architektur ist schon ein
> Alleinstellungsmerkmal, da es sowas bisher noch nicht gibt. Die
> unterscheidet sich komplett vom Propeller. Die einzige Gemeinsamkeit
> ist, das es RAM pro Core gibt.
Es gibt ja auch außer dem Propeller schon Multicore-Prozessoren. Was ja 
schon öfters gefragt wurde, was soll der neue Prozessor besser machen 
als bestehende Konzepte? Also im Vergleich zu einem 
"Standardmikrocontroller" wie STM32 oder einem Mehrkerner wie XMOS.
In der Propeller-Idee sehe ich den Verzicht auf Peripherie. Ich würde 
den Propeller eher als Designstudie betrachten, die zeigt, dass man 
durch mehrere Prozessoren auf Hardwareperipherie verzichten kann. 
Sinnvoll stell ich mir deshalb eine Kombination vor, Standardperipherie 
und einen zweiten, dritten Kern für Spezialaufgaben, als besseren DMA 
oder ähnliches. Dafür wären dann aber 8 Kerne eher zu viel, da ein 
Großteil der Ressourcen meist ungenutzt ist.
Ein anderer Anwendungsbereich für Mehrkerner wären rechenintensive 
Programme, d.h. Parallelrechnen.
Das sind aber zwei recht verschiedene Anwendungen, sicherlich sollte man 
sich auf eine davon konzentrieren. Ich fände den ersten Anwendungsfall 
interessant. Dann sind für die unterschiedlichen Kerne auch getrennte 
Interrupts sinnvoll, oder dass Interrupts von einem (zwischendurch 
schlafenden) "Nebenprozessor" abgearbeitet werden können.
Die Zielstellung ist also einen Mikrocontroller zu schaffen, der erstens 
durch die zusätzlichen Kerne die Programmierung vereinfacht und zweitens 
Peripherie, die es in Standardcontrollern nicht zu kaufen gibt, in 
Software erschlagen zu können.
Ersteres setzt eine einfache Architektur voraus. Zweiteres verlangt 
schnellen Zugriff aller Kerne auf die gesamte Peripherie und gemeinsamen 
Speicher.

von Strubi (Gast)


Lesenswert?

Moin,

also mal abgesehen davon, dass ich den Propeller für eine interessante, 
aber wenig relevante Nischenlösung halte: Der Gag ist gerade am FPGA, 
sich seine Suppe konfigurieren zu können. Also würde ich mal das 
unrealistische Marketing-Ziel "ASIC" vergessen, erfahrene Entwickler 
fressen das sowieso nicht, und Investoren nur bedingt - und wie schon 
gesagt, alleine ASIC, Investorengeld und Opensource beisst sich massiv.
Abgesehen davon: Wenn ein ASIC was werden wollte, machst du nach dem 
FPGA-Design nochmal alles neu, das lässt sich nicht einfach portieren.

Zur konkreten Anwendung: Ich stand mal vor der Wahl, performanten und 
dicken Soft-Core nehmen, Multitasking implementieren, oder: Zwei kleine 
Kerne mit shared memory instanzieren. Das geht also ohne viel 
Konzeptarbeit. Das allerdings OpenSource zu machen, so dass es jeder 
nutzen/dran mitarbeiten kann, DAS ist das spannende. Das haben vor dir 
einige nicht geschafft, inkl. mir :)

von Strubi (Gast)


Lesenswert?

Maier schrieb:
> In der Propeller-Idee sehe ich den Verzicht auf Peripherie. Ich würde
> den Propeller eher als Designstudie betrachten, die zeigt, dass man
> durch mehrere Prozessoren auf Hardwareperipherie verzichten kann.

Ich vergass: Das ist ja schön als Idee, aber die Realität sieht eben 
doch so aus, dass man für's FPGA alles möglichst simpel halten möchte. 
Sobald zuviele SW-Komponenten für gewisse Dinge zuständig sind, wird's 
schon mit der Verifikation heidenkomplex. Das will ich nicht, wenn ich 
für Fehlfunktion oder das Risiko, dass mir ein Szenario durch die Lappen 
geht, haften muss. Lieber will ich einen sehr flexibel konfigurierbaren 
Prozessor.

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Thomas K. schrieb:
>> Ich meine, die geplante Architektur ist schon ein
>> Alleinstellungsmerkmal, da es sowas bisher noch nicht gibt. Die
>> unterscheidet sich komplett vom Propeller. Die einzige Gemeinsamkeit
>> ist, das es RAM pro Core gibt.
> Es gibt ja auch außer dem Propeller schon Multicore-Prozessoren. Was ja
> schon öfters gefragt wurde, was soll der neue Prozessor besser machen
> als bestehende Konzepte?
> Also im Vergleich zu einem
> "Standardmikrocontroller" wie STM32 oder einem Mehrkerner wie XMOS.
> In der Propeller-Idee sehe ich den Verzicht auf Peripherie.

Ich hatte mich bis jetzt noch nicht mit den Chips von XMOS beschäftigt, 
aber ich habe mir mal die Doku von ihrem ersten Modell xCORE-200-XS1 
angeschaut. Der besitzt auch noch keine spezielle Peripherie. 
Stattdessen sind diverse Schnittstellen als Software IP verfügbar.
Später wurden dann für ganz spezielle Einsatzbereiche Chips mit 
entsprechender Peripherie angeboten.

Aus der Doku des xCORE-200-XS1 habe ich entnommen, das der Zugriff von 
den einzelnen Cores auf den RAM über Slices erfolgt. Wie das genau 
funktioniert, konnte ich der Doku jetzt nicht entnehmen. Aber das würde 
bedeuten, das z.B. ein Round-Robin Verfahren angewendet wird. Ein 
Problem tritt dabei aber auf, wenn mehrere CPU-Befehle hintereinander 
mit RAM Zugriff erfolgen. Denn dann muss die Befehlsabarbeitung 
aussetzen, weil dieser Slot eigentlich für das Holen des eines neuen 
Befehls (bei 16 bit Befehlen auch zwei) vorgesehen ist.
In der Doku findet man dazu auch einen entsprechenden Hinweis.
"Typically over 80% of instructions executed are 16-bit, so that the XS1 
processors fetch two instructions every cycle. As typically less than 
30% of instructions require a memory access, each processor can run at 
full speed using a unified memory system."

Im Gegensatz dazu hat beim Propeller jeder Core seinen eigenen RAM plus 
zusätzlichem Shared RAM, auf den alle Cores Zugriff über Slots erhalten. 
Der Propeller (P1) kann jedoch vom Shared RAM direkt keine CPU Befehle 
ausführen. Dieser wird also eher zum Datenaustausch zwischen den Cores 
verwendet.

Beim neuen Prozessor hat auch jeder Core seinen eigenen RAM. Es gibt 
aber keinen Shared RAM. Stattdessen, kann von einem Core direkt auf den 
Speicher eines anderen Cores zugriffen werden, da dual-port RAM 
verwendet wird. Der Zugriff erfolgt hier auch per Slots über einen Port 
des RAM. Über den anderen Port ist der jeweilige Core angebunden und 
kann also, ungehindert des Zugriffs von anderen Cores, weiter laufen.

Zusätzlich soll der verfügbare RAM durch verschiedene 
Konfigurationsmodis auch anders aufgeteilt werden können. So könnte z.B. 
ein Core 4 mal soviel RAM erhalten um damit ein kleines OS abzuarbeiten. 
Die anderen Cores führen nur bestimmte Tasks des OS aus, z.B. für die 
Kommunikation mit Peripherie.

Die Beschreibung dieser Konfigurierbarkeit ist weiter oben im 
angehängten Dokument zu finden.
Beitrag "Re: Mitstreiter für RISC-V Mikrocontrollers gesucht"

> Ich würde
> den Propeller eher als Designstudie betrachten, die zeigt, dass man
> durch mehrere Prozessoren auf Hardwareperipherie verzichten kann.
> Sinnvoll stell ich mir deshalb eine Kombination vor, Standardperipherie
> und einen zweiten, dritten Kern für Spezialaufgaben, als besseren DMA
> oder ähnliches. Dafür wären dann aber 8 Kerne eher zu viel, da ein
> Großteil der Ressourcen meist ungenutzt ist.

Die Anzahl der genutzten Cores hängt natürlich von der Anwendung ab und 
wie viele Tasks dort parallel am laufen sind. Meine Erfahrung ist, das 
man eher mehr als 4 Tasks in einer Anwendung hat und mit 8 Kernen 
dadurch auch für komplexere Anwendungen Luft hat.

> Die Zielstellung ist also einen Mikrocontroller zu schaffen, der erstens
> durch die zusätzlichen Kerne die Programmierung vereinfacht und zweitens
> Peripherie, die es in Standardcontrollern nicht zu kaufen gibt, in
> Software erschlagen zu können.

Für die erste Version eines neuen Mikrocontrollers gehe ich da voll mit. 
Für weitere Versionen könnte man aber auch spezialisierte Hardware 
hinzufügen, um damit andere Einsatzbereiche besser abzudecken.

von Thomas K. (thok)


Lesenswert?

Strubi schrieb:
> Moin,
>
> also mal abgesehen davon, dass ich den Propeller für eine interessante,
> aber wenig relevante Nischenlösung halte:

Das sehe ich anders. Der Propeller erfordert ein Umdenken von der 
monolithischen zur Taskgetriebenen Programmierung. Das fällt aber vielen 
Leuten schwer, da sie bisher keine alternative Programmiermethode 
genutzt haben bzw. anwenden mussten. Nur ein geringer Anteil von 
Programmierern hat auch Erfahrungen mit der Thread-Programmierung, mit 
der ja auch parallele Abarbeitung möglich ist und entsprechende Konzepte 
zum Datenaustausch mit den einzelnen Threads erfordert.

> Der Gag ist gerade am FPGA,
> sich seine Suppe konfigurieren zu können. Also würde ich mal das
> unrealistische Marketing-Ziel "ASIC" vergessen, erfahrene Entwickler
> fressen das sowieso nicht, und Investoren nur bedingt - und wie schon
> gesagt, alleine ASIC, Investorengeld und Opensource beisst sich massiv.
> Abgesehen davon: Wenn ein ASIC was werden wollte, machst du nach dem
> FPGA-Design nochmal alles neu, das lässt sich nicht einfach portieren.

Natürlich könnte auch eine FPGA Version ein Ziel sein, bei der man sich 
die Anzahl der Cores und Größe des RAM konfigurieren kann. Diese Version 
müsste dann aber verschiedene FPGA Hersteller unterstützen. Aber starten 
sollte man erstmal mit der Unterstützung für einen Hersteller.

> Zur konkreten Anwendung: Ich stand mal vor der Wahl, performanten und
> dicken Soft-Core nehmen, Multitasking implementieren, oder: Zwei kleine
> Kerne mit shared memory instanzieren. Das geht also ohne viel
> Konzeptarbeit. Das allerdings OpenSource zu machen, so dass es jeder
> nutzen/dran mitarbeiten kann, DAS ist das spannende. Das haben vor dir
> einige nicht geschafft, inkl. mir :)

Danke für dein Outing. ;-)
Es ist eben nicht einfach, es jedem Recht zu machen. Jeder hat seine 
eigenen Vorstellung, was das Teil am Ende können soll. Aber eine 
Eierlegende Vollmilchsau ist definitiv der falsche Weg.

: Bearbeitet durch User
von Gustl B. (-gb-)


Lesenswert?


von Batzi (Gast)


Lesenswert?

Ich lese das Thema mit großem Interesse, aber mir kommen da Fragen:

Thomas K. schrieb:
> Aber starten
> sollte man erstmal mit der Unterstützung für einen Hersteller.
Warum muss man sich auf einen Hersteller verlassen? VHDL so so flexibel, 
dass es herstellerunabhängig arbeiten kann, zumindest ist das meine 
Erfahrung.

> Nur ein geringer Anteil von
> Programmierern hat auch Erfahrungen mit der Thread-Programmierung, mit
> der ja auch parallele Abarbeitung möglich ist und entsprechende Konzepte
> zum Datenaustausch mit den einzelnen Threads erfordert.
Es ist ein steigender Anteil, das dürfte aber nicht das Problem werden. 
Eher schon, dass eine effektive Verwendung von threading ein OS 
erfordert oder wenigstens Strukturen davon, die das System wieder 
abbremsten was für so langsame Prozessoren fatal ist.

von Strubi (Gast)


Lesenswert?

Thomas K. schrieb:
> Nur ein geringer Anteil von
> Programmierern hat auch Erfahrungen mit der Thread-Programmierung, mit

Ein geringer Anteil?
Wenn ich mir die Linux-Welt so anschaue, kommt mir das nicht allzu 
gering vor. Aber wir sind ja noch bei bare metal, ohne OS. Jeder, der 
sich mit Race-Conditions in Interrupts auf diesbezüglich nicht 
durchgedachten Controllern beschäftigen darf, ist irgendwo ein 
Thread-Programmierer, nicht?

Batzi schrieb:
> Eher schon, dass eine effektive Verwendung von threading ein OS
> erfordert oder wenigstens Strukturen davon, die das System wieder
> abbremsten was für so langsame Prozessoren fatal ist.

Es braucht nur einen Scheduler und allenfalls wie eine 
Wait/Wakeup-Queue, wenn Tasks schlafen sollen, aber die kostet jetzt 
nicht SO viel.
Auf der ZPU-Architektur als Beispiel kann man relativ 'billige' 
Task-Switches machen, da keine Register gerettet werden müssen, sieht 
dann so aus in der Simulation:

https://section5.ch/wp-content/uploads/2018/09/trace-tasks.png

(und wem fällt dabei was auf...)

von Maier (Gast)


Lesenswert?

Batzi schrieb:
> Thomas K. schrieb:
>> Nur ein geringer Anteil von
>> Programmierern hat auch Erfahrungen mit der Thread-Programmierung, mit
>> der ja auch parallele Abarbeitung möglich ist und entsprechende Konzepte
>> zum Datenaustausch mit den einzelnen Threads erfordert.
> Es ist ein steigender Anteil, das dürfte aber nicht das Problem werden.
> Eher schon, dass eine effektive Verwendung von threading ein OS
> erfordert oder wenigstens Strukturen davon, die das System wieder
> abbremsten was für so langsame Prozessoren fatal ist.
Die "Threads" sollen ja auf die verschiedenen Kerne verteilt werden, es 
gibt also schon mal keinen Kontextwechsel, wofür ein OS benötigt werden 
würde. Es sollten m.E. auch Kommunikationsstrukturen auf Hardwareebene 
vorgesehen werden.

Threadprogrammierung mit seinen Gleichzeitigkeiten steht aber nicht 
gerade für Einfachheit...

von Thomas K. (thok)


Lesenswert?

Maier schrieb:
> Batzi schrieb:
>> Thomas K. schrieb:
>>> Nur ein geringer Anteil von
>>> Programmierern hat auch Erfahrungen mit der Thread-Programmierung, mit
>>> der ja auch parallele Abarbeitung möglich ist und entsprechende Konzepte
>>> zum Datenaustausch mit den einzelnen Threads erfordert.
>> Es ist ein steigender Anteil, das dürfte aber nicht das Problem werden.
>> Eher schon, dass eine effektive Verwendung von threading ein OS
>> erfordert oder wenigstens Strukturen davon, die das System wieder
>> abbremsten was für so langsame Prozessoren fatal ist.
> Die "Threads" sollen ja auf die verschiedenen Kerne verteilt werden, es
> gibt also schon mal keinen Kontextwechsel, wofür ein OS benötigt werden
> würde.
>
> Threadprogrammierung mit seinen Gleichzeitigkeiten steht aber nicht
> gerade für Einfachheit...

Völlig korrekt, du hast es verstanden, was ich damit gemeint habe.
Wenn man mehr als einen Core zur Verfügung hat und diese auch schon 
parallel ablaufen, kann auch jeder Core für eine bestimmte Aufgabe 
zuständig sein. Deshalb ist hier kein Kontextwechsel erforderlich.

Wenn man nur einen Core hat muss man sich mit Threads behelfen und dazu 
benötigt man einen Scheduler oder kleines OS mit diesem, der die 
laufenden Threads immer eine gewisse Zeit auf dem einen Core laufen 
lässt, was einen Kontextwechsel erfordert.

> Es sollten m.E. auch Kommunikationsstrukturen auf Hardwareebene
> vorgesehen werden.

Richtig, das habe ich bereits im angehängten Dokument beschrieben.
Beitrag "Re: Mitstreiter für RISC-V Mikrocontrollers gesucht"

Es soll insgesamt 8 Kommunikationskanäle geben, die als DMA arbeiten und 
Daten zwischen den Cores übertragen sollen. Jeder Core kann gleichzeitig 
ein Sende- und einen Empfangskanal haben.

von Thomas K. (thok)


Lesenswert?

Batzi schrieb:
> Ich lese das Thema mit großem Interesse, aber mir kommen da Fragen:
>
> Thomas K. schrieb:
>> Aber starten
>> sollte man erstmal mit der Unterstützung für einen Hersteller.
> Warum muss man sich auf einen Hersteller verlassen? VHDL so so flexibel,
> dass es herstellerunabhängig arbeiten kann, zumindest ist das meine
> Erfahrung.

Ja, das mag sein. Aber wenn du z.B. Resourcen von einem bestimmten Board 
oder FPGA verwenden willst, damit du diese nicht selber nochmal 
implementieren musst, ist es eher hinderlich. Wenn ein bestimmter 
Milestone erreicht ist, kann man dann den Code auf FPGAs und Boards von 
anderen Herstellern portieren.

von Lars R. (lrs)


Lesenswert?

Thomas K. schrieb:
> Aber wenn du z.B. Resourcen von einem bestimmten Board
> oder FPGA verwenden willst, damit du diese nicht selber nochmal
> implementieren musst, ist es eher hinderlich.

Wenn Herstellerabhänigkeit kein Problem und teils sogar gewollt ist, 
dann nimm Microsemi Igloo2 oder PolarFire. Da kannst Du Dir die Risc-V 
cores zusammen klicken. Programmierumgebung ist auch dabei.

von Thomas K. (thok)


Lesenswert?

Lars R. schrieb:
> Thomas K. schrieb:
>> Aber wenn du z.B. Resourcen von einem bestimmten Board
>> oder FPGA verwenden willst, damit du diese nicht selber nochmal
>> implementieren musst, ist es eher hinderlich.
>
> Wenn Herstellerabhänigkeit kein Problem und teils sogar gewollt ist,
> dann nimm Microsemi Igloo2 oder PolarFire. Da kannst Du Dir die Risc-V
> cores zusammen klicken. Programmierumgebung ist auch dabei.

Ja, gefällt mir auch sehr gut, was Microsemi da anbietet. Beim Igloo2 
werden aber nur die kleinen FPGAs bis 25K LE bei der kostenlosen Lizenz 
für Synthese- und Simulationstools unterstützt. Beim PolarFire nur die 
100K LE Version, was aber völlig reichen sollte.
Außerdem, denke ich, sind hier noch weit weniger Leute mit den FPGAs von 
Microsemi vertraut, als mit denen von Xilinx.

Thomas K. schrieb:
> Duke Scarring schrieb:
>> Warum die Beschränkung auf Xilinx bzw. sogar auf Xilinx-Vivado?
>
> Ich kenne mich mit Xilinx ganz gut aus. Ich hätte aber auch Microsemi
> nennen können.

Aber wir können ja mal ein Voting machen.
Wer Erfahrungen mit den Microsemi FPGAs Igloo2 oder PolarFire hat und 
zusätzlich Interesse an dem Projekt hat, bitte mal auf diesen Kommentar 
anworten.

von Lars R. (lrs)


Lesenswert?

Thomas K. schrieb:
> Aber wir können ja mal ein Voting machen.
> Wer Erfahrungen mit den Microsemi FPGAs Igloo2 oder PolarFire hat und
> zusätzlich Interesse an dem Projekt hat, bitte mal auf diesen Kommentar
> anworten.

Das Zusammenklicken schafft Du alleine. Dazu die Einarbeitung.

von Purzel H. (hacky)


Lesenswert?

>Es soll insgesamt 8 Kommunikationskanäle geben, die als DMA arbeiten und
Daten zwischen den Cores übertragen sollen. Jeder Core kann gleichzeitig
ein Sende- und einen Empfangskanal haben.

Sowas gabs auch schon mal, das nannte sich Transputer.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Jetzt ist G. schrieb:
> Sowas gabs auch schon mal, das nannte sich Transputer.

Oh ja, für die beiden älteren Baureihen T200, T400 und T800 gab es 
insbesondere von Herstellern wie Parsytec einige sehr imposante Systeme. 
Eines der Haupteinsatzgebiete lag in der Bilderkennung und 
-verarbeitung. Aber z.B. die ISDN-Einsteckkarte AVM B1 enthielt auch 
einen Transputer.

Leider wurde die Entwicklung des T9000 eingestellt, als SGS Thomson 
(heute ST Microelectronics) den damaligen Hersteller Inmos übernahm. Ich 
hatte damals als Student schon mit konkreten Planungen für einen 
T9000-basierten Rechner begonnen, d.h. es sollten möglichst kleine (ca. 
100*80mm^2) Module werden, die außer dem T9000 nur RAM enthielten und 
die gewünschten Topologie über die Verdrahtung der Backplanes realisiert 
würde.

Teile der Transputer-Architektur lebten noch einige Zeit lang in der 
Microcontrollerfamilie ST20, die aber mittlerweile auch in der 
Versenkung verschwunden ist.

Beitrag "S: Transputer"

: Bearbeitet durch User
von Strubi (Gast)


Lesenswert?

Ha, die Transputer...das erinnert mich an den Hype mit Occam und die 
Atari Workstation, kann sein, dass das auch ein T800 war.
Witzigerweise haben die alten Transputerkonzepte auf dem FPGA wieder 
eine Neubelebung erfahren. Es gibt da ein paar nerdige Anwendungen mit 
Multicore-J1, aber die Links habe ich nicht parat. Mit der ZPU kann man 
ähnliches machen. So richtig nerdy wäre natürlich, wenn einer den 
Occam-Kram noch mal ausgräbt und mit LLVM was hinbekommt, was sich gut 
auf div. Cores verteilt, sei es auch einfach eine Soft-implementation 
eines Interface.
In einer IP-Kamera scheint so ein Ding das Networking zu machen, hab ich 
mir aber noch nicht angesehen: http://excamera.com/sphinx/fpga-j1.html

von Batzi (Gast)


Lesenswert?

Maier schrieb:
> Die "Threads" sollen ja auf die verschiedenen Kerne verteilt werden, es
> gibt also schon mal keinen Kontextwechsel

macht es aber auch wieder unflexibel1

von Maier (Gast)


Lesenswert?

Batzi schrieb:
> macht es aber auch wieder unflexibel1
Eigentlich nicht, zeitunkritische Threads (d.h. wo Kontextwechsel nicht 
zu Timingfehlern fuehren) kann man ja trotzdem noch per Scheduler auf 
einem Kern abarbeiten.

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
Noch kein Account? Hier anmelden.