Hallo, ich habe das was ich gelernt habe von Grunde auf mit blinkenden LEDs und so gelernt. Jetzt geht es aber so wie ich das sehe in letzter Zeit in eine andere Richtung die mich etwas verwirrt. Was ich meine ist, dass es irgendwie einen Trend gibt möglichst einfach ferige Blöcke zusammenzukleben. Da nimmt einem die Entwicklungsumgebung auch einiges ab und schnell hat man ein System mit CPU und diversen Controllern. Mit den SoC-FPGAs sieht das vielleicht noch einfacher und baukastenartiger aus. Jetzt die Frage weil ich keine Ahnung habe: Braucht man dazu noch eigene VHDL Kenntnisse? Dass diese nicht schaden ist mir klar aber benötigt man diese noch wenn es alle Einzelbausteine die man verwenden möchte auch fertig gibt? Und ist es dann sinnvoll fertige Blöche zu verwenden oder selber zu beschreiben? Wie macht ihr das so? Für mich sieht das irgendwie nach Spielzeug aus bei dem man nicht viel verstanden haben muss um trotzdem schnell ein fertiges System zu haben. Ich würde bei FPGAs immer von ganz unten mit dem Lernen anfangen, aber vielleicht ändert sich diese Ansicht. Danke!
Gustl B. schrieb: > Da nimmt einem die Entwicklungsumgebung auch einiges ab und schnell hat > man ein System mit CPU und diversen Controllern. Mit den SoC-FPGAs sieht > das vielleicht noch einfacher und baukastenartiger aus. > Braucht man dazu noch eigene VHDL Kenntnisse? Nein. Die braucht man erst, wenn das geklebte nicht ganz das tut, was es soll. Und glücklich ist dann der, der der aus seinem Tool dann überhaupt noch VHDL oder Verilog herausbekommt... > Ich würde bei FPGAs immer von ganz unten mit dem Lernen anfangen, aber > vielleicht ändert sich diese Ansicht. Zum Lernen ist das auch sehr sinnvoll, denn die grundlegenden Probleme im FPGA können an solch simplen Beschreibungen einfach begriffen werden. Ein wenig provokant gesagt: voll bekommt man heute ein großes FPGA in vertretbarer Zeit nur noch mit Beschreibungen aus Codegeneratoren und Matlab-Modellen... ;-)
Vielen Dank, so sehe ich das auch! Das ist wie der Unterschied zwischen "Ein schönes Bild haben wollen" und "malen lernen wollen". Wenn man malen lernen will setzt man sich vor die leere Leinwand und die ersten Versuche sind entweder total primitiv oder sehen schlimm aus, wenn man ein schönes Bild haben möchte dann kauft man sich eines oder (wenn man selber was machen möchte) löst man ein Puzzle. Es geht darum, dass wir an der Uni Nachfrage nach "FPGA" von Seite der Studenten haben, also nicht viele aber doch ein paar. Und daher werden wir (alles Anfänder wie ich) einen Workshop ohne Credits anbieten (Vorlesung trauen wir uns nicht zu). Die Wünsche zum Inhalt von Seiten der Studenten sind aber eher wenig anfängertauglich, also CCD, OpenCL, PCIe, ... Das macht aus meiner Sicht keinen Sinn und ich könnte da dann nur vorschlagen fertige Kerne zu verwenden was aber eben nicht bedeutet "FPGA zu lernen" und daher in einem Workshop, der hauptsächlich von Änfängern besucht werden wird nichts verloren hat. Oder geht es in die Richtung dass man einfach änfängt Kerne aneinanderzukleben? So wie heutzutage auch programmiert wird mit lauter Fremdbibliotheken?
:
Bearbeitet durch User
Wenn du ein PCIe-Interface implementieren willst, dann musst du auf vorgefertigte Komponenten zurückgreifen. Das gilt auch für viele andere spezialisierte Komponenten im FPGA. Der Einsatz vorgefertigter Komponenten gehört zur ernsthaften Nutzung von FPGAs klar dazu. Aber für Anfänger ist PCIe natürlich 3 Nummern zu groß. Was ich an deiner Stelle machen würde: a) den Leuten die Grundbegriffe der Hardwaresynthese in VHDL beibringen. Darauf achten, dass sie das Wesentliche verstanden haben (synchrones Design mit Registern, FSM, Multiplexer, ... und generell: den Unterschied zwischen Hardwarebeschreibung und Programmierung). b) Zusätzlich an 2-3 halbwegs einfachen Beispielen zeigen, wie man mit dem IP-Generator umgeht, um spezielle Komponenten zu nutzen(z.B. um ein FIFO aus BlockRAM einzubinden und um mit einem CLK-Manager unterschiedliche Frequenzen aus einem Eingangstakt abzuleiten.
Vielen Dank! Mir geht es nicht drum vorgefertigte Komponenten zu verteufeln, nein ich benutze die auch, aber eben nicht im Blindflug. Es gibt für jeden Blödsinn fertige Komponenten (BRAM, FIFO, ...) und viele davon kann man auch mal selber schreiben so wie es auch Lothar gemacht hat. Ich würde unten anfangen so wie ich es mal in einem Praktikum an der FH gelernt habe: - Kombinatorik - Zustandsautomaten - Simulation - und dann erst wie man sich Zeug generieren lässt. Das Problem: Bei einer Veranstaltung die nur einmal je Woche stattfindet wird man auch in einem ganzen Semester nicht sonderlich weit kommen. Das Ende des Praktikums an der FH (nach einem Semester) war eine Laufschrift auf 7-Segment-Anzeigen.
Gustl B. schrieb: > Wie macht ihr das so? Für mich sieht das irgendwie nach Spielzeug aus > bei dem man nicht viel verstanden haben muss um trotzdem schnell ein > fertiges System zu haben. Ich würde bei FPGAs immer von ganz unten mit > dem Lernen anfangen, aber vielleicht ändert sich diese Ansicht. Das Schreiben und Testen dieser Blöcke erfordert sehr viel Zeit (Kosten). Demnach handelt es sich keinesfalls um ein Spielzeug. Der Nutzen für denjenigen, der die Blöcke verwendet, ist immens. Dennoch gibt es auch Argumente, die gegen eine Verwendung der vom FPGA-Hersteller gelieferten Blöcke sprechen. Eines dieser Argumente ist genau der Grund, warum Dir der FPGA-Hersteller immer mehr Blöcke kostenlos liefert: Kundenbindung. > Es geht darum, dass wir an der Uni Nachfrage nach "FPGA" von Seite der > Studenten haben, also nicht viele aber doch ein paar. Und daher werden > wir (alles Anfänder wie ich) einen Workshop ohne Credits anbieten > (Vorlesung trauen wir uns nicht zu). > Die Wünsche zum Inhalt von Seiten der Studenten sind aber eher wenig > anfängertauglich, Achso... Welche Uni? In dem Fall sage ich: Blöcke kleben und den LED-Blink-Block mit dem SoC ansprechen. Dann einen Addierer dazu, usw. "SoC steuert VHDL-Block" wird auch in der Industrie benötigt und die Motivation der Studenten ist höher. Vielleicht kann man es mit "Mikrocontroller" oder "Programmierung" kombinieren oder im Rahmen von "Algorithmen und Datenstrukturen" > also CCD, OpenCL, PCIe, ... Das macht aus meiner Sicht > keinen Sinn und ich könnte da dann nur vorschlagen fertige Kerne zu > verwenden Wahrscheinlich wäre es möglich, ein fertiges Demoprojekt auf den FPGA zu laden. Aber es ist ungleich schwieriger, aus einem neuen, leeren Projekt heraus ein PCIe-Beispiel "zusammenzuklicken" und in Betrieb zu nehmen. > was aber eben nicht bedeutet "FPGA zu lernen" und daher in > einem Workshop, der hauptsächlich von Änfängern besucht werden wird > nichts verloren hat. Ja, aber wie gesagt aus anderen Gründen, als ursprünglich von Dir vermutet. Vielmehr denke ich, "Blöcke kleben" und "SoC steuert VHDL-Block" ist viel eher das, wonach die Studenten gefragt haben, als "Verbringen wir das gesamte Semester damit, mit VHDL einen UART zu schreiben". Wobei auch das nicht alle schaffen werden. Für letzteres muss aus der Person selbst heraus das Interesse kommen, sich in der Freizeit langfristig damit zu beschäftigen, weil die Veranstaltungszeiten dafür nicht ausreichen. Man kann dafür nur die Grundlagen legen. Allein diese haben (oder hatten früher?) bereits einen anderen Umfang, als was Dir zur Verfügung steht: Digitaltechnik (4/2), Rechnerorganisation (4/2/1) sowie HDLs und Simulation, .... Einen UART hatte ich einmal im Rahmen eines Praktiums im Hauptstudium im 5. oder 6. Semester in der Vertiefungsrichtung Technische Informatik schreiben lassen. Das war nicht zu leicht.
Danke für Deine Meinung! Ja, Lars R. schrieb: > In dem Fall sage ich: Blöcke kleben und den LED-Blink-Block mit dem SoC > ansprechen. Dann einen Addierer dazu, usw. > "SoC steuert VHDL-Block" wird auch in der Industrie benötigt und die > Motivation der Studenten ist höher. Richtig, aber: Macht das Sinn ohne die Grundlagen zu kennen? Ich würde mich da irgendwie nicht gut dabei fühlen wenn ich Anfängern zeige wie sie möglichst einfach ein System mit CPU zusammenklicken können ohne vorher Kombinatorik, den Aufbau von Zustandsautomaten, Constraints, Simulation, ... zu vermitteln. Und ja, es ist eher wenig Zeit, daher wird wohl Hardware mit nach Hause genommen werden dürfen. Ich würde trotzdem eher bei den Grundlagen angangen, also damit was Lothar hier jedem Anfänger predigt: Blinkende LED, Laufschrift, ...
:
Bearbeitet durch User
Gustl B. schrieb: > also damit was Lothar hier jedem Anfänger predigt: Blinkende LED, Richtig, es geht ja nicht darum, mit dieser blinkenden LED das komplette Semester herumzuhampeln. Aber an diesem einfachen Beispiel kann man schon mal das grundlegende Konzept eines "Clock Enables" auf zeigen. > Laufschrift, ... Uuups, Laufschrift, das wäre eher was für später... ;-) Aber letztlich geht es schon darum, Grundlagen zu erkennen und zu erklären. Und mögliches Fehlverhalten bei ungünstiger Beschreibung aufzuzeigen. Denn das Design innerhalb eines solchen Blocks mit den selben Methoden aufgebaut. Und wenn der trotz allen Tests "seltsames Verhalten" zeigt, dann ist es gut, solche grundlegenden Fehlermuster erkennen zu können. Das können die Studenten selber natürlich nicht einschätzen und wünschen sich dann absurde Dinge...
:
Bearbeitet durch Moderator
Oh sorry meinte so eine laufende LED auf einer Reihe mehrerer LEDs. Halt einfache Automaten. Laufschrift war wie geschrieben das was am Ende eines Semesters an der FH stand. Und auch das war für echt viele nicht trivial. Ich werde wohl vorschlagen, dass sich Jeder für den Workshop selber raussuchen kann was er will. Dafür wird es ja ein Workshop. Mit der Hilfe werde ich es dann wie im Forum halten und nur Tipps geben aber keine fertigen Lösungen. Die Teilnehmer müssen sich dann eben realistisch einschätzen wenn sie nicht stolpern wollen.
:
Bearbeitet durch User
Ich bin ganz klar der Meinung, dass man um die elementarsten Grundlagen nicht herum kommt und erst dann anfangen sollte, Cores zusammenzuklicken. Ich kann aus meiner Arbeit nur sagen, dass es in den allermeisten Fällen so war, dass es für das, was ich benötigte, gar keine Cores gab, weil es einfach zu speziell war. Lars R. schrieb: > Vielmehr denke ich, "Blöcke kleben" und "SoC steuert > VHDL-Block" ist viel eher das, wonach die Studenten gefragt haben, als > "Verbringen wir das gesamte Semester damit, mit VHDL einen UART zu > schreiben". Kann schon sein, dass es das ist, was die Studenten wollen. In der Klicki-Klicki-Bunti-Zeit.. Ist halt die Frage, ob man den Studenten das anbietet, was sie wollen, oder das, was sie brauchen? Hirnlos ein paar Cores in einem GUI zusammenklicken ist nicht FPGA lernen, sondern GUI lernen. FPGA lernen ist, zu verstehen, wie ein FPGA aufgebaut ist, was er kann und wie man diese Funktionen in HDL so beschreibt und constrained, dass sie dann auch synthetisierbar sind. Ich mache das jetzt schon viele Jahre und egal was ich code, ich sehe vor meinem inneren Auge dabei die Register etc "entstehen". Vielleicht ist das old-school, aber ich bin damit bis jetzt ganz gut gefahren.
Auch Dir vielen Dank! Genau so sehe ich das auch :-) Und genau das kostet eben viel Zeit bis man in Automaten und paralleler Logik denkt.
Gustl B. schrieb: > Danke für Deine Meinung! > > Ja, > > Lars R. schrieb: >> In dem Fall sage ich: Blöcke kleben und den LED-Blink-Block mit dem SoC >> ansprechen. Dann einen Addierer dazu, usw. >> "SoC steuert VHDL-Block" wird auch in der Industrie benötigt und die >> Motivation der Studenten ist höher. > > Richtig, aber: Macht das Sinn ohne die Grundlagen zu kennen? Es ist meiner Ansicht nach in Deinem Fall sinnvoll, damit zu beginnen. Am Beispiel des VHDL für eine blinkende LED und einen Addierer könntest Du auf einer need-to-know-Basis das Nötigste an Grundlagen vermitteln. Anschließend beispielsweise das Lauflicht. > Ich würde > mich da irgendwie nicht gut dabei fühlen wenn ich Anfängern zeige wie > sie möglichst einfach ein System mit CPU zusammenklicken können ohne > vorher Kombinatorik, den Aufbau von Zustandsautomaten, Constraints, > Simulation, ... zu vermitteln. Inkl. Constraints? Dazu VHDL-Syntax, die Entwicklungsumgebung, Arbeit am PC, und das ganze im Rahmen von 1-2SWS? Für Studenten, die Dich ernsthaft danach gefragt haben, innerhalb von 1-2SWS PCIe und OpenCL mit FPGAs machen? > Und ja, es ist eher wenig Zeit, daher wird wohl Hardware mit nach Hause > genommen werden dürfen. Das nützt wenig und die Software ist kostenlos. > Ich würde trotzdem eher bei den Grundlagen > angangen, also damit was Lothar hier jedem Anfänger predigt: Blinkende > LED, Laufschrift, ... Es spricht auch meiner Ansicht nach nichts gegen LED und Lauflicht. > Ich werde wohl vorschlagen, dass sich Jeder für den Workshop selber > raussuchen kann was er will. Dafür wird es ja ein Workshop. Mit der > Hilfe werde ich es dann wie im Forum halten und nur Tipps geben aber > keine fertigen Lösungen. Das wird schief gehen, denke ich. Schon allein deshalb, weil Du selbst gleichzeitig nur an einem Rechner sein kanst. > Die Teilnehmer müssen sich dann eben > realistisch einschätzen wenn sie nicht stolpern wollen. Ist das nicht Dein Job? > Auch Dir vielen Dank! Genau so sehe ich das auch :-) Und genau das > kostet eben viel Zeit bis man in Automaten und paralleler Logik denkt. Zeit, die Du nicht hast. Gut... ich habe alles gesagt, was ich beitragen kann. Viele Grüße Lars
Lars R. schrieb: > Inkl. Constraints? Dazu VHDL-Syntax, die Entwicklungsumgebung, Arbeit am > PC, und das ganze im Rahmen von 1-2SWS? Für Studenten, die Dich > ernsthaft danach gefragt haben, innerhalb von 1-2SWS PCIe und OpenCL mit > FPGAs machen? Ja. Es heißt schließlich FPGA-Workshop und das schließt aus meiner Sicht die Grundlagen ein. Zumindest soweit dass man nicht nur Komponenten generieren lassen kann sondern auch selber welche schreiben lernt. Lars R. schrieb: > Das wird schief gehen, denke ich. Schon allein deshalb, weil Du selbst > gleichzeitig nur an einem Rechner sein kanst. Ja, aber es wird mehrere im Workshop geben die schon etwas Ahnung haben. Im Praktikum an der FH gab es nur einen Betreuer und das hat auch geklappt wobei der auch viel wie in einer Vorlesung erklärt hat (Grundlagen). Es werden auch eher wenige Teilnehmer <10. Lars R. schrieb: > Ist das nicht Dein Job? Nein. Auf mich kam man zu weil ich als Student schon wo anders (Zulassungsarbeit) etwas mit FPGAs mache und sonst nicht wirklich viele was damit machen. Lars R. schrieb: > Zeit, die Du nicht hast. Auch richtig, daher setze ich sehr darauf, dass die Teilnehmer sich selber viel beibringen. Es wird keine Punkte geben also zählt sowieso nur Interesse.
Aus meiner Sicht ist das Problem hier nicht mit was fängt man an sondern die heutige Komplexität eines FPGA und der dazugehörigen Toolchain. Meine Herangehensweise wäre die Folgende: 1) Grundlagen: Automaten, Constraints, ... (kleines Projekt Lauflicht zur Übung) 2) Übergang zu SoC: 2a) Grundlagen über Prozessor, Bussysteme im FPGA, Theorie zum Auslagern der Komponenten aus dem Prozessor (finde ich sehr wichtig da so manche Leute meinen ein FPGA sei ja immer viel besser...) 2b) Übung z.B. umschreiben des Lauflicht IP-Cores zu einem Lauflicht mit Busanbindung über ein einfaches Registerinterface und Ansteuerung aus Software heraus. Aus meiner Sicht bringt dieses vorgehen die Grundlagen bei aber bringt auch einen ersten Kontakt zu SoC's der für einen Anfänger noch überschaubar ist. Und hierbei müssen keine fertigen Klicki-Cores (außer natürlich der CPU) genutzt werden (können aber nach Wunsch). Grüße
Danke! Dann stellt sich die grundlegende Frage CPU oder nicht CPU? Aus meiner Sicht kommt mit einer CPU eine zusätzliche Hürde hinzu und zwar dass der Teilnehmer Grundlagen der Rechnerarchitektur und auch eine Programmiersprache können sollte. Das kann ich leider nicht voraussetzen und im Rahmen des Workshops auch nicht vermitteln. Die Teilnehmer kommen aus dem Bereich Mathe/Physik und nicht aus Informatik, das gibt es bei uns nicht. Ich habe noch nichts mit SoC gemacht und auch nur einmal mit dem Mirkoblaze und C. Wie ist das mit SoC wie dem Zynq, muss man sich da mit Linux auskennen, eigene Treiber schreiben, C oder ähnliches beherrschen, ist das was für Anfänger? Aus meiner Sicht ist da (falls man mit dem PC kommunizieren möchte) ein UART deutlich geeigneter und auch auf PC Seite mit Python (oder noch einfacher mit einem Terminalprogramm wie Cutecom/Realterm) ohne eigene Treiber sehr leicht ansprechbar. Klar das ist lahm und als Fortgeschrittener will man das nicht, aber es ist einfach und trotzdem für Anfänger erstmal angemessen schwer.
Wenn die Studies am Ende des Workshops Spaß an und Lust auf VHDL haben sollen, dann sehe ich es als kontraproduktiv, einen Widerspruch zu konstruieren zwischen "Nutzung von IP-Cores" und "Verstehen, was man tut". Ja, man kann IP-Cores ohne jedes Verständnis zusammenklicken. Aber es muss nicht so sein. Man kann durchaus auch verstehen, was man tut, und trotzdem IP-Cores einsetzen, um für die Studenten interessante Anwendungen zu realisieren (auch jenseits der 7-Segment-Anzeige). Klar würde ich den Workshop mit wirklich elementaren Dingen beginnen. Die blinkende LED ist das "Hello World" des FPGAs. Und klar würde ich die Grundlagen auch so weit treiben, dass die Studies wissen, was sie mit VHDL beschreiben (ich hatte ja oben schon eine kleine Liste beschrieben, bei genauerem Nachdenken fallen einem wahrscheinlich noch ein paar Punkte für diese Grundlagenliste ein). Aber dann hätte ich keinerlei Bauchschmerzen damit, sinnvolle Komponenten einzusetzen, um innerhalb des Semesters auch anspruchsvolle Anwendungen zu realisieren. (Außer du willst mit dem Workshop erreichen, dass die Studies FPGAs öde finden). Ein Beispiel: den Studiwunsch CCD könntest du mit einer 1-DIM CCD-Zeile aufgreifen (kleines Spektrometer basteln, die Hardware dafür notfalls bei einem Edutainment-Versender kaufen). Für die Ansteuerung der CCD-Zeile brauchst du eine Statemachine und ein paar Zähler, darum kann sich ein Teil der Workshopteilnehmer kümmern. Das erste Erfolgserlebnis haben sie, wenn Sie das Ausgangssignal des CCD mit dem Oszi betrachten. Eine zweite Untergruppe des Workshops kann sich um Takterzeugung und Ansteuerung eines ADC kümmern. Die dritte Gruppe kümmert sich darum, die Daten im FPGA zwischenzuspeichern und "irgendwie" in einen PC zu bringen. Das kann über UART gehen (selbst geschrieben oder von woanders übernommen), und eröffnet damit fast schon die USB-Welt durch Anbindung an einen FT232. Wenn UART zu kompliziert ist, dann über SPI auf einen (externen) µC, der seinerseits eine UART bedient. An fertigen Komponenten werden eingesetzt: - BlockRAM: klar kann man den auch direkt in VHDL beschreiben, aber dann muss ich auch (auswendig) lernen, wie genau die Beschreibung auszusehen hat, damit BlockRAM benutzt wird. Ich sehe keine wirklichen Vorteil gegenüber der Nutzung des IP-Assistenten, mit dem die Studies halt auch umgehen lernen sollten. - evtl. CLK Manager (ist aber eigentlich nicht nötig) - ggf. eine UART (nicht unbedingt was von Xilinx, gerne auch eine sinnvolle Beschreibung aus dem Netz. Lothar hat doch sicher sowas auf seiner Seite ;-) Zusammengefasst: mein Ziel wäre, dass die Studies die Grundlagen verstehen und dass sie Spaß an der Anwendung haben (nicht entweder - oder). Dazu brauchen sie eine Anwendung, der sie einen Nutzen zuordnen (auch wenn es ein "spielerischer" Nutzen ist) und die sie als Herausforderung annehmen. Ich würde mich schwertun, ihnen die Siebensegmentanzeige als solche Anwendung zu verkaufen.
Genau, klar sollen Komponenten verwendet werden und Dein Vorschlag ist ziemlich gut. Clockmanager klar, BRAM ist eigentlich komplizierter wenn man die generierte Komponente verwendet finde ich. UART ist ein sehr schönes Beispiel für einen Automaten den man auch gut selber schreiben und auch simulieren kann. Sonst finde ich motivierende Beispiele auch sehr gut, 7-Segment war eben das mit dem ich angefanhen habe aber ja, das ist eher trocken. Gut wäre auch eine Anfängeranwendung die über das was ein uC kann hinausgeht. Z. B. VGA-Video und das Anzeigen von ADC Messwerte auf dem Bildschirm. Quasi eine Art sehr einfaches Oszilloskop mit einfachem Trigger und so. Ein weitere Beispiele die noch Anfängergeeignet sind wären: 1. Ein Frequenz/Signalgenerator mit VGA als DAC für Sinus, Rechteck, Sägezahn. Steuerung über Drehgeber oder vom PC aus über UART. 2. Ansteuerung einer RGB-LED mit PWM über Drehgeber/UART. 3. Uhr/Stoppuhr 4. FM-Sender der das Audio über einen ADC bekommt 5. 1Bit PWM Audio vom ADC zu PWM mit Lautstärkeregelung und so oder Audio über UART an FPGA nach PWM. Das ist alles machbar und braucht eigentich kaum fertige Komponenten. Was ich mit Komponenten unverstanden zusammenkleben meinte ist eher das generieren von Komplettsystemen mit CPU, DDR-RAM und so. Das geht auch und motiviert vermutlich auch, ist aber aus meiner Sicht nichts für Anfänger.
Gustl B. schrieb: > Das ist alles machbar und braucht eigentich kaum fertige Komponenten. Stimmt, aber das ist kein Vorteil: wenn die Studies mit Komponenten umgehen lernen, ist das gut, nicht schlecht ;-) Gustl B. schrieb: > Was ich mit Komponenten unverstanden zusammenkleben meinte ist eher das > generieren von Komplettsystemen mit CPU, DDR-RAM und so. So weit würde ich in einem Anfängerworkshop mit Sicherheit auch nicht gehen.
Ok, dann sehen wir das ähnlich. Wo es nötig und nützlich ist verwende ich auch fertige Komponenten, und das sollte auch definitiv Inhalt des Workshops werden. Wenn ich aber sehe wie manche Tutorials zu FPGA-Boards aufgebaut sind, dann besteht das nur daraus sich ein fertiges System zusammenzuklicken. Das ist zwar auch schön weil man dann sehr schnell Hardware verwenden kann die sehr leistungsfähig ist (SerDes, PCIe, DDR-RAM) und das ist vielleicht auch gewünscht von Seiten der Teilnehmer, bringt aber aus meiner Sicht nicht viel ohne die Grundlagen. Speziell meine ich sowas wie das QSYS von Altera. Ich habe hier das Buch VHDL-Synthese, da geht es die ersten 200 Seiten eigentlich nur um Grundlagen, auch mit dem Kapitel "Komponentengeneratoren".
>> Und ja, es ist eher wenig Zeit, daher wird wohl Hardware mit nach Hause >> genommen werden dürfen. > Das nützt wenig und die Software ist kostenlos. Es schadet sogar, denn dann arbeiten 50% damit und kommen weiter. Die anderen 50% tun nichts und werden abgehängt... Gustl B. schrieb: > Wenn ich aber sehe wie manche Tutorials zu FPGA-Boards aufgebaut sind, > dann besteht das nur daraus sich ein fertiges System zusammenzuklicken. Die sind auch dafür da, dass der FAE vor einer Gruppe Leute in 3 Stunden etwas lauffähiges zuwege bringen kann. Das mit der CPU auf dem FPGA wäre für mich eine eigene Vorlesung. Denn letztlich komm dann ein neuer Freiheitsgrad und eine neue Toolchain dazu: die Software.
Lothar M. schrieb: > Es schadet sogar, denn dann arbeiten 50% damit und kommen weiter. Die > anderen 50% tun nichts und werden abgehängt... Es wird ein Workshop, da haben sowieso nicht alle den gleichen Stand oder machen die selben Dinge. Es wird eher so sein, dass sich die Teilnehmer selber ihre Themen suchen können und es dann auch an ihnen selber liegt wie viel sie tatsächlich lernen. Andernfalls müsste man das doch ähnlich einer Vorlesung/Unterricht aufbauen und langweilt dann Diejenigen die schon Vorwissen haben. Lothar M. schrieb: > Das mit der CPU auf dem FPGA wäre für mich eine eigene Vorlesung. Denn > letztlich komm dann ein neuer Freiheitsgrad und eine neue Toolchain > dazu: die Software. Sehe ich auch so, das könnte man als Fortsetzung des Mikrokontrollerkurses machen.
Gustl B. schrieb: > Danke! > > Dann stellt sich die grundlegende Frage CPU oder nicht CPU? > > Aus meiner Sicht kommt mit einer CPU eine zusätzliche Hürde hinzu und > zwar dass der Teilnehmer Grundlagen der Rechnerarchitektur und auch eine > Programmiersprache können sollte. Das kann ich leider nicht voraussetzen > und im Rahmen des Workshops auch nicht vermitteln. Die Teilnehmer kommen > aus dem Bereich Mathe/Physik und nicht aus Informatik, das gibt es bei > uns nicht. Achso. Dann nehme ich meine Empfehlung von weiter oben zurück. Nimm stattdessen Matlab, Simulink, Xilinx System Generator und ein passendes Board dazu. 30-Tage-Lizenzen gab es mal kostenlos. Vielleicht lässt der Xilinx-Ansprechpartner mit sich reden. Alternativ einen Schematic-Editor. Ggf. mit http://papilio.cc/ oder ähnliches. Keinesfalls VHDL. Welche Uni?
Gustl B. schrieb: > Die Teilnehmer kommen aus dem Bereich Mathe/Physik und nicht aus > Informatik, das gibt es bei uns nicht. Aua, übersehen... :-/ Dann passt das, was Lars R. schrieb: >> Nimm stattdessen Matlab, Simulink, Xilinx System Generator und ein >> passendes Board dazu. Und dann kannst du auch gleich den Speicher-Core und den PCIe- oder USB3- oder 10Gigabit-Ethernet-Core mit reinpacken. Denn genau diese "einfache" Vorgehensweise ist es, von der der Mathworks-Verkäufer den Jungs auf der Messe erzählt und vorgeschwärmt hat...
:
Bearbeitet durch Moderator
Lars R. schrieb: > Keinesfalls VHDL. Lothar M. schrieb: > Und dann kannst du auch gleich den Speicher-Core und den PCIe- oder > USB3- oder 10Gigabit-Ethernet-Core mit reinpacken. Denn genau diese > "einfache" Vorgehensweise ist es, von der der Mathworks-Verkäufer den > Jungs auf der Messe erzählt und vorgeschwärmt hat... Hallo? Meint ihr das ernst? Das wird ein Workshop für Anfänger und es wird ein FPGA-Workshop, also kein Simulink-Workshop. Ich bezweifle auch sehr, dass Erfahrung mit Matlab vorhanden ist weil es keine FH sondern eine Uni (ohne Etechnik) ist. Also da ich selber keine Erfahrung mit Matlab in Bezug auf FPGAs, PCIe- oder USB3- oder 10Gigabit-Ethernet-Core habe werde ich mich dann wohl daraus zurückziehen und das Jemanden anders machen lassen. Ich könnte wirklich nur Grundlagen anbieten. Lars R. schrieb: > Alternativ einen Schematic-Editor. Ggf. mit http://papilio.cc/ oder > ähnliches. Schematic wollte ich eigentlich auch nicht machen, vielleicht mal herzeigen aber auch nicht mehr. Hm ...
:
Bearbeitet durch User
Ja. Das, was Du Dir zunächst mit besten Absichten überlegt hast, ist so unheimlich weit von der Erwartungshaltung der Studenten entfernt. Möglicherweise auch von der Erwartungshaltung derer, die Dich von Uni-Seite dafür anfragen. Insbesondere auch, was das "Ergebnis" des Kurses anbelangt. Du möchtest VHDL mit Studenten benutzen, die keine Informatikstudenten sind, nicht programmiert haben und womöglich auch Matlab noch nicht gesehen haben. Überleg Dir das doch einmal in Ruhe selbst. > Also da ich selber keine Erfahrung mit Matlab in Bezug auf FPGAs, PCIe- > oder USB3- oder 10Gigabit-Ethernet-Core habe werde ich mich dann wohl > daraus zurückziehen und das Jemanden anders machen lassen. Ich könnte > wirklich nur Grundlagen anbieten. Die Konsequenz könnte auch hier wieder richtig sein, aber die Annahme ist falsch. Mit dem System Generator kann man auch Zustandsautomaten modellieren und LEDs blinken lassen. Vorher anschauen müsstest Du Dir die Sache natürlich und vermutlich wäre es auch für Dich ganz interessant. Das FPGA-Systemgenerator-Simulink-Design, welches automatisch auf den FPGA geladen wird auf dem FPGA "läuft", kommuniziert mit dem Systemgenerator-Simulink-Design, welches auf dem PC läuft. Bei Designs bestehen lediglich aus zusammengeklickten und konfigurierten Symbolen. Der Rest läuft im Hintergrund. Wahlweise Cycle-akkurat oder Continuous (oder wie das dort heißt) Als ich das vor einigen Jahren angeschaut hatte, lief das problemlos über UART. Und ich glaube, auch über Ethernet. Ich weiß nicht, wie weit die inzwischen sind. Vielleicht gibt bei der Co-Simulation inzwischen auch die Auswahl "PCIe". Dann läuft es halt über PCIe-Core. Den brauchst Du ggf. nicht mal selbst einbinden. Jedenfalls werden nur für bestimmte Boards die passenden Board-Files im Systemgenerator mitgeliefert. Und so ein Board musst Du dafür nehmen. Dann ist schon alles vorbereitet. Ganz ähnliche Lösungen gibt es auch von NI. Die bieten zu Ihren Umgebungen sogar regelmäßig kostenlose Ganztagsseminare an.
Ja, klar das liegt vielleicht näher an der Erwartungshaltung, ist für mich dann aber kein FPGA-Workshop mehr. Ich werde das mal abklären mit den anderen Beteiligten. Ausserdem möchte ich keine Abhängigkeit zu irgendwelchen Herstellern oder Boards, also Matlab können Studenten nicht daheim benutzen und die Boards mit denen das zusammenarbeitet sind halt auch oft teuer. Naja, wenn der Workshop in diese Richtung gehen sollte wäre ich vielleicht auch froh wenn ich das dann nicht mitbetreue. Jedenfalls Danke für Deine Sicht der Dinge! Du hast auch völlig Recht, dass man sonst innerhalb eines solchen Kurses von Null an nicht so sonderlich viel schaffen würde. Lars R. schrieb: > Du möchtest VHDL mit Studenten benutzen, die keine Informatikstudenten > sind, nicht programmiert haben und womöglich auch Matlab noch nicht > gesehen haben. Überleg Dir das doch einmal in Ruhe selbst. Darin sehe ich jedoch keinen Widerspruch, da VHDL von anderen Sprachen, Prorammiersprachen, sehr unterschiedlich ist, es ist eine Beschreibungssprache mit komplett anderer Denkweise.
Gustl B. schrieb: > Lars R. schrieb: >> Du möchtest VHDL mit Studenten benutzen, die keine Informatikstudenten >> sind, nicht programmiert haben und womöglich auch Matlab noch nicht >> gesehen haben. Überleg Dir das doch einmal in Ruhe selbst. > > Darin sehe ich jedoch keinen Widerspruch, da VHDL von anderen Sprachen, > Prorammiersprachen, sehr unterschiedlich ist, es ist eine > Beschreibungssprache mit komplett anderer Denkweise. Dann solltest Du meiner Ansicht nach mit dem Geben solcher Kurse "ganz vorsichtig sein". Unabhängig davon, in welcher Art und Weise der Kurs letztlich erwartet wird. Die Begründung dazu formuliere ich nicht aus, weil ich nicht weiß, wie ich es in wenigen Sätzen verständlich ausdrücken kann... parallel, sequentiell, Programmablaufpläne, Wie oft wird eine Schleife durchlaufen?, Syntax, Was sind sequentielle VHDL-Zuweisungen, was sind parallele (nur Signale betrachtet), Zuweisungen default cases (nicht case-Statement), Latches statt FFs, Anfänger-multiple-drivers-Error, Bitbreiten, int, std_logic, unsigned/signed, Effekte des Simulators (angefangen bei der Sensitivity list), usw. Das alles und noch viel mehr (constraints...) mit Leuten, bei denen Du mit print HelloWorld und if/else anfängst. Edit: Troll?
:
Bearbeitet durch User
Lars R. schrieb: > Edit: Troll? Ich betrachte so langsam eher Dich als Troll und wünsche mir mehr Kommentare von Anderen. Hier im Forum haben immer wieder Anfänger mit Vorkenntnissen aus Programmiersprachen starke Probleme mit der Beschreibungssprache VHDL. Lars R. schrieb: > parallel, > sequentiell, Programmablaufpläne, Wie oft wird eine Schleife > durchlaufen?, Syntax, Was sind sequentielle VHDL-Zuweisungen, was sind > parallele (nur Signale betrachtet), Zuweisungen default cases (nicht > case-Statement), Latches statt FFs, Anfänger-multiple-drivers-Error, > Bitbreiten, int, std_logic, unsigned/signed, Effekte des Simulators > (angefangen bei der Sensitivity list), usw. Und was soll es bei all dem helfen vorher C oder einen andere Programmiersprache zu können? Ich konnte vor VHDL schon etwas C und mir hat das nicht wirklich geholfen. VHDL sieht eher wie Pascal aus, hat aber auch mit Pascal nicht viel gemein, es ist eine Beschreibungssprache. Egal, ich hab jedenfalls auch Deine Meinung gelesen, Danke dafür.
Lars R. schrieb: > Du möchtest VHDL mit Studenten benutzen, die keine Informatikstudenten > sind, nicht programmiert haben und womöglich auch Matlab noch nicht > gesehen haben. Die studieren BWL. Lars R. schrieb: > Das alles und noch viel mehr (constraints...) mit Leuten, bei denen Du > mit print HelloWorld und if/else anfängst. Oder gar so: Leute, die das Schreiben eines Briefes mit Word schon mit "Programmieren" gleichsetzen. Na gut, das ist jetzt ein wenig überspitzt ausgedrückt, trifft aber vermutlich das Ziel ganz gut. Wenn die Jungs erwarten, dass du ihnen Matlab/Simulink (für Mathematiker und Physiker) beibringst, und du fängst mit VHDL-Grundlagen an, dann ist es, wie wenn du einem Word-Briefeschreiber das Message- und Treibermodell von Windows erklärst. Er wird sagen "Thema verfehlt", obwohl du sicher bist, dass das Wissen um die Interna wichtig ist, um den Rechner sicher und effizient am Laufen zu halten. Und beide haben Recht. Nur haben beide auch nichts von der aufgewendeten Zeit... > Ich werde das mal abklären mit den anderen Beteiligten. Und mit den Studenten... Lars R. schrieb: > Edit: Troll? Nein, leider nicht. So ist das Leben... :-/
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Lars R. schrieb: >> Du möchtest VHDL mit Studenten benutzen, die keine Informatikstudenten >> sind, nicht programmiert haben und womöglich auch Matlab noch nicht >> gesehen haben. > Die studieren BWL. Ja. "Kein Matlab" stand vom TO so im Raum. Deshalb schrieb ich "womöglich". > Lars R. schrieb: >> Edit: Troll? > Nein, leider nicht. So ist das Leben... :-/ Ja, unbedacht und voreilig von mir. Danke. :)
Lothar M. schrieb: > Die studieren BWL. Nein, das machen wir nicht und ist wenig hilfreich. Lothar M. schrieb: > Nein, leider nicht. So ist das Leben... :-/ Das ist auch nur bedingt hilfreich. Wir haben interessierte Studenten (ich bin auch einer) die gerne etwas zu FPGAs lernen möchten. Daher wollen wir einen FPGA-Workshop anbieten. Die Frage ist jetzt was man da genau macht, inhaltlich. Hast Du da eine Empfehlung Lothar? Generell würde mich interessieren ob VHDL von Grund auf, fertige Systeme zusammenklicken, eine Mischung daraus oder etwas mit SoC? Da es ein FPGA-Workshop werden soll möchte ich vor allem nichts voraussetzen müssen was man nicht wirklich benötigt (Matlabkenntnisse, Programmiererfahrung, Linuxkenntnisse). Die Projektideen die ich oben noch zusätzlich zu der Idee mit der CCD-Leiste aufgelistet habe Gustl B. schrieb: > Ein weitere Beispiele die noch Anfängergeeignet sind wären: > > 1. Ein Frequenz/Signalgenerator mit VGA als DAC für Sinus, Rechteck, > Sägezahn. Steuerung über Drehgeber oder vom PC aus über UART. > 2. Ansteuerung einer RGB-LED mit PWM über Drehgeber/UART. > 3. Uhr/Stoppuhr > 4. FM-Sender der das Audio über einen ADC bekommt > 5. 1Bit PWM Audio vom ADC zu PWM mit Lautstärkeregelung und so oder > Audio über UART an FPGA nach PWM. sind alle ohne Vorkenntnisse machbar, vermutlich auch innerhalb eines Semesters.
> Oder geht es in die Richtung dass man einfach änfängt Kerne > aneinanderzukleben? So wie heutzutage auch programmiert wird mit lauter > Fremdbibliotheken? Wenn dein Projekt aus verschiedenen Mudulen besteht, von denen du kein Support bekommst, wirst du Schiffbruch erleiden. Du kannst kein Quellcode anschauen und das hinterlegt Beispiel passt aus verschiedenen Gründen nicht, dann brauchst du schon mal interes Wissen und das ist sehr schwer zu beschaffen.
Gustl B. schrieb: > Braucht man dazu noch eigene VHDL Kenntnisse? Man braucht grundlegende Kenntnisse, z.B. über clock Domains > Ich würde bei FPGAs immer von ganz unten mit dem Lernen anfangen, Meiner Meinung nach nicht sinnvoll. Man kann (in VHDL) beliebige Konstrukte formulieren, die nie synthetisierbar sind. Man muss bei Logikschaltungen auch nichts über Dotierung der Transistoren wissen. Wenn man VHDL/FPGA jemandem wirklich näher bringen will, fängt man nicht mit esoterischem Ballast an. Gustl B. schrieb: > wollen wir einen FPGA-Workshop anbieten. Die Frage ist jetzt was man da > genau macht, inhaltlich. Man fängt beispielsweise mit Logikschaltungen an. Einfache Gatterschaltungen und Register. Man macht am zweiten Abend weiter, in dem man (im ersten Abend fertig gemachte) Gatterschaltungen (wie Volladdierer) verbindert, so wie man TTL-Bausteine verbinden würde. Dann kann man am dritten Abend auch mal komplexe IP nehmen, über deren Innenleben nichts bekannt ist (z.B. ein UART). Natürlich gibt es, wenn man ganz tief in den Grundlagen anfängt, auch manche Optimierungsschritte, die man sonst nicht kennenlernt, aber das ist akademisch. Gustl B. schrieb: > Ich habe hier das Buch VHDL-Synthese, da geht es die ersten 200 Seiten > eigentlich nur um Grundlagen, Ja, es gibt haufenweise schlechter Bücher, mit der Absicht, Konkurrenten mit sinnlosem Ballast zuzuschmeissen, damit man selber schneller weiter kommt. Achim S. schrieb: > Ja, man kann IP-Cores ohne jedes Verständnis zusammenklicken. Aber es > muss nicht so sein. Bei simplen IP (Halbaddierer :-) kann jeder noch beim Entstehen mitmachen, beim komplexen (z.B. UART mit 16-fachem Takt) muss man das nicht mehr machen, das unterscheidet sich nicht vom einfachen, kostet nur mehr Zeit. Achim S. schrieb: > Die dritte Gruppe kümmert sich darum Schlecht. So bekommst du Leute, die nur Teilbereiche kennen und immer noch keine Ahnung haben, wie es zusammenspielt.
Was sicher ein Ziel sein kann, das dauert eben auch Jahre sich wiederverwendbare Module zu schaffen. Diese kosten aber auch Zeit und muss gepflegt und dokumentiert werden. Ich hatte da mal ein SPI Modul angefangen. http://www.dossmatik.de/vhdl/spimaster.pdf Meine Grundidee ist eine Softcore-CPU zu nutzen und den größten Teil der Programmierung in C auszulagern. Das ist den meisten Programmieren bereits vertraut. So kann man schneller die Jungs begeistern, die breits mit Mikrocontrollern zu tun hatten. Die Toolchain wird aufwendiger und ist schon Vorlesung Teil 2. Du sucht aber noch was für Einsteiger.
MaWin schrieb: > Man fängt beispielsweise mit Logikschaltungen an. Einfache > Gatterschaltungen und Register. Genau das meinte ich mit "Grundlagen" also Kombinatorik, Zustandsautomaten, Constraints, Simulation, ... oder sollte man das weglassen? Ich finde das sehr wichtig. MaWin schrieb: > Man muss bei Logikschaltungen auch nichts über Dotierung der > Transistoren wissen. Das wäre mir auch zu tief. Vielen Dank René! So wie Du sehe ich das auch und haben es weiter oben auch Andere. Klar braucht man auch fertige Komponenten, aber eben nur da wo es nützlich ist. Selbst bei einem UART ist das fraglich. Wenn man etwas lernen will, dann schreibt und simuliert man den selber, wenn man nur will dass es funktioniert nimmt man den fertigen Block.
Gustl B. schrieb: > So wie Du sehe ich das auch und haben es weiter oben auch Andere. An einer Elektronik Hochschule sehe ich es als sehr sinnvoll an, mit Grundlagen auf Bitebene loszulegen. Aber du selbst hast geschreiben, dass die Wünsche anders aussehen: Gustl B. schrieb: >>> Die Wünsche zum Inhalt von Seiten der Studenten sind aber eher wenig >>> anfängertauglich, also CCD, OpenCL, PCIe, ... Deshalb musst du dich fragen: Wenn einer einen Rennwagen aus Carbon bauen will, hat der dann Spass daran, einen Roller aus Holz zu basteln? Gustl B. schrieb: > Da es ein FPGA-Workshop werden soll Das ist das Problem: der Name! Ein FPGA-System ist ein Blinklicht genauso wie ein PCIe gekoppelter 32-Bit-Prozessor mit DDR. Wenn du es schaffst, den Studis den OpenCL und PCIe Zahn zu ziehen und zu sagen: "Jetzt lassen wir erst mal was Rollen, das ist auch schon Fortbewegung!" und wenn sie dann trotzdem kommen, dann kann das was werden. Aber es ist eben kein "FPGA-Workshop" im Sinne von Mathematikern/Physikern (wie binde ich ein FPGA an meinen Rechner an um die Berechnung von Bitcoins/Wettermodellen zu beschleunigen), sondern einer im Sinne von Elektrikern (wie werden Zahlen dargestellt und verarbeitet). > Hast Du da eine Empfehlung Lothar? Stell dein Konzept auf. Mit Sachen, bei denen du dich auskennst. Und biete das an. Wenn einer Interesse hat, dann soll und wird er kommen. René D. schrieb: > So kann man schneller die Jungs begeistern, die breits mit > Mikrocontrollern zu tun hatten. Es sind Physiker und Mathematiker, keine Elektroniker. MaWin schrieb: > Gustl B. schrieb: >> Ich habe hier das Buch VHDL-Synthese, da geht es die ersten 200 Seiten >> eigentlich nur um Grundlagen, > Ja, es gibt haufenweise schlechter Bücher, mit der Absicht, Konkurrenten > mit sinnlosem Ballast zuzuschmeissen, damit man selber schneller weiter > kommt. Lustigerweise zählt gerade dieses Buch nicht zu den Schlechten. Überhaupt nicht...
Das Buch hatte ich auch auf Deine Empfehlung hin gelesen und für sehr lehrreich befunden :-) Ja, ich werde mal evaluieren was wirklich das Interesse ist, und dann werde ich anbieten was ich eben so zu bieten habe. Klar wird der Workshop offen sein für alles, aber bei machen Dingen können die Betreuer wie ich eben nicht helfen. Ich bin gespannt was daraus wird.
Moin, wenn die Wünsche der Interessierten anders aussehen, könnte ich noch den Einstieg per MyHDL empfehlen. Die meisten Wissenschaftler kommen irgendwann an Python nicht vorbei, da ist die Hürde zumindest, was das Code schreiben angeht, dann nicht so hoch und man muss sich mit den mühsamen Hinterlassenschaften von "verbosen" (sorry für denglisch, aber "geschwätzig" klingt auch doof) Sprachen wie VHDL oder dem hässlichen Verilog nicht herumschlagen. Und: Man lernt gleich anständig zu simulieren, denn der Simulator ist mit drin. Vorteil an MyHDL ist, dass man genau wie bei VHDL immer noch "elektronisch" statt "programmatisch" denken muss, aber bei der Simulation gleich ein anständiges Scripting zur Hand hat. Das spart viele Wochen bei der Verifikation. Wenn Du in Richtung SoCs willst, was ich jetzt im ersten Anlauf ne recht grosse Nummer finde, gibt's eigentlich nur wenige Möglichkeiten: Gleich den Kram vom FPGA-Hersteller nehmen (kann für gelegentliches Unwohlsein sorgen) oder einen von vielen mehr oder weniger akademischen Ansätzen adaptieren. Zum Thema SoC-Entwurf ohne Schreib-Overhead gibt es einige interessante einigemassen generische Sachen: - IP-XACT und ähnliche XML-Ansätze zur Code-Generierung - kactus2 Toolchain - DesignLab / ZPUino Ich persönlich bin eher ein Fan von XML und kconfig/Makefiles, aber da tickt jeder anders. Grüsse, - Strubi
Hallo, vielen Dank! SoC halte ich auch für ein paar Nummer zu groß, vor allem weil man dafür Anforderungen wie Grundkenntnisse der Rechnerarchitektur mitbringen sollte und auch C können muss. MyHDL werde ich mir mal angucken bei Gelegenheit, ich finde aber auch VHDL ganz in Ordnung, so sonderlich viel Tipparbeit ist die Geschwätzigkeit auch nicht.
> René D. schrieb: >> So kann man schneller die Jungs begeistern, die breits mit >> Mikrocontrollern zu tun hatten. > Es sind Physiker und Mathematiker, keine Elektroniker. Ich kann gut mitfühlen. Ich war als Student HIWI bei den Physikern. Meine Aufgabe war es Messaufbauten zu bauen. Programieren konnen die alle sehr sehr schnell. Nur bei der Sprache mit Fachbegriffen hat es etwas gedauert, bis die Physiker ihr komplexes System auftröseln konnen und einem Fachfremden Ihr Problem erklären konnten. Ich sehe die gleiche Sprachlücke bei deinen Leuten und dir.
Da es ja um eine Grundsatzfrage zu Designstrategien geht, kann mal jemand was zu den Xilinx Software Defined x-Methoden sagen? Habe es bisher nicht benutzt, klingt aber interessant. So etwas in der Art, um FPGAs für SW-Designer zugänglich zu machen? http://www.eejournal.com/archives/articles/20141202-xilinx/ http://www.eejournal.com/archives/articles/20150317-sdsoc/ Zum konkreten Praktikumsfall gibt wie ja schon gesagt mehrere Methoden, je nach Motivation und Kenntnissen der Teilnehmer. Wenn es sich um ausreichend Teilnehmer mit genug Eigenmotivation handelt, mach doch mehrere kleine Gruppen und baue ein größeres Projekt aus vielen Gruppenteilleistungen, was auch für Physiker/Mathematiker interessant ist und wo am Ende was greifbares rauskommt, z.B. Richtung Audio- oder Bildverarbeitung. Wenn z.B. eine Gruppe eine Kosinustransformation umsetzt, eine andere Quantisierung und Codierung usw. , dann haben alle auch bißchen Mathekenntnisse angewendet und was über Umsetzung von Protokollen in HW gelernt. Am Ende könnte man das in ein von dir schon bereitgestelltes größeres Projekt einbinden und z.B. eine MP3/ein jpg decodieren o.ä . Dafür musst du natürlich selbst schon Interfaces definieren und ein Simulationsmodell bereitstellen, damit jede Gruppe unabhängig voneinander vorankommt.
Das sieht sehr interessant aus, habe ich nicht nix von gehört. Nochmal zu dem Ansatz sich von der Entwicklungsumgebung alles generieren zu lassen wie mit diesem QSYS von Altera, ich denke da sollte man unterscheiden. Es gibt Anwendungsfälle, für die gibt es alles fertig, zwar nicht komplett aber in einzelnen Blöcken. Das kann man sich dann ohne VHDL-Kenntnisse generieren lassen. Das ist vor allem im Bereich des Rechnens sinnvoll oder bei Signalverarbeitung. Und es gibt auch Probleme die man mit einem FPGA lösen möchte, für die es nicht alles schon gibt, also z. B. wenn man eigene Hardware gebaut hat und die anbinden möchte. Dann kommt man um eine Beschreibungssprache nicht herum. Ersteres ist für Physiker/Mathematiker wohl sinnvoll wenn es nur um das Rechnen geht, wenn aber selbst gebaute Geräte bedient werden sollen und man da eigene Hardware an das FPGA anschließt braucht man schnell wieder Kenntnisse von Hardware und Beschreibungssprache. Dieses SDx sieht mir auch sehr danach aus wie eine Hilfe Rechenprobleme zu beschleunigen, also man will ein Problem rechnen das sich schön parallelisieren lässt, man hat ein dickes FPGA und dann beschreibt man das Problem in Software und es wird automatisch ins FPGA gesteckt. So wie OpenCL und andere. Das ist aber vermutlich etwas komplett anderes wie wenn man mit dem FPGA selber ein Gerät baut. Das spaltet sich meiner Meinung nach in einen Teil von Anwendungen ohne Notwendigkeit der Kenntnisse von Beschreibungssprachen und ein Teil mit. Was man jetzt in einem Workshop behandelt wird sich nach der Nachfrage richten.
MaWin schrieb: > Man muss bei Logikschaltungen auch nichts über Dotierung der > Transistoren wissen. Das hätte ich bis vor Kurzem auch noch gedacht, habe aber wegen dem hier eine andere Meinung: Beitrag "Re: uC mit sicherem RAM ausstatten"
Ja gut, klar kann man immer tief eintauchen, aber das ist dann meist nicht sinnvoll für das Zeil das man erreichen möchte. Die Frage stellt sich auch, ob es sinnvoll ist VHDL zu erlernen oder generell alles mit Simulink/Labview/QSYS/... zu machen. In diesem Fall für einen Workshop entfällt da aber weil dafür Grundlagen in anderen Bereichen benötigt würden. Nur mit VHDL und den Design-Werkzeugen des Herstellers kommt man auch schon relativ weit und verlangt keine Voraussetzungen von den Teilnehmern - ausser Motivation.
Man muss das eben gedanklich trennen: 1. Abläufe: FSMs, vFSMs, ALUs, C oder ASM auf Softcore 2. SoC - Verschaltung: SoC-Designtool 3. Modulare Verschaltung: VHDL, HDL-Designer 4. SV-Cores: Mathematik, Simulink 5. IO-Cores: VHDL, Megawizzard 6. Elektronik: Pegel, Ströme, physische Interfaces, LVDS Positionen 1 (und 2) kann man mit Softwareentwicklern besetzen, Positionen 4 kann man mit Physikern und Systemern besetzen Der Rest erfordert FPGA- und Digital-Kenntnisse und manchmal analoge Kenntnisse
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.