Hallo, neugierig wie ich bin, wollte ich mir mal das Thema FPGA mit VHDL anschauen. Nur leider fällt mir absolut kein Bastelprojekt ein, wozu ein FPGA wirklich sinnvoll ist. Der Nachteil des erheblichen Stromverbrauchs spielt ja eine grosse Rolle, so dass der Vorteil schon wirklich signifikant sein müsste. Die klassischen Anwendungsbereiche wie 7.1 Decoding und Videoverarbeitung sind für mich keine Bastelprojekte. Selbst eine Drohnensteuerung, die wirklich nur noch mit Mühe als basteltauglich gesehen werden kann, nimmt man doch lieber einen ARM. Was meint Ihr zum Thema?
:
Verschoben durch Admin
Also im Retrocomputer Bereich gibt es z.B. massig Bastelprojekte. FPGASid als ein Beispiel unter vielen.
Ich hab bisher mit FPGAs auch nur im Praktikum im Studium gearbeitet und zuhause etwas damit rumgespielt. Ich kann dir ja aber mal erzählen, wozu ich jetzt ein FPGA in einem konkreten Projekt einsetze, allerdings auch ein wenig um des FPGAs willens, man könnte das Problem sicher auch anders lösen. Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das FPGA aus.
FPGAs haben zwei typische Anwendungsgebiete: a) viel Rechenleistung und viel I/O-Leistung b) schnelles Pinwackeln Gerade bei Bildverarbeitung kommt man schnell an die Grenzen der CPUs, aber Du hast recht, das ist den meisten Bastlern zu komplex. Bleibt das Pinwackeln. Wenn Du zB 10 schnelle SPI-Schnittstellen brauchst, dann ist das für einen FPGA kein Problem, aber es gibt meines Wissens nach keinen µC, der sowas hat.
Bei einem aktuellen Bastelprojekt von mir kommt ein FPGA zum Einsatz um ein altes paralleles Interface zu emulieren und auf einen DDR RAM abzubilden. Die Taktrate ist zwar nur 2MHz aber man hat letztendlich nach dem Anlegen der Adresse ans parallele Interface nur 250ns Zeit die angefragten Daten zu liefern. Auf einem Mikrocontroller wird das doch etwas knapp.
Timmy schrieb: > Nur leider fällt mir absolut kein Bastelprojekt ein, wozu ein > FPGA wirklich sinnvoll ist. Nunja, andere Bastler, andere Visionen :-) Es gibt genug Bastelprojekte, bei denen ein FPGA nützlich ist. Das sie dir nicht einfallen, liegt daran, das du wohl keinen Bedarf daran hast. kleines Beispiel gefällig? http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/#nov2008 SDR ist ein Thema, bei dem FPGAs sehr nützlich sind. Timmy schrieb: > Was meint Ihr zum Thema? S.o., nur weil du keine Anwendung für FPGAs findest bedeutet das nicht, das sie für Bastler nicht zu gebrauchen sind. Vielleicht wirst du mal ein höheres Bastelniveau erreichen und FPGAs einsetzen :-) Mir fällt auch keine Anwendung ein, bei der ein Ferrari nützlich ist, anderen Leuten schon.
Md M. schrieb: > Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese > will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. > Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene > Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das https://en.wikipedia.org/wiki/Fast_inverse_square_root
Horst schrieb: > Md M. schrieb: >> Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese >> will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. >> Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene >> Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das > > https://en.wikipedia.org/wiki/Fast_inverse_square_root Eine Wurzel Rechenoperation ist definitiv ein schlechter Grund, FPGAs zu nutzen. Jeder 2€ µC rechnet das mittlerweile in Hardware.
Timmy schrieb: > Der Nachteil des erheblichen Stromverbrauchs spielt ja eine grosse > Rolle Wieso "erheblicher Stromverbrauch"? Worauf beruht diese Aussage? > Was meint Ihr zum Thema? Wenn du kein Problem hast, das ein FPGA zur Lösung benötigt, dann nimm einen µC. Das ist einfacher und billiger. Wenn du aber die FPGA-Technik nicht beherrschst, dann wirst du eben zwangsweise versuchen, ein vermeintlich kompliziertes Problem mit einem µC zu lösen, das auf einem FPGA völlig simpel beherrschbar ist. Ich würde ganz einfach sagen: lern FPGA-Technik, dann kannst du selber bestimmen, wann du was einsetzt und musst nicht krampfhaft Vor- und Nachteile der einen oder anderen Technik abwägen. Md M. schrieb: > u.A. eine Wurzel-Berechnung. Diese ist auf dem µC aufwändig und passt > nicht mehr in das vorhandene Zeitfenster. Deshalb lagere ich diese und > andere Berechnungen auf das FPGA aus. Ich würde da einfach einen anderen, potenteren µC nehmen. Denn einen µC brauchst du ja trotzdem noch.
:
Bearbeitet durch Moderator
Horst schrieb: > https://en.wikipedia.org/wiki/Fast_inverse_square_root Interessant, werde ich mir durchlesen, danke. Vincent H. schrieb: > Eine Wurzel Rechenoperation ist definitiv ein schlechter Grund, FPGAs zu > nutzen. Jeder 2€ µC rechnet das mittlerweile in Hardware. Sind auch andere Sachen. Filter, die Regelung an sich (wird aufwendiger), etc. Es soll eben alles an Rechnerei ausgelagert werden bis auf Sachen wie z.B. Kommunikation mit einem PC. Lothar M. schrieb: > Ich würde da einfach einen anderen, potenteren µC nehmen. Denn einen µC > brauchst du ja trotzdem noch. Klar, wenn ich von Grund auf neu bauen würde schon. Wie gesagt, es gibt sicher andere Wege, das zu lösen. Mein Board ist aber schon fertig und der Flansch für das FPGA-Board schon vorhanden. Das ganze war von Anfang an als "Projekt in zwei Schritten" geplant.
Timmy schrieb: > Was meint Ihr zum Thema? FPGA lohnt bei Kleinserien/Einzelstücken eigentlich nur dann, wenn es nicht anderst geht. Also im Normalfall nur dann, wenn es sich um extrem Zeitkritische Anwendungen (z.B. SDR) handelt. In den anderen Fällen nimmt man besser einen schnelleren µC und/oder einen richtigen Computer. Mit einem brauchbaren Codegenerator (z.B. Matlab-Studentenversion) kann es manchmal anderst aussehen, da KANN ein FPGA lohnen. Dummerweise sind diese Codegeneratoren nur für Studenten bezahlbar...
> FPGA lohnt bei Kleinserien/Einzelstücken eigentlich nur dann, wenn es > nicht anderst geht. > Also im Normalfall nur dann, wenn es sich um extrem Zeitkritische > Anwendungen (z.B. SDR) handelt. Da muss ich mal dagegenhalten. Mikrocontroller waren für meine Anwendungen in der Industrieautomation ausnahmslos zu lahmarschig. Sie können zwar alles mögliche, aber nichts richtig. Für LCD-Ansteuerungen und Tastaturabfragen reicht es, aber mit allem anderen sind sie überfordert.
Neugier ist doch ne gute Voraussetzung sich FPGAs auch ohne konkrete Anwendung mal anzusehen. Es ist sowieso eher Unwahrscheinlich, dass man ohne Vorwissen in einem konkreten Fall dann mal eben etwas auf die Schnelle umgesetzt bekommt, was auch nur Ansatzweise über die Nutzung schon existierender Module hinaus geht. Ich würde mal sagen, dass bei VHDL das "Begreifen" sehr wichtig ist. Einfach mal Tutorials oder z.B. das Buch "FPGA für Maker" durcharbeiten. Ein FPGA Board für den Anfang gibts ja schon ab ca. 20€. Wenn dann das Verständnis für FPGAs steigt, dann hast du vielleicht auch mehr Ideen.
> das Buch "FPGA für Maker"
Das zu 95% nur aus: "Kaufen Sie Dies" und "Kaufen Sie Das" und
einem oberflächlichem Ausflug in die Bedienung der Synthesetools
besteht: "Klicken Sie Hier" und "Klicken Sie Da".
Klarer Fall von Daumen runter.
Bürovorsteher schrieb: > Da muss ich mal dagegenhalten. Mikrocontroller waren für meine > Anwendungen in der Industrieautomation ausnahmslos zu lahmarschig. Also viel Rechenaufwand und extrem Zeitkritisch? Hab ich doch geschrieben... Bürovorsteher schrieb: > Für LCD-Ansteuerungen > und Tastaturabfragen reicht es, aber mit allem anderen sind sie > überfordert. Die heute üblichen ARM-µCs laufen teilweise mit deutlich über 100MHz Taktfrequenz. Damit kann man viel mehr wie nur LCD-Ansteuerung und Tastaturabfragen machen.
Ich habe im Studium mit einer mitlerweile hoffnungslos veralteten Auflage von VHDL-Synthese (Reichardt, Schwarz) gelernt und fand das sehr gut. Ich persönlich wüsste aber im Moment nicht, ob ich mir überhaupt ein Buch kaufen würde. In der Tat gucke ich zur Zeit immer zuerst auf Lothars Seite vorbei. Ist quasi meine kleine VHDL-Bibel geworden. http://www.lothar-miller.de/s9y/
> Die heute üblichen ARM-µCs laufen teilweise mit deutlich über 100MHz > Taktfrequenz. Schon vor 10 Jahren bekam Mann ARMs mit > 500 MHz Clock. Die nebenbei noch einen richtigen PCI-Bus und andere Nettigkeiten boten.
Kein Maker schrieb: > Schon vor 10 Jahren bekam Mann ARMs mit > 500 MHz Clock. > Die nebenbei noch einen richtigen PCI-Bus und andere Nettigkeiten > boten... ...und von einem bezahlbaren und halbwegs einfach programmierbaren µC weit entfernt waren.
Timmy schrieb: > Der Nachteil des erheblichen Stromverbrauchs > spielt ja eine grosse Rolle, Hä??? Seit wann spielt der Stromverbauch beim Bastelprojekt ein Rolle? FPGAs sind auch ziemlich ausgelutscht: - Stecken in praktisch jedem Prototypen - Stecken in jedem dritten End-Gerät, daß Nicht-Conumer ist - Stecken in so gut wie keinem Conumer-Gerät FPGAs ist also was fürs Prototyping (Basteln!!!) und wenige Spezialanwendungen. Ich kenne kaum wirklichen Bedarf für FPGA-Knowhow, weil das Meiste so einfach ist, dass es jeder Student kann und die wenigen richtigen Anwendungen nur von einigen wenigen Experten beherrscht werden. Das FPGA-Thema ist hier dank Simulation, Matlab, SOPC und Programmierlibraries und Toolboxen sowieso untergeordnet. Es kommt auch die Beherrschung der Tools an und vor allem das Thema. Das heisst man muss sich mit dem Auskennen, was in die FPGAs rein soll. Da gibt es eigentlich nur 2 grundsätlziche Themen: 1) Spezielle Hardware wie RAM-Controller, DMA-Controller, PCIe und SERDES, sowie GBit-Transceiver, also Elektronik auf low level und 2) Signalverarbeitung, also primär Mathematik z.B. irgendwelche Hilberträume, LaPlace oder Fourier, FFT und deren Anwendung. Und diese beiden Argumente machen FPGAs in der Tat ein wenig sinnfrei. Kannst natürlich Deine Eisenbahnsteuerung komplett in Verilog machen, statt einfach einen MC zu kaufen und altes dummes C zu nehmen. Unser eins hat das übrigens mit BASCOM gemacht.
Nun Basteln ist doch eigentlich sowieso sinnfrei, ausser man sieht den Sinn darin dass es Freude macht, die Zeit vertreibt und Erfolgserlebnisse beschert. Also wie kann sich ein Bastler fragen kann ob er nun FPGAs einsetzen muss. Ist es die Angst den Anschluss in Bastlerkreisen zu verlieren oder vielleicht nicht die neuste Technik zu besitzen? Wenn eines deiner Bastelprojekte ein FPGA erfordert wirst du es schon merken. Da hilft es vielleicht zu wissen, dass es heute auch kleine, günstige und stromsparende FPGAs gibt, die übrigens auch millionenfach in Consumerprodukten eingesetzt werden (oder sind Handys keine Consumerprodukte?). Andi
Kein Maker schrieb: > Das zu 95% nur aus: "Kaufen Sie Dies" und "Kaufen Sie Das" und > einem oberflächlichem Ausflug in die Bedienung der Synthesetools > besteht: "Klicken Sie Hier" und "Klicken Sie Da". > > Klarer Fall von Daumen runter. Das Buch trägt im Titel das Wort "Einführung". Kannst du dir vorstellen was das für den Inhalt bedeuten mag? Zudem bezieht sich das Buch auf kein bestimmten Hersteller und kein einzigen FPGA Board. In die Entwicklungsumgebungen wird soweit eingeführt dass man sie benutzen kann. Das Buch taugt als Einstieg bestens. Das Thema FPGA ist mit keinem einzigen Buch erschöpfend zu behandeln. Dazu ist ein Studium mit diverser Literatur notwendig. Bücher über Digitaltechnik, VHDL/Verlig, Entwurfsmuster, nach Auswahl eines FPGA Chip und Board die dazu gehörigen Datenblätter und Handbücher. Natürlich auch die Dokumentation der ausgewählten Entwicklungsumgebung.
Andi schrieb: > Nun Basteln ist doch eigentlich sowieso sinnfrei, ausser man sieht den > Sinn darin dass es Freude macht, die Zeit vertreibt und > Erfolgserlebnisse beschert. ...oder man sich eine Problemlösung zusammennagelt, die man braucht, aber nicht kaufen/bezahlen kann/will Weitere Zauberworte lauten "mehrlagige Platine" und IC. Man kann Induktivitäten durchaus auch aus Silizum bauen. Wird bei Bluetooth und Wlan-Chips gerne gemacht. Und hier mal ein Beispiel aus der Praxis: http://hackaday.com/2015/03/18/how-to-directly-program-an-inexpensive-esp8266-wifi-module/
Nun, was bastelt man denn und warum? Entweder man möchte etwas lernen, dann ist der Weg das Ziel. Oder man möchte etwas lösen was es nicht fertig gibt/teuer ist/sonst nicht passt. Und dann kommt es ganz auf das Problem an was man verwendet. Es gibt viele nette Bastelprojekte mit FPGAs die es so in kaufbar nur für etwas mehr Geld gibt. Z. B. einen Logikanalyzer/Oszi das die Samples in Echtzeit zum PC streamt. Mit USB2 bekommt man da >30MSamples/s bei 8Bit hin, klar ist nicht viel, dafür hat man keine Totzeit. Und da gibt es eben echt viele nette Features die man in manchen Situationen gut brauchen kann, die fertige Geräte aber erst für viel Geld bieten. Mir macht das jedenfalls irre viel Spaß.
> Das Buch trägt im Titel das Wort "Einführung". Kannst du dir vorstellen > was das für den Inhalt bedeuten mag? Das der Inhalt keine relevante Höhe erreicht. Aber das schrieb ich ja schon. Mein (kostenloser) Favorit: Digital McLogic Design von Bryan J. Mealy & James T. Mealy Auch wenn Mister Miller an einigen inhaltlichen Punkten herummäkelt. Das liegt aber wohl an seinen Dogmen^W äh Postulaten...
Andi schrieb: > Nun Basteln ist doch eigentlich sowieso sinnfrei, ausser man sieht den > Sinn darin dass es Freude macht, die Zeit vertreibt und > Erfolgserlebnisse beschert. ...oder weil man irgendwie die eine Emailfunktion für Gefriertruhen-, Heizungs- und Drainagepumpenstörungen nachrüsten will OHNE gleich zur teuren Siemens-SPS greifen oder die vorhandene, historische Technik austauschen zu müssen. ...oder weil die Oma leider schon leicht dement und gebrechlich wird und man den Herd nachrüsten will. Jetzt muss man beim Kochen alle 10 Minuten auf einen Taster drücken. Und wenn der Herd 24 Stunden nicht benutzt wurde, gibts eine Email. Spätestens dann sollte man dringend mal nachschauen... ...und Nachbars Fuchs- und Waschbärfallen melden sich per SMS, wenn sie gefunden wurden. Die meisten Finder dürfen dann zum Kürschner... Häufig bastelt man auch, weil man für irgendein Problem eine Lösung benötigt und das was verfügbar ist nicht den Anforderungen entspricht.
Michel schrieb: > Ich kenne kaum wirklichen Bedarf für FPGA-Knowhow, weil das Meiste so > einfach ist, dass es jeder Student kann und die wenigen richtigen > Anwendungen nur von einigen wenigen Experten beherrscht werden. Das > FPGA-Thema ist hier dank Simulation, Matlab, SOPC und > Programmierlibraries und Toolboxen sowieso untergeordnet. Es kommt auch > die Beherrschung der Tools an und vor allem das Thema. ?? Ich hoffe doch schwer, dass das ironisch gemeint ist! Klar sind FPGA "einfach" und von Studenten beherrschbar, wenn die Taktfrequenz <50MHz ist. Bei 200MHz und mehr wird es dann ohne konkretes Verständnis schon schwierig. Ausserdem haben heutige Studenten oftmals keine Ahnung, was der Unterschied zwischen synchron und asynchron ist. Ergo haben sie KEIN Verständnis für FPGA-Technik.
Patrick B. schrieb: > Ergo haben sie KEIN Verständnis für FPGA-Technik. Bleibt die Frage: Brauchen sie es denn? Als Hobby ist das cool, keine Frage. Wirkliche Beherrschung davon ist extrem aufwändig, auch klar. Und wenn in unserem Umfeld die Firmen reden, dann klingt das tatsächlich auch stark nach Matlab und Freunden (gilt im Übrigen auch für Teile der Softwareentwicklung, also der Algorithmen).
Andi schrieb: > Ist es die Angst den Anschluss in Bastlerkreisen zu verlieren oder > vielleicht nicht die neuste Technik zu besitzen? Das eher nicht, die FPGAs gibt es ja schon eine Weile. So gefühlt 25 Jahre, sage Ich mal. > Wenn eines deiner Bastelprojekte ein FPGA erfordert wirst du es schon > merken. So ist es. Hier wäre ein nettes Projekt für einen FPGA: Beitrag "Re: Suche MOPPEL Projekt in Heft oder .PDF" Schreiber schrieb: > ...oder weil man irgendwie die eine Emailfunktion für Gefriertruhen-, > Heizungs- und Drainagepumpenstörungen nachrüsten will > ...oder weil die Oma leider schon leicht dement und gebrechlich wird und > man den Herd nachrüsten will. Jetzt muss man beim Kochen alle 10 Minuten > auf einen Taster drücken. > ...und Nachbars Fuchs- und Waschbärfallen melden sich per SMS, wenn sie > gefunden wurden. Die meisten Finder dürfen dann zum Kürschner... > Häufig bastelt man auch, weil man für irgendein Problem eine Lösung > benötigt und das was verfügbar ist nicht den Anforderungen entspricht. Da stimme Ich zu, wobei Ich etwas unsicher bin, ob ausgerechnet diese 3 Beispiele ideale Ziele fürs FPGA-Basteln sind.
Patrick B. schrieb: > Klar sind FPGA "einfach" und von Studenten beherrschbar, wenn die > Taktfrequenz <50MHz ist. Bei 200MHz und mehr wird es dann ohne konkretes > Verständnis schon schwierig. Nun, an der Frequenz direkt kann man es nicht so festmachen, denke Ich, die ist beim FPGA nur interessant, wenn es an die Grenzen desselben geht und man tricksen muss. Steigende Frequenzen sind eher ein Peripherie- und ein IO-Thema, das natürlich dazu gehört. > Ausserdem haben heutige Studenten oftmals keine Ahnung, was der > Unterschied zwischen synchron und asynchron ist. Was verwunderlich ist, weil das eigentlich in jeder Digitaltechnikvorlesung erklärt wird und mit FPGAs direkt nicht viel zu tun hat, sondern immer schon ein Thema war, wenn man mit Logikgattern mit irgendwelchen Chips verknüpft hat.
Patrick B. schrieb: > Klar sind FPGA "einfach" und von Studenten beherrschbar, wenn die > Taktfrequenz <50MHz ist. Bei 200MHz und mehr wird es dann ohne konkretes > Verständnis schon schwierig. Eigentlich ist das auch nicht so schwer. Man muss lernen mit einem sauberen für Synchronität sorgenden Grundkonzept zu arbeiten. Das sollte man auch bei unter 50Mhz tun, sonst wundert man sich wieso die Anwendung normalerweise zwar immer wie erwartet funktioniert aber alle paar Tage oder Wochen plötzlich unerwartete Dinge tut. Je nach Anwendung kann das bereits sehr ärgerlich werden und zu schwer auffindbaren Fehlern führen.
Timmy schrieb: > Nur leider fällt mir absolut kein Bastelprojekt ein, wozu ein > FPGA wirklich sinnvoll ist. Wem gar nichts einfällt, einfach mal das aktuelle Angebot an PMods anschauen (z.B. http://store.digilentinc.com/pmod-modules/), da kommt man schon auf Ideen. Ob Projekte wie eine LED-Strip Frequenzanzeige (http://www.instructables.com/id/Nexys-4-DDR-LED-strip-Audio-Spectrum/) oder eine FPGA basierte Orgelsemulation (https://github.com/heise/HOAX) als "sinnvoll" durchgehen, muss jeder Bastler für sich selbst entscheiden. Meine erste Fingerübung war ein DCF77-Decoder - schreit nicht wirklich nach nem FPGA - hat aber Spaß gemacht und ich habe mir wichtige Konzepte dabei erarbeitet. Und nicht zuletzt - manche Dinge sind auf dem FPGA plötzlich einfach, z.B. "krumme" Taktraten für Peripheriegeräte (immer gerne: Audio Codecs, z.B. CS4344), ein 24bit NCO von 1 bis 50 MHz oder die Ansteuerung von Geräten mit nicht-standardkonformen Protokollen.
Burkhard K. schrieb: > oder eine FPGA basierte Orgelsemulation (https://github.com/heise/HOAX) Oha, ausgerechnet den HOAX zu linken, ist schon etwas gewagt. Der hat den Status des "Bastelns" signifikant hinter sich gelassen. Laut Entwickler sind es zwar in erster Linie "schmutzige DDSen, die da laufen" (Originalzitat), aber die klangliche Nachbildung einer Hammond setzt sehr viel funktionelles Knowhow über das System voraus, das nicht einmal Ich habe. Wenn man sich in Musikerkreisen so umhört, hat er es wohl am Besten hinbekommen, was die Authentizität des Klangs anbelangt. Etwas einfacher und immer noch nach Orgel klingend, wäre dies hier: http://www.96khz.org/htm/virtualpldorgan07spartan3e.htm Was es noch braucht (und was noch keiner so richtig hinbekommen hat) ist eine Verbrennungsmotorsimulation, um z.B. einen Ferrari oder einen Bugatti nachzubilden, wenn er Gas gibt. Vielleicht wäre das was ... Wer mag: Die einzelnen Elemente, aus denen sich so ein Motor zusammensetzt, müssen bezüglich Torsionen, Schwingungen und generellen mechanischen Spannungen, so exakt modelliert werden, dass sie in einer Rechenpipeline parallel arbeiten und wenigstens alle 2-5us ein stabiles, lokal eingeschwungenes Ergebnis liefern, damit man eine entsprechende Audio-Abtastrate hinbekommen kann. Es muss dabei - anders, als Viele wahrscheinlich erwarten, bis weit in den Ultraschallbereich simuliert werden und Schallausbreitung in Metallen, in komprimierten und unkomprimierten, trockenen und feuchten Gasen berücksichtigt werden. Ach ja: Mit MATLAB geht da nix. Gleich zwei mir bekannte angehende Wissenschaftler sind mit der Umsetzung von akustischer Modellierung in ähnlichen Projekten mittels Modellierung und Erzeugung des Codes über den C- oder HDL-Coder schwer gescheitert. Da ist 4D-Denken (Raum+Zeit) und die Umsetzung in entsprechende partiell iterative Rechenpipelines gefordert.
:
Bearbeitet durch User
Lothar M. schrieb: > Wenn du aber die FPGA-Technik nicht beherrschst, dann wirst du eben > zwangsweise versuchen, ein vermeintlich kompliziertes Problem mit einem > µC zu lösen, das auf einem FPGA völlig simpel beherrschbar ist Meist ist es genau umgekehrt. Ein E-Techniker soll einen Regler machen, fühlt sich aber nur in VHDL standfest, und macht mit 100 Zeilen prozeduralem Code wo ein 50 Cent uC gereicht hätte, ein 40 EUR Artix zu 90% voll. Md M. schrieb: > Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese > will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. > Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene > Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das > FPGA aus Genau sowas meine ich :-)
Lothar schrieb: > Md M. schrieb: >> Ich habe in meinem vorherigem Projekt eine Regelung mit einem µC. Diese >> will ich jetzt recyclen. Dazu brauche ich u.A. eine Wurzel-Berechnung. >> Diese ist auf dem µC aufwändig und passt nicht mehr in das vorhandene >> Zeitfenster. Deshalb lagere ich diese und andere Berechnungen auf das >> FPGA aus > > Genau sowas meine ich :-) Md M. schrieb: > allerdings auch > ein wenig um des FPGAs willens, man könnte das Problem sicher auch > anders lösen. Jo. Ich wollte halt ein FPGA einsetzen. Erstens, weil ich es halt als Fingerübung wollte und zweitens fand ich es auch sinnvoll, weil ich im ersten Teil des Projekts noch nicht genau wusste, was ich im zweiten Teil genau machen werde, in welche Richtung es geht und wie rechenintensiv das wird. Es sid Projekte fürs Studium, wobei das zweite möglichst auf dem ersten aufbauen soll.
Kurze Ergänzungsfrage: gibt es für Bastler günstige PIC(e) FPGA Karten? Idealerweise mit Netzwerkbuchse? Damit man die Daten schnell ins FPGA bekommen könnte? Vielen Dank im Voraus, Andreas
Andreas R. schrieb: > gibt es für Bastler günstige PIC(e) FPGA Karten? > Idealerweise mit Netzwerkbuchse? Damit man die Daten schnell ins FPGA > bekommen könnte? Fall mit PIC(e) eher PCI(e)-Karten gemmeint sein sollten: Ja die gibt es und nein, für privat sind die nicht wirklich günstig: Beitrag "Suche günstigen und "kleinen" FPGA mit PCIe" Duke P.S.: Ich will die Daten eher schnell aus dem FPGA raushaben...
Andreas R. schrieb: > Kurze Ergänzungsfrage: gibt es für Bastler günstige PIC(e) FPGA Karten? > Idealerweise mit Netzwerkbuchse? wozu die Netzwerkbuchse bei PCI(e)? Name schrieb: > NEIN! FPGA-Benutzung als Bastler nicht sinnfrei! WOW! Gut dazwischengebrüllt, Löwe! Hast Du noch mehr zu sagen? Jetzt noch mal mein Senf: Basteln ist immer sinnfrei.
Andreas R. schrieb: > Kurze Ergänzungsfrage: gibt es für Bastler günstige PIC(e) FPGA Karten? > Idealerweise mit Netzwerkbuchse? Damit man die Daten schnell ins FPGA > bekommen könnte? > Für die Versa ECP5-Dinger von Lattice gabs vor ner Weile die hier schon öfters genannte 99$ Promo-Aktion, frag mal deinen Lieblingsdisti. Den PCIe habe ich aber noch nicht genutzt, dafür hat das Ding zwei 1G-Ethernetbuchsen. Und wo ich, wenn ich mich recht entsinne, über die Tools gemotzt habe: Mit Diamond v3.9 wurde offenbar das lästige Pfadnamenproblem behoben. Thumbs up, Lattice Semi!
Vielen Dank für den freundlichen Tip! Meinte natürlich ne PCIe Karte... Das Ding sieht auf den ersten Blick irgendwie ziemlich anders aus als der Altera oder Xilinx Kram, den ich bis jetzt gesehen hab. Muss ich mich erst noch bischen einlesen... Danke nochmal!
Andreas R. schrieb: > Also im Retrocomputer Bereich gibt es z.B. massig Bastelprojekte. > FPGASid als ein Beispiel unter vielen. Wobei Ich noch keinen virtuellen SID gefunden habe, der wirklich klingt, wie ein echter SID. Das liegt an den analogen Komponenten im Chip und bei der Klangausgabe.
Weltbester FPGA-Pongo schrieb im Beitrag #5007066: > etzt noch mal mein Senf: > Basteln ist immer sinnfrei. Klar, sonst macht es keinen Spass ;-) Also das erinnert schon ein Wenig an die Schulzeit, als Mama und Papa immer zu "sinnvollen Freizeitbeschäftigten" drängten. Interessanterweise bedeutete da manchmal sinnvoll es darf keinen Spass machen und es darf nichts kaputtgehen. Aber andere meinen gerade das Kaputtmachen wäre das Wichtige dran: https://www.youtube.com/watch?v=xhQ7d3BK3KQ
bastler schrieb: > Sinnfreies Bastlerprojekt sucht Mitstreiter > http://www.bo8h.de Ja, das ist wohl der Spitzernreiter und den richtig sinnlosen FPGA-Projekten. Kommt gleich hinter einem voll ausgebauten Microblace mit 64 Bit Emulation als uc-Beschleunigung.
Weiss nicht...ich such ne ausbaubare CPU. Also wo man ne Reihe eigener Befehle einbauen kann für so paar Spezialprobleme.
Andreas R. schrieb: > Also wo man ne Reihe eigener Befehle einbauen kann für so paar > Spezialprobleme Du meinst einem Core-i mit 10k Befehlen fehlt immer noch einer :-) Ansonsten siehe diese ältere "Diskussion" ;-) http://www.keil.com/forum/11876/
Ich hab die Sache ja auf so nem Intel und AMD Kram laufen. Aber nun soll es schnell werden.
Andreas R. schrieb: > Weiss nicht...ich such ne ausbaubare CPU. > > Also wo man ne Reihe eigener Befehle einbauen kann für so paar > Spezialprobleme. Spezialbefehle bremsen aber die 08-15 Befehle aus. Da kommst mit (FPGA-) Co-Prozessor besser. Ausnahme vielleicht Bitoperationen, aber das ist wieder die Stärke von Signalprozessoren, die es auch in Taktfrequenzen jenseits des FPGA-möglichen gibt: http://www.eetimes.com/document.asp?doc_id=1195819 Und wenn man doch der FPGA den DSP aussticht, dann ist die Entwicklungszeit deutliche höher als bei einem DSP. >Ich hab die Sache ja auf so nem Intel und AMD Kram laufen. Aber nun soll >es schnell werden. FPGA-CPU-Cores sind aber so faktor 10 langsamer als die Top-runner von intel & Co. Aber dafür deutlicher teurer. Um welche Sache geht es denn?
Ha, spannendes Thema.. C. A. Rotwang schrieb: > Andreas R. schrieb: >> Weiss nicht...ich such ne ausbaubare CPU. >> >> Also wo man ne Reihe eigener Befehle einbauen kann für so paar >> Spezialprobleme. > An sowas experimentiere ich schon länger rum, und hätte da inzwischen ne Lösung, aber leider nich OpenSource. > Spezialbefehle bremsen aber die 08-15 Befehle aus. Da kommst mit (FPGA-) > Co-Prozessor besser. Ausnahme vielleicht Bitoperationen, aber das ist > wieder die Stärke von Signalprozessoren, die es auch in Taktfrequenzen > jenseits des FPGA-möglichen gibt: > http://www.eetimes.com/document.asp?doc_id=1195819 > Wenn es nur ein "Beschleuniger" sein muss, der inline (wie ein Funktionsaufruf) laufen soll, geht das ganz gut. Wenn es volle Pulle laufen muss und wild Memories indizieren muss, dann hat man halt mit dem DSP mehr Spass. > Und wenn man doch der FPGA den DSP aussticht, dann ist die > Entwicklungszeit deutliche höher als bei einem DSP. > Nicht mehr zwingend, würde ich sagen - wenn die Toolchain mal steht. Die meisten DSP-Ops kannst du in Python hinschreiben, und im Gegensatz zum DSP ist alles funktional verifizierbar und auf HDL-Level beweisbar. Aber sobald es aus klassischen Problemen rausrennt, bist du wieder da, wo du mit HLS halt eben schnell mal auch bist. >>Ich hab die Sache ja auf so nem Intel und AMD Kram laufen. Aber nun soll >>es schnell werden. > > FPGA-CPU-Cores sind aber so faktor 10 langsamer als die Top-runner von > intel & Co. Aber dafür deutlicher teurer. > > Um welche Sache geht es denn? Oder so: Kann man die Sache auf einer GPU/VPU laufen lassen? Hab mal eben noch den alten Thread zu dem Thema ausgegraben, passt eigentlich nicht so ganz in die "Bastelecke".. Beitrag ""Neue" CPU-Architektur-Aspekte (FPGA softcores)"
Was PCI betrifft: Wenn ich das richtig verstehe kommen zu dem Lattice Sonderangebot zu ca. 250€ noch die Kosten für die Entwicklungsumgebung und für die benötigten IP, damit man PCI überhaupt nutzen kann, richtig? Macht also ca. 2000€ Bei AWS gibt es EC2 Instanzen mit FPGA. Kostet mit einem FPGA $1.65 pro Stunde (8 vCPU Kerne, 122GB RAM). Die Entwicklung kann man auf einer günstigeren EC2 machen, die aber die Software schon enthält. Ich gehe mal davon aus, dass auch die IP schon mit drin ist. Kann man ja einige Stunden laufen lassen, bis man auf die 2000€ kommt. Die EC2 mit 8 FPGAs kostet $13.20 pro Stunde. Keine Werbung, ist nur das was ich machen würde, wenn ich das dringende Bedürfnis spüren würde damit mal was rumzuspielen.
Also mein Problem ist hauptsächlich Text parsen und zusammensetzen. Singlethread, also OpenCL nützt gerade wenig .
:
Bearbeitet durch User
MagIO schrieb: > Was PCI betrifft: > Wenn ich das richtig verstehe kommen zu dem Lattice Sonderangebot zu ca. > 250€ noch die Kosten für die Entwicklungsumgebung und für die benötigten > IP, damit man PCI überhaupt nutzen kann, richtig? Mit der Probierlizenz kannst du immerhin ein Jahr lang spielen und den Core im Demo-Modus ausprobieren. Aber ok, es gibt Kunden, die sowas unsäglich nervt und dann lieber mehr für ein Spartan6-Board mit 'fertigem' PCIe ausgeben. Andreas R. schrieb: > Also mein Problem ist hauptsächlich Text parsen und zusammensetzen. > Singlethread, also OpenCL nützt gerade wenig . Dann nützt dir ein FPGA aber auch wenig. Es scheint grade ein oszillierender Hype zu sein, mit FPGAs Genom-Analyse zu machen, aber das ist im Vergleich zu einer 0815 i86-Cruncherfarm eher sinnlos.
Wieso nützt mir FPGA da wenig? Wenn ich z.B. als ersten Schritt mal einen Befehl implementiere, der alle Delimiter in einem String findet und in eine Tabelle einträgt, dann hätte ich mir schonmal eine Schleife gespart.
Jetzt wird es interessant. Wie lange ist denn der Text? Und von wo kommt der Text? Ich kann mir nicht denken, dass ein Programm auf einer CPU, welches den Text einliest, nicht schon beim einlesen die Delimiter in eine Tabelle eintragen kann. Damit fällt auch eine extra Schleife weg. Und so massiv parallel, dass man 1MB an Text auf einen Schlag durchsuchen könnte, ist ein FPGA auch nicht, würde ich sagen.
Text kommt übers Netz. Sind max. paar hundert Byte. Meine Idee war die Zeichenvergleiche alle parallel laufen zu lassen und dann ein Bitfeld entsprechend zu setzen.
:
Bearbeitet durch User
Markus K. schrieb: > Wenn Du zB 10 schnelle SPI-Schnittstellen > brauchst, dann ist das für einen FPGA kein Problem, aber es gibt meines > Wissens nach keinen µC, der sowas hat. Doch. Renesas R32C116/117/118A haben 11 davon ... und wenn das nicht reicht kann man sich über das intelligent I/O-Modul noch ein paar weitere konfigurieren. https://www.renesas.com/en-us/products/microcontrollers-microprocessors/m16c/r32c100/r32c116a-r32c117a-r32c118a.html
Andreas R. schrieb: > Wenn ich z.B. als ersten Schritt mal einen Befehl implementiere, > der alle Delimiter in einem String findet und in eine Tabelle einträgt, > dann hätte ich mir schonmal eine Schleife gespart. Du denkst viiiieeeeel zu abstrakt für ein FPGA. Dort musst du denken: was ist ein String? Was ist ein Tabelle? Was bedeutet "finden"? > Text kommt übers Netz. Also tendenziell schnarchlangsam. > Meine Idee war die Zeichenvergleiche alle parallel laufen zu lassen und > dann ein Bitfeld entsprechend zu setzen. Einarmiger Handstand mit Händeklatschen? Wie schnell brauchst du die Lösung? Wenn du jetzt sagst "100ns", dann mach das parallel mit einem Monstermultiplexer in einem FPGA. Wenn aber die Zeichenkette schon nur mit 100MBit/s reinkommt, dann löse das Problem mit einem Prozessor. Du kannst übrigens einen Parser auch als FSM auf einen seriellen Datenstrom Zeichen für Zeichen laufen lassen. Also nicht erst alles empfangen und dann parsen, sonder schon während des Empfangs den Parser mitlaufen lassen... MagIO schrieb: > Und so massiv parallel, dass man 1MB an Text auf einen Schlag > durchsuchen könnte, ist ein FPGA auch nicht, würde ich sagen. Schon bei den angesprochenen "paar hundert Byte" wird der Vergleicher und der Multiplexer so groß, dass diese Logik, wenn sie stupide nach dem "komplett empfangen, dann verarbeiten" Motto aufgebaut ist, sicher Laufzeiten im µs Bereich ergibt (wenn die Tools das Ding so massiv parallel überhaupt noch reinkriegen). Und im FPGA kann man sich die überschlägige "paar hundert Byte" Denkweise gleich mal abschminken. Dort sollte man schon zu Beginn genau wissen, ob es 100 oder 500 Byte sind. Denn dazwischen liegen Welten...
:
Bearbeitet durch Moderator
Ist man als Physik Student an physikalischen Simulationen interessiert sind FPGAs sehr interessant. Häufig werden dabei Teilchensysteme simuliert, die massiv parallele Verarbeitung in einem FPGA kann die Berechnungen dabei im Vergleich zu einem Desktop Rechner extrem beschleunigen. http://hackaday.com/2017/01/02/gravity-simulations-with-an-fpga/ Auch für Kryptographie Anwendungen kann man lustige Sachen ausprobieren. "Hier zeigt sich die Technik programmierbarer logischer Schaltungen dem PC gegenüber als leistungsfähiger. So kann beispielsweise ein FPGA vom Typ Xilinx Spartan-3 1000 400 Millionen Schlüssel im Data Encryption Standard (DES) pro Sekunde berechnen, wohingegen ein PC vom Typ Intel Pentium 4 mit 2 GHz für den ungefähr vierfachen Preis nur ca. zwei Millionen DES-Schlüssel berechnen kann. COPACOBANA berechnet eine vollständige Schlüsselsuche des Data Encryption Standards (56-Bit DES) mit einer Rate von 65 Milliarden DES-Schlüsseln pro Sekunde. Dies ergibt eine durchschnittliche Zeit von 6,4 und eine maximale Zeit von 12,8 Tagen zur Schlüsselsuche." https://de.wikipedia.org/wiki/Copacobana
Lothar M. schrieb: >> Meine Idee war die Zeichenvergleiche alle parallel laufen zu lassen und >> dann ein Bitfeld entsprechend zu setzen. > Einarmiger Handstand mit Händeklatschen? Wie schnell brauchst du die > Lösung? Wenn du jetzt sagst "100ns", dann mach das parallel mit einem > Monstermultiplexer in einem FPGA. Wenn aber die Zeichenkette schon nur > mit 100MBit/s reinkommt, dann löse das Problem mit einem Prozessor. > > Du kannst übrigens einen Parser auch als FSM auf einen seriellen > Datenstrom Zeichen für Zeichen laufen lassen. Also nicht erst alles > empfangen und dann parsen, sonder schon während des Empfangs den Parser > mitlaufen lassen... So ähnlich mach ich das gerade mit einer CPU. Braucht da aber über 300ns. Jetzt möchte ich die Sache halt weiterentwickeln.
Har23 schrieb: > "Hier zeigt sich die Technik programmierbarer logischer Schaltungen dem > PC gegenüber als leistungsfähiger. So kann beispielsweise ein FPGA vom > Typ Xilinx Spartan-3 1000 400 Millionen Schlüssel im Data Encryption > Standard (DES) pro Sekunde berechnen, wohingegen ein PC vom Typ Intel > Pentium 4 mit 2 GHz für den ungefähr vierfachen Preis nur ca. zwei > Millionen DES-Schlüssel berechnen kann. Noch schneller und günstiger wird es, wenn man mit Grafikkarten rechnet. Gab es damals aber noch nicht so wie heute.
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.