Hi Leute, mache gerade meine ersten Schritte mit FPGA. Muss das so kompliziert sein kann man die Dinger nicht mit irgend einer Hochsprache programmieren? Bitte um Antwort
wirst du gezwungen? wenn nicht, lass es doch einfach bleiben und verschone dieses Forum...
Lisa Löwenschwanz schrieb: > Muss das so kompliziert > sein kann man die Dinger nicht mit irgend einer Hochsprache > programmieren? Ja
Beitrag #5084401 wurde von einem Moderator gelöscht.
Björn L. schrieb im Beitrag #5084401: > Ihr seit mir Experten. VHDL geht gar nicht viel zu > unübersichtlich. Da > bleib ich doch besser bei Assembler und DSPs. Dann schau dir mal ABEL an, das wird aber nur noch wenig unterstützt, viel zu übersichtlich. https://en.wikipedia.org/wiki/Advanced_Boolean_Expression_Language#/media/File:ABEL_HDL_example_SN74162.png
Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA von programmieren sprechen? :D
Dussel schrieb: > Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA > von programmieren sprechen? :D Trolle ja!
@ Lisa Löwenschwanz (Gast) >mache gerade meine ersten Schritte mit FPGA. Muss das so kompliziert >sein kann man die Dinger nicht mit irgend einer Hochsprache >programmieren? >Bitte um Antwort Such dir ein anderes Mädchenspielzeug und toll dich.
Dussel schrieb: > Da das ja schon offensichtlich eine Trollfrage ist: Kann man bei FPGA > von programmieren sprechen? :D Da sie das Wort "feldprogrammierbar" im Namen haben, sicher. Warum nicht?
Dussel schrieb: > Da das ja schon offensichtlich eine Trollfrage ist: > Kann man bei FPGA von programmieren sprechen? :D Sicher kann man. Man kann auch bei Heißluftballonen von "fliegen" sprechen. Die Allermeisten würden zustimmen. Björn und Lisa: bitte nur 1 Namen pro Thread. Steht so in den Nutzungsbedingungen
Heissluftbalone "schweben", wie jeder weiß und die Ballonfizzis nennen es "fahren", weil sie sich für wichtig halten und zu der Sorte gehören, die glauben, sie wären was Besseres und werden für schlauer gehalten, wenn sie sich eine eigenen Terminologie zulegen. Da solcherlei Treiben aber schon durch die Machenschaften der Jäger und ihrer Spezialsprache in der Bevölkerung lächerlich geworden ist und nicht mehr zieht, muss man davon abraten. Ohne Gefühlsduselei kann man bei elektronischen Bausteinen, die eine Einstellmöglichkeit besitzen, problemlos von PROGRAMMIEREN reden. Da FPGAs eine Reihe von Freiheitsgraden haben, werden sie ganz sicher und mit grösstmöglicher Inbrunst von mir programmier!
Sprachliche Feinheiten, Differenzierungen und exakte Ausdrucksweise sind wohl nicht dein Freund? Dann "programmiere" auch weiterhin FPGA(s).
Mein Beispiel ist ja die Waschmaschine. So eine ganz alte noch ohne Software drinnen. Die hat auch Waschprogramme die dann abgearbeitet werden. Da drehen sich langsam irgendwelche Rädchen. Und ganz am Anfang stellt man ein paar Schalter ein ind legt dann fest was danach passiert, man nennt das Programmieren. Man muss das aber unterscheiden vom Programmieren im Sinne von Software schreiben. Ene HDL schreiben ist kein Programmieren, es ist eben das Beschreiben von Hardware, wenn man das Ergebnis davon aber ins FPGA schiebt dann programmiert man es im Sinne von festlegen was das danach tut. Eigentlich ist aber natürlich auch ein FPGA ein ASIC. Wobei die Anwendung hier eben die Flexibilität ist. Einmal gefertigt verändert sich der Aufbau im FPGA nichtmehr, egal mit welcher Konfiguration, es verhält sich nur anders. Man beschreibt so zwar mit einer HDL Hardware, aber die wird nicht als Hardware gebaut oder erzeugt, sondern nur auf die schon im FPGA vorhandene Hardware abgebildet.
:
Bearbeitet durch User
Lisa Löwenschwanz schrieb: > mache gerade meine ersten Schritte mit FPGA. Muss das so kompliziert > sein kann man die Dinger nicht mit irgend einer Hochsprache > programmieren? > Bitte um Antwort Kann man die Dinger auch irgendwie anders programmieren als in einer Hochsprache? xD Im Ernst - VHDL, Verilog oder SystemC* finde ich schon ziemlich hochsprachig. Was soll denn danach noch folgen? Eine JVM, oder gar ein ganzes OS in HW? Hmm, es gibt ja durchaus auch FPGAs die einen PowerPC-Core oder sowas integriert haben, aber wirklich durchgesetzt haben die sich nicht. Macht ja auch nur bedingt Sinn. FPGAs und CPUs sind halt zwei unterschiedliche Dinge, haben ihre ganz einen Aufgabenbereiche, und sind eben auch unterschiedlich anzusteuern. Je mehr man sich an eine bequeme Hochsprache annähern möchte desto weniger Sinn macht es einen FPGA zu verbauen. Muss man halt abwägen. Aber der Lohn für die Mühe ist dann eben auch die Freisetzung ungeahnter Resourcen. :) * SystemC habe ich damals an der Uni gelernt. Ist auch ganz interessant, obgleich es in der Industrie eigentlich gar keine Bedeutung hat. Wer dennoch mal reinschnuppern möchte kann in diesem "Kurs" einen Eindruck davon bekommen: https://www.youtube.com/watch?v=NCFxBGLB5xs&list=PLcvQHr8v8MQLj9tCYyOw44X1PLisEsX-J
Besucher schrieb: > Hmm, es gibt ja durchaus auch FPGAs die einen > PowerPC-Core oder sowas integriert haben, aber wirklich durchgesetzt > haben die sich nicht. Doch klar, bei Altera/Intel die ganzen SoC Chips und bei Xilinx die Zynq Reihe. Und naja, wenn man die Hradware beschreibt programmiert man eben nicht. Ausser man bezeichnet das schreiben von Code schon als Programmieren. Man kann in einer HDL einzelne Gatter beschreiben, aber eben auch abstraktere Dinge die die Software dann selber aus einfacheren Bauteinen zusammensetzt. Hochsprachen überlassen das dann nur der Software die passende Hardware zu beschreiben.
:
Bearbeitet durch User
Komplexität entsteht weil der Mensch seine Fähigkeiten immer weiter entwickelt. Vieles wird mit der Zeit durch Verbesserung und bessere Konzepte einfacher. Aber es wird immer komplizierte und schwierige Tätigkeiten geben, weil es immer Menschen geben wird die nicht nur das tun was einfach ist. Und mit der Zeit werden schwierige Aufgaben irgendwann einfacher. Vielleicht braucht der eine oder andere auch ein gewissen Respekt und Einsicht. Viele Werke und Tätigkeiten sind das Ergebnis disziplinierter Bemühungen und einer langen Lernphase. Entweder man ist bereit die notwendige Zeit und Energie zu investieren oder man sucht sich etwas anderes.
Klar geht das. Mit MATLAB Simulink und dem DSP Builder Blockset z.B. Damit lässt sich das FPGA-Programm schön grafisch modellieren.
Borislav B. schrieb: > Damit lässt sich das FPGA-Programm schön *grafisch modellieren* Hier gehts es aber darum, FPGAs zu programmieren. Und das geht mit VHDL erst, wenn aufgrund steigender Nachfrage der Nachfolger VHPL(*) freigegeben und genormt ist. Und auch Verilog muss erst mal den Schritt aus der HDL Ecke in die HPL(*) Liga schaffen. (*) HPL = Hardware Programming Language
klar kann man ein FPGA programmieren: Man konfiguriert sich einen Controller Core da hinein (z.B. NIOS bei Altera/Intel oder MicroBlaze bei Xilinx). Dann lässt sich das sogar in gewöhnlichem ANSI-C programmieren! ;-)
also echt schrieb: > wirst du gezwungen? wenn nicht, lass es doch einfach bleiben und > verschone dieses Forum... Solche Kommentare sollten dieses Forum verschonen!
Hört das eigentlich nie auf, das Wort "Programmieren" ständig nur den Hochsprachen zuzuordnen? Ich antworte auf solches Gemetzel inzwischen nur noch mit einer Phrase: "FPGA" = field PROGRAMMABLE gate array. Frrtig! Bedeutet das Wort "programmable" im Deutschen "Konfigurierbar"? Die Amerikaner und Engländer sprechen auch von "Programming", wenn sie von der Erstellung der Software (Verilog) fürs FPGA reden. Die Niederländer tun das auch und auch von der Franzosen und Italienern höre Ich nichts anderes. Warum sollte das in Deutschland nicht so heissen? Dass VHDL, formell "Description" beinhaltet, widerspricht dem nicht. Ein Simulink-Model ist auch eine Beschreibung und dennoch wird das Simulink durch diese Software "programmiert". Mitunter wird dann daraus dann ein FPGA programmiert.
Besucher schrieb: > ann man die Dinger auch irgendwie anders programmieren als in einer > Hochsprache? xD Ja, du kannst mit dem FPGA-Editor nach wie vor Verbindungen ziehen, eine Netzliste vorgeben und Gleichungen verwenden, wenn Du magst.
Es gäbe auch noch MyHDL (http://www.myhdl.org/start/overview.html), damit soll man FPGAs mit Hilfe von Python "programmieren" können... Wie ich es verstanden habe definiert man mit der Python lib ein bestimmtes Verhalten und das Tool wandelt es dann in VHDL oder Verilog um.
So ist es. Auch deshalb wird ein FPGA programmiert. Fertig! Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen: Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint nur ein Problem für abstrakt denkende Heinis.
Meister E. schrieb: > Auch deshalb wird ein FPGA programmiert. Jawoll. Mit VHPL! Ich habe übrigens kein Problem damit, ein FPGA zu "programmieren". Das Problem haben die, die meinen, ein FPGA genauso und mit der selben Denkweise wie einen Mikrocontroller "programmieren" zu können. Ist ja auch das selbe Wort, dann muss es auch die selbe Vorgehensweise sein. Logisch.
:
Bearbeitet durch Moderator
Ja, ich suche bei den 'programmable resistor' auch immer nach dem JTAG-Anschluss: https://www.ebay.com/sch/items/?_nkw=programmable+resistor
Markus F. schrieb: > "Ach, Sie sind Programmierer?" > "Nö, ich bin nur Beschreiber." Ich bin Hardwareentwickler und setze auch FPGA ein.
Jan B. schrieb: > Es gäbe auch noch MyHDL > (http://www.myhdl.org/start/overview.html), > damit soll man FPGAs mit Hilfe von Python "programmieren" können... Wie > ich es verstanden habe definiert man mit der Python lib ein bestimmtes > Verhalten und das Tool wandelt es dann in VHDL oder Verilog um. Ist aber auf dem MyHDL-Level nicht gross anders als eine 'Beschreibung' der HW wie in VHDL/Verilog. Nur viel weniger schwerfällig und im Testbenching/Modelling an vorderster Front und man kann auf höheren Leveln viel elegantere und robuste HLS machen. Wenn ich ganz spitzfindig tun will, abgesehen von diversen Threads hier zum Thema "Was ist der Unterschied von Programmiersprache zu Beschreibungssprache" (VHDL ist eine Programmiersprache, aufgepasst): Wenn man erst mal ein digitales Design anschmeisst, muss man sich (Design!) um eine brauchbare formale Beschreibung kümmern, d.h. das Subset der Programmiersprache nutzen, was sinnvoll in Hardware umsetzbar ist. Der Schritt, bestehenden Logikelementen per Design Seele einzuhauchen wäre wiederum ein Programmieren. Also wenn ich mittels einer Turing-vollständigen Sprache beschreibe, was existierende Vielzweck-Primitiven tun sollen, ist es rein technisch gesehen 'Programmieren'. Wenn ich das Ding in einen ASIC giessen will, ist es aber wieder ein pures Design. Und damit ist VHDL explizit keine wirkliche Beschreibungssprache, da ein Designregeln-Schema auf der HDL-Ebene fehlt (wie in IP-XACT) oder nur schwierig umsetzbar ist. Der Coder (ich sag jetzt mal nicht Programmierer) muss einiges Wissen erwerben, welches Konstrukt vom Tool in was umgesetzt wird. Erinnert irgendwie an den Welle-Teilchen-Dualismus, wo sich vor Jahren zwei (gleich gute) Physikerlager auf die Köppe gegeben haben. Vielleicht wäre es konsequenter gewesen, man hätte das 'D' in VHDL mit Design bezeichnet.
Das ist ein interessanter Interpretationsansatz. Nicht unbedingt einer, dem ich zu 100% folgen kann, aber einer der zweifelsfrei zu respektieren ist. Turing, wer war das noch gleich?
Meister E. schrieb: > Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen: > Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint > nur ein Problem für abstrakt denkende Heinis. Ich habe auch schon bei der Arbeit mit anderen FPGA-Entwicklern gesprochen und da war auch meistens (oder immer) von programmieren die Rede. Das ist wie die Schraubenzieher-Schraubendreher-Diskussion. Wer Ahnung hat, weiß, dass es beide Begriffe gibt und benutzt den ihm lieberen, andere versuchen sich halt durch das Kennen des 'richtigen' Begriffs zu profilieren. Im Anfängerumfeld hat meiner Meinung nach Lothar aber Recht. Bei Anfängern kann es schon sinnvoll sein, ihnen klarzumachen, dass es kein sequentielles Programm erstellt wird.
Meister E. schrieb: > So ist es. Auch deshalb wird ein FPGA programmiert. Fertig! > > Ich habe das überigens auch schon im Kollegenkreis mehrfach besprochen: > Kein Mensch regt sich darüber auf, von Programmieren zu reden. Scheint > nur ein Problem für abstrakt denkende Heinis. Naja, wer ein Fahrzeug führen kann, kann noch kein Flugzeug führen, obwohl beides *"führer" sind. Und deshalb kann ein Computer-Programmierer auch nicht notwendigerweise ein FPGA programmieren. Das kann man nicht oft genug betonen indem darauf hinweist das ein Flugzeug-führer fliegt und der Wagen-führer fährt. Nicht das ein Mantafahrer glaubt, Pedal ist Pedal und Steuerhorn ist auch nur ein halbes Lenkrad und fliegen kommt vom "schnell fahren" , denn abheben tut die Kiste von ganz alleine wenn der Speed stimmt ...
Auf FPGAs läuft doch in der Regel sogar in C programmierter Code. Ein FPGA kann alles Mögliche sein: - dummer Pegelwandler - Prozessor (mit C-Programmierten Programmen) - hochkomplexer DSP - bester Freund - ... Eigentlich gibt es doch nur Hardware, denn die Software ist einfach nur eine Abstraktionsebene - ein Konzept. Real ist nur die stumpfe Materie und deren Anordnung und der Fluss der Energie.
Wenn man euch so liest, muss man sich fragen, ob ihr je irgendwas Reales programmiert habt. Unter normale Leuten im Job, wird so eine Diskussion gar nicht geführt. Wenn man so spitzfindig wäre, müsste man wohl auch behaupten, dass es keine Mittagspause gibt, weil die nicht mitten am Tag ist und das 10-Uhr-Frühstück keines ist, weil 10.00 nicht mehr "früh" ist.
Beitrag #5114898 wurde von einem Moderator gelöscht.
Versoffener FPGA-Programmierer-Philosoph schrieb im Beitrag #5114808: > Auf FPGAs läuft doch in der Regel sogar in C programmierter Code. Meinst Du jetzt echten C in einem Core oder umgesetzten C in Form von VHDL aus Simulink?
Markus W. schrieb: > Versoffener FPGA-Programmierer-Philosoph schrieb im Beitrag #5114808: >> Auf FPGAs läuft doch in der Regel sogar in C programmierter Code. > Meinst Du jetzt echten C in einem Core oder umgesetzten C in Form von > VHDL aus Simulink? Ist das nicht sogar egal? Wenn ich im FPGA nur Dinge verwende die nicht von einem Speicherinhalt abhängen, dann wäre da ein Unterschied, aber wie ist was wenn man z. B. eine FSM einbaut, dann verwendet man schon Speicher. Sprich das FPGA verhält sich unterschiedlich je nachdem was in einem Speicher steht. Bei einer CPU im FPGA mit Programm liegt das Programm auch in einem Speicher und das FPGA macht was anderes je nachdem was da gerade im Speicher steht. Ich meine, wenn man Dir zwei Konfigurationsdateien gibt, eine mit CPU und Programm drinnen, die andere ohne, kannst du dann sagen welche welche ist? Die konfigurieren beide das FPGA und das verhält sich entsprechend, auch mit CPU und Programm, das ist am Ende auch Hardware, die Bits vom Programm sind genauso im FPGA gelandet wie die Bits einer FSM und bestimmen das Verhalten. Vielleicht sollte man Im FPGA unterscheiden und sagen hier, der Teil mit den LUTs, das ist konfigurierbar (natürlich auch ASIC, aber macht dass es sich anfühlt als sei es kein ASIC), aber das BRAM, die DSP Slices, ... das ist eben feste Hardware wie man sie auch in einer CPU finden könnte.
:
Bearbeitet durch User
Duke Scarring schrieb: > Eine CPU ist auch nur eine FSM :-) Ein CPU betreibt eine FSM, ist aber keine. Beim FPGA ist die Schaltung, die die FSM abarbeitet, eine CPU - das macht Sinn.
Marc H. schrieb: > Ordner schrieb: >> Flugzeug-führer fliegt und der Wagen-führer fährt. > > Was macht dann ein Zugführer? Der marschiert an der Spitze seines Zuges.
Selbi schrieb: > Ein CPU betreibt eine FSM, ist aber keine. Fast jede CPU besteht aus FSM(**). Und letztlich werden diese CPU-FSM zusammen mit dem Programmcode eine noch komplexere FSM. (**) Sie ist halt einfach nur ein wenig komplexer, als das was der Erstsemestler zu machen bekommt, aber sieh dir einfach mal die Beschreibung einer realen CPU an: da gibt eine FSM der anderen die Hand (Prefetch, Pipelining, Memory-Controller, dazu Timer und die gesamte sonstige Peripherie). (**) Bestenfalls simple Single-Cycle-CPUs kommen mit einem Register-Alu-Satz aus und erhalten den kompletten Ablauf (und somit ihre FSM-Funktionalität) aus dem Programmspeicher. Marc H. schrieb: > Was macht dann ein Zugführer? Er zieht... Und ein Ballonfahrer? Was macht der? Wie gesagt: ob ich ein FPGA mit VHDL programmiere oder mit VHDL eine Schaltung für ein FPGA beschreibe ist eigentlich reine Nomenklatur und hat bestenfalls was mit der zugrunde liegenden Denkweise zu tun. Die aus der µC-Softwaretechnik kommenden "Hardware-Programmierer" stellen (sich) dann ab und zu seltsame Fragen.
:
Bearbeitet durch Moderator
Gustl B. schrieb: > Ist das nicht sogar egal? Ich finde das nicht egal, weil erzeugter Code wirklich hardwarenah die gewünschte Funktion mit einer optimierten Schaltung abbildet, während ein CORE die Tätigkeiten nur virtuell mit einer normierten Hwardware nachstellt. Das eine ist eine Schaltung, das andere tut so, als wäre es eine Schaltung.
Hm, also für mich ist das alles keine Schaltung. Das FPGA ist unveränderbarer Baustein. Das verält sich einfach anders je nach Konfiguration, ändert aber nicht seinen internen Aufbau. Wenn man jetzt sagt, ja der Bitstream ist eine Schaltung, OK, wenn in diesem Bitstream eine CPU enthalten ist, dann ist das auch eine Schaltung. Wenn im Bitstream auch noch ASM für die CPU enthalten ist, tja ... da läut zwar dann ein Programm, aber das ist doch auch feste im FPGA?! Solange sich das Programm selber nicht zur Laufzeit verändert kann man das doch immer auch mit FSM beschreiben und es bleibt deterministisch was es macht, wie eine Mechanik. Ob da jetzt im BRAM irgendein Bild liegt das über VGA ausgegeben wird oder om da Code für eine CPU drinnen ist sollte doch egal sein, das ist feste im FPGA nach der Konfiguration und solange sich der Code selber nicht ändert kann man das als Hardware betrachten. Oder man betrachtet alles als Software und nur das nackte FPGA selbst als Hardware das sich dann durch Software irgendwie verhält. Wenn da ein Bit in einer LUT gesetzt ist dann steht das eben genauso da wie ein Bit in einem Register einer CPU. Das verändert Verhalten, ist aber keine Hardware. Oder zählt man sie elektrischen Zustände als Hardware? Ich finde das alles nicht so trennscharf und eher philosophisch.
Technisch gesehen, ist das richtig. Alles, was veränderlich ist, ist eine Software. Es macht allerdings von der Sicherheitsbetrachtung schon einen Unterschied, ob Teile davon fixiert und getestet sind, wie es bei einem Core der Fall ist, oder ob dieselbe Funktion komplett frei programmiert wurde. In dem Zusammenhang ist es interessant, dass bestimmte Funktionen in klassischem VHDL in Form von geschalteten LUTs erheblich kleiner sind und damit weniger Angriffsfläche gegen Störungen der Programmierung durch Strahlung oder EMV bieten (so das relevant ist) und bei anderen es auch durchaus anders herum ist: Da belegt eine zyklische Software zusammen mit der Soft-Core-CPU in Summe viel weniger Speicherfläche, die geschützt werden muss, als die ausgerollte Hardware. Diese ist damit zunächst vulnerabler, es sei denn, man nutzt die Masse an zeitlicher Geschwindigkeitsreserve zur Mehrfachrechung und Redundanz. Wieder ein anderes Thema sind die funktionellen Fehler einer Software, weil nicht gut genug nachgedacht wurde und Fälle übersehen wurden und/oder weil ein Multitaskingsystem verwendet wird. Und auch da gilt: Je mehr selber gemacht wurde, desto anfälliger ist es meistens. Die Fragestellung "sicher" oder "nicht sicher" lässt sich also nicht so direkt mit der Frage "Software" "Hardware" verknüpfen.
Jürgen S. schrieb: > Und auch da gilt: > Je mehr selber gemacht wurde, desto anfälliger ist es meistens. Und das, was man nicht selber gemacht hat, hat jemand anders selber gemacht - und dem muss man dann vertrauen. Das ist der Knackpunkt bei "Sicherheit".
An einem Softcore haben aber schon viele dran gearbeitet und Fehler rausgeworfen und dasselbe gilt für Echtzeitsysteme die draufinstalliert werden. Die sind Tausendfach getestet und ziemlich gut gesichert.
E. M. schrieb: > Die sind Tausendfach getestet und ziemlich gut gesichert. Nur dann, wenn du auch einen tausendfach getesteten und ziemlich gut gesicherten IP-Core nimmst und selbst keine Fehler beim Einbauen machst. Das gilt aber auch für eine entsprechend gewartete Programmbibliothek.
S. R. schrieb: > Das gilt aber auch für eine entsprechend gewartete Programmbibliothek. Du hast einen kompletten von Tausenden Entwicklern eingesetzen und getesteten Softcore mit einem Echtzeitsystem in der Programmbibiliothek? Du verstehst schon, was Ich Dir sagen will? ;-= Was man kaufen kann, kann man selber kaum billiger und besser machen und SoftCore muss man nicht mal kaufen ... auch das Linux gibt es umsonst ..
E. M. schrieb: > Du verstehst schon, was Ich Dir sagen will? ;-= Nein. Ich gehe schlicht davon aus, dass ein Mikrocontroller in Hardware besser getestet ist als ein Softcore, und dass eine Backdoor in einem Softcore wesentlich leichter zu verstecken ist. Mir ging es um die Aussage von Jürgen, dass das Hauptproblem meist im selbst gewarteten Code steckt. Nur ist der Code, den ich irgendwo einkaufe, von jemand anderem "selbst gewartet", also ist die Aussage nur bedingt sinnvoll (von Schadensersatzansprüchen - also dem Schwarzen Peter - mal abgesehen).
S. R. schrieb: > dass ein Mikrocontroller in Hardware > besser getestet ist als ein Softcore, Das ist sicher der Fall. Ich allerdings verglich einen Softcore mit ein bischen C-Code mit der Alternative, alles in VHDL zu machen. Nur um ein Beispiel zu bringen, wo wenig selber machen muss und auf Getestetes zurückgreifen kann. Das ist - so nebenbei bemerkt - bei uns DAS Argument, das in jedem zweiten Projekt kommt, warum wir einen fertigen Core einsetzen, auch wenn der eigentlich Kanonen auf Spatzen ist. Wir haben dann nur sehr wenig Software zu prüfen, zu pflegen und dem Kunden an Funktion nachzuweisen.
S. R. schrieb: > E. M. schrieb: >> Du verstehst schon, was Ich Dir sagen will? ;-= > > Nein. Ich gehe schlicht davon aus, dass ein Mikrocontroller in Hardware > besser getestet ist als ein Softcore, Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu ihren prozessoren. Der intel-FDIV - Bug wurde in Massenproduktion ausgeliefert. Und einen Softcore kann man nach Bugentdeckung fixen, bei µC ist das eher selten der Fall. Und im FPGA kann man ggf Inspektions und Korrekturlogik um Bugs/potentielle Backdoors herumbauen. > und dass eine Backdoor in einem > Softcore wesentlich leichter zu verstecken ist. Häh? für nen Softcore kriegste Source/RTL-Simulation - code; damit kann man analysieren was das tun tut. Bei Hardware, kriegste vielleicht nen schaltplan/Gatterliste analysier den mal nach backdoors!? Oder man aktiviert die HardwareBackdoor beim Laserabgleich oder durch gezielte Alterung/Elektronenmigration, oder oder. In Hardware ist eine backdoor leichter versteckbar als in einem Soft-Core.
E. M. schrieb: > Ich allerdings verglich einen Softcore mit ein > bischen C-Code mit der Alternative, alles in VHDL zu machen. Dann stimmt das. Trotzdem musst du allem, was du nicht selbst gemacht hast, schlicht vertrauen. C. A. Rotwang schrieb: > Der intel-FDIV - Bug wurde in Massenproduktion ausgeliefert. Der ist jetzt über 20 Jahre her und betrifft eine Klasse von Prozessoren, von denen zumindest ich in diesem Zusammenhang nicht ausgehe. Bei "Softcore im FPGA" denke ich an einen kleinen 8- oder 32-Bitter ohne große Features und vergleiche mit entsprechenden Hardcores... > Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu > ihren prozessoren. ...und da ist an den CPU-Cores eher selten was faul. Die Peripherie (oder bestimmte Interaktionen mit selbiger) sind etwas anderes, gebe ich dir recht. > Und einen Softcore kann man nach Bugentdeckung fixen, bei µC ist das > eher selten der Fall. Kann man - tut man es auch? Bei einem µC wird eher der Compiler gefixt, aber das führt hier zu weit. :-) > Und im FPGA kann man ggf Inspektions und Korrekturlogik um > Bugs/potentielle Backdoors herumbauen. Macht das wer? Vom Militär mal abgesehen, meine ich. C. A. Rotwang schrieb: > Häh? für nen Softcore kriegste Source/RTL-Simulation - code; damit kann > man analysieren was das tun tut. Das funktioniert weder bei C-Code noch bei VHDL-Code, wenn du mich fragst. Allerdings gebe ich dir recht, dass man Backdoors in Hardware noch besser verstecken kann, insofern spielt das in beiden Fällen keine Rolle.
Moin, ist zwar am Ursprungs-Thema vorbei, aber lest euch doch mal so ein paar aktuelle Erkenntnisse zum Prozessor-HW-Fuzzing durch und probiert es aus. Erschreckend, wie der eine oder andere aktuelle Intel mal stehenbleibt. Bei ARM ist das eine ähnliche Katastrophe, da kann man aber m.W. nicht mal eben mit Microcode (wie bei Intel) noch herumpatchen. Deswegen: NIE ein ARM in sicherheitskritischen Umgebungen. S. R. schrieb: > Das funktioniert weder bei C-Code noch bei VHDL-Code, wenn du mich > fragst Wieso soll das nicht funktionieren? Ich tippe hier täglich "make run" :-) C. A. Rotwang schrieb: > In Hardware ist eine > backdoor leichter versteckbar als in einem Soft-Core. Das hängt wohl im Einzelfall davon ab, was sich hinter einer grösseren Komplexität verstecken lässt. Bei einer gut etablierten DSP-Architektur liegt das Bootrom "offen rum", somit sich die Hintertürchen zum vercryptenen Bootloading mal eben so öffnen lassen. Hätten sie's in HW versteckt, müsste man erst den ganzen Silicon-Zoo unterm Mikroskop in ne Netzliste umwandeln.
Martin S. schrieb: > Wieso soll das nicht funktionieren? > Ich tippe hier täglich "make run" :-) Ich bezog mich auf "Backdoors per Blick auf den Quelltext erkennen", hab das aber nicht ausformuliert. ;-)
C. A. Rotwang schrieb: > Nein, die Hardwaree-Hersteller liefern auch nach Jahren noch Erratas zu > ihren prozessoren. Der intel-FDIV - Bug wurde in Massenproduktion > ausgeliefert. Warum sollte da auch irgendwas anders sein? Die µC-Hersteller beschreiben ihre Käfer auch nicht wesentlich anders als unsereins (eben auch mit einer HDL, vielleicht oder wahrscheinlich sogar mit VHDL). Vielleicht haben sie an der ein oder anderen Stelle besseres Equipment, vielleicht auch nicht. Vielleicht haben sie bessere Entwickler, vielleicht auch nicht (oder halt nur Dienstags bis Freitags). Letztendlich ist es eine Frage des Vertrauens: wem vertraut man mehr, sich selbst (bzw. den eigenen Leuten) oder einem (großen oder kleinen) Hersteller. Früher hieß es mal "nobody ever got fired for buying IBM". Der Spruch funktioniert heute (auch) mit Microsoft oder Intel. Obwohl die auch nicht weniger Murks machen als sonstwer.
Martin S. schrieb: > Deswegen: NIE > ein ARM in sicherheitskritischen Umgebungen. AHA! Allerdings muss man irgendwelche Hänger sowieso annehmen und Systeme redundant bauen.
Sicherheit hat mehrer Bedeutungen: 1. funktionale Sicherheit ( Maschinensicherheit z.B. der Ausfall der elektronischen Lenkung eines Autos ) 2. Datensicherheit ( Trojaner usw ). Redundanz wird üblicherweise nur bei '1.' angewendet.
Markus F. schrieb: > Die µC-Hersteller beschreiben ihre Käfer auch nicht wesentlich anders > als unsereins (eben auch mit einer HDL, vielleicht oder wahrscheinlich > sogar mit VHDL). Vielleicht haben sie an der ein oder anderen Stelle > besseres Equipment, vielleicht auch nicht Geht wohl eher Richtung SystemVerilog und XML-Schweinereien... Auf jeden Fall haben sie nette Money-Tools um mehr Testszenarien in endlicher Zeit (co-)Simulieren zu können. Aber bei der Komplexität rutscht schon mal was durch. chris schrieb: > 1. funktionale Sicherheit ( Maschinensicherheit z.B. der Ausfall der > elektronischen Lenkung eines Autos ) > 2. Datensicherheit ( Trojaner usw ). Wenn du eine 'IoT'-Industrieanlage nicht per Buffer-Overflow/Paket-Flood o.ä. sabotieren können sollst, gibt's da keinen Unterschied mehr zw. 1 und 2..
Backdoor in Hardware ? Eher nicht. Hin und wieder geistern abenteuerliche Stories durch die Medien, wie "FPGA einer Drohne im Flug gehackt" ... die deswegen nicht wahrer werden.
Obwohl das jetzt eigentlich nicht das Thema ist gibt es sehr wohl Hardware-Angriffe: https://en.wikipedia.org/wiki/Row_hammer
Falk B. schrieb: > @ Lisa Löwenschwanz (Gast) > >>mache gerade meine ersten Schritte mit FPGA. Muss das so kompliziert >>sein kann man die Dinger nicht mit irgend einer Hochsprache >>programmieren? >>Bitte um Antwort > > Such dir ein anderes Mädchenspielzeug und toll dich. Da ist er wieder - der Frauenhasser.
chris schrieb: > Obwohl das jetzt eigentlich nicht das Thema ist gibt es sehr wohl > Hardware-Angriffe: > https://en.wikipedia.org/wiki/Row_hammer ... und hier wurde bereits vor zwei Jahren abgefrühstückt: Beitrag "Rowhammer-Attacke"
Sapperlot W. schrieb: > Backdoor in Hardware ? Eher nicht. Weil? Nur, weil du nen Strohmann aufstellst, wird Ursprungsbehauptung nicht falscher.
Die Fragestellung nach der Machbarkeit und Auswirkung solcher Bitattacken stellt sich eigentlich nicht wirklich, weil in solchen Systemen die Speicherzugriffe ohnehin als unsicher gelten müssen und über entsprechende Mechanismen geschützt werden. Da macht es dann keinen Unterschied, ob Bits wegen Übertragungsproblemen, Fertigungsfehler, Strahlung oder einem schlechten Speicherriegel falsch sind.
Marc H. schrieb: > Ordner schrieb: >> Flugzeug-führer fliegt und der Wagen-führer fährt. > > Was macht dann ein Zugführer? Es kontrolliert die Fahrkarten. Wer den Zug fährt heisst nämlich Lokführer.
Retro N. schrieb: > Es kontrolliert die Fahrkarten. > Wer den Zug fährt heisst nämlich Lokführer. und "Zugführer" hiess bei uns immer der, der die Soldaten angeführt hat.
Ordner schrieb: > "Zugführer" hiess bei uns immer der, der die Soldaten angeführt hat. Du bist zu spät: Beitrag "Re: Programmierung von FPGAs"
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.