FPGA/VHDL-Einstieg mit Xilinx - wie weitermachen?

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.

hilf mir meinen xaui core anzuschließen xD

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.

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.

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.

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.

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!