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
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.
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?
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.
Angehängte Dateien:
-
Smith_HDL_Chip_Design__VHDL-History.png
52 KB -
VHDL_history.png
8,3 KB
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
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.
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. ;-)
Gibt es schon eine Website zum Projekt, auf die man verlinken könnte?
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. ;-)
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.
Andreas Rückert schrieb: > Gibt es schon eine Website zum Projekt, auf die man verlinken könnte? Nein, die gibt es noch nicht.
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.
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.
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?
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/
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?
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.
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.
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.
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.
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.
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.
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...?
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.
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.
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.
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.
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.
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.
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. ;-)
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.
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.
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.
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.
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.
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.
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.
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...
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.
Nur wenn man so ein Projekt selbst macht, kann man aber was dabei lernen?
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.
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
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. ;-)
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.
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. ;-)
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.
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
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.
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.
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).
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?
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.
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.
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?
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
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
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?
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.
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.
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
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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
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.
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.
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?
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.
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."
Meinst, die Controller Idee hat im Trading Bereich mehr Chancen? Dort setzt man ja aus anderen Gründen oft auf FPGA.
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. :-)
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!
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.
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.
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.
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
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"
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.
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.
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.
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?
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.
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?
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
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...
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
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.
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.
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
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?
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
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
>Und das steht in erheblichem Gegensatz zu einem Open-Source-Ansatz.
Wofür hat IBM dann heute 30 Milliarden bezahlt?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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?
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.
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 :)
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.
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.
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
Da ist der ASIC! Das ging ja schnell! http://linuxgizmos.com/sifive-unveils-octa-core-risc-v-designs-including-two-linux-ready-models/
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.
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...)
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...
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.
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.
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.
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.
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.
>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.
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
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
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
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.