Gibt es zufällig ein Forenmitglied, dass sich mit dem Einbringen eines STM32 in einen FPGA auskennt oder gar das bereits gemacht hat? Ich hatte zuvor wie empfohlen auch die Suche verwendet, die scheint aber defekt. Es kommt immmer "interner Fehler". Wäre nett, wenn sich jemand dazu äußern würde. Es geht um dauerhaften Ersatz zur Beschleunigung einer MCU-Einheit.
Moin, Wieso sollte jemand sowas machen wollen? Das kommt mir vor, wie wenn ich frag', ob man eine ECH81 in ein FPGA "einbringen" kann, weil ich einen multiplizierenden Mischer und einen LO fuer ein SDR-Projekt benoetige... scnr, WK
Andreas M. schrieb: > Was meinst du mit einbringen? Er meint wohl dass man einen STM32 schnell mal in einem FPGA emulieren kann. Ist ja alles open source .....
Bernd H. schrieb: > Ersatz zur Beschleunigung einer MCU-Einheit Die Beschleunigung soll ersetzt werden? Das erkläre mal genauer! Ansonsten denke ich, dass Soft-Cores eher alles ausbremsen werden. Vlt. kommt sowas wie ein Zync-7k infrage?!
:
Bearbeitet durch User
"zur Beschleunigung" 🤔 Cortex-M0 gibt es frei oder auch irgendwelche Risc-V ... Soweit ich mich erinnern konnte, kriegt man beide problemlos auf 100MHz. Aber der M0 ist halt echt die Sparversion ... Aber der einzige sinnvolle Weg etwas zu beschleunigen, ist, einen schnelleren STM32 zu benutzen. Die gehen ja bis ein paar Hundert Megaherz (genau weiß ich es nicht mehr, "stm32profi" müsste es aber wissen^^) und haben auch noch Sachen wie FPU usw eingebaut. Softcores machen nur Sinn, wenn man ein ganzes SoC im FPGA haben möchte.
:
Bearbeitet durch User
Mampf F. schrieb: > Cortex-M0 gibt es frei oder auch irgendwelche Risc-V ... Soweit ich mich > erinnern konnte, kriegt man beide problemlos auf 100MHz. Aber der M0 ist > halt echt die Sparversion ... Oha, hat ARM da sein Lizenzmodell geändert? Normalerweise müsste man da blechen. Aber teure FPGA Gatter für nen Soft-Core verschwenden? Ein CM0+ bekomme ich aber auch als Dual-Core mit 120MHz fürn Appl und'n Ei. Mampf F. schrieb: > Die gehen ja bis ein paar Hundert Megaherz (genau weiß ich es nicht > mehr, "stm32profi" müsste es aber wissen^^) und haben auch noch Sachen > wie FPU usw eingebaut. Ein STM32H7 hat ne 500MHz CM7 und 240MHz CM4 Das mit einem Soft-Core topen zu wollen halte ich für sehr ambitioniert :-) Und wem das nicht reicht, es gibt ja nicht nur STM32. Da hätten wir zum Beispiel den RA8D1 der mit 480 MHz CM85 daher kommt. Oder wie wäre es mit einem NXP i.MX RT1170 1GHz CM7 + 400 MHz CM4. Da ist bestimmt was dabei was reicht. Zugegeben zugespitzt aber: Und wenn das immer noch nicht reicht, dann stellt halt nen anständigen Softwareentwickler ein, der löst das Problem dann vermutlich mit nem ollen 8 Bitter, weil der eigentliche Fehler ganz woanders liegt.
:
Bearbeitet durch User
> Ein CM0+ ... als Dual-Core mit 120MHz fürn Appl und'n Ei. Was nuetzen die (2x) 120 MHz, wenn das Zwergerl nicht mal in Hardware 32 bit mit weiteren 32 bit zu einem 64 bit Ergebnis multiplizieren kann? > hat ne 500MHz CM7 und 240MHz CM4 > 1GHz CM7 + 400 MHz CM4 Schnelle DSPs hatte der geneigte Signalverarbeiter schon lange. Dafuer musste man nun wirklich nicht auf ARM warten. Dedizierte DSPs sind heute allerdings selten, weil als Teil des Gesamtkonzeptes in den SoC gewandert. Sie sind dort auch nicht langsamer geworden. Und wenn man es schafft, seine Signalverarbeitung zu "parallelisieren", kann auch ein Einstiegs-FPGA mit < 10k LEs so einen "GHz-Boliden" leicht an die Wand verarbeiten. Natuerlich nicht mit einem oder mehreren Soft-Core(s). Der ist aber immerhin fuer die Initialisierung mancher Peripherie zumnindest nicht ganz unnuetz. Grundsaetzlich wird der TO aber sein Konzept ueberdenken muessen.
Motopick schrieb: > Was nuetzen die (2x) 120 MHz, wenn das Zwergerl nicht mal in Hardware > 32 bit mit weiteren 32 bit zu einem 64 bit Ergebnis multiplizieren kann? Stimmt, das ist natürlich eine Funktion die tagtäglich überall gebraucht wird.
> Stimmt, das ist natürlich eine Funktion die tagtäglich überall gebraucht > wird. Ja, ebenT. Sogar deutlich oefter als einmal tagtaeglich. Immerhin haben sie wohl einen Barrelshifter.
Bernd H. schrieb: > Gibt es zufällig ein Forenmitglied, dass sich mit dem Einbringen eines > STM32 in einen FPGA auskennt oder gar das bereits gemacht hat? Auch wenn die Suche grad kaputt ist: ich kann dir sicher sagen, dass du hier der erste bist, der danach fragt. > mit dem Einbringen eines STM32 in einen FPGA Das finde ich besonders bei den AD-Wandlern interessant. > Es geht um dauerhaften Ersatz zur Beschleunigung einer MCU-Einheit. Bei welcher Arbeit? Von wie schnell auf wie schnell? Wastl schrieb: > Er meint wohl dass man einen STM32 schnell mal in einem FPGA > emulieren kann. Worauf bezieht sich dieses "schnell"? Ich bin mir zimelich sicher, dass die Implementierung weder schnell klappt noch schnell läuft. Und zudem wird sie auf er Leiterplatte viel teurer sein und viel mehr Strom brauchen. Andreas M. schrieb: > Und wenn das immer noch nicht reicht, dann stellt halt nen anständigen > Softwareentwickler ein Funktioniert erstaunlich oft. Gerade wenn es um µC geht.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Worauf bezieht sich dieses "schnell"? Deine Frage sagt uns dass du meinen Sarkasmus / meine Ironie nicht verstanden hast. Es gibt 32-Bit Cores in FPGAs (siehe Zynq) aber nicht von STM, jedenfalls nicht so bekannt dass ich welche kennen würde. Der TO fragte jedoch nach STM32: Bernd H. schrieb: > Einbringen eines STM32 in einen FPGA
Lothar M. schrieb: > Ich bin mir zimelich sicher ..... dass der TO hier heisse Luft produziert da er sich schon mal micht mehr meldet. Allein die Fragestellung ist schon fast ein Freitags-Thema.
Moin, Wastl schrieb: > Allein die Fragestellung ist schon > fast ein Freitags-Thema. Ach. Und an welchem Tag wird die Frage wohl diskutiert? Uebrigens koennte ich in meinem SDR-FPGA-Projekt noch AM und FM Demodulator und 'nen kleinen Vorverstaerker brauchen, also baut mir mal gschwind einer eine EABC80 als IP-Core? scnr, WK
Andreas M. schrieb: > Oha, hat ARM da sein Lizenzmodell geändert? Schon seit ein paar Jahren - aber glaube nur, wenn man den für Xilinx Produkte in Vivado benutzt :) edit: oh 2018 war das schon. https://www.elektronikpraxis.de/arm-for-fpga-kostenlose-cortex-m-prozessoren-fuer-xilinx-fpgas-a-762575/
:
Bearbeitet durch User
Mampf F. schrieb: > Schon seit ein paar Jahren - aber glaube nur, wenn man den für Xilinx > Produkte in Vivado benutzt :) > edit: oh 2018 war das schon. Danke für die Info. Die werden doch nicht etwa Angst vor Risc-V bekommen haben?
Motopick schrieb: > Was nuetzen die (2x) 120 MHz, wenn das Zwergerl nicht mal in Hardware > 32 bit mit weiteren 32 bit zu einem 64 bit Ergebnis multiplizieren kann? Diese Aussage ist doch ohne Sinn! Wenn ich eine 32x32->64 bit Multiplikation in Hardware gieße, diese aber nur mit 1 MHz läuft, ist diese deutlich langsamer als eine "Software" Version auf dem M0+, die wohl so ca. 26 Taktzyklen braucht Gugst du: https://codereview.stackexchange.com/questions/114393/fast-32x32-bit-multiply-on-arm-m0
Klaus R. schrieb: > Motopick schrieb: >> Was nuetzen die (2x) 120 MHz, wenn das Zwergerl nicht mal in Hardware >> 32 bit mit weiteren 32 bit zu einem 64 bit Ergebnis multiplizieren kann? > > Diese Aussage ist doch ohne Sinn! Wenn ich eine 32x32->64 bit > Multiplikation in Hardware gieße, diese aber nur mit 1 MHz läuft, ist > diese deutlich langsamer als eine "Software" Version auf dem M0+, die > wohl so ca. 26 Taktzyklen braucht > Gugst du: > https://codereview.stackexchange.com/questions/114393/fast-32x32-bit-multiply-on-arm-m0 Deine Anmerkung ist in diesem Kontext ohne Sinn. CPUs/Controller die eine signed 32 bit x 32 bit Multiplikation mit einem 64 bit Ergebnis in einem Takt bewaeltigen, laufen ganz typisch nicht mit 1 MHz. Die ersten Exemplare die das konnten, hatten bereits einen 50 MHz Takt. (TMS32C10) Beim Intel 2920 habe ich jetzt nicht nachgeschaut. Der duerfte aber auch nicht langsamer sein. Und ein ARM M3 kann es ja auch in einem Zyklus. Troedelige 26 Takte sind da eben nur 3. Liga. Das es obendrein noch "troedeligere" M0 gibt, die auch fuer die beschraenkte unsigned Multiplikation noch laenger brauche, findest du ja sicher selbst in dem referenzierten Artikel.
[ ] Du hast meine Aussage verstanden. Unabhängig davon: Viele spielen gerne in der 3. oder gar 4. Liga und sind da genau richtig. Und für manche macht halt nur die Champions League Sinn!
:
Bearbeitet durch User
Klaus R. schrieb: > [ ] Du hast meine Aussage verstanden. Das tut mir ja leid. Kern deiner Aussage wie ich sie mir zusammenreime ist: Ein M0(+) braucht ca. 26 Takte. Abgeleitet daraus: Bei 120 MHz also ca. 217 ns. Ein M3, mal als typischer Vertreter ein STM3F103 bei 72 MHz Takt: 14 ns. Wem das nicht reicht, laesst die Single-Cycle-Multiplizierer eines FPGA antreten. Ein Max10 10M08 hat davon bereits 24 und ein 10M50 schon 144. Die sind schon einzeln noch schneller als so ein STM32F103 und koennten alle parallel zu einem Ergebnis beitragen. Wenn es das Problem hergibt. Aber wenn es jemanden gefaellt nur in der Dorfliga zu spielen dann soll er es tun. Ich benutze auch M0 und M0+ in Form von z.B STM32F030, STM32L053, ... Aber eben nicht zur Signalverarbeitung.
Dergute W. schrieb: > Wieso sollte jemand sowas machen wollen? Weil es so beschlossen wurde :-) Andreas M. schrieb: > Was meinst du mit einbringen? Hineintun(?) -> das FPGA soll und wird noch mehr tun und ist ohnehin vorhanden. Kay-Uwe R. schrieb: > Die Beschleunigung soll ersetzt werden? Nein, etwas falsch gelesen: Der STM soll ZUR Beschleunigung ersetzt werden. Das FPGA kann schneller, haben wir gerechnet. Noch wichtiger: Es können Prozesse, die konkurrieren, auf 2 oder gar 3 Implementierungen verteilt werden. Dabei können jeweils die nicht benötigten Peripherie-Komponenten ausgelassen werden.
Moin, Bernd H. schrieb: > Dergute W. schrieb: >> Wieso sollte jemand sowas machen wollen? > Weil es so beschlossen wurde :-) Also voellige Schnapsidee. So wie meine ECH81 oder EABC80. Nur: ich mein' sowas nicht ernst. Nehmt ein FPGA was schon ein paar ARM-Kerne ab Werk eingebaut hat. Oder wollt ihr den CPU Befehlssatz irgendwie selber erweitern? Mit dem NIOS von Altera gingen mal so Kunststueckchen. Aber ob's sinnvoll ist? Gruss WK
Bernd H. schrieb: > Dergute W. schrieb: >> Wieso sollte jemand sowas machen wollen? > Weil es so beschlossen wurde :-) OMG würde ich schnell die Firma wechseln, wenn es Entscheidungsträger gibt, die soetwas beschließen 😱 Das muss dann jemand sein, der schonmal gehört hat, dass FPGAs schnell sind und sonst keinerlei Ahnung davon hat.
:
Bearbeitet durch User
Dergute W. schrieb: > wollt ihr den CPU Befehlssatz irgendwie selber erweitern? Nein, wieso? Es geht um die direkt Einbringung des Cores zu dessen Ersatz! Wo ist das Verständnisproblem? FPGA werden doch andauernd genutzt, um digitale Logik zu ersetzen und zu kompaktieren. Mampf F. schrieb: > OMG würde ich schnell die Firma wechseln, Wenn man das täte, sobald Entscheider "falsche" Entscheidungen fällen, könnte man jede Woche wechseln. Allerdings: Die Entscheidung kommt nicht wirklich von "uns" sondern vom Kunden und ich finde sie auch nicht falsch: Mampf F. schrieb: > Das muss dann jemand sein, der schonmal gehört hat, Es ist jemand der sicherstellen will, dass eine SW passend zu einer STM-Version, die einmal voll durchgetestet wurde, immer wieder verbaut werden kann, ohne Gefahr zu laufen, dass es den STM nicht mehr gibt, weil in 5 Jahren abgekündigt. Dann muss das gesamte Szenario wiederholt werden, weil eine neue Version andere bugs haben könnte. Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. Solange ist die Lieferzeitgarantie - ist oliv!
Bernd H. schrieb: > ist oliv ah, also überall Kompetenz pur, inclusive der des TE. Keine weiteren Fragen.
Bernd H. schrieb: > ist oliv! OMG! Wenn unsere Landesverteidigung von Leuten mit derartig abstrusen Ideen abhängig ist, dann mal gute Nacht, Marie...
Bernd H. schrieb: > Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. > Solange ist die Lieferzeitgarantie - ist oliv! Das ist ähm naja eine ganz schöne Herausforderung. Also den Kunden kann ich schon verstehen ... Aber das ist halt wahrscheinlich unmöglich, weil niemand die komplette ganze STM32 Peripherie in einem FPGA nachgebaut hat. Damit ist "und zwar sofort" schon überhaupt nicht erfüllbar. Und Peripherie nachbauen ... Naja ... könnte man schon machen. Und nach wie vor ist > es geht um dauerhaften Ersatz zur Beschleunigung einer MCU-Einheit. totaler Blödsinn, weil schneller wird es ziemlich sicher nicht. Ansonsten ja, ist nachvollziehbar, was der Kunde möchte. Macht auch irgendwie Sinn, aber ist halt so nicht umsetzbar. Ein guter Weg wäre ein komplett neues SoC aus IP-Komponenten wie Cortex-M0 (wenn man auf Hardware-Divider und -Multiplier verzichten kann), AXI-Bux, AXI-Peripherie usw zu bauen. Das läuft dann für immer und in jedem (Xilinx^^) FPGA. Alternativ gäbe es sowas wie den Vexriscv, mit dem ich sehr gute Erfahrungen gemacht hab. Der ist gut erweiterbar und deutlich deutlich schneller als der M0. Ist zwar Risc-V, aber dann nimmt man halt einen anderen Compiler. Glaub gabs auch AXI dafür, muss man aber nicht benutzen. Der unterstützt ein paar verschiedene simplere Bus-Systeme. Ist auch ziemlich Herstellerunabhängig ... Läuft auch in einem ice40 wenn es sein muss. Peripherie ist halt wieder der Knackpunkt.
:
Bearbeitet durch User
> dann nimmt man halt einen anderen Compiler
Na du hast vielleicht Vorstellungen.
Das muss ein olivgruener ADA-Compiler sein!
Sonst wird das nuex.
Bernd H. schrieb: > Es ist jemand der sicherstellen will, dass eine SW passend zu einer > STM-Version, die einmal voll durchgetestet wurde, immer wieder verbaut > werden kann, ohne Gefahr zu laufen, dass es den STM nicht mehr gibt, > weil in 5 Jahren abgekündigt. Dann muss das gesamte Szenario wiederholt > werden, weil eine neue Version andere bugs haben könnte. > > Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. > Solange ist die Lieferzeitgarantie - ist oliv! Auch FPGA's werden abgekündigt. Oder der Flash für die Config. Und mit einen FPGA bekommt man weitere Testszenarien an die Backe - in der Luftfahrt bsp. neben DO-178 auch die DO-254. Die Gängige Methoden sich gegen solche Fälle abzusichern sind - den Bedarf für die Gesamte serie spätestens beim "Last time buy" einzukaufen und sich aufs Lager zu legen -Strategien für Obsoloszenzenaustausch zu entwickeln, bspw. das Design in mehrere Teildesigns/Boards zu partitionieren und diese Teildesigns komplett zu qualifizieren. Dann spart man sich den Gesamtumfang des Tests. -ein Upgrade aka Kampfwertsteigerung einzuplanen um dann eine ein neues Los/flight zu designen, fertigen und zu liefern (Re-design) https://www.ihlemann.de/fileadmin/inhalt/presseberichte/pdf/Elektronik_H.14-2015_S.34_Bauteilabkuendigungen.pdf https://aeroimpulse.de/insights/obsoleszenzmanagement/
Bernd H. schrieb: > Gibt es zufällig ein Forenmitglied, dass sich mit dem Einbringen eines > STM32 in einen FPGA auskennt oder gar das bereits gemacht hat? Wirst Du nicht finden, weil es das nicht gibt, bzw. nicht geben kann. STM32 ist eine hardwarespezifische Implementierung eines Cortex-M Cores plus diverser (auch herstellerspezifischer) Peripherie. Da ist allein der Technologiewechsel eine Herausforderung, wenn die typ. Parameter erhalten werden sollen. Bernd H. schrieb: > Es ist jemand der sicherstellen will, dass eine SW passend zu einer > STM-Version, die einmal voll durchgetestet wurde, immer wieder verbaut > werden kann, ohne Gefahr zu laufen, dass es den STM nicht mehr gibt, > weil in 5 Jahren abgekündigt. Das müsste man aber bei einem Wechsel zum FPGA trotzdem komplett neu testen. Da könnte man aber auch direkt ein eigenes IC bauen. Den Core und (vermutlich) die meiste Peripherie kann man ja lizensieren. Bei entsprechenden Stückzahlen kann man aber auch direkt mit STM reden und eine entsprechende Verfügbarkeit sicherstellen. Alles eine Frage der Stückzahlen, bzw. des Preises. Das einzige was nun wirklich nicht geht ist STM32 --> FPGA. Sry. /regards
Bernd H. schrieb: > Es ist jemand der sicherstellen will, dass eine SW passend zu einer > STM-Version, die einmal voll durchgetestet wurde Ihr wollt also gar keinen STM sondern irgend einen Softcore mit Peripherie. Ihr glaubt doch nicht im Ernst, das ST euch den IP für einen STM zur Verfügung stellt. Und selbst wenn, wird der im FPGA nicht ansatzweise so schnell laufen wie in Hardware. Davon das die Analogfunktionen so garnicht umsetzbar sind sprechen wir besser mal nicht. Scheinen ja so einige Leuchten bei euch zu arbeiten. Kleiner Tipp: in der Industrie hat man solche Probleme schon längst gelöst, 20 Jahre Verfügbarkeit sind da völlig normal.
Bernd H. schrieb: > Die Entscheidung kommt nicht wirklich von "uns" sondern vom Kunden und > ich finde sie auch nicht falsch: Ideas are a dime a dozen. > [Aufwand für erneute SW-Verifikation] > Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. Die Idee ist gut, aber dafür ist es spät; Jetzt ist das zu teuer. Das nächste Mal vorher an geeignete FPGA-Firma wenden. > Solange ist die Lieferzeitgarantie - ist oliv! Trotzdem zu teuer und 15 Jahre ist nicht lang.
>> [Aufwand für erneute SW-Verifikation] >> Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. > Die Idee ist gut, aber dafür ist es spät; Jetzt ist das zu teuer. Das > nächste Mal vorher an geeignete FPGA-Firma wenden. Oder architekturunabhängige Software einfordern. Und erst mal festlegen, was "Software" hier konkret bedeudet. Ich hab da den Eiondruck, der Kunde meint mit Software den Quelltext in ADA, während die Entwicklerseite auf das STM/ARM-Cortex binäry fixiert ist. Und der zertifizierenden Stelle prüft aber gegen die Systemspezifikation/-requirements, die in keiner Computersprache vorliegt sondern natursprachlich in eine Datenbank gestopft, die da DOORS heisst. Nicht nur Früher sind auch gerne zur Wahrung der Kompabilität Emulatoren verwendet worden. Da läuft dann auch die SW unverändert aber eben nicht nur die. Siehe bspw. Homecomputer-Soft/Hardware-Emulationen. https://de.wikipedia.org/wiki/Amiga-Emulator#UAE Und wennn nicht ganzer Emulator, dann gestern doch diverse Abstraktion layers im System, mit denen hrampfhaft versucht wird, die Veränderungen der letzten Jahrzehnte einzukapseln. >> Solange ist die Lieferzeitgarantie - ist oliv! > Trotzdem zu teuer und 15 Jahre ist nicht lang. Grundsatz der Projektentwicklung, es sind drei! Kriterien zu erfüllen, nicht nur die Lieferzeit muss stimmen, sondern auch die Qualität und die Kosten/Aufwand (in time, in quality, in budget). Und wenn die Lieferzeit garantiert ist, dann kann man eben nur teil-geprüfte und -entwanzte Pakte schicken. Vielleicht will der Kunde genau solche Zeillieferungen/einen Zwischenstand. So was nennt man heute "Agile Entwicklung".
Klaus K. schrieb: >>> [Aufwand für erneute SW-Verifikation] >>> Die Sw muss unverändert laufen und zwar sofort und auch in 15 Jahren. >> Die Idee ist gut, aber dafür ist es spät; Jetzt ist das zu teuer. Das >> nächste Mal vorher an geeignete FPGA-Firma wenden. > Oder architekturunabhängige Software einfordern. Und erst mal festlegen, > was "Software" hier konkret bedeudet. TO schaut auf das Binary. Das soll sich nicht ändern. Regelmäßig hat jemand eine Idee, wie man Aufwände vom eigenen Teller herunter schiebt, ohne zu wissen oder berücksichtigen zu wollen, welche Aufwände das an anderer Stelle bedeutet. Wenn man es nicht weiß, muss man es diskutieren. Manche Ideen funktionieren ja auch. Bis zur Frage im Internet-Forum hat es gereicht. Vielleicht haben andere (MA oder andere Firmen) schon vorher verneint und man wollte das noch nicht so recht glauben. Der angefragte Ansatz ist schon zielführend, wenn man das vorher einplant bzw. sich zusammen setzt. Aber hinterher zum FPGA "herunter" schieben um die (erneute) Verifikation eines MCU-Projektes komplett zu sparen... kopfschüttel.
>> Oder architekturunabhängige Software einfordern. Und erst mal festlegen, >> was "Software" hier konkret bedeudet. > TO schaut auf das Binary. Das soll sich nicht ändern. Dann Emulator/bit-code-Interpreter. Ob dieser bit-code-Interpreter grad ein STM Softcore nachbau ist oder ein emulator, der auf einen hochgetakteten ARM-Softcore läuft ist Zertifizierungstechnisch gleich. Es muss nachgewiesen werden, das die geforderte Funktion 1:1 übertragen wurde und das Dreck-/Seiteneffekte nicht die Funktion beeinträchtigen. > man es diskutieren. Manche Ideen funktionieren ja auch. Nicht sobald der Leitgedanke/Idee ist, "wir machen es so billig wo möglich", das funktioniert nie. Sieht man schön an der Entstehungsgeschichte der Avionik-Norm DO-254 - weil den Managern die Kosten für die Prüfung der Software-entwicklung nach DO-178 zu teuer war, wollten sie das mit "programmierbare Logic" aka Hardware realisieren lassen, für die vor Einführung der DO-254 keine strikten Nachweiskriterien galten. > Der angefragte Ansatz ist schon zielführend, Geographisch gesehen ist auch "ein Abgrund" ein Ziel. Insofern ist die "Formulierung "zielführend" ziemlich sinnfrei. > wenn man das vorher > einplant bzw. sich zusammen setzt. Aber hinterher zum FPGA "herunter" > schieben um die (erneute) Verifikation eines MCU-Projektes komplett zu > sparen Es ist halt immer der fromme Wunsch, man könnte Sicherheit nachträglich in ein Systen "hineintesten", weil man ja Fehler durch den Test findet und eliminiert. Und "hinein-getestete" Sicherheit ließe sich irgendwie auf ein anderes Systen übertragen. Dabei hat die Erfahrung gezeigt, das man: (a) von Anfang ein System auf Sichherheit auslegen muss (bspw. durch verringerung der Komplexität (KISS-prinzip) und (struktureller) Redundanz) und (b) einen Entwicklungsprozess aufzieht, der von sich aus sicher und nachvollziehbar ist, "design assurance" und (c) muss die Qualität des Produktes und der Entwicklung mess- und nachweisbar sein - "Quality assurance". -------------------------------------------------------------- > dass sich mit dem Einbringen eines > STM32 in einen FPGA auskennt Da hat mal einer angefangen hier fürs Forum allgemein zu beschreiben wie man einen CPU-Core in die Xilinx Toolchain einklinkt: https://www.mikrocontroller.net/articles/Xilinx_Microblaze_MCS_Workflow Allein die Integration des binaries in den config-datastream ist mit vielen nicht klar dokumentierten Schritten verbunden, das es für nicht durch die GUI vorgesehene Cores langwierig wird. Deshalb ist es IMHO bei den mikroblaze als voll unterstützen Core geblieben und die ARM-Softcore Ankündigungen trafen auf wenig praktisches Echo. Wenn man sich da heranwagt, dann verrichtet man sozusagen Pionierarbeit. Beitrag "ARM gibt Cortex-M-Prozessoren für Xilinx FPGAs frei" https://embdev.net/topic/498890 Und dann wäre noch der Schritt vom ARM-Softcore zur STM32 (Peripherals übertragen) Nachstellung zu gehen. Wobei aber auch die Frage wäre, warum man nicht gleich einen SoC wie den Zynq verwendet. Oder macht man das schon, um welchen FPGA-Typ handelt es sich denn hier?
Klaus K. schrieb: >>> Oder architekturunabhängige Software einfordern. Und erst mal festlegen, >>> was "Software" hier konkret bedeudet. >> TO schaut auf das Binary. Das soll sich nicht ändern. > > Dann Emulator/bit-code-Interpreter. Ob dieser bit-code-Interpreter grad > ein STM Softcore nachbau ist oder ein emulator, der auf einen > hochgetakteten ARM-Softcore läuft ist Zertifizierungstechnisch gleich. Plus Nachweis/Beleg, dass sich "Emulator/bit-code-Interpreter" genauso verhält wie Original, mit dem das SW-Binary ursprünglich verifiziert wurde. > Es muss nachgewiesen werden, das die geforderte Funktion 1:1 übertragen > wurde und das Dreck-/Seiteneffekte nicht die Funktion beeinträchtigen. Erneute Verifikation der SW wollte man ja gerade vermeiden. > Allein die Integration des binaries in den config-datastream ist mit > vielen nicht klar dokumentierten Schritten verbunden Kein Problem.
Moin, Bernd H. schrieb: > Gibt es zufällig ein Forenmitglied, dass sich mit dem Einbringen eines > STM32 in einen FPGA auskennt oder gar das bereits gemacht hat? Sagen wir so: Ich habe mal einen Cortex-M0-Core auf einem FPGA laufen lassen und bin sehr bald auf eine andere Architektur umgestiegen. Hat u.a. auch mit dem Interrupt-Handling zu tun. Um Rechnungen zu beschleunigen, gibt es verschiedene Konzepte, dazu musst du etwas mehr Fleisch an den Knochen legen. Die simpelste Streaming-Variante basiert auf Bufferqueue mit Scatter-Gather-DMA und Packetizer-Engines, die nahtlose Datenverarbeitung mit CPU-Intervention wie bei FX3 und Konsorten erlaubt. So werden hier bei mir Datenstroeme von FPGA zu Host durchgepustet. CPU-Befehle aufbohren ist hingegen gar nicht unterhaltseffektiv, aber darauf zielst du wohl auch nicht ab. Dazu kostenlose Beratung zu bekommen ist allerdings relativ unwahrscheinlich und dein Management taete besser daran, dich nicht vorzuschicken.
Mampf F. schrieb: >> Solange ist die Lieferzeitgarantie - ist oliv! > > Das ist ähm naja eine ganz schöne Herausforderung. Das ist mehr oder weniger Standard! Bestimmte Sachen müssen auch mal 10 Jahre irgendwo liegen, um dann binnen weniger Stunden flott gemacht werden zu können. Es muss nur der Treibstoff installiert werden, damit es "fliegt". Andreas M. schrieb: > Ihr wollt also gar keinen STM sondern irgend einen Softcore mit > Peripherie. NNEEIIINN! Es scheint schwer zu sein, mit dem Lesen. Ich schrieb: > STM32 in FPGA Was ist daran so schwer zu verstehen? Dass es ein Erfordernis wird, etwas einmalig anzupassen und das unwirtschaftlich sein könnte, steht außer Frage - ist aber Gegenstand des gegenwärtigen Klärungsprozesses. Daher ist zu erruieren, ob es einen tauglichen Core gibt und welche Erfahrungen es damit gibt. Zur Info an die Gemeinde: In einem speziellen Fall haben wir einen als eigentlich open Source deklarierten Core direkt vom Entwickler nach unseren Vorgaben umbauen lassen und ihn gekauft. Die Version ist dann in einen ASIC gegeben worden. Klaus K. schrieb: >>> Oder architekturunabhängige Software einfordern. Und erst mal festlegen, >>> was "Software" hier konkret bedeudet. >> TO schaut auf das Binary. Das soll sich nicht ändern. Wieder nein. Die Software, die in den STM geladen wird, darf sich natürlich einmal ändern und angepasst werden. Danach muss aber Sense sein! Das ist die Forderung. Wenn das Teil einmal steht, soll es stehen, damit nicht in 5 Jahren wieder ein anderer Entwickler eine SW anpassen muss, weil es einen neuen Prozessor gibt. Die Teile müssen in aus heutiger Sicher unbekannter Menge nachproduziert werden können. Daher FPGA. Für ASIC sind es wahrscheinlich zu wenige.
Bernd H. schrieb: > Die Teile müssen in aus heutiger Sicher unbekannter Menge nachproduziert > werden können. Daher FPGA. Aha. FPGA gibts also mit 15 Jahre Liefergarantie, Controller aber nicht? Wieder was gelernt.
Klaus schrieb: > Aha. FPGA gibts also mit 15 Jahre Liefergarantie, Controller aber nicht? > Wieder was gelernt. ??? 1. FPGAs sind in der Struktur konfigurierbar - Controller nicht. 2. Ein in einem FPGA eingefrorener Controller von 2003 ist in einem FPGA 2030 noch immer der gleiche, läuft mindestens genau so schnell und hat den gleichen Befehlssatz. 3. Mehrere Elektronik-Einheiten unterschiedlicher Controllerfamilien lassen sich mit einem FPGA bauen und damit vereinheitlichen. Es ist damit möglich, ein bereits etabliertes System, das 2 Controller absorbiert hat, so umzuprogrammieren und ohne einen PCB-Neubau weiterzunutzen, dass es auch die neue, 3. Elektronik, die von einer aufgekauften Firma kommt, absorbiert. Dazu muss nur die STM32-FW die dort entwickelt wurde, integriert werden. 4. In einem FPGA lässt sich ein und dasselbe CPU-System mehrfach einbauen, um Redundanz zu erzielen. JETZT! hast du etwas gelernt! Und im Übrigen: Klaus schrieb: > FPGA gibts also mit 15 Jahre Liefergarantie, Ja, Xilinx hat uns für den verwendeten FPGA seinerzeit 20 Jahre Garantie gegeben. Davon sind noch fast die Hälfte übrig. Und selbst wenn das FPGA einmal getauscht werden müsste, so müsste das nur einmal für alle Serien passieren.
Martin S. schrieb: > CPU-Befehle aufbohren ist hingegen gar nicht unterhaltseffektiv, aber > darauf zielst du wohl auch nicht ab. Möglichst nicht. Besagte FA hat aber sehr viel auf STM32-CPUs gemacht und mehrere der Einheiten, meistens Steuersysteme sollen nun adaptiert werden. Es geht dabei nicht nur um die FW sondern auch das gesamte SCstem drum herum, inklusive UNIX-PC und embedded-PC Software, die das Protokoll fährt. Das Timing muss da eingehalten werden. Es braucht in einem Fall z.B. exakt den Faktor 3, den man mit einem FPGA ausreichender Größe und Güte- locker hinbekommt. Die Alternative ist es, den Code und vieles drum herzum zu portieren. Das will aber auch gut überlegt sein, weil das vor 10 Jahren schondurchgeackert wurde, als Xilinx die Power PCs abgelöst hatte und mit den ARMs in den Zynqs ankam. Wenn man das als Soft-Core hat, ist es egal, ob AMD demnächst auf die Idee kommt, die ARMs durch irgendetwas zu ersetzen ... Und wie gesagt: Eine Soft-Core CPU in Verilog bekommt mitsamt fest eingebautem BIOS-Code binnen weniger Tage von einem ASIC-Hersteller in eine simulierbare Netzliste übersetzt und zugeschickt, die dann auf den Analog-Libs des Herstellers basierend das gesamte System abbildet und komplett durchvalidierbar ist. Damit lässt sich alles Gebaute zielsicher rapid in einen neuen ASIC setzen, wenn nötig.
Bernd H. schrieb: > JETZT! hast du etwas gelernt! Jawohl. Nämlich, dass Du immer noch nicht einmal ansatzweise verstanden hast, wie dein Problem sinnvoll lösbar wäre. Du also mit deiner Aufgabe heillos überfordert bist. Und wenn ich dann sowas lese, Bernd H. schrieb: > 4. In einem FPGA lässt sich ein und dasselbe CPU-System mehrfach > einbauen, um Redundanz zu erzielen. dann bin ich mir sicher, dass Du keine Ahnung hast, was Controller leisten können, noch dass Du jemals den Begriff Lockstep gehört hast. Ach und noch etwas habe ich gelernt: Wenn man einen Softcore in ein FPGA integriert, heißt das in deiner Welt wohl > absorbiert
:
Bearbeitet durch User
Bernd H. schrieb: > Möglichst nicht. Besagte FA hat aber sehr viel auf STM32-CPUs gemacht > und mehrere der Einheiten, meistens Steuersysteme sollen nun adaptiert > werden. Es geht dabei nicht nur um die FW sondern auch das gesamte > SCstem drum herum, inklusive UNIX-PC und embedded-PC Software, die das > Protokoll fährt. Das Timing muss da eingehalten werden. Es braucht in > einem Fall z.B. exakt den Faktor 3, den man mit einem FPGA ausreichender > Größe und Güte- locker hinbekommt. > Ich habe nun nicht alle Beitraege hier durchgelesen, aber: Wenn eine ausreichend automatisierte Testbench des ganzen Systems "in the loop" vorliegt, laesst sich das (nach Austausch des CPU-Core) in wenigen Tagen zyklengenau verifizieren und Latenzgarantie geben. Wenn das komplexer als eine Software-Main-loop wird, oder eure Toolchain das nicht kann, steckt typischerweise ein Wurm im Grundgeruest. Deine Argumente pro FPGA sind absolut nachvollziehbar, aber eine Portierung (auf die es so oder so typischerweise hinauslaeuft) wird so oder so draus, und dazu sollten die Hausaufgaben bereits gemacht worden sein. Wenn Ihr in der Liga spielt, einen ASIC anzuwerfen, solltet Ihr auch die Tools haben, um eure timingkritischen Anwendungen in einen Coprozessor zu giessen, damit der Rest der SW-Steuerung architekturunabhaengig wird (BTDT). Und damit ist die Frage immer noch offen, was Ihr genau wissen wollt.
Bernd H. schrieb: > Es scheint schwer zu sein, mit dem Lesen. Ich schrieb: >> STM32 in FPGA > Was ist daran so schwer zu verstehen? >>>> was "Software" hier konkret bedeudet. >>> TO schaut auf das Binary. Das soll sich nicht ändern. > > Wieder nein. Arm Cortex xyz sind CPU-Kerne der Firma Arm. Diese werden verwendet als Softcore, Hardmacro und als dedizierte MCU. STM stellt unter anderem dedizierte MCUs her, unter anderem mit Arm Cortex xyz; mit ganz bestimmter, eigener Peripherie um den CPU-Kern herum. Deshalb funktioniert beispielsweise ein Binary für einen Arm Cortex R52 der Firma STM nicht auf einer MCU mit Arm Cortex R52 der Firma NXP. Bereits seit einigen Beiträgen bestehst Du darauf, dass es ein STM sein muss. Ich nahm an, das SW-Projekt soll bereits jetzt nicht wieder angefasst werden wegen Aufwänden der Verifikation. Unklar ist, warum genau es ein STM32 mit seiner STM-Peripherie (welcher genau?) sein muss. Wenn die Motivation ist, damit die SW-Entwicklungsumgebung exakt genauso beibehalten werden kann, dann ist das noch weniger verhältnismäßig. Martin S. schrieb: > Ich habe nun nicht alle Beitraege hier durchgelesen, aber: Wenn eine > ausreichend automatisierte Testbench des ganzen Systems "in the loop" > vorliegt, laesst sich das (nach Austausch des CPU-Core) in wenigen Tagen > zyklengenau verifizieren und Latenzgarantie geben. Wenn es um einen exakten STM-Nachbau mit dennoch ungefähr gleicher Leistung geht und ggf. noch Lockstep-Redundanz, dann denke bei "zyklengenau" auch an den integrierten Cache, integrierten SRAM und integrierten Flash der MCU. Dann ist die BOM schnell beim Faktor 50 bis 500+ aufgrund des Wechsels von dedizierter MCU auf Softcore im FPGA.
Lars R. schrieb: > und ggf. noch Lockstep-Redundanz, Eigentlich macht man das ja nicht unbedingt zyklengenau, oder? Im Gegenteil: Ich möchte eine Einflussgröße, was auch immer sie ist und wirkt, nicht zeitlich auf den selben Bearbeitungsschritt in allen Prozess-Einheiten wirken haben. Bei einem jüngst entworfenen System war das Bestreben eher, das auseinander zu ziehen und komplementär arbeiten zu lassen. Besonders wegen Störungen auf den Übertragungsstrecken. Inwieweit es bei Prozessorsystemen so oder so gehandhabt wird, weiß ich nicht, aber bei FPGAs ziehen wir Redundanz räumlich und auch zeitlich auseinander. RAM-Zugriffe z.B.
Motopick schrieb: > Das muss ein olivgruener ADA-Compiler sein! Ja, und? Gibt es doch schon seit einem Moment auch für Risc-V: https://www.adacore.com/gnatpro/comparison Die ersten Risc-V sind auch schon im Weltraum aber erst in kleinen Dingen. Die grossen, kritischen Projekte kommen noch dafür muss aber der PolarFire-SoC zuerst qualifiziert sein bzw. der Gaisler GR765 fertig entwickelt werden. Bernd H. schrieb: > 4. In einem FPGA lässt sich ein und dasselbe CPU-System mehrfach > einbauen, um Redundanz zu erzielen. Dazu würde ich gerne mal die FMEA sehen.
Moin, Bernd H. schrieb: > Dergute W. schrieb: >> wollt ihr den CPU Befehlssatz irgendwie selber erweitern? > > Nein, wieso? "Haett' ja koenn' gesei'", sagt da der Unterfranke. > Es geht um die direkt Einbringung des Cores zu dessen Ersatz! Wo ist das > Verständnisproblem? FPGA werden doch andauernd genutzt, um digitale > Logik zu ersetzen und zu kompaktieren. Das Verstaendnisproblem ist ganz einfach: Du kommst mit recht knapp gehaltenen, aber schon erkennbar wirren Vorstellungen hier an. D.h.: Ich weiss dass es eine Schnapsidee ist, aber ob jetzt eher Kirsch-, Zwetschge- oder gar Kartoffelbrand war noch nicht klar. Jetzt, nachdem du dir ein paar weitere Salamischeiben wie zaehe Klabusterbeeren aus der Nase hast ziehen lassen, kann man/ich schon etwas besser abschaetzen, in welche Geschmacksrichtung diese Schnapsidee laufen soll. Bleibt aber wohl erstmal eine Schnapsidee. Sehe anscheinend auch nicht nur ich so... Sorry for no better news. Gruss WK
Projekt hört sich irgendwie spannend an ... Würde ich hauptberuflich Sw- und Hw-Entwicklung machen, würde ich mich da sofort drauf stürzen 🤔 Aber wenn da soviel Geld dahinter ist, dass man sogar ASICs machen kann, gibt es bestimmt auch soviel Geld, um STMicro zu motivieren, einen STM32 nach Wahl für einen FPGA zur Verfügung zu stellen. Odeer zumindest eine Garantie zu kaufen, dass es genau den speziellen STM32 noch 50Jahre gibt^^ Oder STMicro zu motivieren, einen kundenspezifischen ASIC zu produzieren, der für immer nachproduziert werden kann.
:
Bearbeitet durch User
Mampf F. schrieb: > Aber wenn da soviel Geld dahinter ist, dass man sogar ASICs machen kann, > gibt es bestimmt auch soviel Geld, Einen Design in einen eigenen ASIC zu gießen kostet weniger als man glaubt. Da kosten ein paar Schuss mit der Patriot oder Iris-T weitaus mehr. Daher sollte das bei oliv kaum eine Rolle spielen.
Mampf F. (mampf) Benutzerseite >Projekt hört sich irgendwie spannend an ... Würde ich hauptberuflich Sw- >und Hw-Entwicklung machen, würde ich mich da sofort drauf stürzen 🤔 Ja, ein interessantes Projekt. Ich aber lehne die Unterstützung von olivgrünen Projekten aus moralischen Gründen grundsätzlich ab. https://www.youtube.com/watch?v=O-2tpwW0kmU
Mampf F. schrieb: > Projekt hört sich irgendwie spannend an ... Würde ich hauptberuflich Sw- > und Hw-Entwicklung machen, würde ich mich da sofort drauf stürzen 🤔 Wenn etwas nicht passt, dann häufig das Budget. Insofern ist "drauf stürzen" relativ. > Odeer zumindest eine Garantie zu kaufen, dass es genau den speziellen > STM32 noch 50Jahre gibt^^ Eventuell möchte man das ebenso vermeiden wie das Lagern der ICs, weil man die Stückzahlen schwer abschätzen/vorhersehen kann. Daher die Idee mit einem Chip, der mit geringem Aufwand und ohne SW-Änderung gegen einen anderen getauscht werden kann.
Lars R. schrieb: > Eventuell möchte man das ebenso vermeiden wie das Lagern der ICs, weil > man die Stückzahlen schwer abschätzen/vorhersehen kann. Wenn das Projekt mit dem FPGA, Redesign, Software-Anpassungen, Zertifizierungen usw. nachher 100 Mio mehr kostet, kann man entweder sagen: Scheiß drauf, ist eh nur Geld vom Steuerzahler. Oder man kauft für 1 Mio einen Container voller STM32, stellt den auf eine Kaserne, und lässt die nächsten 50 Jahre Soldaten außenherum patrouillieren. Selbst wenn kein einziger der STMs jemals ausfällt, und der Vorrat nie gebraucht wurde, ist das noch ein gutes Geschäft.
:
Bearbeitet durch User
Εrnst B. schrieb: > [...] Ganz so ungünstig ist die Relation über mehrere Projekte hinweg betrachtet nicht. Im Gegenteil. Auch mit vorausschauender Auswahl einer aktuellen MCU wird diese gewählte MCU für manche der zukünftigen Projekte nicht geeignet sein. Das Lagern von Teilen mit hoher garantierter Verfügbarkeit ist für extreme Szenarien nicht trivial. Die Teile werden ja nicht in der Kaserne gelagert (scherzhaft von Dir gemeint). Firmen können pleite gehen und Lagerbestand kann verloren gehen. Manche Geräte/Komponenten werden extrem lang genutzt, aber man weiß nicht, welche von den heute Aktuellen das sein werden. Die Ersatzteilkosten werden exorbitant, aber das Redesign rechnet sich nicht, weil eins ins andere greift und andere Stellen auch betroffen sind. Für kleine Stückzahlen ist es ein Ansatz, die Kosten einmal an den Anfang zu ziehen mittels "Virtualisierung des MCU-Kerns". Die SW wird einmal zertifiziert und läuft dann auf verschiedenen ICs (FPGAs) auf den Taktzyklus genau so wie ursprünglich zertifiziert. Nur verwendet man dafür typischerweise keinen STM32; falls möglich keinen ARM. Ein anderer Aspekt ist, dass manche Abläufe mit komplett unabhängig voneinander laufenden MCUs (nicht Multicore) einfacher verifizierbar sind. In einem FPGA kann man mehrere MCUs abbilden und hat auf dem PCB nur einen IC mit relativ homogener Struktur.
Lars R. schrieb: > Ganz so ungünstig ist die Relation über mehrere Projekte hinweg > betrachtet nicht. Bei Neuentwicklungen mag das Sinn machen. Da kannst du dir 1,2,x Softcores mit in den FPGA packen, und darauf hoffen/vertrauen dass das Ganze in zukünftigen FPGA-Generationen genauso synthetisierbar bleibt. Aber für eine existierende Applikation ganze STM32, incl. aller Erratas und ungenutzter Funktionen, in den FPGA zu verschieben macht halt wenig Sinn. Und manövriert dich in eine Sackgasse, willst du wirklich dann die ganze zukünftige Weiterentwicklung und Neuentwicklungen auf so einer Workaround-Krücke aufsetzen?
Christoph M. schrieb: > Ich aber lehne die Unterstützung von olivgrünen Projekten aus > moralischen Gründen grundsätzlich ab. Wir werden OT, aber dazu muss ich eins loswerden: Deine Haltung in Ehren - und als Berufsanfänger habe ich auch so gedacht, habe sie aber inzwischen geändert: Wenn jeder deutsche Ingenieur so denken würde, dann würde die Waffentechnik, die die Bundeswehr benutzt, nur noch von anderen Ländern entwickelt werden, womit diese dann auch die Preise bestimmen, das KnowHow aufbauen und langfristig haben, uns weiter abhängen und sogar und entscheiden können, was wir bekommen und welche Ausstattung es hat. Das geht gar nicht! Die Verteidiungstechnik ist die allerletzte Branche, bei der man darüber nachdenken darf, sie anderen Ländern zu überlassen! Wir machen das bekanntlich schon mit Medizinprodukten und Pharma und haben uns z.B. von den Chinesen abhängig gemacht! Je mehr man sich freiwillig aus der Knowhowentwicklung herausnimmt, um so mehr macht man sich zum Bittsteller. Andere greifen das erfreut auf und springen da hinein! Da haben nicht wenige ganz und gar keine moralischen Probleme, uns mal zu erpressen und vereinzelt passiert das ja schon! Da lässt ein chinesischer Minister offen durchblicken, dass Deutschland zur Kenntnis nehmen möge, das man im Lande es Lächelns doch so viele tolle Medizinprodukte herstellt , statt sich ständig um Uyguren zu kümmern. So sieht es inzwischen aus! Mit Bezug zum Thema, ist die Softwareentwicklung - auch und vor allem in FPGAs - wo es high-tech Signalverarbeitung geht, ein essenzieller Faktor in Sachen Selbständigkeit und Unabhängigkeit dieses Landes, denn mit Software lässt sich sehr viel anstellen und auch verhindern und es ist gut und richtig, hier in eigene Technologien zu investieren, um die Zügel in der Hand zu behalten! Ich rede jetzt nicht über Details, weise aber auf folgende Fakten hin und überlasse die letztliche Schlussfolgerung dem Leser: - Elektronische Systeme kann man generell mit sehr unterschiedlich gut ausgebauter Software ausstatten, - Oszilloskope z.B. können mit gleicher Hardware dank Softwareupdate sehr viel mehr. Sie sind z.B. schneller und messen mit mehr Rate und erfassen mehr Daten, die eine präzisiere Auswertung erlauben. - Medizingeräte werden für unterschiedliche Länder mit abweichender SW ausgestattet, je nachdem, was dort gefordert ist und man hinliefern muss, aber auch, was man da hinliefern möchte! - Bestimmte Messtechnikprodukte werden z.B. nicht an chinesische Hersteller geliefert, auch nicht an "ähnlich orientierte" Staaten in der östlichen Region - Mit einer guten Bildverarbeitung sehen manche Medizingeräte bei gleicher MRT-, Laser und Kameratechnik deutlich mehr und besser, sie arbeiten und lokalisieren genauer, sie fokussieren schneller und wissen früher, wo was ist Und das Wissen wenden wir jetzt mal bitte auf Laser- und kameragestütze Flugobjekte an und Radare an. Na? Vielleicht ein Hinweis noch: Im Golfkrieg haben die Amis die Flugzeuge der Iraker nur deshalb so leicht vom Himmel geschossen, weil die eigenen Radare etwas weiter gucken konnten und die Raketen losgelassen werden konnten, bevor die anderen was gesehen hatten und reagieren konnten. Ich selbst habe mit exakt diesem Hinweis bereits an Radaren gearbeitet und mittels verbesserter SW - ohne irgendeine Änderung an der HW - die Reichweite um 20% erhöht. Da machen einige Kilometer und Zehntelsekunden sehr viel aus. Und um noch deutlicher zu werden: Am Ende entscheiden Sensorauflösungen in Chips, Beamformingtechniken in der Antenne sowie die Signalverarbeitung darüber, ob die russische Rakete in Kiew einschlägt, oder ob man sie vorher erwischt! Solange es Leute gibt, die eigene Soldaten für etwas Prestige- und Landgewinn zu opfern bereit sind, in andere Länder einmarschieren und uns mit Nuklearraketen drohen, können wir uns hier leider keine so hohen Moralmaßstäbe leisten.
Lars R. schrieb: > In einem FPGA kann man mehrere MCUs abbilden und hat auf dem PCB > nur einen IC mit relativ homogener Struktur. Ich darf aus NDA-Gründen kein konkretes Beispiel bringen, aber genau das wird in der Tat gemacht und man geht noch einen Schritt weiter: Man kann Aufgaben auf unterschiedliche CPU-Kerne verteilen und das System passend reskalieren, wenn in einem neuen Gerät z.B. 9 statt 7 Einheiten verbaut werden, die mit geringerer Rate arbeiten. Statt die 63 Takteinheiten auf dem Prozessor laufen zu lassen, steckt man eben 2 mehr hinein und arbeitet mit 7/9 der Taktfrequenz. So einen Umbau bekommt man kostengünstig nur in einem FPGA hin. Eine Firma für die ich tätig war, hat dazu sogar eine SW, die automatisch die Prozesse verteilt und die Module so zusammenstrickt, dass man 6,8 oder 10 Prozessoren damit versorgen kann. Das ganze passiert zu Designzeit inklusive der Generation aller SW-Interfaces. Man muss sich damit keine Gedanken mehr über die Partitionierung des Systems machen, sondern gibt es einfach vor. Was ich dazu erwähnen kann, ist ein offiziell angebotenes System der Firma Sundance, wo es möglich ist, einmal geschriebene Module zwischen DSPs und FPGAs hin und herzuschieben, je nachdem, wie das eigene System aussieht. Die einen arbeiteten in C, die anderen in VHDL. Die Interfaces wurden auch da automatisch generiert.
:
Bearbeitet durch User
Jürgen S. schrieb: > Wir werden OT, aber dazu muss ich eins loswerden: > [...] 100% signed. /regards
Jürgen S. schrieb: > Statt die 63 Takteinheiten auf > dem Prozessor laufen zu lassen, steckt man eben 2 mehr hinein und > arbeitet mit 7/9 der Taktfrequenz. So einen Umbau würde niemand machen, der noch ganz bei Sinnen ist.
Klaus schrieb: > würde niemand machen, Nur der Klärung wegen, die Aussage bezieht sich darauf, dass mit (den beispielhaften Zahlen) insgesamt 63 ähnliche Aufgaben parallel zu machen sind. Damit erhebt sich die Frage, wie man sie auf wieviele Prozessoren verteilt. Denkbar sind ja die ganzzahligen Teiler, wenn man die Proz. symmetrisch und damit maximal auslasten will. Die 63 könnte man als 64 laufen lassen mit z.B. 4 CPUs und 16x PRozess - wenn das zeitlich geht, oder auch 8x8. Wenn die CPU-Last steigt, braucht man z.B. 30% mehr Leistung. Wie verteilt man ein bestehendes (z.B.) 5 Prozessor-System? Die erste Antwort lautet 7. Legt man aber zugrunde, dass jeder Prozessor 3 Hauptprozesse fährt - z.B. 3 Farben berechnet, dann stimmt das nicht mehr so einfach, denn 15/7 geht erstens nicht und reicht auch nicht. Du wirst das System also auf 4x2x2 umbauen, um die 16 zu erzielen. Bei Farben liegt man da aber auch daneben. Du hast also mehrere Randbedingungen und Lösungen. Wenn man die Struktur per Script umbauen kann, weil man, wie in FPGAs üblich, bei gleicher Wärmelast und Rechenleistung Platz gegen Frequenz austauschen kann, hat man einfach mehr Möglichkeiten, als ein neues PCB mit getauschten Prozessoren. Wenn wir hier eine "Dichte" von 7 auf 9 erhöht wird und das Gesamtszenario gleich bleibt, setzt man einfach die Rate runter und ist fertig. Die Struktur die vorher 63 Aufgaben gepackt hat, wird sie auch jetzt wieder packen. Ist die Struktur von vorn herein dynamisch aufgezogen, daß die Einheiten über Interfaces miteinander reden können, kann man das auch leicht auf die physische Struktur verteilen und z.B. bei einem Wärmeproblem auf weitere CPUs ausbreiten. Wie gesagt, darf ich kein Beispiel aus der Projekthistorie bringen, hatte aber einst so eine Implementierung für Audio-DSP-Einheiten entwickelt: http://www.96khz.org/htm/scalableaudiodsp.htm Mit immer leistungsfähigeren FPGAs wird das auch immer öfters zum Einsatz kommen. Ob da allerdings STM32 oder SOFT-ARMs zur Anwendung kommen, halte ich für fraglich. Eher kleine abgespecte RISC-Einheiten, wo jeweils anwendungsspezifisch das nicht benötigte wegsynthetisiert wird.
Jürgen S. schrieb: > Ob da allerdings STM32 oder SOFT-ARMs zur Anwendung kommen, halte ich > für fraglich Ich nicht. Niemals werden relativ langsame General-Purpose-CPUs massiv parallel eingesetzt, wenn man noch klar bei Verstand ist.
Beitrag #7564219 wurde vom Autor gelöscht.
Klaus schrieb: > Niemals werden relativ langsame General-Purpose-CPUs Am Ende reicht es, nur die für die jeweilige Aufgabe relevanten Teile mit ins FPGA zu packen. Mich hat am ARM-Cortex-M1 die Größe im FPGA gestört: https://developer.arm.com/Processors/Cortex-M1
Klaus schrieb: > Ich nicht. Niemals werden relativ langsame General-Purpose-CPUs massiv > parallel eingesetzt, wenn man noch klar bei Verstand ist. Sag' niemals nie: https://blogs.oracle.com/developers/post/building-the-worlds-largest-raspberry-pi-cluster
Markus F. schrieb: > Klaus schrieb: >> Ich nicht. Niemals werden relativ langsame General-Purpose-CPUs massiv >> parallel eingesetzt, wenn man noch klar bei Verstand ist. > Sag' niemals nie: @Klaus: Nicht alles, was du nicht für möglich und machbar hältst, wurde von Menschen erdacht, die nicht bei Verstand waren.(?) Es gibt viele Lösungen und Gründe für scheinbar ungewöhnliche Ansätze. Im industriellen sind es oftmals Sachzwänge - im Privaten einfach Spass an der Freude - siehe 8-Bit-Computing. Ich kann z.B. Beispiele nennen, wo auch kleine MCUs in FPGAs gesteckt wurden, um einfach die Schaltung zu verkleinern. Wie gesagt, lässt sich damit die Parallelität nutzen, um echtzeitfähig(er) zu werden / bleiben. Ob das jeweils auch die beste Lösung war, hatte ich auch jeweils hinterfragt :-) @Markus: Das sind z.B. solche privaten Lösungen, die natürlich eher Repräsentationsgründe haben, sage ich mal. Wir hatten mit der Uni Bochum seinerzeit mal ein Projekt mit ähnlichem Ansatz, wo wir einen Riesenhaufen UNIX-Rechner vernetzt haben. Das hatte und hat einen realen Nutzen, auch wenn es damals, vor 25 Jahren im Wesentlichen aus Privatinteresse initiiert wurde, um sich am Unix-Weltrekord zu beteiligen, der damals in NRW lief. Über geblieben sind die Leute und die Ideen, die auch nach wie vor dort verfolgt werden, was ich so sehe und höre. Ganz konkret zu deinem link: So ein "Himbeerklumpen" macht natürlich was her, weil die ganze Welt auf Raspberry abfährt, ist aber nicht wirklich ein lohnenswerter Ansatz, weil die Rechenleistung pro cm3 zu gering ist. Außerdem liefert so ein RBP nichts, was ein erwachsener PC nicht auch hat und toppen kann. Die grundsätzliche Problematik bei der Integration von Soft-CPUs in FPGAs besteht halt darin, dass die CPU nur in SW läuft - FPGA-spezifische Techniken also nicht nutzen kann. Umgekehrt ist das FPGA-Universal-Silizium zu langsam und zu stromfressend, was ein Packungsdichteproblem macht. Sobald eine MCU richtig performant arbeiten soll, ist sie im FPGA als Softcore einfach zu verschwenderisch.
Jürgen S. schrieb: > - Oszilloskope z.B. können mit gleicher Hardware dank Softwareupdate > sehr viel mehr. Sie sind z.B. schneller und messen mit mehr Rate und > erfassen mehr Daten, die eine präzisiere Auswertung erlauben. Sehe ich genau andersherum. Mit der Gängelsoftware in der Basisversion und dem vermeintlichen "Upgrade" für die Vollversion bedient man beide Marktsegmente mit der gleichen bzw. derselben Hardware. Die Hardware bestimmt, was möglich ist, die Software, wie weit dies erreicht wird. Die "Drosselkom" hatte seinerzeit die Datenrate auf den Telefonleitungen gekappt, das GPS erhielt einen Störkubus aufgepfropft. Das sind vorsätzliche Maßnahmen, die die Fähigkeit der gegebenen Hardware einschränken. Sicher gibt es auch Entwicklungen, die noch nicht abgeschlossen sind und man vorab Versionen mit reduziert performanter Firmware ausliefert – mit dem Angebot oder zumindest der Aussicht auf ein späteres Update. Wenn ich nur eine CPU oder einen µC im System habe, nutzt es nichts, Multiprozessor-fähige Software hochzuladen. Mehr als 100 % geht nun mal nicht. Im vorliegenden Fall sollte man vorerst abschätzen, inwieweit die Firmware drosselt und was eine Umsetzung z. B. auf Assemblerebene brächte. Ich selbst entwickle seit den 80ern Hard- und Software für Weltraumanwendungen und habe für etliche Instrumente Umsetzungen auf Assemblerebene für zeitkritische Prozesse realisiert. Der Gewinn war jeweils ordentlich bis beträchtlich. Auch die aktuelle Plattform mit den LEON-Prozessoren (übrigens liefen die ersten Space-tauglichen LEONs als Soft-Cores in FPGAs, bevor es die ersten, nicht wesentlich schnelleren ASICs gab) wird mit den verfügbaren (und zugelassenen) GNU-Compilern erheblich gedrosselt. Selbst mit allen verfügbaren Optimierungen erkennt der Compiler mögliche Einsparpotenziale nicht. Der Compiler ist extrem schlecht im Vergleich mit z. B. Microsofts VS, Keil, IAR und wie sie heißen. Es liegen Welten dazwischen, zumindest wenn es "bittig" wird. Die Qualifizierung ist inzwischen auch recht komplex geworden, aber es muss nicht alles Class A oder B sein, wie z. B. Bootloader, denn Applikations-SW lässt sich auch per Telecommand hinterherschicken. Bei so manchem Projekt hat man so noch viele Jahre Zeit, die SW weiterzuentwickeln. (Stimmt nur, solange der Etat das hergibt.)
Jürgen S. schrieb: > So ein "Himbeerklumpen" macht natürlich was her, weil die ganze Welt auf > Raspberry abfährt, ist aber nicht wirklich ein lohnenswerter Ansatz, > weil die Rechenleistung pro cm3 zu gering ist. Außerdem liefert so ein > RBP nichts, was ein erwachsener PC nicht auch hat und toppen kann. Korrekt. Das ist nicht mehr als ein Spielzeug. Mittlerweile gibt's das ähnlich aber auch in professionell. Neben den ARM Multicore-Ansätzen (die man nicht kaufen kann), die z.B. Amazon oder Alibaba bereits in ihren RZs einsetzen, gibt's durchaus auch 256 ARM-Kerne in 2HE für jeden: https://www.primeline-solutions.com/de/server/nach-prozessor/arm-ampere/ Interessant ist hier nicht die Rechenleistung/cm³ sondern die Gesamtenergieeffizienz im Verhältnis zur Rechenleistung (da sieht ARM deutlich besser aus als "erwachsene PCs"). Mit den Dingern kann man - anders als bei x64 - ganze full height Rackreihen ohne spezielle Kühlungs-Klimmzüge betreiben.
Markus F. schrieb: > Klaus schrieb: >> Ich nicht. Niemals werden relativ langsame General-Purpose-CPUs massiv >> parallel eingesetzt, wenn man noch klar bei Verstand ist. > > Sag' niemals nie: > https://blogs.oracle.com/developers/post/building-the-worlds-largest-raspberry-pi-cluster Ein Raspi mit 4x Cortex-A72 @1.5GHz ist aber genau keine > relativ langsame General-Purpose-CPU und mit einem Cortex-M* eines STM32 nicht mal im Ansatz zu vergleichen. Wenn die Rechenleistung des Cortex-M* nicht reicht, wird man halt die nächstgrößere/schnellere Version wählen, oder auf Cortex-R* gehen, aber doch nicht n schwache Kerne parallel rechnen lassen.
:
Bearbeitet durch User
Klaus schrieb: > Bernd H. schrieb: >> 4. In einem FPGA lässt sich ein und dasselbe CPU-System mehrfach >> einbauen, um Redundanz zu erzielen. > > dann bin ich mir sicher, dass Du keine Ahnung hast, was Controller > leisten können, noch dass Du jemals den Begriff Lockstep gehört hast. Ich bin mir sehr wohl bewusst "was Controller leisten können" und habe diverse Mechanismen und Strategien in petto um solchige zu synchronisieren und zu parallelisieren. Es ändert aber nichts an der Tatsache, dass die GEschäftsstrategie so ist, wie sie ist und umgesetzt werden muss. Natürlich kann man in dem Zusammenhang die Technologiplaner und Systemingenieure kritisieren, deren Entscheidungen infragestellen, RASPIS vorschlagen, Bundeswehreinsätze diskutieren und sonst allen Quatsch dahertratschen, wie es einige hier tun ... geht aber alles an der Fragestellung vorbei! Die Fragestellung lautete, ob es hier jemanden gibt, der das zufällig schon durchgeführt hat oder nicht. Die Frage lautete nicht, wer alles eine Meinung hat zu den hier nun abseits diskutierten Fragestellungen.
Bernd H. schrieb: > Die Fragestellung lautete, ob es hier jemanden gibt, der das zufällig > schon durchgeführt hat oder nicht. > > Die Frage lautete nicht, wer alles eine Meinung hat zu den hier nun > abseits diskutierten Fragestellungen. Wenn Du nur Antworten haben willst, die dir genehm sind, dann bist Du hier falsch. Die Antowrt auf die erste Frage wurde indirekt schon zig mal beantwortet. Natürlich hat das noch nie jemand gemacht und auch Du wirst das nie machen (können).
:
Bearbeitet durch User
Bernd H. schrieb: > Es ändert aber nichts an der Tatsache, dass die GEschäftsstrategie so > ist, wie sie ist und umgesetzt werden muss. Natürlich kann man in dem > Zusammenhang die Technologiplaner und Systemingenieure kritisieren, > deren Entscheidungen infragestellen Dem Anschein nach bist Du verantwortlich. Demnach wäre genau das Dein Job (leider lose-lose-Situation). Oder versuchen, nachzuverhandeln. > geht aber alles an der Fragestellung vorbei! In anderen Foren stört mich das weit verbreitete Verhalten (auch) sehr, dass alles mögliche geschrieben und vorgeschlagen wird, nur keine konkrete Antwort auf die gestellte Frage. In diesem Fall hast Du jedoch, wie bereits angemerkt, die Antwort auf exakt Deine Frage schon lang bekommen, und zwar mehrfach. Die weitere Diskussion drehte sich um Aspekte, wie man Dein Anliegen dennoch prinzipiell umsetzen könnte mit etwas anderen Anforderungen. Das waren viele konstruktive Beiträge. Ohne weiteren Input von Dir läuft das in alle möglichen Richtungen und ohne weiteren Input von Dir bleibt es bezüglich Deiner ursprünglichen Frage bei der ursprünglichen Antwort. Wenn Du nur eine einzelne Person suchst für eine ganz bestimmte Aufgabe, dann ist das passende Instrument eine Stellenausschreibung.
Klaus schrieb: > Die Antowrt auf die erste Frage wurde indirekt schon zig mal > beantwortet. Bedingt! Ich habe niemanden sagen hören "ja, habe ich" . Ich habe nur Beiträge von Personen gelesen, die keine Erfahrung haben, aber viel ins Blaue hinein interpretiert haben.
Bernd H. schrieb: > Ich habe niemanden sagen hören "ja, habe ich" . Zumindest diesen Part hast du zu 100% richtig verstanden.
> Ich habe nur > Beiträge von Personen gelesen, die keine Erfahrung haben, aber viel ins > Blaue hinein interpretiert haben. Naja, dieses Unterforum ist eines der wenigen in der überwiegend Personen mit langjähriger Erfahrung (als Entwickler) schreiben, die Person mit wenig praktischer Erfahrung ist meist allein der TO. Da der TO hauptsächlich mit "sloganhaften Allgemeinplätzen" wie "FPGA werden doch andauernd genutzt, um digitale Logik zu ersetzen und zu kompaktieren." argumentiert, drängt sich die Einschätzung auf, da er das Problem aus Sicht eines Projektmanager betrachtet, der lediglich auf die Allokation von Fachkräften im Entwicklungsprozess fokussiert ist, ohne deren Tätigkeit und spezifischen Probleme überhaupt zu kennen. Äußerst bedenklich, besonders im Bereich sicherheitskritischer Systeme, klingt eine Argumentation wie: "Die Alternative ist es, den Code und vieles drum herzum zu portieren. Das will aber auch gut überlegt sein, weil das vor 10 Jahren schondurchgeackert wurde, als Xilinx die Power PCs abgelöst hatte und mit den ARMs in den Zynqs ankam." Das liest sich wie die Rechtfertigung des billigen "Code-klau" um das "Invest" von vor 10+ Jahren unge-testet, un-verifiziert und un-validiert auf grundsätzlich andere Hardware "retten" zu können. Also einfach auf Kosten der Qualität/Sicherheit billig weitermachen wie in den letzten Jahren. Typische Projektmanager-denke, jedenfalls bei denen, die eben vorher nicht 20 Jahre lang (gute) Entwickler waren, bevor sie "Manager" wurden.
Morty S. schrieb: > drängt sich die Einschätzung auf, da er das > Problem aus Sicht eines Projektmanager betrachtet, der lediglich auf die > Allokation von Fachkräften im Entwicklungsprozess fokussiert ist, ohne > deren Tätigkeit und spezifischen Probleme überhaupt zu kennen. So betrachtet ergeben sowohl die initiale Fragestellung als auch das Nicht-Verständnis sämtlicher Antworten ob der Sinnlosigkeit des Vorhabens plötzlich einen Sinn. Zum Glück arbeite ich in einer Firma, in der die Projektmanager auf das Urteilsvermögen und das Know-How ihrer eigenen Entwickler vertrauen, anstatt ohne Ahnung inm nächstbesten Forum nachzufragen.
Moin, Bernd H. schrieb: > Bedingt! Ich habe niemanden sagen hören "ja, habe ich" . Das deckt sich sicher mit Erfahrungen, die man in einem Chirurgenforum machen kann, wenn man dort anfragt: "Ich will mir ein Loch ins Knie bohren und Milch hineingiessen, hat das schon mal jemand gemacht?" Was willst du, selbst als alter "Schlachtross"-Chirurg, der durchaus schon Loecher in Kniee gebohrt hat, auf sowas antworten? scnr, WK
Morty S. schrieb: > "Invest" von vor 10+ Jahren unge-testet, un-verifiziert und un-validiert > auf grundsätzlich andere Hardware "retten" zu können. Also einfach auf > Kosten der Qualität/Sicherheit billig weitermachen Nicht ganz. Die Frage ist, wie erzielt man am Besten eine Langzeitverfügbarkeit unter diversen Bedingungen (safety, zertifizierte Compiler, usw)? Firmen nutzen dafür verschiedene Konzepte. Manche davon wurden hier angesprochen. Gern würde ich mehr mit Softcores (nicht STM32) machen. Aber andere Maßnahmen sind auch für MIL/Aero sehr effizient. Dazu kommt: MCU-Entwicklung bleibt nicht stehen. Automotive-MCU mit 10 Kernen und 20MByte SRAM kostet 130 EUR.
Morty S. schrieb: > Naja, ... sehr viel Philosphie und Mutmaßung. Wahnsinn, was in machen Köpfen so abgeht. Auch das hier passt dazu: Klaus schrieb: > ob der Sinnlosigkeit des Vorhabens plötzlich einen Sinn. Nein, der Sinn ist, eine bereits vollständig durchvalidierte, getestete und in den Produkten laufende Software möglichst unverändert konservieren zu können, indem man eine HW baut, die das leistet. Ein Grund ist eben der Portierungsaufwand. Da steckt nicht nur Validierung dahinter, sondern auch die Nutzung zertifizierter Libraries von Zulieferern. Das muss auch alles wieder eingephast werden.
Bernd H. schrieb: > Nein, der Sinn ist, eine bereits vollständig durchvalidierte, getestete > und in den Produkten laufende Software möglichst unverändert > konservieren zu können, indem man eine HW baut, die das leistet. Das haben wir schon verstanden. Ist ja dann egal, dass die Entwicklung der Hardware, die das leistet, eine zigfaches kostet und die SW trotzdem neu validiert werden muss, weil sie ja auf anderer Hardware läuft.
Klaus schrieb: > Ist ja dann egal, dass die Entwicklung der Hardware, die das leistet, > eine zigfaches kostet und die SW trotzdem neu validiert werden muss, > weil sie ja auf anderer Hardware läuft. wieso sollte das mehr kosten, als einen neuen Prozessor einzubauen? ?? Und sie muss eben nicht neu validiert werden. Sie muss nur getestet werden. Und das einmal.
Bernd schrieb: > wieso sollte das mehr kosten, als einen neuen Prozessor einzubauen? ?? Weil es keinen STM32 in einem FPGA gibt und ST da auch keinen portieren wird, ganz abgesehen von analoger Peripherie, die sich sowieo kaum sinnvoll abbilden lässt. Darüber hinaus: > Es geht um dauerhaften > Ersatz zur Beschleunigung einer MCU-Einheit. Ein Softcore in einem FPGA wird niemals schneller sein als ein dedizierter Controller, sondern ganz im Gegenteil. Wurde in diesem Thread alles schon zigfach bemerkt, und alle haben's verstanden, nur einer nicht. Aber wenn Du dich hier trotzdem weiter ins Knie bohren willst - es hält dich keiner ab.
:
Bearbeitet durch User
Bernd schrieb: > der Sinn ist, eine bereits vollständig durchvalidierte, getestete > und in den Produkten laufende Software möglichst unverändert > konservieren zu können, indem man eine HW baut, die das leistet. Und für diese Hardware nimmt man dann Komponenten, die dazu geeignet sind. Zum Beispiel einen Controller, dessen Lieferbarkeit seitens des Herstellers garantiert wird. Eigentlich ganz einfach.
:
Bearbeitet durch User
Bernd schrieb: > Klaus schrieb: >> Ist ja dann egal, dass die Entwicklung der Hardware, die das leistet, >> eine zigfaches kostet und die SW trotzdem neu validiert werden muss, >> weil sie ja auf anderer Hardware läuft. > > wieso sollte das mehr kosten, als einen neuen Prozessor einzubauen? ?? Weil der "neue Prozessor", bzw. der Nachbau ebenfalls zu zertifizieren ist. So etwas wird nicht her verschenkt. Weil Du nicht nur einen "neuen Prozessor" auf der FPGA-Architektur zertifizieren musst, sondern sogar, dass sich der "neue Prozessor" exakt genau so verhält, wie der Bisherige. SW und Libaries sind für den Bisherigen zertifiziert und nicht für einen Nachbau, der sich nur in 99.99% der Fälle genauso verhält wie das Original. Man denke nur an Bus-Multiplexer, mehrere Busmaster/DMA, CDCs, IRQs, IOs, unterschiedliche Taktfrequenzen. Ursprünglich wurde das Projekt ja nicht auf eine saubere Trennung ausgelegt. Weil Peripherie, die zur Laufzeit konfigurierbar ist (MCU), wesentlich aufwendiger ist als Peripherie, die zur Designzeit konfiguriert wird (typisches FPGA-Projekt). Weil die Zertifizierung konfigurierbarer Peripherie noch einmal eine andere Dimension hat. Deshalb gibt es Zertifizierung auch nicht für jede MCU oder für jede MCU-Peripherie-Komponente. Weil bis heute on-chip SRAM und on-chip Flash in den Größenordnungen, die MCUs mitbringen, in FPGAs Mangelware sind. Weil analoge Peripherie, wie von anderen erwähnt. Übrigens haben wir nicht nur langjährige Entwickler im Unterforum, sondern auch einige, die offensichtlich mehrfach Projektverantwortung übernommen haben. > Und sie muss eben nicht neu validiert werden. Sie muss nur getestet > werden. Und das einmal. Ich interpretiere ins Blaue hinein: Wenn die CPU-Performance-Anforderungen überschaubar und die Zertifizierungsaufwände wirklich! hoch sind, dann empfehle ich für Deine Zielsetzung, das SW-Projekt ganz wegzulassen (ernst gemeint). Was nicht da ist, das macht keinen Stress.
Bernd schrieb: > Und sie muss eben nicht neu validiert werden. Sie muss nur getestet > werden. Und das einmal. "Test" ist eine Worthülse, was hier nachgewiesen werden muss ist Äquivalenz. Und das nicht erst wenn die Geschäftsführung nachfragt, sondern als "proof of concept" sollte schon der Ideengeber das von sich aus vorführbar haben. Also, wie sieht die Umgebung für die Überprüfung des gleichen Verhaltens zwischen der "diskreten" und der FPGA-Integrierten Lösung aus?: Die Pins der µC-Variante auf freie Pins des FPGA it Fädeldraht gelegt und dort einen Vergleicher laufen lassen, der Abweichungen mit Zeitstempel an einen Steuerrechner schiebt? Welche Testcases und wieviele müssen für einen Äquivalenzcheck aufgestellt werden? Oder genügt die Abarbeitung eines "klassischer" Verifikationsplan wie aus der funktionalen Verifikation bekannt? Bei Soft-Cores ist Simulation mandatory, eine Daumenregel besagt ca. 1 Test-Case in der Simulation pro 10 Zeilen VHDL/Verilog-Code. Wer stellt diese cases auf, wer programmiert die Simulation/Verification? Hat unter den "Betroffenen" einer Erfahrung mit OSVVM? Und wie gedenkt man mit den Parametern umzugehen, bei denen man keine Equivalence zwischen den diskreten und dem integrierten Controller nachweisen kann? : * Das wäre neben dem Stromverbrauch das Gehäuse. Im angesprochenen Bereich der defence-Elektronik wird gern das Gehäuse pass genau auf die elektronik gefräst, das wäre dann auch neu zu gestalten. * Die Zeit zwischen PowerUp und "system ready" ist bei FPGA's oft ein mehrfaches gegenüber einer diskreten Lösung. Klar kann man da Zeit mit einen "strafferen" Boot-Code sparen, aber der Code soll ja nicht verändert werden. * Signal integrity ist auch eine Kategorien in der es eigentlich immer Unterschiede zwischen FPGA- und Controller-GPIO's gibt. Das fängt schon bei Logik-pegeln an, moderne FPGA's unterstützen gerne schon alles über 2V5 nur über Levelshifter, während bei STM32 auch 5V tolerante IO zu finden sind. Aufmerksamkeit sollte man da besonders dem IRQ-Eingang widmen, da blockt ein diskreter Controller schon wegen seinem "trägen" Siliziums kurze Stör-Nadel-Impulse ab, die ein ohne besondere Spezifikation programmierter FPGA-Interruptcontroller passieren lässt ... * https://www.design-reuse.com/articles/51622/understanding-logic-equivalence-check-lec-flow-and-its-challenges-and-proposed-solution.html * https://www.design-reuse.com/articles/36332/pitfalls-for-logical-equivalence-check.html * https://www.synopsys.com/glossary/what-is-equivalence-checking.html https://www.doulos.com/knowhow/vhdl/the-open-source-vhdl-verification-methodology-osvvm/
Morty S. schrieb: > [ganz viel] Theorie, weil niemals ein STM32 in ein FPGA portiert werden wird, und sich dann auch noch nur grob ähnlich verhalten wird wie sein reales uC-Vorbild.
> Morty S. schrieb: >> [ganz viel] > > Theorie, weil niemals ein STM32 in ein FPGA portiert werden wird, Nix Theorie und auch nix STM32 spezifisches. Wer sich einen Überblick über die ganz praktischen Probleme bei der Portierung von diskreter Logic (Prozessor, Custom-Chips) vertraut machen will, beteiligt sich an Retrocomputing-projekten wie * Minimig https://www.minimig.ca/ * https://www.computerbase.de/forum/threads/der-mister-das-groesste-fpga-retro-projekt-derzeit.2045949/ * https://www.heise.de/news/Retro-Computing-6502-mit-100-MHz-6223820.html > ... sehr viel Philosphie und Mutmaßung. Nö, jahrelange Erfahrung > Wahnsinn, was in machen Köpfen > so abgeht. Eben, wie wärs wenn du endlich mal selbst und tatkräftig Dein Projekt realisierst anstatt weiterhin darauf zu warten, das Dir eine fertige Lösung mit Schleife drum unter den Weihnachtsbaum geschoben wird?! Wenn man mal hemdsärmlig pro Beitrag 0.1h und einen Stundensatz für einen embedded Entwikler v. 100€/h ansetzt, sind dem TO hier Tipps im Gegenwert von ca. 800€ geschenkt wurden. Mach was draus, genügend Starthilfe um Dir selbst zu helfen haste ja hier, durch dein Studium und deine Berufspraxis genug bekommen. Oder ist der TO bereits ein Opfer des Peter-Prinzips geworden ?!! https://de.wikipedia.org/wiki/Peter-Prinzip
Kay-Uwe R. schrieb: > Sie sind z.B. schneller und messen mit mehr Rate und >> erfassen mehr Daten, die eine präzisiere Auswertung erlauben. > Sehe ich genau andersherum. Mit der Gängelsoftware in der Basisversion > und dem vermeintlichen "Upgrade" für die Vollversion bedient man beide > Marktsegmente mit der gleichen bzw. derselben Hardware. Du siehst das Thema damit aber nicht "anders", sondern nur von der anderen Seite :-) Ja, die Oszilloskope-Software-Strategie hat auch die Komponente, des vorab aufgespielten downgrades aber um die ging es mir nicht. Man kann durchaus mit SV aus Messtechnik mehr rausholen und es gibt auch Beispiele im OSC-Bereich, wo die HW gehackt und verbessert wurde, nebst dem Umstand, dass die Entwickler das selber nochmal besser hinbekommen, wenn sie die Zeit bekommen :-) Gerade in Sachen Offset- und Temperaturdrift und deren Kompensation in SW kann man viel machen.
Morty S. schrieb: > Welche Testcases und wieviele müssen für einen Äquivalenzcheck > aufgestellt werden? DAs ist eben alles schon da , weil für die CPU-Version gemacht. Eines der vielen Pakete, die man übernehmen könnte.
Bernd schrieb: > DAs ist eben alles schon da , weil für die CPU-Version gemacht. Eines > der vielen Pakete, die man übernehmen könnte. Also für eine CPU-Version gemacht, die es gar nicht gibt und die es auch nie geben wird. Du hast echt viel verstanden und dazugelernt im letzten Monat. Nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.