Ahoi zusammen, ich habe die Coronazeit ein wenig genutzt und mich mal in etwas neues eingearbeitet - Thema FPGA mit nem Xilinx-Board von Digilent und VHDL in Vivado. Dort habe ich zur Übung, ohne den ganzen in Vivado vorhandenen "bloat" (absichtlich in "") wie IP-Cores, Code-Generation und Soft-Microcontroller usw. rein in VHDL nach Lehrbuch Dinge wie blink-LED, Binärzähler, 7-Segment-Counter (PMOD-Modul) hinbekommen. Soweit so gut. Nun wollte ich mal eine Stufe weiter gehen, jedoch fehlt mir dazu die Idee, ob das ganze Vorhaben überhaupt sinnvoll und stemmbar ist als Anfänger. Eigentlich habe ich aktuell gar keine direkte Projektidee, bei der man einen FPGA sinnvoll anwenden kann, für mich ist es einfach zur Übung und zum lernen, wer weiß wann man es mal studiumsmäßig oder beruflich brauchen kann. Das einzige woran ich dachte (ich weiß, aktuelle MCUs können das leistungsmäßig auch schon längst) wäre nen (Audio) Spektrumanalyzer (sprich FFT), bei der ich den FPGA als "number cruncher" nutze. Da gibts ja auch entsprechende IP-Cores dazu, da würde ich quasi mich auch gleich damit einmal beschäftigen und mich in deren Verwendung einarbeiten. Doch wie zeige ich die Daten an? Klar, Ausgabe an nen Rechner wäre eine Möglichkeit (USB/serial), aber schicker wäre das ganze natürlich als Standalone. Dann stünde allerdings die Programmierung einer kompletten Displayansteuerung + graphischer Repräsentation auf dem Plan, aber das macht man doch sicher üblicherweise nicht in VHDL (außer man ist TV- oder TFT-Entwickler ;))? Wäre das eine bessere Aufgabe für den Softcore (plus etwaiger Libraries)? Oder nutzt man für die Ansteuerung LVDS-IP-Cores um das ganze etwas zu vereinfachen? Ich möchte wie gesagt auch keine komplette LCD-Panel-Ansteuerung für 4K selberbauen (wofür FPGAs mit der entsprechenden Kenntnis & Manpower sicher geeignet wären), und mich an der Aufgabe auch nicht verheben, sondern nur so nen kleines TFT. Danke für Eure Tipps, hoffe es bringt mein Verständnis etwas weiter, ob das Vorhaben so überhaupt sinnhaft ist und wie da die optimale Umsetzung ist, also die Schnittstelle komplexerer paralleler Rechenaufgaben mit einfachen Standardaufgaben.
Also bei der Anzeige geht es auch von einfach bis kompliziert. VGA ist einfach. HDMI mit geringer Auflösung ist auch gut machbar, auch 1024*768. Displayport und schnelles HDMI wird schon schwerer. Einfach einen Signalverlauf anzeigen, auch von einer FFT, also eine Wertetabelle als Linie ist einfach. Fang doch klein an. Zuerst Audio live als Wellenform auf VGA ausgeben. Mit einstellbarer Zeitauflösung. Mit Trigger, quasi ein einfaches Oszi. Dann dazu noch FFT in der unteren Bildhälfte. Dann das Ganze mit HDMI. ... auch wenn das nicht nützlich ist, du lernst sehr viel.
>Eigentlich habe ich aktuell gar keine direkte Projektidee, bei der man >einen FPGA sinnvoll anwenden kann, für mich ist es einfach zur Übung und >zum lernen, wer weiß wann man es mal studiumsmäßig oder beruflich >brauchen kann. Interessant für FPGAs sind vom Hersteller unabhängige Multicorearchitekturen insbesondere RISC-V, die gerade schwer im kommen sind: Beitrag "Re: RISC V minmal CPU" Da kannst Du die FFT auf eine Core laufen lassen und die Darstellung auf einem anderen.
Es gibt auch relativ billige Graphikdisplays. https://www.reichelt.de/lcd-module-grafik-c3008.html?&nbc=1 Die sollten auch nicht zu schwer anzusteuern zu sein. Wenn nicht schon geschehen, solltest du dich beim Umgang mit IP-Cores meiner Meinung nach auch mit den graphischen Entwicklungswerkzeugen beschäftigen, also zum Beispiel Block Design in Vivado oder Platform Designer in Quartus. Ich habe mich damit erstmal schwer getan, aber es erleichtert doch vieles. Auf jeden Fall ist es kein Zeichen von Professionalität, das nicht zu benutzen.
Testuser schrieb: > VGA ist einfach. Eben, da gibt es sogar einen Core hier im Wiki: https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL oder einen LA mit Cusor und Zeiotmaarkenanzeige, alles in VHDL, nix Soft-Core.
Foxy schrieb: > Eigentlich habe ich aktuell gar keine direkte Projektidee, Das ist wohl der entscheidende Grund für deine Mißstimmung. Einfach so - also quasi rein akademisch - mit irgendwas herumzupröbeln, führt zumeist dazu, das Ganze nach einiger Zeit wieder bleiben zu lassen. Also bist du im Prinzip auf der Suche nach Projekten, die sowohl ein FPGA erfordern als auch in deinem persönlichen Rahmen bleiben. Tja, da wird es schwer, dir irgend einen Vorschlag zu machen. Ich versuche es denoch: - Spektrum-Analysator, also den HF-Bereich in Streifen abgrasen und innerhalb der Streifen per FFT nach Frequenzen auseinandernehmen. - Universal-Retro-Homecomputer, also sowohl die verwendeten µP als auch die Funktionalität der jeweiligen Leiterplatten nachbilden, so daß die damaligen Spiele drauf laufen wie auf den Originalen. Mal sehen, ob jetzt noch weitere Beispiele kommen. W.S.
Just do it schrieb: > Eben, da gibt es sogar einen Core hier im Wiki: > https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL > > oder einen LA mit Cusor und Zeiotmaarkenanzeige, alles in VHDL, nix > Soft-Core. Wat is en Zeiotmaarkenanzeige? Nederlaands Sprach? W.S. schrieb: > - Universal-Retro-Homecomputer, Ich würde eine 8-BIT-CPU vorschlagen. Die kommen hier im Forum am Besten an.
Foxy schrieb: > Dann stünde allerdings die Programmierung einer kompletten > Displayansteuerung + graphischer Repräsentation auf dem Plan, aber das > macht man doch sicher üblicherweise nicht in VHDL (außer man ist TV- > oder TFT-Entwickler ;))? Genau so eine Displayansteuerung ist Bestandteil meiner "FPGA-Einführung für Praktikanten und Bacheloranden". Microsteps sind: Steuere einen VGA-Monitor an. Zeige ein vertikales/horizontales Strifenmuster/Farbverlauf an. Dann ein Schachbrett und ein Gitternetz. Skaliere das Gitternetz. Gib die Daten dafür über eine PS2-Tastatur oder eine RS232-Schnitte (praktisch ist an dieser Stelle, wenn man solche Interfaces schon vorher gemacht hat) ein. Schreibe Code für ein One- und Two-Player-Pong. Steuere den Schläger über eine Tastatur. (Für Hacker: denke dir eine einfache Lösung zum Einlesen von Potiwerten aus und steuere die Schläger mit einem Poti). Foxy schrieb: > Das einzige woran ich dachte Was auch eine nette Anwendung für ein FPGA ist: ein Indexer für eine mehrachsige Schrittmotorsteuerung. Den kann man auch beliebig kompliziert implementieren.
Foxy schrieb: > Dann stünde allerdings die Programmierung einer kompletten > Displayansteuerung + graphischer Repräsentation auf dem Plan, aber das > macht man doch sicher üblicherweise nicht in VHDL (außer man ist TV- > oder TFT-Entwickler ;))? Wäre das eine bessere Aufgabe für den Softcore > (plus etwaiger Libraries)? Oder nutzt man für die Ansteuerung > LVDS-IP-Cores um das ganze etwas zu vereinfachen? Ich möchte wie gesagt > auch keine komplette LCD-Panel-Ansteuerung für 4K selberbauen (wofür > FPGAs mit der entsprechenden Kenntnis & Manpower sicher geeignet wären), > und mich an der Aufgabe auch nicht verheben, sondern nur so nen kleines > TFT. Mein Senf: Irgend ein 8080-Interface-Display (wichtig: Dokumentierte Ilitek oder Sitronix-Controller) hernehmen und ein UART->TFT Charakterdisplay implementieren. Das impliziert: - UART-Einsynchronisation - "Terminal"-Engine mit State-Machine - Charakter->Bildschirm: (komprimierte) Bitblöcke auf den Controller schicken - Somit: 8080 Bus-Interface-Timing-Logik Das ist schon lustig genug, ohne Soft-CPU. Die Charaktertabellen kann man gut im Boot-SPI-Flash ablegen (sofern gross genug) Dann kannst du immer noch einen CPU-Kern ins Spiel bringen, Hardware-Bresenham-Units einbauen, usw. Generell bist du mit einer CPU und einem vernünftigen Debug-Interface viel schneller in der Entwicklung. Da gibt's auch fertige SoC-Designs in der Opensource, falls du weiter oben einsteigen willst. Alles komplexere, was mit DDR3-Framebuffern oder HDMI zu tun hat, kann mit fertigen IP-Blöcken wunderbar funktionieren, oder auch eben nicht, und dann ist der Frust bei den Einsteigern gross, wenn keine vollständige Simulation verfügbar ist.
Lothar M. schrieb: > Genau so eine Displayansteuerung ist Bestandteil meiner "FPGA-Einführung > für Praktikanten und Bacheloranden". Microsteps sind: > Steuere einen VGA-Monitor an. Zeige ein vertikales/horizontales > Strifenmuster/Farbverlauf an. Dann ein Schachbrett und ein Gitternetz. > Skaliere das Gitternetz. Gib die Daten dafür über eine PS2-Tastatur oder > eine RS232-Schnitte (praktisch ist an dieser Stelle, wenn man solche > Interfaces schon vorher gemacht hat) ein. Schreibe Code für ein One- und > Two-Player-Pong. Steuere den Schläger über eine Tastatur. Genau sowas verdirbt den Leuten den Umgang mit programmierbarer Logik. Also soll nach deiner Vorstellung so ein FPGA folgendes tun: 1. die Signale für einen VGA-Monitor erzeugen 2. Streifen anzeigen (horizontal und vertikal) 3. Schachbrettmuster und Gitternetz darstellen 4. Daten in Form von Scancodes (make&break) von einer PS2 Tastatur empfangen 5. das Schachbrett bzw. das Gitternetz nach den eingegebenen Scancodes einstellen - alternativ über Bitmuster, die über eine Serielle empfangen werden. 6. ein Ping-Pong-Spiel in VHDL für das Ganze schreiben. 7. das Ping-Pong-Spiel über Scancodes von der PS2-Tastatur steuern. Mit deinem Beispiel hast du dich mit Fleiß um all die Dinge herum maneuvriert, die im realen Leben wichtig sind. Zum ersten: Die Punkte 2..7 sind für eine praktische Verwendung irrelevant. Sodann: So ein FPGA soll ein irgendwie geartetes Display ansteuern. Alles weitere ist eher die Aufgabe einer Rechenmaschine z.B. eines µC. Und dazu bedarf es eines Speichers, der den gewünschten Displayinhalt vorhält. Und auf diesen müssen 2 Instanzen zugreifen: die Logik nach Punkt 1 und besagte Rechenmaschine. So etwas ist zu organisieren und das ist Obliegenheit des FPGA (aber sowas kommt bei dir nicht vor). Das praktische Interface zur Rechenmaschine ist ebenso eine Obliegenheit des FPGA, jedoch abhängig von besagter Rechenmaschine. Mal ganz generell: irgendeine Display-Ansteuerung ist eine periphere Einrichtung einer anderen Maschine, die einer Anzeige (wovon auch immer) bedarf. Es ist nie ein Elfenbeinturm, der nur mit sich selbst und seinem eigenen Takt beschäftigt ist. Und genau deshalb ist deine Einführung für Praktikanten un Bacheloranden ziemlich daneben. Es wäre anders, wenn du deine Punkte 2..7 weglassen würdest und stattdessen ein Interface für irgendeinen µC konzipieren würdest. W.S.
W.S. schrieb: > Und genau deshalb ist deine Einführung für > Praktikanten un Bacheloranden ziemlich daneben. Aha und W.S. schrieb: > Interface für irgendeinen µC ist gut geeignet um die Grundlagen von FPGA und Beschreibungssprache zu lernen? Kombinatorik, getaktete Beschreibung, Zustandsautomaten, Hardwarebauteile wie DSP, BRAM, MMCM, SerDes, IODelaye, ... Ich finde wenn man ein uC Interface schreibt, dann ist nur ein sehr kleiner Teil vom den FPGA Grundlagen abgedeckt. Und zusätzlich hat das den Nachteil, dass man Dinge voraussetzt, die man für die Entwicklung mit FPGAs nicht zwingend benötigt. Nämlich Kenntnisse von uC und einer Hochsprache. Ja, ist vielleicht sinnvoll, aber gerade bei Studenten die einen Kurs zu FPGAs belegen kann man sowas nicht voraussetzen. Entweder man packt diese Lerninhalte zum uC + Hochsprache also mit in den Kurs, oder man macht im Kurs etwas mit FPGAs ohne solche Voraussetzungen. Letzteres ist an den Hochschulen der übliche Weg.
W.S. schrieb: > Mit deinem Beispiel hast du dich mit Fleiß um all die Dinge herum > maneuvriert, die im realen Leben wichtig sind. Es ist mir unklar, warum du immer querschießen musst. Kann sein, dass das in deiner Natur liegt oder dass ich dich mal zugeparkt habe oder sonstwas. Denn ich habe ja nicht behautpet, dass nach diesen Schritten der Lernprozess zu Ende ist. > Und genau deshalb ist deine Einführung für Praktikanten un Bacheloranden > ziemlich daneben Sei dir sicher: alle, die diese einführenden Schritte durchlaufen haben, waren mit der Schrittweite zufrieden. Manchen war sie zu groß und zu schnell. In jedem Fall war die Einführung zwingend nötig. Weil jeder ankam und wie mit C gelernt drauflos programmierte, ohne zu wissen, WAS er da programmierte. Ich war in vielen Fällen der erste, der einen Blick auf den RTL-Plan und das Abschätzen von Ressourcen verlangte. > Es wäre anders, wenn du deine Punkte 2..7 weglassen würdest Kaum zu glauben, wie viel man beim Pong und bei Kollisionsberechnungen über Latency lernen kann. > und stattdessen ein Interface für irgendeinen µC konzipieren würdest. Du hast gelesen, dass dort eine serielle Schnittstelle verwendet werden soll. Diese serielle Schnittstelle wurde übrigens dann als Modul schon in vorherigen Arbeitsschritten ausgeknobelt und in verschiedenen Varianten realisiert. In einem anderen Schritt werden dann die SPI-Schnitte und die I2C-Schnitte realisiert. Und zwar nicht im Stil "hab ich im Netz gefunden", sondern im Stil "da schauen wir uns mal das Datenblatt an". Aber wenn du für deine Praktikanten und Bacheloranden die Sache anders angehst, dann habe ich damit kein Problem. Hauptsache, sie lernen dabei, wie ein FPGA funktioniert und wo man sich die Finger einklemmt.
Lothar M. schrieb: > Es ist mir unklar, warum du immer querschießen musst. Das mag dir so erscheinen, es ist in Wirklichkeit aber nur ein Versuch, das Thema geradezubiegen. Naja, mich erinnert dein Beitrag an das berüchtigte Zitat "..wie ich bereits in meinem Booche von der Verantwortung däs Läährers.."usw. aus der Feuerzangebowle. Ich bin ganz bewußt nicht auf die Themen 4, 6 und 7 eingegangen, weil so etwas eher in der Domäne von Rechenmaschinen und Bahnberechnungen liegt, also auch in einem FPGA eine Ebene, die im Grunde lokale Turingmaschinen hervorbringt, wenn man sie dort ansiedeln will. In eine Displayansteuerung gehört so etwas nicht hinein. Wozu also? Um im akademischen Rahmen zu bleiben? Wahrscheinlich, ich hab nicht ohne Grund das Wort vom Elfenbeinturm gebraucht. Tja, ich kenne das - allerdings auf etwas anderem Gebiet. Teilweise ist das dem Lauf der Zeit geschuldet. Dinge, die man für manche Signalverarbeitung heutzutage praktisch gebraucht, waren zu meiner Studienzeit nur ein rein theoretisches und damit nur akademisches Thema, denn Rechentechnik, auf der man so etwas praktisch machen konnte, ohne dann hundert Jahre auf's Ergebnis zu warten, war bestenfalls ein Wunschtraum. Kommen wir also lieber auf etwas praxisnähere Gefilde zurück. Und das heißt für eine Displayansteuerung, daß sie ein Display ansteuern soll und selbst nicht die Inhalte bestimmt, sondern selbige von einer anderen Instanz bekommt. Da tun sich andere, aber nicht weniger wichtige Probleme auf: Kollisionsverwaltung, Ansteuerung von externen Baugruppen wie Speicher usw. Kein Pingpong, dafür aber Beachtung von Interfaces anderer Bauteile. Und das ist wichtig, denn ein FPGA lebt nicht als Einzelkind, sondern muß mit anderer Elektronik zusammenspielen. Und was die VHDL-Lehre betrifft: Da würde ich mir bessere Lehrmaterialien wünschen als das, was man gemeinhin derzeit vorfindet. Bloß wenn man als Übungsstücke für Studenten vornehmlich solche Dinge wie dein VGA-Pingpong vorfindet, dann setzt das nicht die richtigen Akzente. Digitale Signalverarbeitung muß, wenn's schnell gehen muß, auf dem FPGA stattfinden, aber sie ist nicht das FPGA als solches und auch nicht der Lehrinhalt für VHDL. So, das war ein Ausflug in Gefilde, die für den TO wohl eher nicht in Frage kommen. Wir sollten das beenden und drauf warten, ob noch etwas an anderen Vorschlägen hereinkommt, die eventuell ein angemessener Ratschlag für ihn wären. W.S.
Eine Interessante, 1D-Denkweise erklärst du uns da W.S. Ich versuche dir mal au die Sprünge zu helfen: Jemand möchte FPGAs kennenlernen. Klar könnte man jetzt nach seinem ersten Hello World Projekt loslegen und ein komplexes Design mit DDR Speicher, Ethernet und dem ganzen Kram inklusive 10 Clk Domains erstellen. Oder man backt kleine Brötchen und versucht über ein motivierenden Ansatz zu begeistern und darüber die Basics zu vermitteln. Es ist nämlich verdammt motivierend wenn man als Anfänger nach ein paar Tagen ein Bild auf dem Monitor flimmern hat. Natürlich sollten dann weitere Vertiefungen und andere Übungen folgen, hat ja auch keiner bestritten. Und ja, da gehört selbstverständlich auch DSV dazu. FPGAs sind dafür schließlich da.
raX schrieb: > Es ist > nämlich verdammt motivierend wenn man als Anfänger nach ein paar Tagen > ein Bild auf dem Monitor flimmern hat. Ist dir eigentlich klar, was für einen physikalischen und damit auch rechentechnischen Gehalt ein Pinpong-Spiel hat? Wohl nicht, denn das ist für einen "Anfänger" viel zu hoch gegriffen. Andererseits ist ein Schachbrettmuster oder ein Gittermuster noch lange keine Bildschirmansteuerung. Was dazu nötig ist, habe ich ja bereits mehrfach geschrieben. Das ist auch nicht ohne, schließlich mündet das Ganze in das Finden einer Strategie, Kollisionen zwischen zwei voneinander unabhängigen Zugreifern auf einen Speicher zu organisieren. Versuche du mal, das zu begreifen, anstatt mir auf deine Sprünge helfen zu wollen. Jetzt will ich nicht Persönliches heraushängen lassen, sowas gehört hier nicht hinein. Also zurück zum Thema und das heißt, für jemanden wie den TO interessante und zugleich von ihm stemmbare Projekt-Vorschläge zu machen und nicht sich in imaginierten Höhenflügen zu verlieren. Zu deutsch: bleib mal auf dem Teppich. Naja, und das Kennenlernen von FPGA's geht am ehesten durch das gründliche Lesen der zugehörigen Manuals und Datenblättern. Man kann auch zunächst mit CPLD's anfangen. Sowas ist in gewisser Weise gutmütiger als FPGA's und es ist für manche Dinge nützlicher. Ich denke da an sowas wie die historisch bekannten "Glue"-Logiken bei Rechnern aller Art, die früher aus Breitseiten von TTL bestanden oder die ersten Stufen bei einem Frequenzzähler oder ein DDS oder eben auch Displaycontroller. Daß für letzteren bereits ein CPLD mit so etwa 120..140 MC ausreicht, weiß ich aus eigener Erfahrung. Ich halte auch nichts davon, Dinge, die man besser in einem µC macht, partout in ein FPGA quetschen zu wollen. Oder umgekehrt. Und bei meinem Vorschlag eines Retro-Spiel-Computers wäre die Aufgabe des FPGA, die damalige CPU und deren Verschaltung zu emulieren. Aber nicht die Firmware und die ladbaren Spielprogramme. Auch kein Pingpong. W.S.
W.S. schrieb: > Ist dir eigentlich klar, was für einen physikalischen und damit auch > rechentechnischen Gehalt ein Pinpong-Spiel hat? Wohl nicht, denn das ist > für einen "Anfänger" viel zu hoch gegriffen. Autsch. Du willst mir nicht ernsthaft erzählen, dass das Speichern von 3 x/y-Werten (das reicht nämlich, die bounding boxes sind Konstant) und dessen Vergleich auf Kollision eine ach so komplexe Speicherstrategie bedarf. Jedes FPGA wird dir dabei vor langeweile einschlafen. Erst recht weil die Berechnung nur alle paar Millisekunden stattfinden muss. Ich hoffe das deine "Lehrstrategie" - Lesen von Datenblättern noch nie auf irgendwelche Anfänger oder Studenten losgelassen wurde.
W.S. schrieb: > Ist dir eigentlich klar, was für einen physikalischen und damit auch > rechentechnischen Gehalt ein Pinpong-Spiel hat? Wohl nicht, denn das ist > für einen "Anfänger" viel zu hoch gegriffen. Also, meine Anfänger schaffen das mit meiner Vorgehensweise. Und jeder hat sich hinterher wie ein kleines Kind über das Ergebnis gefreut. Und das ist dann die beste Motivation. raX schrieb: > das Speichern von 3 x/y-Werten Wenn man es genau betrachtet, ist sind es nur 3 y-Werte und 1 x-Wert, denn die Schläger gehen ja nur auf und ab. W.S. schrieb: > Und bei meinem Vorschlag eines Retro-Spiel-Computers wäre die Aufgabe > des FPGA, die damalige CPU und deren Verschaltung zu emulieren. Genau da sind wir: die "damalige CPU" war eben nicht mehr als ein x/y-Register für den "Ball" und zwei y-Register für die Schläger und ein paar Zähler für das Bildschirmtiming. Denn immerhin wurde das in bester Arcadegame-Manier mit diskreten Zählern und Vergelichern realisiert: https://de.wikipedia.org/wiki/Pong
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Genau da sind wir: die "damalige CPU" war eben nicht mehr als ein > x/y-Register für den "Ball" und zwei y-Register für die Schläger... Ach wo. Schau dir mal "Steccy" an, da weißt du, was tatsächlich dahinter steckt. Aber so etwas ist auch nicht das Thema für einen Displaycontroller. Wenn es ein bissel anspruchsvoller sein darf, dann schau dir mal das Manual für den RA8875 an. W.S.
Angehängte Dateien:
-
docnav.png
140 KB
W.S. schrieb: > Naja, und das Kennenlernen von FPGA's geht am ehesten durch das > gründliche Lesen der zugehörigen Manuals und Datenblättern. Na sicher doch! Da hätte ich bei Xilinx ein paar Jahre lang nix anderes zu tun. Behalte doch bitte deine praxisfernen Vorschläge für dich! Duke
Duke Scarring schrieb: > W.S. schrieb: >> Naja, und das Kennenlernen von FPGA's geht am ehesten durch das >> gründliche Lesen der zugehörigen Manuals und Datenblättern. > Na sicher doch! > Da hätte ich bei Xilinx ein paar Jahre lang nix anderes zu tun. naja, ein Studium der Elektrotechnik oder technischen Informatik dauert durchaus mehrere Jahre und ist IMHO notwendig für die Tätigkeit als FPGA-Designer > Behalte doch bitte deine praxisfernen Vorschläge für dich! Sorry, aber bezüglich des Lesens der relevanten Dokumente hat W.S. durchaus Recht. Auch wenn es deutlich weniger als die plakativ behaupteten 3000+ Dokumente sind, sind das gut über 1000 Seiten, die man mal überflogen haben sollte: *Das Datenblatt der verwendeten Familie, *die tcl-kommandos, *Synthese style guide, *Simulation guide "How to write testbenches" *applikation notes zu architekture details wie DSP-slice, LUT-slice, Clocking resources, ->grob vielleicht 10 dokumente. Und wenn sich dabei herausstellen sollte, das einem die Grundlagen ehlenen, muss man sich eben Digitale Schaltungstechnik und Technische Informatik auf Hochschulniveau aneignen. Es gibt auch an FPGA angepasste Hochschullehrbücher: http://www.zynqbook.com/ Die sind aber kein Ersatz für die xilinx-docs, eher eine Einführung wie man diese Herstellerlektüre on-the.job einsetzt.
Lothar M. schrieb: > Also, meine Anfänger schaffen das mit meiner Vorgehensweise. Und jeder > hat sich hinterher wie ein kleines Kind über das Ergebnis gefreut. Und > das ist dann die beste Motivation. > Also aus der Sicht eines absoluten FPGA Anfängers im 7ten Semester Elektrotechnik... Da hast du zu 100% recht. Wenn ich mir vorstellen würde, dass ich als "Lernbeispiel" irgendeinen effizienten DSP-Kram, IIR,FIR implementieren müsset, dann hätte ich da nach bestimmt 3h keinen Spaß dran mehr, wenn es da keine Sichtbaren Erfolge gibt. Natürlich kann man sich darüber unterhalten wie "Sinnvoll" ein Pong auf nem FPGA ist. Das tut ja aber beim Grundlagen lernen eh nicht zur Sache. Lernprojekte wo man "alles" einmal abfrühstückt und danach auch versteht sind meiner Meinung nach der richtige Weg. In meinem letzten Semester wurde ganz nebenbei auch eine VGA Schnittstelle in Matlab Simuliert und anschließend auf nem Artix 7 implementiert. Ganz so schlecht scheint dieser Ansatz also nicht zu sein ;)
Fpgakuechle K. schrieb: > Sorry, aber... Laß mal, hier scheinen mir zwei Welten aneinander zu reiben: zum einen die Welt der tatsächlichen Anwendung, also eher Industrie und Geld verdienen und zum anderen die akademische Welt, also Assistenten, Lehre und Veröffentlichungen. Die ganze Diskussion ist mittlerweile ziemlich aus dem Ruder gelaufen, man vergleiche mal die mentalen Probleme des TO mit dem derzeitigen Diskussions-Stand: Foxy schrieb: > Nun wollte ich mal eine Stufe weiter gehen, jedoch fehlt mir dazu die > Idee, ob das ganze Vorhaben überhaupt sinnvoll und stemmbar ist als > Anfänger. > > Eigentlich habe ich aktuell gar keine direkte Projektidee, bei der man > einen FPGA sinnvoll anwenden kann,... Mit meinen Worten: der TO ist auf der Suche nach sinnvollen Anwendungen und nicht nach praxisfernen Pingpong-Spielen. Und das Abdriften des Themas hat ganz deutlich Lothar verzapft. Ich schätze mal, auch hier wäre die Rückkehr zu den Problemen des TO dringend angesagt. W.S.
Ole W. schrieb: > Wenn ich mir vorstellen > würde, dass ich als "Lernbeispiel" irgendeinen effizienten DSP-Kram, > IIR,FIR implementieren müsset, dann hätte ich da nach bestimmt 3h keinen > Spaß dran mehr, wenn es da keine Sichtbaren Erfolge gibt. Naja, falls du ein Funkamateur wärest, dann hättest du die Erfolge zwar nicht sichtbar, aber dafür hörbar gehabt. Aber die Leute sind eben unterschiedlich. Immer nach dem Motto "wat dem eenen sin Uhl, is dem annern sin Nachtigall". W.S.
hol dir mal n artix 7 mit ethernet port. diese GTP transceiver vom artix7 können ethernet daten senden!
W.S. schrieb: > Laß mal, hier scheinen mir zwei Welten aneinander zu reiben: zum einen > die Welt der tatsächlichen Anwendung, also eher Industrie und Geld > verdienen und zum anderen die akademische Welt, also Assistenten, Lehre > und Veröffentlichungen. Und dann gibt es noch Nummer 3: Man beschäftigt sich damit weil es einem Spaß und Freude macht. Im Idealfall überschneiden sich die drei Bereiche: Man implementiert etwas praktisches, lernt etwas dabei und hat Freude daran wenn es nach tagelangem herumprobieren endlich klappt.
:
Bearbeitet durch User
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.