Hallo, Ich mache seit einiger Zeit videotutorials über FPGA. Ich denke diese videos können sehr gut bei dem Einstieg in die FPGA Geschichte helfen: Videos sind auf English. Das erste Video is ohne Stimme, danach habe ich doch versucht auf english zu sprechen( ich habe seit vielen Jahren kein english gesprochen, aber es wird langsam Zeit), wie erfolgreich das war, musst ihr mir sagen:) FPGA Tutorial 1. Blinking LEDs on DE1 Altera Board http://www.youtube.com/watch?v=T9VbBI3foGQ FPGA Tutorial 2. Functions and procedures in VHDL on DE1 Altera Board http://www.youtube.com/watch?v=j2lAPIjpF1w FPGA Tutorial 3. UART in VHDL on Altera DE1 Board http://www.youtube.com/watch?v=fMmcSpgOtJ4 FPGA Tutorial 4: VGA interface in VHDL on DE1 Altera Board http://www.youtube.com/watch?v=mS0VZwnZssA
Bei allem Respekt und Zustimmung für die Absicht, wird mir doch spontan wieder das alte Problem der Video-Youtube-Internet-Zeit bewusst: Es darf jeder posten. Das Ergebnis sind Präsentationen weit weg von dem was nötig und sinnvoll ist, gespickt mit Grafik und Vidoe und Musik, die das Thema konterkarieren. Es gab Studiengänge, wo sowas unterrichtet wurde, wie man Farben benutzt, wie man Musik benutzt, und vieles mehr. Gerade Musik ist ein Thema für sich. Wer da nicht fit ist, dem empfehle ich, WEGLASSEN! Puristisch ist immer besser, als falsche Additive! Das ist die erste Regel die man lernt. Leider lernt keiner was und das Netz ist voll mit Mist. Ich habe wegen der Musik, dem Kratzen und dem Rauschen schon gleich abgeschaltet, weil ich es als unangenehm empfinde! Lasst die Finger von den Soundmixprogrammen, dem Kompressor und den Grafikvideotrickkisten. Weniger ist mehr.
> Ich habe wegen der Musik, dem Kratzen und dem Rauschen schon gleich > abgeschaltet, weil ich es als unangenehm empfinde! Es gibt da so eine Funktion, die nennt sich Lautstärkeregler :-O ^^
hallo. Ich habe mich für Hintergrundmusik entschieden, aus folgenden Grund: Alle Videos sind ca. 25-30 Min lang. Es gibt oft Momente, wo ich nichts sage, und bei 3-5 minutige Stille verliert man sofort Konzentration, daher habe ich ruhige Hintergrundmusik ausgewählt. Außerdem bei den letzen 2 Videos geht die Musik fast aus während ich spreche. Andere sache ist die Bildqualität. Ich habe im Moment das Problem, dass der Text bei der Videoaufnahme irgendwie farbig und verschwommen wird,und beim zoomen fällt das wirklich auf...Daran wird gearbeitet.
Böser Kommunist schrieb: > erliert man sofort Konzentration, > daher habe ich ruhige Hintergrundmusik ausgewählt. nein, man steigert die Konzentration durch Stille. VErlieren tut man sie, wenn man sich auf die Musik konzentriert, was bei musikalischen Personen immer der Fall ist. Zudem gilt für alle, dass das Ausblenden von Musik KOnzentration und Energie kostet. Wenn Deine Meinung korrekt wäre, müssten wir in allen Bibliotheken demnächst Musik anmachen. Wenn Dein Vortrag / Dein Video nicht durch Inhalte überzeugt, dann arbeite daran oder lass es weg. Füge aber nicht Additive ein, wie Perl mit seinen halbnackten Weibern.
Böser nichtkommunistischer Ingenieur schrieb: > Böser Kommunist schrieb: >> erliert man sofort Konzentration, >> daher habe ich ruhige Hintergrundmusik ausgewählt. > nein, man steigert die Konzentration durch Stille. VErlieren tut man > sie, wenn man sich auf die Musik konzentriert, was bei musikalischen > Personen immer der Fall ist. Zudem gilt für alle, dass das Ausblenden > von Musik KOnzentration und Energie kostet. > > Wenn Deine Meinung korrekt wäre, müssten wir in allen Bibliotheken > demnächst Musik anmachen. Das ist reichlich individuell, mancher braucht absolute Stille zum lesen, anderern verschafft Klimber-klingel im Hintergrund die nötige Entspannung und wieder anderer lassen HeavyMetal dröhnen um nicht übermüdet einzuschlafen. Ich fand die musikalische Untermalung und Videoeffekte angemessen um den trögen Stoff aufzulockern. Wenn die Musi stört, kann sie abschalten. Der Zuhöher will nicht "inhaltlich überzeugt" werden, sondern ihm soll Lehrstoff vermittelt werden. MfG,
Mir ist nur aufgefallen, dass der in dem Video extrem langsam tippt ... Ich versteh auch garnicht, wieso man jemandem beim Tippen zuschauen soll ... Vorallem wird es ja bestimmt nicht live-engineert, sondern vermutlich von einem funktionierenden Beispiel abgetippt. Vielleicht so ähnlich, wie bei den Piano-Tutorials, bei denen man langsam die Noten nachspielt? Dann wäre das doch eher was für Leute, die nicht wissen, wie man eine Tastatur bedient? Hmm ... Fragen über Fragen :) Ich finde es aber gut, dass sich der OP Zeit genommen hat, sowas zu machen :) Kritiker gibt es mehr, als Leute, die etwas tun ...
@ Fpga Kuechle (fpgakuechle) Benutzerseite >Ich fand die musikalische Untermalung und Videoeffekte angemessen um den >trögen Stoff aufzulockern. Tröge? Warum schut man es sich dann an? >Wenn die Musi stört, kann sie abschalten. >Der Zuhöher will nicht "inhaltlich überzeugt" werden, sondern ihm soll >Lehrstoff vermittelt werden. Ich glaube du verwechselst Unterricht mit Infotainment.
Wenn gleich das Medium Video sehr viele Möglichkeiten bietet, so muss man sie auch wenigstens ansatzweise beherrschen. Sonst kommt nämlich das raus, was mehrfach bemängelt wurde. Ein nerviges, diletantisches Video-Etwas. Dann lieber ein gutes Dokument oder Powerpoint mit vielen, GUTEN Screenshots erstellen. Geht beim ersten Video schon los. Man sieht das Video, gleichzeitig wird unten Text eingeblendet. Auf was soll man sich denn nun konzentrieren? Worüber nachdenken? Eine Aneinanderreihung von Informationen ist noch lange keine gute Erklärung eines Themas. Die "langweiligen" Passagen beim Eintippen vom VHDL Grundgerüst kann man sich sparen, sowas liefert man bei einem Tutorial fertig. Wenn man es im Quelltext ausreichend kommentiert, hat man sein Ziel deutlich besser erreicht. Sprache UND Musik gleichzeitg? Generation ADHS? Geht gar nicht! IMO ist so ein Tutorial in Text + Bildern deutlich besser aufgehoben. Denn selbst Full Screen ist dein Monitormitschnitt nur schlecht lesbar. Bringt also mehr Irritation als Information. Ich verstehe den Elan des OPs, und es sicher eine schöne Aufgabe, so ein Tutorial zu machen. Aber man muss auch wissen wie. Wollen allein reicht nicht.
Fpga Kuechle schrieb: > Böser nichtkommunistischer Ingenieur schrieb: >> Böser Kommunist schrieb: >>> erliert man sofort Konzentration, >>> daher habe ich ruhige Hintergrundmusik ausgewählt. >> nein, man steigert die Konzentration durch Stille. VErlieren tut man >> sie, wenn man sich auf die Musik konzentriert, was bei musikalischen >> Personen immer der Fall ist. Zudem gilt für alle, dass das Ausblenden >> von Musik KOnzentration und Energie kostet. >> >> Wenn Deine Meinung korrekt wäre, müssten wir in allen Bibliotheken >> demnächst Musik anmachen. > > > Das ist reichlich individuell, mancher braucht absolute Stille zum > lesen, anderern verschafft Klimber-klingel im Hintergrund die nötige > Entspannung Nein, das ist nicht subjektiv. Es lenkt immer ab, auch wenn es nicht bemerkt wird, siehe Handytelefonieren. Wer Zusatzsounds braucht, um Sprache zu hören, der ist nicht ganz ok. (?) Ich würde das schon deshalb weglassen, weil der SNR sinkt und die Sprache bei dem Youtubeformat eh schon schlecht ist. > Ich fand die musikalische Untermalung und Videoeffekte angemessen DAS ist etwas Subjektives. > um den trögen Stoff aufzulockern. Da sind wir beim Punkt. Wer soll sich das denn reinziehen, wenn er kein Interesse hat? Wer soll den FPGAs programmieren, wenn er nicht in der Lage ist, 30min Konzentration aufs Lernen zu verwenden? > Wenn die Musi stört, kann sie abschalten. und damit den Ton gleich mit oder was?
Falk Brunner schrieb: > @ Fpga Kuechle (fpgakuechle) Benutzerseite > >>Wenn die Musi stört, kann sie abschalten. >>Der Zuhöher will nicht "inhaltlich überzeugt" werden, sondern ihm soll >>Lehrstoff vermittelt werden. > > Ich glaube du verwechselst Unterricht mit Infotainment. Oder Du verwechselst Wahlkampf (überzeugen) und Promotionsvorträge (inhaltlich überzeugen) mit Ausbildung (Inhalte vermitteln) und Edutainment (Inhalte multimedial vermitteln). MfG,
@ Kommunist, ich würde die musikalische Untermahlung entfernen. Was ich auch gut fände ist zu Beginn des Tutorials eine kurze Zusammenfassung zu machen was genau gelernt werden soll (ev. mit Power Point). Bedenke: Du machst das Tutorial für den Zuschauer und nicht für dich! Darum solltest du auch beherzigen, was an Kritik vermittelt wird. Was dir persönlich gefällt ist irrelevant! Die vorhandene musikalische Untermahlung ist ein Problem für viele Zuschauer, aber die nicht vorhandene Untermahlung wäre nur ein Problem für ganz wenige Zuschauer --> Darum lasse sie weg. Tu immer das, was einem möglichst breiten Spektrum an Usern zusagen könnte und vermeide Elemente (zB. Musik) die stören könnten. Dadurch maximierst du die Breite des Publikums und erhöhst somit den Nutzen der Präsentation.
Ralf schrieb: > Fpga Kuechle schrieb: >> Das ist reichlich individuell, mancher braucht absolute Stille zum >> lesen, anderern verschafft Klimber-klingel im Hintergrund die nötige >> Entspannung > > Nein, das ist nicht subjektiv. Es lenkt immer ab, auch wenn es nicht > bemerkt wird, siehe Handytelefonieren. Wer Zusatzsounds braucht, um > Sprache zu hören, der ist nicht ganz ok. (?) Ich würde das schon deshalb > weglassen, weil der SNR sinkt und die Sprache bei dem Youtubeformat eh > schon schlecht ist. > Schaut dich mal um. Im Lesesaal sitzen etliche mit Kopfhörer und jeder Ausbilder lernt das es bei der Gruppenarbeit nützlich ist mindestens 3 Gruppen in einem Raum diskutieren zu lassen und nicht 2 da mittels Cocktailparty-Effekt (der heist wirklich so (http://de.wikipedia.org/wiki/Cocktailpartyeffekt)) bei mehrern Störquellen die Konzentration auf eine Nutzquelle leichter ist als bei einer Störquelle. Ebenso ist bekannt, das es sich in einem Entspannungszustand wie bei Alphawellen im EEG die Merkfähigkeit besser ist (sicher auch mit individuellen Abstufungen) und man diesen entspannungszustand eben durch Höreindrücke initiiert kann (siehe auch http://de.wikipedia.org/wiki/Mindmachine ). Da sind die Leute nun mal verschieden, manche sind auf Frontalunterricht gedrillt, andere machen es sich mit Edutainment leichter. MfG,
D A N K E für die FPGA Videos. Lass dich nicht beirren. Hier sind ein Haufen Leute unterwegs die nur rummeckern können und genau das suchen. Mach gerne weiter deine Videos und lass die anderen andere sein.
> Hier sind ein Haufen Leute > unterwegs die nur rummeckern So Leute gibt es, aber man darf konstruktive Kritik nicht mit "Meckern" gleichsetzen. Ein "Danke" erhöht zwar die Motivation des Erstellers, hilft aber nicht seine Tutorials zu verbessern. lg
Lautstärkeregler-Experte schrieb: >> Hier sind ein Haufen Leute >> unterwegs die nur rummeckern > > So Leute gibt es, aber man darf konstruktive Kritik nicht mit "Meckern" > gleichsetzen. Ein "Danke" erhöht zwar die Motivation des Erstellers, > hilft aber nicht seine Tutorials zu verbessern. Nunja deine Forderung den sound aus den videos zu entfernen statt den Laustärkeregler zu benutzen verbessert die Qualität erst recht nicht. Und deine Argumentation, das was nur einer (von dir postulierten) Minderheit nützt, einfach wegzu lassen ist IMHO genau das Gegenteil einer konstruktiven Kritik zum Nutzen der Allgemeinheit. MfG,
Spass am Lernen schrieb: > Nunja deine Forderung den sound aus den videos zu entfernen statt den > Laustärkeregler zu benutzen verbessert die Qualität erst recht nicht. Es ging nicht um "den Sound", sondern um die Hintergrundmusik. Und weil mit dem Lautstärkeregler eben nicht nur die Musik, sondern auch die Sprache betroffen ist kann sich an der Qualität insgesamt durchaus was ändern. BTW: am besten lerne ich, wenn ich schon Musik will, mit meiner Musik, die ich ja ganz einfach in der gewünschten Lautstärke aufsummieren könnte...
Spass am Lernen schrieb: > > Nunja deine Forderung den sound aus den videos zu entfernen statt den > Laustärkeregler zu benutzen verbessert die Qualität erst recht nicht. Es war die Rede von Musik, nicht von "sound". Und bei normalen YT-Videos gibt es halt nur einen Audiokanal, womit du die Hintergrundmusik nicht bei Beihaltung des gesprochenen Wortes ausblenden kannst. Eigentlich schlimm, dass man so etwas simples erklären muss...
Hallo Danke für das feedbakc. Ich werde die Musik in den näcnhsten video zwar nicht komplet entfernen, aber leiser machen. Ich lerne zwar auch in kompletter Stille, aber für das Programmieren benötige ich immer Musik, ich weiss nicht wieseo. Was die Tippeschwindigkeit angeht: ja, ich tppe den Code ab, und an vielen Stellen seiht man, das das video ordentlich beschleunigt wurde. Aber an manchen stellen gege ich den Zuschauer extra die Zeit, den Code in Ruhe noch einmal anzuschauen.
Böser Kommunist schrieb: > Aber an manchen stellen gege ich den Zuschauer extra die Zeit, den Code > in Ruhe noch einmal anzuschauen. Genau das stört mich irgendwie an solchen Videotutorials: eigentlich sollte man es selber machen, aber man muss immer schauen, was gerade passiert... > und an vielen Stellen seiht man, das das video ordentlich beschleunigt > wurde. Ich würde bei zu erklärenden Stellen den Code gleich z.B. zeilenweise komplett einblenden und hinterher erklären, was da passiert. Wenn man zusieht, wie so eine Zeile Code langsam vor sich hinwächst, das kann anstrengend sein...
nicht "Gast" schrieb: > Spass am Lernen schrieb: >> >> Nunja deine Forderung den sound aus den videos zu entfernen statt den >> Laustärkeregler zu benutzen verbessert die Qualität erst recht nicht. > > Es war die Rede von Musik, nicht von "sound". Und bei normalen YT-Videos > gibt es halt nur einen Audiokanal, womit du die Hintergrundmusik nicht > bei Beihaltung des gesprochenen Wortes ausblenden kannst. Eigentlich > schlimm, dass man so etwas simples erklären muss... Ich bezog mich auf das erste Video das kein gesprochenes Wort enthält. Da kann man sehr wohl den Lautstärkeregler benutzen um die Hintergrundmusik auszuschalten ohne Informationen zu verlieren. Bei einer Stichprobe in einem anderen Video fanden sich Untertitel zu gesprochenen Wort. Auch hier kein Informationsverlust bei Benutzung eines Lautstärkereglers. Aus dem Einleitungstext des TO entnehme ich das die Tutorials eh unter der Prämisse entstanden ohne gesprochenes Wort auszukommen also selbsterklärende Vorführung. Und es ist in Youtube seit Nov/2008 sehr wohl möglich sein Stereo als Mehrkanalton zu verwenden, nur muss man sein Video vor dem Upload in das richtige Format (H.264/MPEG-4 AVC mit AAC Unterstützung (itag-value 22)) konvertieren. Dann kann man bei passender Aufbereitung sehr wohl Hintergrundmusik (z.B. rechter Kanal) von Sprache (z.B. links) trennen. MfG
@ Böser Kommunist (Firma: UdSSR) (chromosoma) >Was die Tippeschwindigkeit angeht: ja, ich tppe den Code ab, und an >vielen Stellen seiht man, das das video ordentlich beschleunigt wurde. >Aber an manchen stellen gege ich den Zuschauer extra die Zeit, den Code >in Ruhe noch einmal anzuschauen. Das ist Unsinn in einem Video. Um einen Quelltext zu studieren und zu verstehen, muss man in in einem normalen Editor oder gedruckt vor sich haben. Nicht als Standbild in einem Video (Auf was für Ideen die Leute kommen). Das sit ein totaler Fail der Bildformate, um es mal hipp auszudrücken.
Lautstärkeregler-Experte schrieb: > Bedenke: Du machst das Tutorial für den Zuschauer und nicht für dich! > Darum solltest du auch beherzigen, was an Kritik vermittelt wird. Was > dir persönlich gefällt ist irrelevant! DAS ist mal eine gesunde Haltung! Und sie is genau richtig. Leider ist es aber industrieweit so, dass die meisten sich keine Mühe machen in Erfahrung zu bringen, was benötigt wird, wie man es aufbereitet und darstellt. Dabei gibt es dazu haufenweise Literatur. So kommt es, dass wir beschissene und unlesbare Webseiten, Bücher und "tutarials" haben, die einfach nur deshalb da sind, weil der Autor ein bischen Selbstbefriedigung betrieben hat und nach eigenem subjektiven Geschmack vorgangen ist.
Ralfi schrieb: > Lautstärkeregler-Experte schrieb: >> Bedenke: Du machst das Tutorial für den Zuschauer und nicht für dich! >> Darum solltest du auch beherzigen, was an Kritik vermittelt wird. Was >> dir persönlich gefällt ist irrelevant! > DAS ist mal eine gesunde Haltung! Und sie is genau richtig. > > Leider ist es aber industrieweit so, dass die meisten sich keine Mühe > machen in Erfahrung zu bringen, was benötigt wird, wie man es > aufbereitet und darstellt. Dabei gibt es dazu haufenweise Literatur. > > So kommt es, dass wir beschissene und unlesbare Webseiten, Bücher und > "tutarials" haben, die einfach nur deshalb da sind, weil der Autor ein > bischen Selbstbefriedigung betrieben hat und nach eigenem subjektiven > Geschmack vorgangen ist. Wie fg schon oben anmerkte: "Hier sind ein Haufen Leute unterwegs die nur rummeckern können und genau das suchen"
Spass am Lernen schrieb: >> >> So kommt es, dass wir beschissene und unlesbare Webseiten, Bücher und >> "tutarials" haben, die einfach nur deshalb da sind, weil der Autor ein >> bischen Selbstbefriedigung betrieben hat und nach eigenem subjektiven >> Geschmack vorgangen ist. > > Wie fg schon oben anmerkte: > "Hier sind ein Haufen Leute > unterwegs die nur rummeckern können und genau das suchen" War das gerade ein Antrag auf eine Merkbefreiung?
Ralfi schrieb: > Lautstärkeregler-Experte schrieb: >> Bedenke: Du machst das Tutorial für den Zuschauer und nicht für dich! >> Darum solltest du auch beherzigen, was an Kritik vermittelt wird. Was >> dir persönlich gefällt ist irrelevant! > DAS ist mal eine gesunde Haltung! Und sie is genau richtig. FULLACK! Genauso bei z.B. Buchautoren ... Der Autor schreibt die Bücher nicht für sich, sondern für die Leser ... Das ist tatsächlich etwas grundlegendes, wofür vielen Autoren das Verständnis fehlt ...
Ralfi schrieb: > Lautstärkeregler-Experte schrieb: >> Bedenke: Du machst das Tutorial für den Zuschauer und nicht für dich! >> Darum solltest du auch beherzigen, was an Kritik vermittelt wird. Was >> dir persönlich gefällt ist irrelevant! > DAS ist mal eine gesunde Haltung! Und sie is genau richtig. > > Leider ist es aber industrieweit so, dass die meisten sich keine Mühe > machen in Erfahrung zu bringen, was benötigt wird, wie man es > aufbereitet und darstellt. Dabei gibt es dazu haufenweise Literatur. > > So kommt es, dass wir beschissene und unlesbare Webseiten, Bücher und > "tutarials" haben, die einfach nur deshalb da sind, weil der Autor ein > bischen Selbstbefriedigung betrieben hat und nach eigenem subjektiven > Geschmack vorgangen ist. Was? Welche industrie?Was zum Teufel redest du? Ich bin ein student und mache meine videos aus Spaß und den Wunsch den anderen zu helfen. Ich verdiene mit meinen videos nichts, und habe es auch nicht vor. Du spricht so, als ob ich dich dazu zwinge VHDL nur an meinen tutorials zu lernen... Woher solche Empörung...?
@Böser Kommunist (Firma: UdSSR) (chromosoma)
>Was? Welche industrie?Was zum Teufel redest du?
Das ging nicht direkt an dich, es war nur eine Anekdote aus der Praxis.
Falk Brunner schrieb: > @Böser Kommunist (Firma: UdSSR) (chromosoma) > >>Was? Welche industrie?Was zum Teufel redest du? > > Das ging nicht direkt an dich, es war nur eine Anekdote aus der Praxis. Genau das war es. Und es ist eine Frage der Kritikfähigkeit. Ich selbst habe früher als Student auch allesmögliche gemacht und gedacht ich kann alles, bis ich mit einigen wesentlichen Themen tiefer gegangen bin und erkennen musste, dass dem nicht so ist. Ich habe sowohl mit Musik, mit Grafikzeichnungen und Illustrationen mit Webseiten und einigem mehr richtig Geld verdient und hatte ein sehr hohes Niveau. Und trotzdem habe ich vieles gekippt, weil ich erkennen musste, dass es nicht für ganz vorne reicht. Das, was ich nur so gut konnte wie jeder, habe ich sofot gekippt und gar nicht den Versuch unternommen, zu publizieren, da ich mich bei den Fachleuten nicht blamieren wollte. Heute ist das anders. Da "releast" jeder sein Zeug und erwartet Applaus und Verständnis für Mittelmass, das 3-5 Stufen unter dem liegt, was ambitionerte Amateure und Semiprofis bringen. Fotografie und elektronische Musik ist so ein Thema. Alles, was man mit dem PC zusammenstricken kann, wird gestrickt. Nee, nee, nee ... Soweit das Allgemeine. Jetzt nochmal was Konkretes: Der TE hat hier ausdrücklich um Meinungen gebeten. Die hat er bekommen. Ich halte es auch für sehr unzweckmässig, als Student, Wissen weitergeben zu wollen, zumal in mittelmässiger Form. Entweder ein Spitzenprodukt oder gar nichts.
@ Ralf (Gast) >hohes Niveau. Und trotzdem habe ich vieles gekippt, weil ich erkennen >musste, dass es nicht für ganz vorne reicht. Naja, es gibt nicht nur die Top 10, darunter gibte auch viele. Oder gibt es nur die Bundesliga im Fussball? >Ich halte es auch für sehr unzweckmässig, als Student, Wissen >weitergeben zu wollen, zumal in mittelmässiger Form. Jain. Das Ausarbeiten eines Themas ist elementarer Bestandteil des Studiums. Das bringt vor allem demjenigen was, der es tut. Das kann man auch weitergeben, allerdings sollte man sich seiner Grenzen bewußt sein. Und halt Kritik vertragen und nicht als Vernichtungsangriff betrachten. Lobhudelei und "ganz toll gemacht" gibt es im Kindergarten mehr als genug. > Entweder ein Spitzenprodukt oder gar nichts. Schwarz-Weiß Denken ist selten sinnvoll. Krankhaft elitäre Ansprüche sowieso nicht.
Falk Brunner schrieb: >> Entweder ein Spitzenprodukt oder gar nichts. > > Schwarz-Weiß Denken ist selten sinnvoll. Krankhaft elitäre Ansprüche > sowieso nicht. Das nenne ich aber nicht Schwarz-weiss-denken, sondern Konzentration in der Spitze. Es gibt genug durchschnittliche Darstellungen, egal bei welchem Thema, da braucht es nicht noch eine 117te. Einige wenige richtig gute wären sinnvoll. Und da denke ich auch und vor allem an die Inhalte. Da gäbe es vieles zu verbessern. In der grossen Masse geht dann die Qualtität unter! Ich sehe hier durchaus Züge der Endzeit wo wir dabei sind, dass alles völlig entropisch und chaotisch wird. Wenn die Selektion der Qualität ausfällt, nimmt der Unsinn immer mehr zu und am Ende ist alle Information wieder völlig amorph und aufgelöst. Siehe Wikipedia. Wer wirklich was lernen will, greift lieber zu einem Buch. Da ist wenigstens ein Verlag dahinter, der verkaufen will und nicht alles druckt, was eingereicht wird. Ganz früher gab es da noch einen wissenschaftlichen Beirat und einen Lektor.
Falk Brunner schrieb: > @ Böser Kommunist (Firma: UdSSR) (chromosoma) > >>Was die Tippeschwindigkeit angeht: ja, ich tppe den Code ab, und an >>vielen Stellen seiht man, das das video ordentlich beschleunigt wurde. >>Aber an manchen stellen gege ich den Zuschauer extra die Zeit, den Code >>in Ruhe noch einmal anzuschauen. > > Das ist Unsinn in einem Video. Um einen Quelltext zu studieren und zu > verstehen, muss man in in einem normalen Editor oder gedruckt vor sich > haben. Nicht als Standbild in einem Video (Auf was für Ideen die Leute > kommen). Das sit ein totaler Fail der Bildformate, um es mal hipp > auszudrücken. ???? Also für mich ist ein Tutorial zum Thema Programmieren OHNE Code-Beispiele ein totaler fail, nicht ein Tutorial mit. MfG,
Fpga Kuechle schrieb: > Falk Brunner schrieb: >> Das sit ein totaler Fail der Bildformate, um es mal hipp >> auszudrücken. > Also für mich ist ein Tutorial zum Thema Programmieren OHNE > Code-Beispiele ein totaler fail, nicht ein Tutorial mit. Es war nicht gemeint, dass kein Quelltext zu sehen sein sollte, sondern, dass 500 ASCII Zeichen auch leicht in einer 500 Bytes großen Datei unterzubringen wären. Das entspräche einer verlustlosen Datenreduktion um etwa den Faktor 1000000... ;-)
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >dass 500 ASCII Zeichen auch leicht in einer 500 Bytes großen Datei >unterzubringen wären. Das entspräche einer verlustlosen Datenreduktion >um etwa den Faktor 1000000... ;-) Das solltest du zum Patent anmelden! Du wirst STEINREICH!
@ Kritiker (Gast) >Das nenne ich aber nicht Schwarz-weiss-denken, sondern Konzentration in >der Spitze. Es gibt genug durchschnittliche Darstellungen, egal bei >welchem Thema, da braucht es nicht noch eine 117te. Ja, aber der wesentliche Aspekt hier ist eher die Ausarbeitung des Themas für sich selber. Wenn dann was >Einige wenige >richtig gute wären sinnvoll. Und da denke ich auch und vor allem an die >Inhalte. Da gäbe es vieles zu verbessern. >In der grossen Masse geht dann die Qualtität unter! Ist wohl leider wahr. >Ich sehe hier durchaus Züge der Endzeit wo wir dabei sind, dass alles >völlig entropisch und chaotisch wird. Wenn die Selektion der Qualität >ausfällt, nimmt der Unsinn immer mehr zu und am Ende ist alle >Information wieder völlig amorph und aufgelöst. Siehe Wikipedia. ;-) >Wer wirklich was lernen will, greift lieber zu einem Buch. Da ist >wenigstens ein Verlag dahinter, der verkaufen will und nicht alles >druckt, was eingereicht wird. Ganz früher gab es da noch einen >wissenschaftlichen Beirat und einen Lektor. Solche Verlage werden aber auch immer weniger. Und gerade bei Fachbüchern mit tagesaktuellem Inhalt sieht es meistens dünn aus. Diese Lücke könnte man duch diverse Onlineinhalte füllen. Aber auch da ist Qualität rar, wie immer (definitionsgemäß?).
Böser Kommunist schrieb: > Ich denke diese > videos können sehr gut bei dem Einstieg in die FPGA Geschichte helfen: Ich hab mir mal ein paar Stellen des ersten Videos angeschaut und bin nun völlig anderer Meinung. Du hast dir zwar ne Menge Mühe gegeben, aber etwas, das beim Zuschauer tatsächlich nen Bildzungseffekt hat, ist es nicht geworden. Mein Vorschlag: Wenn überhaupt, dann mach ein PDF draus, das man sich ausdrucken und durchlesen kann - in Stücken, so wie man's grad braucht, zum vor- und zurückblättern und so. Ansonsten finde ich, daß die Planung zur Verwendung eines FPGA's eben NICHT mit irgendeinem fertigen Board und blinkenden LED's beginnen sollte, sondern damit, daß man sich für eine Aufgabe ein FPGA aussucht, dessen Besonderheiten (was es alles an speziellen Sachen darin gibt) abwägt, ob das die Lösung der Aufgabe erleichtert oder nicht, - und dann ein passendes Board konzipiert - einschließlich der Frage, woher und wie die Versorgung des FPGA's mit seiner Programmierung gedacht ist (hat ja Einfluß auf die Pinbelegung). Kurzum, ich würde mir ein systematischeres Konzept wünschen. W.S.
W.S. schrieb: > Ansonsten finde ich, daß die Planung zur Verwendung eines FPGA's eben > NICHT mit irgendeinem fertigen Board und blinkenden LED's beginnen > sollte, sondern damit, daß man sich für eine Aufgabe ein FPGA aussucht, > dessen Besonderheiten (was es alles an speziellen Sachen darin gibt) > abwägt, ob das die Lösung der Aufgabe erleichtert oder nicht, - und dann > ein passendes Board konzipiert Pff, bitte? Du meinst der jenige, der gerade Lust und Interesse an FPGA hat, soll sich zuerst in Hardware und PCB design gehen, damit ein halbes Jahr verbringen und erst dann eigene PCB mit FPGA bauen? Nein, ich denke du liegst hier gaanz falsch: FPGA ist kein ATtiny mit 8 Pins oder so, den man einfach verdrahten kann. FPGA hat Ü 300 I/O, soll sehr schlau mit der Spannung versorgt werden etc.Geschweige jetzt die zeitkritische sachen wie SDRAM, SRAM etc... Ich kann es mir nicht vorstellen, wie ein Anfänger das alles meistern soll, und vor allem wieviele Jahre das nimmt...und ob dann noch die Lust für FPGA programmierung noch da bleibt.
Spass am Lernen schrieb: > das es sich in einem > Entspannungszustand wie bei Alphawellen im EEG die Merkfähigkeit besser > ist Damit steckst Du aber die Annahme hinein, dass diese Musik diese Entspannung erzeugt, was schon mal bei mehr als der Hälfte der Personen grundsätzlich nicht geht und der anderen Hälfte auch nur bei der richtigen Art der Musik. Diese Musik in den Videos ist davon aber weit weg. Wer unbedingt Musik braucht zum Lernen, kann sich ja beim Videogucken den MP3player zusätzlich anmachen. Daher heisst die Devise: Alles was potenziell stört, weglassen. In der Kantine wird auch nicht so viel gewürzt wie es nur geht, sondern sehr wenig und Salz und Pfeffer hingestellt, wer es mag. Das ist die einzig sinnvolle Strategie, wenn man ein Produkt für die Masse herausbringen will,
Böser Kommunist schrieb: > Ich kann es mir nicht vorstellen, wie ein Anfänger das alles meistern > soll, und vor allem wieviele Jahre das nimmt...und ob dann noch die Lust > für FPGA programmierung noch da bleibt. Wenn sich einer das nicht antun kann oder will, wird er eh kein guter Entwickler, sondern nur ein FPGA Bastler. Und wer braucht das? FPGAs sind zu elementar, als dass man damit mal schnell was basteln kann. Für solche Leute sind die AVR besser. Da kann man mit einigen Tagen einlesen schon richtige Programme schreiben, wenn man etwas Talent hat. FPGAs brauchen ihre Zeit, weil viel mehr dahinter steckt.
@ Ingenieur (Gast) >> Ich kann es mir nicht vorstellen, wie ein Anfänger das alles meistern >> soll, und vor allem wieviele Jahre das nimmt...und ob dann noch die Lust >> für FPGA programmierung noch da bleibt. Stimmt. >Wenn sich einer das nicht antun kann oder will, wird er eh kein guter >Entwickler, sondern nur ein FPGA Bastler. Und wer braucht das? Diese Argumentation ist ebenso unsinnig wie "Nur echte Männer können Assembler". >FPGAs sind zu elementar, als dass man damit mal schnell was basteln >kann. Das hat mit BASTELN rein gar nicht zu tun, sondern sinnvoller Problemtrennung! Die Hardware des FPGAs ist das Eine, die "Software", sprich VHDL & Co das andere. Das KANN man sehr wohl trennen. Wenn jemand beides kann, ist er halt besser. Ist aber nicht zwingend für die erfolgreiche Anwendung eines FPGAs nötig. Damit ist der Ansatz, ein fertiges Evalboard zu nutzen mehr als richtig. >FPGAs brauchen ihre Zeit, weil viel mehr dahinter steckt. Mag sein, aber beim Faustkeil fängt man auch dort nicht an.
Böser Kommunist schrieb: > W.S. schrieb: > Pff, bitte? Du meinst der jenige, der gerade Lust und Interesse an FPGA > hat, soll sich zuerst in Hardware und PCB design gehen, So ganz falsch ist die These nicht, denn heutige FPGAs sind kleine EVAL-boards mit dedizierter HW drin und deren ureigenster Vorteil gegenüber Controllern oder Chips ist die Bandbreite und die flexible Verschaltung und híerbei kommen genau solche Aspkete wie Physik, Timing etc zum Tragen. Das ist es, was FPGAs ausmachen, alles andere ist Banalität die sich auch mit anderen Bauteilen machen lässt. Ich lerne Kampfflugzeuge auch nicht dadurch kennen, in dem ich die Waffen, die Zielvorrichtungen, die spezielle Fluglagekorrektur und vieles mehr ausser Acht lasse und mir es erst mal in den Sesseln bequem mache und übers Rollfeld rolle. Das geht auch in einem Auto und ein bissl fliegen im Passagierflugzeug. FPGAs dadurch ergünden zu wollen, dass man Zähler baut, halte ich daher nicht für zweckmässig. FPGAs sollten nicht am Beginn des Lernprozesses in der digitalen Welt stehen. Da baut man lieber mal eine Platine mit einigen Chips, kümmert sich um Logikgatter etc. Die SW Schiene von der anderen Seite her lässt sich wiederum besser mit Controllern ergründen. Da ist vieles vorgegeben und man kommt schnell und frustfrei zum Ziel. Wer genug Kenntnisse mit Digitaltechnik, Logik, Software und Analogtechnik hat, der sollte sich an die FPGAs wagen. Dann ist das, was bei rauskommt auch praxisnah und fundiert. Der Schnelleinstieg mit Zähleren und Prozessen führt nur zu einem komplett faslchen Verständnis dieser Systeme und ihrer Möglichkeiten.
Juergen S. schrieb: > Wer genug Kenntnisse mit Digitaltechnik, Logik, Software und > Analogtechnik hat, der sollte sich an die FPGAs wagen. Dann ist das, was > bei rauskommt auch praxisnah und fundiert. Der Schnelleinstieg mit > Zähleren und Prozessen führt nur zu einem komplett faslchen Verständnis > dieser Systeme und ihrer Möglichkeiten. Ich bin aber mit so gut ohne Vorkenntnissen in die FPGA Welt eingestiegen , und zwar ziemlich erfolgreich. Wieso gibt es dann schon fertige FPGA/ARM dev. board? Solche boards sind professionel designed, und ich kann mich zu 99.99% auf FPGA und Hardware Programmierung konzentieren, gleichzeitig lerne ich wie z.b. SDRAM/SRAM/FLASH funktioniert und angesteuert wird, Vorteile , Nachteile etc. Genau so habe ich gelernt, wie RS232, VGA oder SPI Interface funktionert, indem ich eins selber in VHDL von NULL geschrieben habe. Ich denke solche voll mit interessanten Bauteilen bestückte Entwicklungsboards sind genau das richtige für den Einstieg. Man muss nicht erst beim Attiny anfangen, oder wieso dann nicht zuerts beim Si-Einkristal züchten, Wafer schneiden, Lithographie und Dotierung erlernen und schließlich eigenen µC bauen. Richtige Männer bauen ihre IC selbst aus dem Sand vom Baumarkt...
@ Juergen S. (engineer) Benutzerseite >So ganz falsch ist die These nicht, denn heutige FPGAs sind kleine >EVAL-boards mit dedizierter HW drin und deren ureigenster Vorteil >gegenüber Controllern oder Chips ist die Bandbreite und die flexible >Verschaltung und híerbei kommen genau solche Aspkete wie Physik, Timing >etc zum Tragen. Naja, die großen FPAGs haben das, es gibt aber auch kleinere Modelle. Auch FPGAs ohne Hardcore CPU, Gigabit Tranceiver und wasweißich sind FPGAs. Und ja, auch damit kann man verdammt gute Sachen bauen. >Das ist es, was FPGAs ausmachen, alles andere ist >Banalität die sich auch mit anderen Bauteilen machen lässt. Jaja, alles Kindergeburtstag. > Ich lerne >Kampfflugzeuge auch nicht dadurch kennen, in dem ich die Waffen, die >Zielvorrichtungen, die spezielle Fluglagekorrektur und vieles mehr >ausser Acht lasse und mir es erst mal in den Sesseln bequem mache und >übers Rollfeld rolle. Das geht auch in einem Auto und ein bissl fliegen >im Passagierflugzeug. Du macht den gleiche Fehler wie W.S. Und du vergisst, dass auch DU mal bei NULL angefangen hast. >FPGAs dadurch ergünden zu wollen, dass man Zähler baut, halte ich daher >nicht für zweckmässig. FPGAs sollten nicht am Beginn des Lernprozesses >in der digitalen Welt stehen. Warum nicht? Sie sind ein modernes Bauteil, das dafür nahezu ideal ist. Dass dabei bisweilen der Fehler gemacht wird, FPGAs wie einen (sequentiellen) Prozessor zu betrachten ist kein wirkliches Problem, der Irrtum löst sich irgendwann mal auf. > Da baut man lieber mal eine Platine mit >einigen Chips, kümmert sich um Logikgatter etc. Nö, das war einmal. Heute kann man deutlich schneller und komfortabler Logik per Software erstellen, eben in FPGAs. TTL-Gräber schaufelt heute keiner mehr. >Die SW Schiene von der >anderen Seite her lässt sich wiederum besser mit Controllern ergründen. >Da ist vieles vorgegeben und man kommt schnell und frustfrei zum Ziel. Kein Lernprozess ist problemlos und frustfrei. Er ist IMMER mit Anstrengung verbunden, wenn gleich es auch dort schlechte und gute Lernmethoden gibt. >Wer genug Kenntnisse mit Digitaltechnik, Logik, Software und >Analogtechnik hat, der sollte sich an die FPGAs wagen. Du legst die Messlatte reichlich hoch, man könnte meinen fast schon elitär. Hast du Angst, dass dir morgen ein paar pfiffige Abiturienten mit ihren FPGA-Kreationen OHNE Löten den Rang ablaufen? >bei rauskommt auch praxisnah und fundiert. Der Schnelleinstieg mit >Zähleren und Prozessen führt nur zu einem komplett faslchen Verständnis >dieser Systeme und ihrer Möglichkeiten. Du kannst dich mit Josef G. zusammentun, der pflegt eine ähnlich Logik.
Falk Brunner schrieb: > Naja, die großen FPAGs haben das, es gibt aber auch kleinere Modelle. > Auch FPGAs ohne Hardcore CPU, Gigabit Tranceiver und wasweißich sind > FPGAs. Und ja, auch damit kann man verdammt gute Sachen bauen. Du wirst aber letztlich nicht um das Wissen der charakteristschen Hardware der FPGAs herum kommmen und die ist auch ohne Spezialfunktionen nicht trivial. >>Das ist es, was FPGAs ausmachen, alles andere ist >>Banalität die sich auch mit anderen Bauteilen machen lässt. > Jaja, alles Kindergeburtstag. Du hast den Sinn meiner Aussage nicht verstanden. Worin soll der Lernerfolg beim LED-BLinken und Zählen liegen? Das ist Software, Ablauf und solche Dinge lernt man lange, bevor man sich mit FPGAs befasst, z.B. mit den erwähnten MCU. Kennt man sie, ist die Umsetzung im FPGA eine Trivialität, die kein Tutorial braucht. > Und du vergisst, dass auch DU mal bei NULL angefangen hast. Es geht nicht darum, dass man überhaupt mal mit irgendwas anfangen muss, sondern darum, womit und ob man eine Spezialhardware nutzt, um elementare Dinge zu lernen. Ich meine Nein. Es hat seinen Grund, warum man in Schule und Studium mit basics anfängt und dann zu höheren Abstraktionsebenen übergeht. > Warum nicht? Sie sind ein modernes Bauteil, das dafür nahezu ideal ist. Ein FPGA ist nicht ideal, um einfache Digitalelektronik zu lernen. Allein das Erlernen der Sprache, der Tools und einfacher Konstrukte kostet wenigstens Tage, wenn nicht Wochen. Die Funktion von digitaler Logik erlernt man mit definierten Funktionen einfacher und zielführender. Und deshalb wird es auch so gemacht. Im ersten Semester kommen erstmal Logik und KV-Diagramme. :-) > Dass dabei bisweilen der Fehler gemacht wird, FPGAs wie einen > (sequentiellen) Prozessor zu betrachten ist kein wirkliches Problem, der > Irrtum löst sich irgendwann mal auf. Ein Irrtum, der bei Leuten, die eine Vorstellung von der Funktion von Hardware haben, überhaupt nicht auftritt. >> Da baut man lieber mal eine Platine mit >>einigen Chips, kümmert sich um Logikgatter etc. > Nö, das war einmal. Heute kann man deutlich schneller und komfortabler > Logik per Software erstellen, eben in FPGAs. TTL-Gräber schaufelt heute > keiner mehr. Warum werden sie dann nach wie vor verkauft und verbaut? Es geht wie gesagt um den Einstieg in die digitale Schaltungstechnik und nicht das Anfertigen von komplexe Designs, die ein "TTL-Grab" erfordern würden. Ich habe übrigens gerade einen Serializer-Chip verbaut/verplant. Dessen Funktion ist auch einem Anfänger einleuchtend, der kein Krümel VHDL kann. Und vor allem kann man einen Eindruck über die Aspekte in Sachen Timing etc erhalten, ohne sich real im FPGA damit durchzukämpfen und in die Synthesfallen zu rennen. Wenn die Funktion solcher Systeme fest im Kopf verankert ist, kann man darüber nachdenken, sie virtuell zusammenzubasteln. Beim Thema FPGA wird sehr gerne die Elektronik vergessen. Wer damit beginnt, eine Platine mit ein paar einfachen Chips zu machen, wird wenigstens mit einigen realen Problemen konfrontiert, sie sich später beim FPGA ergeben. Die sind es nämlich, die nach Lösungen rufen und den eigentlichen Anspruch beim FPGA definieren, nicht das Zählen und das VHDL. So ein Video suggeriert nur, dass die Welt ganz einfach sei. > Kein Lernprozess ist problemlos und frustfrei. Er ist IMMER mit > Anstrengung verbunden, Es geht darum, welches Vorgehen das Effektivste ist. Lernen Stück für Stück von den basics her ist nach wie vor das Beste. Die basics im FPGA sind die Transitoren und Schaltfunktionen, dann das was daraus aufgebaut im FPGA "herumliegt" sowie deren Beschreibung auf Logik, Funktions und physikalischer Ebene. Wenn man das mal richtig im Blick hat, fallen viele unsinnige Aktionen in VHDL erst gar nicht an, die man überall sehen kann, in design, wo einer vom anderen abkopiert hat. Ich nenne da nur die konsquent falsche Deklaration der architecture als "Behavioural" sowie die Nutzung negativer Resets und "loaktiver Signale" im Logikdesign. >>Wer genug Kenntnisse mit Digitaltechnik, Logik, Software und >>Analogtechnik hat, der sollte sich an die FPGAs wagen. > Du legst die Messlatte reichlich hoch, man könnte meinen fast schon > elitär. Nein, ich zeige nur einen logischen Lernweg auf. > Hast du Angst, dass dir morgen ein paar pfiffige Abiturienten > mit ihren FPGA-Kreationen OHNE Löten den Rang ablaufen? Du meinst nicht ernsthaft, ich lege absichtlich einen falschen Weg dar, um die hilflosen und unaufgeklärten Abiturienten am schnellen Erlernen der FPGA-Technik zu hindern? Dazu zwei Fakten: 1) Die pfiffigen Abiturienten brauchen und lesen keine Ratschläge. Sie gucken auch keine Video-Tutorials sondern basteln drauf los und umschiffen solche Dinge rasch und intuiviv. Die lernen Digitales, soweit man es sich selber beibringen kann(!), in Windeseile ganz ohne Tutorial. Zählerbasteln ist da defintiv kein Anspruch. Ich konnte es ja auch und hatte damals noch kein Internet. Ich habe aber wirklich mit SW und Chips angefangen und schon viele basics drauf, bevor es mit GALs und PALs losging. 2) Auch die noch so pfiffigsten Abiturienten sind viele Jahre zurück. Die zu verwirren, ist fruchtlos. :-) Der Knowhowaufbau im Bereich FPGA und Digitaltechnik ist nicht trivial und vor allem nicht in 2-3 Jahren zu leisten, wie mancher meint. Die Sprache und ein bissl tool-Kenntnis sind noch das Wenigste. Wenn ich ein Interesse daran hätte, potenzielle Nachfolger zu blockieren, würde ich einfach weniger korrektive Dinge posten und sie einfach mit den Youtube-Tutorials alleine lassen :-)
@ Juergen S. (engineer) Benutzerseite >> FPGAs. Und ja, auch damit kann man verdammt gute Sachen bauen. >Du wirst aber letztlich nicht um das Wissen der charakteristschen >Hardware der FPGAs herum kommmen und die ist auch ohne Spezialfunktionen >nicht trivial. Aber sie ist in Stufen erlernbar. Du legst die Stufe unnötig hoch. >Du hast den Sinn meiner Aussage nicht verstanden. Worin soll der >Lernerfolg beim LED-BLinken und Zählen liegen? Wer sagt, dass das alles ist? Vielleicht in den "Tutorials" des OP, aber das die nicht so wirklich gut sind ist ja hinreichend diskutiert worden. Klar geht es nach Zähler und LED-Blinken WEITER! >Das ist Software, Ablauf >und solche Dinge lernt man lange, bevor man sich mit FPGAs befasst, z.B. >mit den erwähnten MCU. Kennt man sie, ist die Umsetzung im FPGA eine >Trivialität, die kein Tutorial braucht. Viele Wege führen nach ROM. Auch mit wenig Erfahrung auf MCUs kann man mit FPGAs anfangen. OK, ein paar elementare Grundlagen der Digitaltechnik braucht man schon. Niemand wird einem 3. Klässler ein FPGA unter die Nase reiben. >> Warum nicht? Sie sind ein modernes Bauteil, das dafür nahezu ideal ist. >Ein FPGA ist nicht ideal, um einfache Digitalelektronik zu lernen. >Allein das Erlernen der Sprache, der Tools und einfacher Konstrukte >kostet wenigstens Tage, wenn nicht Wochen. Die Funktion von digitaler >Logik erlernt man mit definierten Funktionen einfacher und >zielführender. Und deshalb wird es auch so gemacht. Im ersten Semester >kommen erstmal Logik und KV-Diagramme. :-) Die Grundlagen der Digitaltechik hast weder DU noch Ich in drei Tagen gelernt. Denk mal GENAU zurück, welchen Weg du da gegangen bist. Also warum soll ein FPGA plötzlich diesen unerfüllbaren Anspruch erfüllen? Ausserdem hat keiner behaupte, dass FPGAs die Grundlagen vermitteln sollen. Mit FPGAs sollen die weiterführenden Möglichkeiten eben der FPGAs erklärt werden. >> Nö, das war einmal. Heute kann man deutlich schneller und komfortabler >> Logik per Software erstellen, eben in FPGAs. TTL-Gräber schaufelt heute >> keiner mehr. >Warum werden sie dann nach wie vor verkauft und verbaut? Legacy support. Riesige, gar neue, innovative Dinge werden damit schon lange nicht mehr gemacht. Selbst die ollen GALs/PALs fasst keiner mehr an. CPLDs noch ein wenig, geht aber auch runter. > Es geht wie >gesagt um den Einstieg in die digitale Schaltungstechnik und nicht das >Anfertigen von komplexe Designs, die ein "TTL-Grab" erfordern würden. Kann man entweder simulieren oder per graphischer Eingabe mit TTL-Funktionsblöcken machen. >Ich habe übrigens gerade einen Serializer-Chip verbaut/verplant. Dessen >Funktion ist auch einem Anfänger einleuchtend, der kein Krümel VHDL >kann. FPGAs sind nicht zwingend an VHDL gebunden, wenn gleich man dort über kurz oder lang landet. Dass VHDL nicht unbedingt das Mittel der Wahl ist, wenn es um elementare Grundlagen der Digitaltechnik geht, ist unbestritten. Man muss mal ein paar Gatter, FlipFlops und Zähler als Symbole gesehen haben. >Beim Thema FPGA wird sehr gerne die Elektronik vergessen. Nein, du willst sie nur auf Teufel komm raus verschweißen! Jeder IC muss elektrisch korrekt angeschlossen werden! Jede LED, jeder Mikrocontroller, jedes FPGA. Und auch für Mikrocontroller gibt es tonnenweise Eval-Boards, damit die Softwerker sich um ihre Software kümmern können und nicht Gott und der Welt beweisen müssen, die interdisziplinären Überflieger zu sein. > Wer damit >beginnt, eine Platine mit ein paar einfachen Chips zu machen, wird >wenigstens mit einigen realen Problemen konfrontiert, sie sich später >beim FPGA ergeben. Das interessiert einen guten Teil der FPGA-Programmierer nicht, denn auch dort ist die Trennung in Programmierung und Hardware längst Alltag. Klar gibt es Leute die beides können, das ist aber gar nicht der Punkt! > Die sind es nämlich, die nach Lösungen rufen und den >eigentlichen Anspruch beim FPGA definieren, nicht das Zählen und das >VHDL. So ein Video suggeriert nur, dass die Welt ganz einfach sei. Welche Video tut das nicht? Ich sehe schon, dir fehlt der Götterkult ums FPGA und das bußfertige Niederknien. >Es geht darum, welches Vorgehen das Effektivste ist. Lernen Stück für >Stück von den basics her ist nach wie vor das Beste. Die basics im FPGA >sind die Transitoren und Schaltfunktionen, dann das was daraus aufgebaut >im FPGA "herumliegt" sowie deren Beschreibung auf Logik, Funktions und >physikalischer Ebene. Wenn man das mal richtig im Blick hat, fallen >viele unsinnige Aktionen in VHDL erst gar nicht an, die man überall >sehen kann, in design, wo einer vom anderen abkopiert hat. Ich nenne da >nur die konsquent falsche Deklaration der architecture als "Behavioural" >sowie die Nutzung negativer Resets und "loaktiver Signale" im >Logikdesign. Jaja, da isser wieder, der alleinige Wahrheitsanspruch. >> Du legst die Messlatte reichlich hoch, man könnte meinen fast schon >> elitär. >Nein, ich zeige nur einen logischen Lernweg auf. Nö. >> Hast du Angst, dass dir morgen ein paar pfiffige Abiturienten >> mit ihren FPGA-Kreationen OHNE Löten den Rang ablaufen? >Du meinst nicht ernsthaft, ich lege absichtlich einen falschen Weg dar, >um die hilflosen und unaufgeklärten Abiturienten am schnellen Erlernen >der FPGA-Technik zu hindern? Dazu zwei Fakten: Man könnte es so interpretieren. Wo ist dann das Problem? Lass die Leute doch die Tutorials machen und nutzen. Die des OP sind nicht gut, hatten wir schon. Es gab Zeiten, da hat man sich mit deutlich weniger Infomaterial eingearbeitet. VHDL-Cookbook hatte ich am Anfang mal in den Fingern. Danach halt viel App-Notes von Xilinx und praktische Anwendung, Dokumente von anderswo, Newsgroup lesen etc. So hab ich es gelernt. Was aber nicht heißen soll, dass das der Königsweg ist. Ist es sicher nicht, es war eher ein mehr oder weniger zufälliger, nicht sonderlich straffer ungeplanter Weg. Hat trotzdem funktioniert ;-)
Falk Brunner schrieb: > Aber sie ist in Stufen erlernbar. Ganau das war meine Aussage.(?) Siehe oben "basics". > Du legst die Stufe unnötig hoch. Nein eben genau nicht. Ich betreite nur, dass der Einstieg auf der hohen Abstraktionsebene der formellen Bescheibung der Richtige ist. > Die Grundlagen der Digitaltechik hast weder DU noch Ich in drei Tagen > gelernt. Wo habe ich das behauptet? Ich habe doch hier das genaue Gegenteil geschrieben: "Ich habe aber wirklich mit SW und Chips angefangen und schon viele basics drauf, bevor es mit GALs und PALs losging." > Legacy support. Riesige, gar neue, innovative Dinge werden damit schon > lange nicht mehr gemacht. Es geht nicht um "riesige" Designs. Es geht um einfach Funktionen, sowohl bez der Argumentation "Lernen" und auch "Anwenden". Selbstredend werden auch heute noch in x Schaltungen simple Und-Gatter und Schieberegister eingesetzt, wenn man nicht viel mehr braucht. Kein Mensche steckt da unnötig ein PLD rein, es sei denn, es ist aus anderen Gründen drauf. >> Es geht wie >>gesagt um den Einstieg in die digitale Schaltungstechnik und nicht das >>Anfertigen von komplexe Designs, die ein "TTL-Grab" erfordern würden. > > Kann man entweder simulieren oder per graphischer Eingabe mit > TTL-Funktionsblöcken machen. Ja, und was willst Du damit sagen? Du entfernst Dich vom Argumentationsstrang. Deine Aussage war, dass man keine Gatter mehr einsetzt, der Komplexität wegen und ich entgegnete, dass es nicht um komplexe Designs ging. > um elementare Grundlagen der Digitaltechnik geht, ist > unbestritten. Man muss mal ein paar Gatter, FlipFlops und Zähler als > Symbole gesehen haben. aha, da kommen wir also langsam doch zu Potte. >>Beim Thema FPGA wird sehr gerne die Elektronik vergessen. > Nein, du willst sie nur auf Teufel komm raus verschweißen! Was möchte ich?(??) >> Wer damit >>beginnt, eine Platine mit ein paar einfachen Chips zu machen, wird >>wenigstens mit einigen realen Problemen konfrontiert, sie sich später >>beim FPGA ergeben. > > Das interessiert einen guten Teil der FPGA-Programmierer nicht, Sollte es aber. > denn auch dort ist die Trennung in Programmierung und Hardware längst > Alltag. Das ist nur theoretisch so. In der virtuellen Programmierung kann man sich etliche Kontrukte erdenken, die formell funktionieren, aber bei der konkreten Umsetzung in FPGAs äusserst suboptimal sind. Ohne die Kenntnis der spezifischen Vorgänge und Randbedingungen geht da viel in die Wiese. Sobald es an die effektive Ausnutzung der Chipresourcen geht, ist eine genaue Kenntnis der Resourcen nötig. Die totale Trennung von SW und HW klappt nur bei der Nuzung echter Software (in C) bei Nutzung eines (Soft-)Cores, also einer bekannten Struktur. >>Nein, ich zeige nur einen logischen Lernweg auf. > Nö. Gegenrede ist kein Argument. Nur weil Du den Einstieg in die digitale Welt auf abstaktem Niveau für machbar hälst, ist meine Vorstellung sich von den realen Grundfunktionen her einzuarbeiten keinesweg infragezustellen. >>Du meinst nicht ernsthaft, ich lege absichtlich einen falschen Weg dar, >>um die hilflosen und unaufgeklärten Abiturienten am schnellen Erlernen >>der FPGA-Technik zu hindern? > Man könnte es so interpretieren. Aber dem dritten Bier vielleicht. Nur, weil Du das jetzt so gelesen haben willst, heisst das noch nicht, dass "man" = der REst der Welt das ebenso zu interpretieren hat. > Wo ist dann das Problem? Lass die Leute doch die Tutorials machen und > nutzen. Ich habe kein Problem mit den Tutorials als solchen, wenn man bitte nochmal meinen ersten Beitrag lesen möchte. Ich habe nur ein statement zu der Frage abgegeben, ob es sinnvoll ist, ohne vertiefte Kenntnisse der Digitaltechnik mit FPGAs zu beginnen und die Aussage gemacht, dass ich Kenntnisse der Digitaltechnik und der Elektronik für sehr wichtig halte und es ferner meine Ansicht ist, dass das simple Implementieren von Zählfunktionen oder anderen Trivialitäten noch nicht viel zum Thema FPGA sagt, da die eigentlichen Themen im FPGA damit noch nicht angeschnitten werden und man sich nur den Illusion hingibt, FPGA-Entwicklung sei was Einfaches und leicht erlernbar. Das Zähler schreiben und LED-Blinken ist einfach, ja, aber es hat nichts direkt mit FPGA-Technik zu tun. Die Leistung der FPGAs ist es eben nicht, auch das zu können, was man schon mit Controllern oder einfachen Chips machen kann, sondern eben Dinge zu können, die man nur mit FPGAs machen kann. Das hat nichts mit elitärem Denken zu tun, sondern nur mit einer fokusierten Argmentation. Ich verweise nochmal auf meinen Flugzeugvergleich zu oben: Das Probesitzen im Cockpit darf einen nicht dazu verlassen, zu glauben, man habe auch nur ansatzweise einen Kampfjet geflogen. Und letztlich geht es bei dem Lernen auch um Effizienz: Der overhead, den man braucht, um ein paar LEDs im FPGA blinken zu lassen ist relativ gross im Bezug auf den Lernerfolg. Daher lernt 90% der Welt seit Dekaden erfolreich von Einfachen zum Komplizierten und vom Konkreten zum Abstrakten. Ich halte meine Behauptung aufrecht, dass der Einstieg in die Digitaltechnik über die abstrakte Beschreibung von Hardware (und es muss ja nicht nur die Schaltung beschrieben werden und drei grafisch Gattersymbole plaziert werden) suboptimimal ist und potenziell in falsche Richtungen führt. Das kann man in der Praxis sehr oft und häufig aufzeigen, wenn man die Ergebnisse von Leuten sieht, die keine E-Technik gemacht haben, sondern z.B. über die SW gekommen sind. > Die des OP sind nicht gut, hatten wir schon. Ich habe zu den Tutorials selbst nicht Stellung genommen. > Es gab Zeiten, da > hat man sich mit deutlich weniger Infomaterial eingearbeitet. Es geht nicht um die Menge sondern die Art und Qualität. Und vor allem geht es um die Vorkenntnisse und die richtigen Denkansätze. Man muss um die Mittel und Methoden der Digitaltechnik wissen. Eine abstrahierte Beschreibungssprache zu erlernen und anzuwenden ist dann eine Frage der Zeit. > VHDL-Cookbook hatte ich am Anfang mal in den Fingern. Danach halt viel > App-Notes von Xilinx und praktische Anwendung, Dokumente von anderswo, > Newsgroup lesen etc. So hab ich es gelernt. Was aber doch nichts anderes ist, als sich mit praktischer HW auseinanderzusetzen und mithin erfordert, dass man ein Grundverständnis für die Funktionen bereits mitbringt. > nicht sonderlich straffer ungeplanter Weg. Wenn man so argumentiert könnte man das auch auf den gesamten Lernstoff im Leben applizieren und damit Schulzeit und Studium um 50% erweitern. > Hat trotzdem funktioniert ;-) Was zu beweisen wäre. Wie misst man das FPGA-Können? Bzw die Intelligenz einer Schaltung?
Ich denke "Juergen S" ist ehe aus OLD School Generation, wo wirklich nur mit Assembler und breadboard gebastelt wurde. Diese Menschen denken, das nur dieser , zum vergleich schwerer, Weg der einziger richtiger ist. Die moderne bequeme Dev. boards, C++ ist ein Kindergarten, und derjenige der richtig was lernen will, soll auch den gleichen antiken Weg gehen... Ah ja, darum geht es in meinem Thread nicht:) Ich habe den letzen "tutorial" editiert, und die musik komplett ausgeschaltet: http://www.youtube.com/watch?v=WK5FT5RD1sU
Böser Kommunist schrieb: > Pff, bitte? Du meinst der jenige, der gerade Lust und Interesse an FPGA > hat, soll sich zuerst in Hardware und PCB design gehen, damit ein halbes > Jahr verbringen und erst dann eigene PCB mit FPGA bauen? Ähhm.. JA. Wer keine Ahnung hat von Hardware gehört nicht in die FPGA-Entwicklung. Basta. Und wer keine Ahnung hat von PCB-Design, wird auch kein guter FPGA-Designer, denn schließlich werkelt so ein FPGA ja nicht im luftleeren Raum, sondern muß mitten in anderen Schaltungsteilen seine Funktion erfüllen - und dazu gehört sehr viel mehr als bloß ne Liste, wo low und wo high wann anliegt. Ich frag dich mal ganz im Ernst: Was meinst du, was für Leute dabei herauskommen, die nur gelernt haben, auf einem fertigen Evalboard mit vorgefertigten Stücken Software LED's blinken zu lassen? Und was meinst du mit "Lust und Interesse.."? In meinen Ohren klingt das wie Selbstbefriedigung (es gibt auch deftigere Wörter dazu..) auf die elektronische Art. Von sowas lernt man garantiert nicht, irgendeine echte Hardware-Aufgabe zu lösen - von optimalem Lösen mal ganz abgesehen. W.S.
Böser Kommunist schrieb: > wo wirklich > nur mit Assembler und breadboard gebastelt wurde. Du unterschätzt, wie viele andere auch, was vor Deiner Zeit gemacht wurde. Den FPGA-Designflow gibt es nicht erst seit gestern, nur weil er mittlerweile in allen Unis vertreten ist und viele Studenten ihn lernen und daher meinen, es sei was Neues und Modernes. VHDL/Verilog wird schon seit >20 Jahren flächendeckend eingesetzt, seit wenigstens 15 Jahren kann man FPGAs grafisch bauen und seit schon rund 10 Jahren gibt es z.B. den ISE-DesignFlow in seiner jetzigen Form. Also alles nix Neues. > Diese Menschen denken, > das nur dieser , zum vergleich schwerer, Weg Da ist nichts schwerer oder leichter sondern es geht um die Reihenfolge. Das Wissen insgesamt brauchst Du so oder so, wenn Du auf dem Sektor was marktwirksames bauen willst, denn über Eines musst Du Dir im Klaren sein: Die Dinge, die jemand bei FPGAs oder welchen Technologien auch immer in kurzer Zeit erlernen und beherrschen kann, können viele andere auch in der gleichen Zeit erlernen. Mit dem Wissen ist zwar je nach Technologiegrenze (hier Intelligenz der Tools) immer mehr hinzubringen, aber das stellt dann auch eine immer kleinere Leistung dar. Die Tools werden immer besser (fehlerfreier) und das Zusammenklicken von ganzen SOPC-Systemen ist heute ein Kinderspiel. Daher liegen die eigentlichen Hasen im Bereich FPGA auf dem Elektronik-, dem Analog- und dem EMV/SI-Sektor begraben. Das sind die Kern-FPGA-Themen. Nun kommt sicher gleich wieder das Argument von oben, dass man das heute Trennen kann und auch (hochmoderner Weise) mit C++, SystemC und C auf Soft-Cores die heutigen großen FPGAs programmieren kann. Aber genau weil man das kann, sind dies eben allgemeine Softwarekenntnisse und keine ureigensten FPGA-spezifischen Themen. Wenn man das deklarationstechnisch vermischt, hat man zwar durch die vielen weltweit verfügbaren C-Programmierer scheinbar schlagartig massenweise "FPGA-Experten", aber es bleibt letztlich nur ein Argumentationstrick, bzw. eine Verklärung der Fakten und ändert nichts an der (mit den Taktfrequenzen und den dedizierten Innereien heutiger FPGAs wachsenden!) Menge an typischen FPGA-Problemstellungen im Umfeld der Elektronik und Physik, die mit der SW nichts zu tun haben und auch nicht mir ihr gelöst werden können. Diese Dinge mal aufzudröseln, wäre ein lohnendes Ziel für ein Tutorial. In jedem Falle ist es offenbar stark interpretationsabhängig, was man alles als FPGA-Entwicklung deklarieren soll. Nach der Vorstellung der Firma Mathworks ist ja praktisch jeder Chemiker, der seinen Titrations-Regelungs-Algorithmus für den Fermenter ins MATLAB reingehackt hat und in der Lage ist, den Generate-Knopf im Simulink-Fenster zu finden, ein FPGA-Entwickler. Ich nehme solche Einschätzungen belustigt zur Kenntnis.
To W.S. Ich denke du verwechselst hier einiges. Nicht alle FPGA interessierten wollen FPGA profis werden. Ich z.B. erlerne FPGA und Hardware design einfach als Zusatzfähigkeit and Hobby, die mir später im berufsleben zusätzlich helfen kann. Ich habe wirklich nicht vor mit FPGA mein Brot zu verdienen, dafür soll man wirklich sehr tief in Detail gehen. Aber falls ich später in einer Forschungslabor arbeiten werde (worauf ich wirklich hoffe) und mir jemand die Aufgabe stellt einen Messplatz für irgendwelche experimentelle Probe zu errichten, werde ich dann ruhig ein fertiges FPGA/ARM board nehmen, und diesen "programmieren". Und wieso beschränks du dich auf die blinkende LED's? Sobald du den Prozess auf deinem Dev Board verstanden hast, kanns du was eigenes entwickeln. So habe ich es gemacht. Ersmal mit sehr wenig ahnung mit DE1 FPGA board angefangen, dann erlernte ich wie SDRAM, SRAM,RS232,SPI etc fuktionieren, später habe ich eigenes Acquisition Board gebaut (s.Link) mit selbst enwickelter PCB,Firmware für CPLD etc. Dabei lernte ich was zum PCB/hardware design usw. http://www.eevblog.com/forum/projects/acquisition-module-first-prototype-inside)/msg261192/ Man muss nicht ungedingt durch Bottom-UP Methode lernen, TOP-DOWN geht auch;)
Hallo, Dein 4. Video mit deinen Kommentaren und ganz ohne Musik gefällt mir. Den anderen 3 Videos mit der Musik kann ich nicht folgen, da es mir auch mit großer Anstrengung nicht gelingt mich auf den VHDL Code zu konzentrieren. Nimm doch auch dort die Musik weg und erzähle dafür immer was du gerade machst(eintippst). Gruß Helmut
Leider habe ich die Source-Datei für die übrigen 3 videos verloren (HDD-Tod):( Daher ist es mir nicht möglich die Musik einfach rauszunehmen, wie in den 4. Video. Die nächtse Tutorials werden wohl ohne Musik sein.
W.S. schrieb: > Wer keine Ahnung hat von Hardware gehört nicht in die FPGA-Entwicklung. > Basta. :-) Böser Kommunist schrieb: > jemand die Aufgabe stellt einen Messplatz > für irgendwelche experimentelle Probe zu errichten, werde ich dann ruhig > ein fertiges FPGA/ARM board nehmen, und diesen "programmieren". Da mach Dir mal keine Hoffnung. Wenn es was Wichtiges ist, das nach Außen vertrieben werden soll, wird es an einen Selbständigen rausgegeben und wenn es ein internes Projekt ist, wird man einen Studenten per DA dransetzen, der nichts kostet. Bei vielen werden die erlernten VHDL-Kenntnisse genau so vor sich hingammeln, wie es heute mit dem C der Fall ist. Jeder Ingenieur, der nach 1990 studiert hat, kann es, aber keine 5% setzt es ein, die aber richtig! Ein Tipp: Wenn Du wirklich in der Hoffnung lebst, dass Du mit Nebenher-Kenntnissen später mal im Job sowas machen darfst, dann solltest Du nicht so viele Tutorials machen, denn Du züchtest Dir genau auf dem Sektor die Konkurrenz. :-) >Man muss nicht ungedingt durch Bottom-UP Methode lernen, TOP-DOWN geht auch;) Das was Du in Deinem Text beschreibst, ist nicht "Top-Down", sondern "MID-UP". Du hast mitten drin angefangen und dich hochgehangelt und dabei einiges überblättert. Alle Aufgaben, die Du Dir selber gestellt hast, haben scheinbar funktioniert. Das wird anders, wenn Du Aufgaben bekommst, die ein anderer definiert und/oder Du nicht merkst, dass Dir Grundlagen fehlen und Du falsche Prinzipien anwendest. In dem Projekt z.B., das Du als Referenz oben anführst, hast Du einen ADC übertaktet. Denk mal darüber nach, welche grundsätzlichen Probleme Du damit bekommst.
@Juergen S. (engineer) Benutzerseite >Da mach Dir mal keine Hoffnung. Wenn es was Wichtiges ist, das nach >Außen vertrieben werden soll, wird es an einen Selbständigen rausgegeben >und wenn es ein internes Projekt ist, wird man einen Studenten per DA >dransetzen, der nichts kostet. Du bist ein richtiger Optimist. Mann O Mann. >Fall ist. Jeder Ingenieur, der nach 1990 studiert hat, kann es, aber >keine 5% setzt es ein, die aber richtig! Ist in vielen anderen Bereich nicht anders. Im Studium lernt man viele verschiedene Dinge, spezialisieren tut man sich dann nur auf einige. >Ein Tipp: Wenn Du wirklich in der Hoffnung lebst, dass Du mit >Nebenher-Kenntnissen später mal im Job sowas machen darfst, dann >solltest Du nicht so viele Tutorials machen, denn Du züchtest Dir genau >auf dem Sektor die Konkurrenz. :-) Aha, also doch die Angst vor dem Göttersturz. >Das was Du in Deinem Text beschreibst, ist nicht "Top-Down", sondern >"MID-UP". Du hast mitten drin angefangen und dich hochgehangelt und >dabei einiges überblättert. Alle Aufgaben, die Du Dir selber gestellt >hast, haben scheinbar funktioniert. Das wird anders, wenn Du Aufgaben >bekommst, die ein anderer definiert und/oder Du nicht merkst, dass Dir >Grundlagen fehlen und Du falsche Prinzipien anwendest. In dem Projekt >z.B., das Du als Referenz oben anführst, hast Du einen ADC übertaktet. >Denk mal darüber nach, welche grundsätzlichen Probleme Du damit >bekommst. Mann O Mann, es ist unglaublich, wieviel Miesepetrigkeit hier herrscht. Naja, EOD. Wird ja doch nur Blindleistung.
Ich kann ehrlich gesagt nicht glauben, dass eine Firma/Uni sich extra einen FPGA Enwickler eintellen wird, um so eine Nebenaufgabe zu erledigen. Das wird doch viel zu teuer werden. Hier ein Beispiel aus der Realität: An der Uni wird es an organische gedruckte Elktronik geforscht(gedruckte OLED's, Transisotoren etc). Die Doktorandin spezialisiet sich eigentlich für Chemie/physik => optimiert den Druckprozess, forsch nach den neuen Lösungsmitteln, dotierungen etc. Im moment baut sie egenen Drucker mit den ganzen Sensoren, CCD kamera, Laser für Tintentverdampfung etc. Dafür lernt sie praktisch von Null die ganze Hardware und Software programmierung. Keiner stellt hier einen Studenten oder übergibt die Aufgabe an den Proffis. So sehe ich es an den Firmaen oder in der Forschung: es ist immer besser und billiger wenn die Arbeit von einem Mitarbeiter erledigt wird. Zum Projekt Ja, die ADC werden bei 250 Mhz sehr ungenau.Es gibt dort noch mehr Fehler... Wie gesagt, das war mein erstes Projekt und meine erste Platine im Leben. Nicht alles funktioniert dort wie ich es geplant habe, aber daraus habe ich sehr viel gelernt, und das hat auch spaß gemacht. Zu deinem Tipp: Diese Tutorials haben auch ein Vorteil für mich: ich übe richtig english zu sprechen. Außerdem glaube ich an Karma;)
@Böser Kommunist (Firma: UdSSR) (chromosoma) > So sehe ich es an den Firmaen oder in der Forschung: es ist immer >besser und billiger wenn die Arbeit von einem Mitarbeiter erledigt wird. Das ist oft ein Irrtum. Denn man erfindet dabei das Rad neu, meist etwas eckig. Am PREISWERTESTEN macht es immer der Profi, der in der Materie wirklich fit ist. BILLIG ist das nicht zwangsweise.
Böser Kommunist schrieb: > Ich kann ehrlich gesagt nicht glauben, dass eine Firma/Uni sich extra > einen FPGA Enwickler eintellen wird, um so eine Nebenaufgabe zu > erledigen. Das wird doch viel zu teuer werden. Ich sprach auch nicht vom Einstellen, sondern von externer Vergabe. Es gibt einige Forschungsinstitute, die regelmäßig Produkte und Dienstleistungen in die Industrie verkaufen, bzw. Aufträge abarbeiten, wo sie spezielles Knowhow haben, z.B. auf dem Gebiet der SV. Dazu gehört dann aber bei bestimmten Produkten und Branchen auch eine normengerechte Entwicklung und Validierung dazu und diesbezüglich liegt da meist kein Knowhow vor. Führt aber jetzt zu weit. >Ja, die ADC werden bei 250 Mhz sehr ungenau. S&H! Neben SI, ein klassisches Analogthema im Umfeld von FPGA-Designs. Da haben wir es doch schon. :-) >ich übe richtig english zu sprechen. Das funzt aber nur, wenn Du Dir diesbezüglich ein Feedback des Auditoriums abholst und ich werde mich hüten, zu Deinem English was zu sagen. >Außerdem glaube ich an Karma Ich auch. Da ist aber kein FPGA drin sondern ein DSP: http://www.korg.de/produkte/fruehere-modelle/karma-produktinfo/karma-produktinfo-2.html Falk Brunner schrieb: > Das ist oft ein Irrtum. Denn man erfindet dabei das Rad neu, meist etwas > eckig. Am PREISWERTESTEN macht es immer der Profi, der in der Materie > wirklich fit ist. BILLIG ist das nicht zwangsweise. und genau deshalb schrieb ich, dass es entweder nach Draussen an einen Selbständigen (oder eine Firma) geht oder es intern ein Studi ganz billig macht. Und der ist immer billig, egal wie lange er bastelt. Ein Festangstellter an einem Forschungsinstitut muss auch einigermaßen produktiv arbeiten, wenn auch unter anderen Randbedingungen, als in der Industrie.
Böser Kommunist schrieb: > Aber falls ich später in einer Forschungslabor arbeiten werde (worauf > ich wirklich hoffe) und mir jemand die Aufgabe stellt Ach herrjemineh... da tun sich ja Abgründe auf! Du willst in einem Forschungslabor ähem.. arbeiten? Und dann erwartest du, daß dir jemend in seiner Weisheit ne tolle Aufgabe stellt? Nee, träume du mal lieber nicht weiter, sondern komm runter uaf den Boden, solange du noch jung bist. Mal abgesehen davon führt der Weg in ne unbefristete Stelle in nem Institut über Promotion und ne gehörige Portion "Karriere machen", also Ellenbogen usw. Da bleib keine graue Zelle mehr übrig um sich mit VHDL und FPGA's zu befassen. Böser Kommunist schrieb: > Ich kann ehrlich gesagt nicht glauben, dass eine Firma/Uni sich extra > einen FPGA Enwickler eintellen wird, um so eine Nebenaufgabe zu > erledigen. Siehste, das glaub ich auch nicht. Deswegen ist es so, daß sich besagte Firma überhaupt nicht drum schert, wie du deine Entwicklungsarbeit erledigst, sondern nur, daß es sich gut verkaufen läßt und die Herstellungskosten in der Serie niedrig bleiben. Ob du da ein FPGA nimmst oder die Sache ganz anders löst, ist deiner hoffentlich umfassenden Kompetenz überlassen. Genau deshalb ist es ja so eminent wichtig, nen Überblick und breit angelegte Kenntnisse zu haben - Hardware/Software/Gerätetechnik/Design/Maschinenbau und technisches Zeichnen/Kalkulation und und und. W.S.
Abgesehen von den ganzen Diskussionen, die hier gelaufen sind und laufen, fällt mir bei den Tutorials (die ich zugegebenermaßen nicht komplett geschaut habe), dass eigentlich nicht ganz klar wird, WAS du vermitteln willst. Geht es dir darum, speziell auf dieses Dev-Board einzugehen, oder auf die IDE oder willst du fundiert VHDL-Kenntnisse vermitteln? Irgendwie ist das ein Mischmasch aus allem. Wenn jemand keine Ahung von VHDL hat, dann kann er anhand deines Tutorials irgendwelche Spielereien auf dem Board nachbasteln, aber WAS er da letztendlich beschreibt, lernt er dabei meines Erachtens nicht. Ich würde dem ganzen ein Kapitel voranstellen, wo du auf die Sprachlichen Grundelemente von VHDL eingehst und ein paar Konstrukte vorstellst und darauf eingehst, was sie letztendlich bei der Synthese bewirken. Erst dann würde ich das Ganze anhand von Beispielen auf der realen Hadware vorführen. Setzen wir mal voraus, dass der geneigte Zuschauer die über Kenntnisse der Digitalen Schaltungstechnik verfügt, dann wird er sich doch fragen: "Wie sag ich jetzt in VHDL, dass ich ein Register haben will?", "Wie sag ich, dass ich ein UND-Gatter haben will?" etc... Du näherst dich dem Thema eher von der Sofware-Sicht. "Programmiere" etwas so und so und dann tut es. Aber was da im FPGA wirklich passiert, geht aus dem Tutorial nicht hervor. Mag sein, dass viele das als ausreichend empfinden, aber meiner Meinung nach sollte man schon eine Vorstellung haben, welche Konstrukte sich nach der Syntehse wie darstellen. Spätestens, wenn es an´s Constraining geht, muss man wissen, wo man welche Register und Logikpfade beschrieben hat. Zum Thema Musik: Ich empfinde es auch als eher störend. Arbeite zwar auch gerne mit Musik, aber ich habe vielleicht doch einen etwas anderen Geschmack ;-) Zuschauen, wie jemand Code eintippt, das wirkt auf mich eher einschläfernd. Sinnvoller fände ich es, wenn du fertige Code-Snippets nach und nach einfügst und lieber dann erklärst, was dieser Code-Teil macht. So hat man den Code vor Augen, kann den Erklärungen folgen und muss nicht bei jedem Buchstaben hinschauen, was jetzt als nächstes passiert.
W.S. schrieb: > Wer keine Ahnung hat von Hardware gehört nicht in die FPGA-Entwicklung. > Basta. > > Und wer keine Ahnung hat von PCB-Design, wird auch kein guter > FPGA-Designer, denn schließlich werkelt so ein FPGA ja nicht im > luftleeren Raum, sondern muß mitten in anderen Schaltungsteilen seine > Funktion erfüllen - und dazu gehört sehr viel mehr als bloß ne Liste, wo > low und wo high wann anliegt. Da bin ich anderer Meinung. Bei der Entwicklung von IP-Cores wie bspw. digitalen Filtern, Glue-Logic, Soft-Cores und anderen Schweinereien würde ich keine Tiefgreifenden HW-Kenntnisse voraussetzen. Hier sind eher Kenntnisse im Entwurf von digitalen Schaltungen gefragt, ganz zu Schweigen von Signalverarbeitung, Prozessor-Architektur etc. pp.. Ein HW-Entwickler der das entsprechende Board designen kann UND darüber hinaus die angesprochenen Fertigkeiten mitbringt ist natürlich Gold wert :-). Aber es muss nicht zwingend so sein. Was meint ihr dazu?
> Wer keine Ahnung hat von Hardware gehört nicht in die FPGA-Entwicklung. > Basta. Man muss nur dann Ahnung von Hardware haben, wenn man auch das PCB-Design entwickelt auf dem der FPGA zum Einsatz kommt. Ansonsten kann doch jeder was in VHDL entwerfen, ohne je einen Widerstand in der Hand gehalten zu haben. Ich sehe da keinen Widerspruch. Ganz im Gegenteil: Ein kluger Kopf kann sich zum Beispiel überlegen wie er einen speziellen, trickreichen mathematischen Algorithmus in VHDL beschreiben kann. Dann muss er das nur noch auf ein fertiges FPGA-Board laden und kann es nutzen. lg
to Schlumpf Mein Ziel ist den Einstieg in die FPGA Welt möglichst zu vereinfachen. D.h. ich erkläre ausführlich wie man LED's zum blinken bringt, wie man einen Zähler baut, RS232 oder VGA Kommunication in VHDL beschreibt etc. Ich setze zwar vorraus, das der jenige, der diese Videos sich anschaut schon einwenig Ahnung von VHDL und FPGA hat. Trotzdem erkläre ich (besonders in den ersten 2 Videos) wie man ENTITY deklariert, was sind Signale, Processe, wie baut man eigene "Packages" und Komponente etc. Das alles wird ziemlich ausfühlich beschrieben.
Böser Kommunist schrieb: > to Schlumpf > > Mein Ziel ist den Einstieg in die FPGA Welt möglichst zu vereinfachen. > D.h. ich erkläre ausführlich wie man LED's zum blinken bringt, wie man > einen Zähler baut, RS232 oder VGA Kommunication in VHDL beschreibt etc. > > Ich setze zwar vorraus, das der jenige, der diese Videos sich anschaut > schon einwenig Ahnung von VHDL und FPGA hat. Trotzdem erkläre ich > (besonders in den ersten 2 Videos) wie man ENTITY deklariert, was sind > Signale, Processe, wie baut man eigene "Packages" und Komponente etc. > Das alles wird ziemlich ausfühlich beschrieben. Ich finde das ziemlich gut! Hast du denn auch vor, dass Ganze in Textform zu machen? Als PDF oder so?
Nein, aber der Source Code ist unter jedem video zum download vorhanden.
Böser Kommunist schrieb: > Trotzdem erkläre ich > (besonders in den ersten 2 Videos) wie man.... Dann habe ich wohl zu früh abgebrochen.. sorry.
Schlumpf schrieb: > Böser Kommunist schrieb: >> Trotzdem erkläre ich >> (besonders in den ersten 2 Videos) wie man.... > > Dann habe ich wohl zu früh abgebrochen.. sorry. Du musst ein Stück unterhalb des Videos auf "Mehr anzeigen" klicken. Dann klappt mehr Text mit dem Download-Link auf.
Schlumpf schrieb: > Ich würde dem ganzen ein Kapitel voranstellen, wo du auf die > Sprachlichen Grundelemente von VHDL eingehst und ein paar Konstrukte > vorstellst und darauf eingehst, was sie letztendlich bei der Synthese > bewirken. Das ist doch nicht zu leisten! In so einem Minivideo kannst Du doch nicht einen kompletten Lehrplan unterbringen. Sowas muss konzentriert ein Thema abhandeln und zwar möglichst ein eng begrenztes sonst wird das Ganze zu einem Torturial. Böser Kommunist schrieb: > Ich setze zwar vorraus, das der jenige, der diese Videos sich anschaut > schon einwenig Ahnung von VHDL und FPGA hat. Trotzdem erkläre ich > (besonders in den ersten 2 Videos) wie man ENTITY deklariert, was sind > Signale, Processe, wie baut man eigene "Packages" und Komponente etc. > Das alles wird ziemlich ausfühlich beschrieben. Viel zu knapp und unübersichtlich. Wer es kann, braucht es nicht, wer es nicht kann, lernt es damit auch nicht. Konzenztiere Dich auf einen Punkt: Wie nimmt man so ein board in Betrieb, z.B. Du solltest auch nicht versuchen, Sachen zu machen, die es schon gibt, sondern Dinge identifizieren, die es bei Altera und Xilinx nicht als Webinar gibt - die Lücke sozusagen.
Markus Wagner schrieb: > Das ist doch nicht zu leisten! In so einem Minivideo kannst Du doch > nicht einen kompletten Lehrplan unterbringen. Stimmt, aber es ist ja auch nicht die Rede von einem kompletten Lehrplan mit allen Konstrukten und Sprachlichen Besonderheiten, die VHDL so bietet. Genaugenommen kann man in VHDL mit sehr wenigen konstrukten eigentlich schon alles machen. Alles, was darüber hinausgeht, ist nice aber nicht notwendig. Variablen braucht man nicht. Schleifenkonstrukte sind nicht notwendig, sondern ersparen lediglich Tipparbeit. Eigene Packages braucht man auch nicht zwingend. usw.. Was man im Grunde braucht, sind die Elemente, die man auch als reale Bausteine zur Verfügung hat. Register, Logikelemente, etc... Wenn man einen "Fahrplan" bekommt a la "Alle Signalzuweisungen in einem getakteten Prozess werden zu Registern, alles andere wird Kombinatorik", dann ist das schonmal was, womit man was anfangen kann. Dann vielleicht ein paar Beispiele, wie man einen Zähler beschreibt, oder ein Schieberegister oder einen Addierer... Ein wenig darauf eingehen, dass man grundsätzlich ein HDL-Design in Register und dazwischenliegende Kombinatorik trennen kann (z.B. über die 2-Prozess-Methode). Oder vielleicht eine Erklärung, warum man bei mehreren Takten im System besonders aufpassen muss. Das alles lässt sich meines Erachtens schon komprimiert darstellen, unter der Voraussetzung, dass der Zuschauer über Grundkenntnisse verfügt und man nicht erst erklären muss, was ein Register ist. Wer weiss, was die Synthese aus gewissen sprachlichen Grundkonstrukten baut, kann dann mit diesem Wissen immer komplexere Designs bauen und sich natürlich weiterführender Sprachkonstrukte bedienen. Meiner Meinung nach muss man gleich dem Anfänger den Zahn ziehen, dass er meint, er "programmiert", wie er es von einem Controller her kennt. Ihm muss klar werden, dass er mit seinen abstrakten Beschreibungen letztendlich Grundelemente der Digitaltechnik verschaltet. Das sollte das allererste Ziel sein. Und das kann man vermutlich am Besten, indem man es mit einfachen Konstrukten vorführt. z.B. durch Erklären des Syntheseergebnis (RTL). Dieser Groschen sollte bei jedem gefallen sein, bevor er sich an komplexere Designs macht. Sonst fällt einem das Ganze spätestens dann auf die Füße, wenn man sich an´s Constrainig macht, Übergänge zwischen Taktdomänen in den Griff kriegen muss oder einfach nach der Synthese die gewünschte Taktrate nicht erreicht wird. Ob ein Video da das Lehrmittel der wahl ist, bleibt fraglich. Ich würde für sowas generell ein Buch bevorzugen.
Ich bin ja eher so stiller Beobachter, aber eine Sache muss ich doch anmerken...! PCB-Layout als Hardware-Design zu bezeichnen ....llllloooooolllll!! In allen Firmen wo ich gearbeitet hab egal ob Asic-Entwurf oder Entwurf diskreter Elektronik, haben wir Layout-Aufgaben an unsere ausgebildeten Elektroniker (Nicht-Ingenieure) abgegeben oder es wurde nebenbei erledigt!! Schaltungsentwurf und PCB-Design gleichzusetzen - selbst beim Chip-Entwurf (also Asic-Design) ist eine Beleidigung für jeden der Schaltungstechnik studiert hat!!! Aufgabe eines Ingenieurs egal, welcher Richtung ist es strukturierte Lösungsansätze (auch Algorithmen genannt) zu entsprechenden Problemstellungen zu entwickeln!! Nicht Mal-/Zeichenprogramme zu bedienen!! Zum TO: Daumen hoch für dein Engagement! Sicher kann man nicht alles perfekt machen. Aber selbst wenn einem deine Videos auch nur 1-2 Stunden bei einem Anfänger die in Betriebnahme von irgendeinem Demo-Board verkürzen... Well Done!!
OT: @Trundle Trollkönig (shaheed): wenn ich das schon lese -- Trundle Trollkönig schrieb: > Aufgabe eines Ingenieurs egal, welcher Richtung ist es strukturierte > Lösungsansätze (auch Algorithmen genannt) zu entsprechenden > Problemstellungen zu entwickeln!! Nicht Mal-/Zeichenprogramme zu > bedienen!! da weiß ich, dass in nie ohne Arbeit bleiben werde. Wenn Du PCB-Layout mit Malprogrammen gleichsetzt, dann "Halleluja"! Das sind dann Firmen, die jemanden suchen, der die Karre aus dem Dreck zieht, wenn es plötzlich nicht funktioniert. Kann nur den Kopf schüttlen Kest p.s.: bist eben ein Troll
Na na nicht Troll... Trollkönig!!! hier Vorlesungsverzeichnis meines ehemaligen Studiengangs!! http://lsf2.tubit.tu-berlin.de/pdf/ws13/22411.pdf - Du wirst das Wort Layout genau 2 mal finden (Seite 2 und 36) beide Vorlesungen/Projekte habe ich besucht. Pi*mal-Daumen Zitat von Prof Klar (damals verantwortlich für integrierte Schaltungen). " Ich erwarte von Studenten, dass Sie sich die Bedienung von CAD-Programmen selbst aneignen, dies ist nicht Thema dieser Vorlesung" Eine Doppelstunde von 14 hat er für eine einfache Layouteinführung verwendet um zu zeigen wie man Widerstandsmatching bei integrierten Schaltungen verwirklicht!! (Nicht zu vergessen es handelt sich hier um integrierte Schaltungen wo parasitäre Effekte eine bedeutendere Rolle als bei diskreten Bauteilen besitzen). Anweisung vom Betreuer vom Projektlabor: "Benutzt mal Eagle für euer Platinen-Layout, da gibt es eine free-Studenten-Version und es gibt genug Tutorials zum Einarbeiten"!!! Nur mal so welche Bedeutung, euer hochgepriesenes Layouten in meinem Elektrotechnikstudium hatte (Schwerpunkt integrierte Schaltungen)!! Kannst ja mal den Gegenbeweis antreten und zeigen an welcher Uni mehr zum Thema Layout angeboten wird. Ich bezweifle, dass du eine Universität findest wo eine ganze Vorlesung sich dem Thema Layout widmet! Aber hey ich lass mich gerne vom Gegenteil überzeugen. Ps. bis dahin geh weiter malen ;)
Ich bin kein Layouter, also "male" ich extremst selten. Dafür haben wir Leute (Ings), die sich damit richtig auskennen. Ich möchte hier nichts beweisen. Und übrigens, beim Prof Klar hatte ich auch mal eine oder die andere Vorlesung. Seine Äußerungen (und auch von ein Paar anderen) sind sehr weit von der Realität entfernt. Zu Eagle sage ich auch mal nichts. Und ja, die Bedeutung von PCB-Layout wird an den Unis komplett unterschätzt, weil eben viele denken "mit niederen Arbeiten werde ich als Ing mich nicht beschäftigen". Das ganze resultiert in katastrophalen Geräte-Designs. Aber was erzähle ich hier: sage ich doch, solange es solche Menschen wie Dich gibt und auch solche Firmen, werde ich immer einen Job haben :-) Ich sage nicht, dass eure angelernte Elektroniker schlecht sind. Ich sage nur, dass Deine Haltung denen gegenüber unmöglich ist. Kest
Ich hab hier gar nichts angefangen!!! Hier sind einige auf den TO losgegangen und hab ihm gesagt er soll sich lieber mit PCB-Design befassen, statt mit den Konzepten und Strukturen des Logischen Entwurfs!! Und haben das als Schaltungsentwurf betitelt. Das sehe ich als äußerst kontraproduktiven Ratschlag für den TO. Denn der scheint andere Dinge in seinem Berufsleben machen zu wollen. Lieber TO, wenn du in deinem Berufs irgendwann mal Projektverantwortung übernehmen willst, forschen willst, Dinge tun willst die dir Spass machen und Sachen Entwicklen willst, dann mach da weiter wo du jetzt bist! Trainiere dir eine strukturelle und mathematische Denkweise an und lerne so viele Lösungskonzepte und Algorithmen kennen, wie es geht! Und fange nicht an dich auf das Bedienen von CAD-Software zu spezialisieren! Sonst passiert genau folgendes - du wirst abgestempelt und darfst, fröhlich den ganzen Tag Layout, während andere ihre Lösungskonzepte ausprobieren dürfen und ihnen darauf einer abgeht!! (live gesehen bei einer Firma eines weiteren TU-Profs, den du (Kest) vllt ebenfalls kennen dürftest)
Trundle Trollkönig schrieb: > In allen Firmen wo ich gearbeitet hab egal ob > Asic-Entwurf oder Entwurf diskreter Elektronik, haben wir > Layout-Aufgaben an unsere ausgebildeten Elektroniker (Nicht-Ingenieure) > abgegeben oder es wurde nebenbei erledigt!! Na, das müssen ja dann absolut grossartige Firmen gewesen sein. PCB Design für FPGAs mit HF, EMV und möglichst noch Analoges drum herum "nebenbei" erledigen. Wie weltfremd ist das denn????? > Schaltungsentwurf und > PCB-Design gleichzusetzen - selbst beim Chip-Entwurf (also Asic-Design) > ist eine Beleidigung für jeden der Schaltungstechnik studiert hat!!! Eher umgekehrt. Die Eagle-Fraktion, die nur LED-boards gebastelt hat, denkt, sie könne ein taugliches PCB hinbringen und heraus kommt nur mittelmässiges. Wer so argumentiert, wie Du zeigt, dass er keine Ahnung hat und PCB-Layout komplett unterschätzt. Ich möchte Deine Nichtingenieure mal sehen, wenn sie ein DDR3-Layout mit mehr als einem Chip machen sollen und mit welchen Frequenzen das dann noch läuft. > Nicht Mal-/Zeichenprogramme zu > bedienen!! Das Bedienen von Malfunktionen ist beim PCB Design genauso wenig hinreichend, wie beim FPGA-Design. Das sind notwendige Befähigungen, die 5% des Knowhows ausmachen. Mehr nicht. Wer glaubt, er könne mit 2-3 Symbolen aus dem CAE ein FPGA zusammenklicken wird daher genauso rasch scheitern, wie beim PCB. Deswegen halte ich zumindest grundlegende Kenntnisse des analogen Schaltungsdesigns und des PCB-Designs für absolut nötig, um wenigstens die Komplexität des Themas FPGA erfassen zu können. Leutchen, die nicht auf diesen Gebieten gearbeitet haben und nicht wenigstens je 5 Jahre Erfahrung mit Analoger, Digitaler und Funktioneller Hardware haben und mal grössere Layouts gemacht haben, tendieren dazu, dies alles masslos zu unterschätzen. Und von der Sorte scheint es hier im Forum eine ganze Horde zu geben!!! Von daher muss man dringendst infragestellen, ob ein Student den Überblick mitbringt, Videotutorials für andere zu machen. Das Machbare scheint mir da sehr limitiert. >Nur mal so welche Bedeutung, euer hochgepriesenes Layouten in meinem >Elektrotechnikstudium hatte (Schwerpunkt integrierte Schaltungen)!! Denk mal darüber nach, warum! Das ist ein ganz anders Thema und die Profs wissen um die Probleme, von daher macht es keinen Sinn, alle Studenten darauf vorzubereiten.
Trundle Trollkönig schrieb: > In allen Firmen wo ich gearbeitet hab egal ob > Asic-Entwurf oder Entwurf diskreter Elektronik, haben wir > Layout-Aufgaben an unsere ausgebildeten Elektroniker (Nicht-Ingenieure) > abgegeben oder es wurde nebenbei erledigt!! Hier muß ich Trollkönig leider recht geben: In unserem Unternehmen (>10.000 Beschäftigte) werden die Layouts von einer gesonderten Abteilung durchgeführt. Dort beschäftigen sich ca. 30 Mitarbeiter mit PCB-Layout und keiner davon ist Ingenieur, sondern bspw. Kommunikationselektroniker. Nahezu alle haben Fortbildungen des Fachverband Elektronik-Design e.V. (www.fed.de) besucht. Dieser FED bietet abartig viele Fortbildungen zum Thema PCB-Layout an.
Naja, wenn sie die Erfahrungen haben, ist das ja ok, alledings hängt es auch hier von den Anforderungen ab. Man darf sowas nicht als Massstab nehmen. Bei etlichen meiner Kunden gibt es auch eigene Layoutabteilungen, aber dort arbeiten HF Spezialisten, Analogepextern mit Erfahrung von 10-20 Jahren.
Der TO, wollte SOWEIT ich das verstanden habe, sich in den logischen Entwurf digitaler Systeme einarbeiten und seine Erfahrung mit anderen teilen. Egal ob nun um anderen den Einstieg zu erleichtern, durch das Resumé seine eigenen Erkenntisse zu vertiefen oder aufgrund von beidem, ist erst mal nebensächlich. Aber ihm dann ans Herz zu legen sich erstmal mit Layouts und PCBs von CPLDs TTL-Bausteinen oder FPGAs zu befassen, statt sich mit den Grundlagen vom Digitalentwurf zu befassen, ...ist doch wohl ähm nicht so schlau!! An den TO: Das Design woran ich jetzt arbeite, beinhaltet nen FPGA mit ca 400 IOs (89 % Auslastung), DDR2 Ram, SDRam,2 MCs, Flashs, PHYs, eigene Busse, etc...... Mit ein bissel hilfe von nem Kollegen war das Design in 2 Monaten gelayoutet (und das mit meinen obenbeschrieben Kenntnissen vom Layouten) -> Es funktioniert alles innerhalb unserer Spezifikationen! An dem was in den FPGA und die MCs kommt sitze ich schon mehr als einem Jahr (+ 1 Kollege)... und es ist immer noch nicht fertig!! Nur mal so zur Einschätzung des Arbeitsaufwandes!! Nun ratet mal, wenn ich mich mal bei einem anderem Unternehmen bewerben werde, was ich da wohl als Referenz anpreisen werden?? Hier mein tolles Layout oder hier mein .... - FPGA-Konzept?? Sry ich will hier keinen Angreifen, der layoutet noch sonst irgendwas!! Und ich habe auch nie behauptet, das man sich keine Grundkenntnisse im Layouten aneignen soll. Aber wenn er(TO) Digital-Design lernen oder machen möchte, dann sollte er sein Hauptaugenmerk auch darauf legen und nicht dem Layouten von Digital-Design! Da finde ich, Empfehlungen von bsp. Schlumpf doch wesentlich konstruktiver und (vllt noch mit einer guten Buchempfehlung, um seinen Videos noch ein bissel theoretischen Background zu geben), als ihm hier zu sagen: Junge mach erst mal ne Platine, bevor du Register im FPGA zusammenklickerst!
Trundle Trollkönig schrieb: > Nun ratet mal, wenn ich mich mal bei einem anderem Unternehmen bewerben > werde, was ich da wohl als Referenz anpreisen werden?? > Hier mein tolles Layout oder hier mein .... - FPGA-Konzept?? Nimm lieber das Layout, denn ein Aufwand von 2 Monaten ist aus Projektsicht noch akzeptabel und auch noch halbwegs plausigbel, nicht aber Bearbeitungszeiträume von >1 Jahr! Entweder taugt Dein FPGA-Konzept nichts und Du hast Dich mehrfach verrannt und in die Ecke geputzt und musstes zu viel revidieren oder ihr seid nicht teamfähig und arbeitet zu unproduktiv. Oder Du hattest von Anfang an kein gut durchdachtes Bearbeitungskonzept, anhand dessen man hätte den Aufwand abschätzen und entscheiden können, es auf 3 oder mehr Personen aufzuteilen, um in akteptablen Zeiten fertig zu werden! Genau um solche ewigen Basteleien an Designs zu verhindern, beauftragen zielführend arbeitende Firmen immer mal gerne externe Projektleiter wie mich, um Bastelbübchen, die sich beim Programmieren verlustieren, die Flausen auszutreiben und sie in der Spur zu halten. Was seid ihr denn für eine Firma, dass man sich da >1 Jahr an der FPGA Software leisten kann? Was wird da parallel gebaut, dass man so lange auf Ergebnisse warten kann? In der Regel werden PCB und FPGA teilweise sogar parallel erzeugt, um zeitnah eine IB machen zu können, und das Design verbessern zu können. Dafür braucht es eine weitgehend fertige FPGA-Software. Da ohne funktionierende Elekronik auch der Rest des Systems nicht testbar ist, ist das Resultat der Betrachtung, dass alle Software, die mehr als 6 Monate dauern wird, unbedingt aufgeteilt und beschleunigt werden muss, um die TTM nicht unnötig aufzublähen. Einzig bei Grossanlagen und geräten, die der mehrfach iterativen Überarbeitung unterliegen, kann man sich mit der SW mehr Zeit lassen, aber auch dann darf das nicht überborden. Wie wäre es denn mal mit einer Videoanleitung, wie man Projekte plant?
Wir sind jetzt reichlich OT hier :-/ Ich musste jetzt auch noch mal schmunzeln, wegen einem Jahr am FPGA Design ;-) An Deiner Stelle würde lieber nichts von FPGA-Konzept sagen, falls Du Dich bewerben solltest ;-) Layout in 2 Monaten? Wenn Du die ganze Zeit daran gearbeitet hast, dann sagt das schon eine Menge über die Firma aus. Die Produktion von 2 Monaten ist ja verständlich, aber Layout? Eure Kunden möchte ich gerne haben, die bereit sind soviel zu bezahlen :-o Kest
- Du wirst das Wort Layout genau 2 mal finden (Seite 2 und 36) Und das ist dann der Grund dafür, dass gestandene Ingenieure plötzlich aus allen Wolken fallen, weil ihr Gerät den EMV-Test nicht besteht und plötzlich "komische" Sachen passieren die keiner versteht. Seltsam, dass es beispielsweise in der Automobilindustrie ganze Forschungsabteilungen gibt (Mit Leuten die Doktortitel haben) die sich mit nichts anderem beschäftigen als EMV-gerechten Layouts und Kabelführung. Man Man Man...
Mayer schrieb: > Und das ist dann der Grund dafür, dass gestandene Ingenieure plötzlich > aus allen Wolken fallen, weil ihr Gerät den EMV-Test nicht besteht und > plötzlich "komische" Sachen passieren die keiner versteht. So ist es. Genau so ist es. Nicht nur das FPGA-Design, sondern auch das Layout in der Umgebung, Abblockkondensatoren, Startstrombedarf, all das wird komplett und regelmässig unterschätzt. > Seltsam, dass es beispielsweise in der Automobilindustrie ganze > Forschungsabteilungen gibt Sagen wir mal "Arbeitsgruppen" bestehend aus 3-5 Personen > (Mit Leuten die Doktortitel haben) Ausgerechnet auf die würde ich mich nicht verlassen. Die laufen den ganzen Tag nur durch die Gegend, scheuchen die anderen umher und lassen Robert Bosch einen guten Mann sein. Nichts, aber auch rein garnichts, von dem, was sie mit ihren tollen Automotive-SPICE Simulationen VHDL-AMS-Simulationen und MATLAB Simulation ausgerechnet haben, trifft nachher so ein, rein garnichts. Für jeden von den Heinis zwei Techniker eingestellt, die ordnetliche Messreihen machen, tät mehr Ergebnis bringen. > Man Man Man... http://de.wikipedia.org/wiki/MAN
Kest schrieb: > Wir sind jetzt reichlich OT hier :-/ Warum, passt doch prima zum Thema Lernen > Ich musste jetzt auch noch mal schmunzeln, wegen einem Jahr am FPGA > Design ;-) Es gibt aber Entwicklungspakete, bei denen es keinen Sinn macht, sie auch mehrere Personen aufzuteilen, weil sonst der Einarbeitungsaufwand für jeden Einzelnen zu gross wird. Wenn natürlich schon 2 dann wurschteln, ist ein Jahr verdammt viel. Was ist das für einen Riesen-App? > An Deiner Stelle würde lieber nichts von FPGA-Konzept sagen, > falls Du Dich bewerben solltest ;-) Halte ich auch für ein Eigentor. :-) > Layout in 2 Monaten? Wenn Du die ganze Zeit daran gearbeitet hast, dann > sagt das schon eine Menge über die Firma aus. Nun ja, wenn man Bauteile neu anlegen muss, Gehäuse noch vermessen und die 3D-Modelle machen muss, sind 2 Monate für ein grosses Design eher wenig.
Hallo Böser Kommunist, Hut ab vor Deinem Einsatz! (Videos ohne Musik und in Deutsch wären mir persönlich aber lieber ;-))
Irgendwie werde ich den Eindruck nicht los, dass viele hier FPGA-Design gleichsetzen mit High-Speed-Systemintegratrions-Gedöns.. und ein FGPA ohne DDR2, nem Arsch voll 4 GHz Serdes-Schnittstellen und was weiss ich was, gar nicht lebensfähig ist. Klar, bei solchen Designs klickt man ein paar IP-Cores zusammen, schreibt dazu ne handvoll Wrapper und man ist fertig. In diesen Fällen ist mit Sicherheit das Design des PCB auch angemessen komplex. Aber dass ein FPGA auch durchaus seine Daseinsberechtigung darin hat, nicht nur eine höhere Integrationsdichte und Flexibilität von "bekannten" Bausteinen herbeizuführen, sondern ein FPGA auch dazu genutzt werden kann, gänzliche neue Funktionen zu realisieren, für die es keine bekannten Lösungen gibt, scheint man hier zu vergessen. Daher finde ich es auch unangemessen, darüber zu lästern, wenn ein FPGA-Desing mal ein Jahr dauert. Wenn man ein Design von Grund auf aufsetzt, wo man nachher jedes Register mit Namen kennt, dann ist ein Jahr nicht viel. Wohlgemerkt, ich rede hier nicht nur vom eigentlichen Codieren, sondern natürlich von dem gesamten Entwurf. Beispielsweise gibt es für viele Industrielle Busprotokolle IP-Cores. Die hat irgendjemand mal entworfen und geschrieben. Ich glaube kaum, dass derjenige schneller war, als die Layouter, die dann die paar FPGA-Pins mit den PHYs und dem uC verdrahtet haben, um den Core zu Leben zu erwecken. Das Layout für einen kleinen FPGA mit ein paar LEDs und nem kleinen uC ist kein Hexenwerk und bedarf keiner HF-Spezialisten. Bei komplexen Systemen in denen auch ein FPGA mitspielen darf, sieht die Welt natürlich anders aus.
Schlumpf schrieb: > sondern ein FPGA auch dazu > genutzt werden kann, gänzliche neue Funktionen zu realisieren, für die > es keine bekannten Lösungen gibt An welche denkst Du dabei? Müsste man nicht exakt dann sehr viel tiefes Wissen haben?
Weltbester FPGA-Pongo schrieb im Beitrag #3307001: > An welche denkst Du dabei? Habe ich ja geschrieben... z.B. Ethernetbasierte Busprotokolle (Ethercat, Profinet IRT etc) So ein IP-Core wurde vermutlich nicht aus bestehenden IP-Cores zusammengeschustert, sondern von Grund auf neu beschrieben. Da gibt es sicher noch viele andere Beispiele. Weltbester FPGA-Pongo schrieb im Beitrag #3307001: > Müsste man nicht exakt dann sehr viel tiefes Wissen haben? Exakt. Genau das muss man dann haben. ABER man muss kein Tiefes Wissen über das PCB haben, sondern darüber, was im inneren eines FPGA vonstatten geht. Ich wollte lediglich zum Ausdruck bringen, dass es Designs gibt, wo das PCB um den FPGA herum deutlich mehr Hirnschmalz erfordert, als der PFGA selber. Es aber auf der anderen Seite sicher Designs gibt, wo das Board um den FPGA herum leicht zu beherrschen ist, aber die Funktionalität im FPGA sehr tiefes Verständnis der Materie erfordert. Einen Controller per Businterface oder Schnittstelle an ein FPGA zu hängen und vom FPGA ein MII an nen PHY zu Layouten ist vielleicht nicht auf einem Steckbrett möglich, aber dennoch auch kein Voodoo, der nur von wenigen Spezialisten beherrscht werden kann. Daher stört mich zum einen die Aussage, dass man ohne fundierte Kenntnisse im PCB-Layout sowieso gar nicht mit FGPA-Design anfangen braucht und die pauschalisierte Aussage, dass jemand, der für ein FPGA Desing ein Jahr benötigt, wohl ziemlich unfähig sein muss. Ich würde sogar den Spieß umdrehen wollen und sagen, dass jemand, der in vier Wochen einen 100kLUT-FPGA mit fertigen IP-Cores vollstopft, weniger Verständnis für die Materie PFGA benötigt, als jemand, der ein tricky 10 kLUT-Design mit einer leeren Architecture beginnt...
Schlumpf schrieb: > Daher stört mich zum einen die Aussage, dass man ohne fundierte > Kenntnisse im PCB-Layout sowieso gar nicht mit FGPA-Design anfangen > braucht Das wurde aber auch nicht behauptet sondern herausgestellt, dass diese Themen eine Rolle spielen und mehr Gewicht haben, als simples VHDL. Ob das alles in ein Tutorial muss (und in jedes) steht auf einem anderen Blatt. > und die pauschalisierte Aussage, dass jemand, der für ein FPGA > Desing ein Jahr benötigt, wohl ziemlich unfähig sein muss. Das wurde schon gar nicht so behauptet, sondern nur hinterfragt, ob man sich ausgerechnet damit bewerben sollte, weil eine so lange Projektzeit sehr unüblich ist und den Grund haben kann (nicht muss) dass der Entwickler sind verkalkuliert oder schlecht geplant hat. Oftmals allerdings ist es ja so, dass die Entwicklung von oben her schlecht geplant ist und er alles allein machen muss. > Ich würde sogar den Spieß umdrehen wollen und sagen, dass jemand, der in > vier Wochen einen 100kLUT-FPGA mit fertigen IP-Cores vollstopft, weniger > Verständnis für die Materie PFGA benötigt, als jemand, der ein tricky 10 > kLUT-Design mit einer leeren Architecture beginnt... Auch das ist interpretierbar. Wer in 4 Wochen ein Design zukriegt, ist definitiv ein Meister, auch wenn es noch so easy war. Wer aber ellenlange braucht, muss schon eine gute Begründung haben. Meiner Beobachtung zufolge ist der Hauptgrund für eine zu lange Bearbeitungszeit die Unterschätzung der Aufgabe durch den Entwickler oder seiner Führungskräfte, bzw ein falsches zu optimistisches Herangehen, sowie eine schlampige oder nicht vorhandene Doku. Irgendwann verliert jeder den Überblick und entwickelt ins Nirvana. Am Schlimmsten sind die undokumentierten Vorprojekte von ausgeschiedenen Kollegen: Auch wenn da 99% funktionieren, fängt man meistens wieder bei Null an, weil das Einlesen in den Code mindestens so lange dauert, wie das erstellen, wenn nicht länger. Der Grund dafür sind nichtstandardisierte Vorgehensweisen, Methoden, Dokumentationsnormen und allgemein die Tatsache, dass jeder macht, wie er will. Die Schlussfolgerung muss für jeden, der sich anschickt, anderen etwas im Bereich FPGA beibringen zu wollen, lauten, auf wesentliche Grundlagen hinzuweisen und die Erfordernisse und Fallstricke aufzuzeigen. Der Masterplan lautet: - Anforderungen sammeln - Konzept erstellen - Struktur definieren - Modularisierung vornehmen - Priorisierung tätigen - Zeitplan erstellen - Bedarfsabschätzung vornehmen - Projekt aufteilen Nur damit ist der Aufwand einschätzbar und das Designen (gerade längerer Projekte) steuerbar und nochvollziehbar und man kann jederzeit eine Einschätzung liefern, wie weit man ist. Das Ganze muss ferner in Einklang gebracht werden mit den internen Prozessen der Firma, den Anforderungen deren Kunden, bestehenden Normen und Zertifizierungen und den Rahmenbedingungen der Firma, also wie die Kosternstrukturen aussehen, ob investiert werden darf, ob es ein Alleinprojekt bleibt, welche Wiederverwendbarkeit hergestellt werden soll All das das mündet letztlich in die Frage, wie stark man modularisiert, simuliert, testet, was man an Simulations- und Testunterstützung in ein System einbaut, wer welches Knowhow an Physik, Analogtechnik und Mathematik braucht, um seinen Teil effektv zu packen. Und es bestimt, wieviel und wie früh dokumentiert wird und wie eng man sich an Normen (bib und Codingstyles) zu halten hat. Mal eben schnell ran ans FPGA und losgelegt und was reinprogrammiert führt aber ganz genau zu der falschen Vorstellung, dass das alles ganz einfach zu erledigen sei und ein Tutorial, dass diesen Eindruck erweckt, deutet irgendwo in die falsche Richtung. Studenten und Schüler, die so starten, gewöhnen sich falsche Methoden und Arbeitsweisen an, die ihnen hinterher nur wieder umständlich abtrainiert werden müssen, wenn es überhaupt geht.
Weltbester FPGA-Pongo schrieb im Beitrag #3307960: > Das wurde schon gar nicht so behauptet Nicht ganz.. es wurde als Grund für ein FPGA-Design >1 Jahr unterstellt, dass... Andreas F. schrieb: > Entweder taugt Dein FPGA-Konzept nichts und Du hast Dich mehrfach > verrannt und in die Ecke geputzt und musstes zu viel revidieren oder ihr > seid nicht teamfähig und arbeitet zu unproduktiv. Oder Du hattest von > Anfang an kein gut durchdachtes Bearbeitungskonzept, anhand dessen man > hätte den Aufwand abschätzen und entscheiden können, es auf 3 oder mehr > Personen aufzuteilen, um in akteptablen Zeiten fertig zu werden! > > Genau um solche ewigen Basteleien an Designs zu verhindern, beauftragen > zielführend arbeitende Firmen immer mal gerne externe Projektleiter wie > mich, um Bastelbübchen, die sich beim Programmieren verlustieren, die > Flausen auszutreiben und sie in der Spur zu halten. Wenn der Retter der versaubeutelten Projekte diejenigen, die für ein FPGA-Design > 1 Jahr benötigen, als Bastelbübchen bezeichnet, dann halte ich das doch schon für ziemlich eindeutig... Weltbester FPGA-Pongo schrieb im Beitrag #3307960: > Wer in 4 Wochen ein Design zukriegt, ist > definitiv ein Meister, auch wenn es noch so easy war. Ich mach dir in 4 Minuten einen 100k LUT-FPGA voll.. Zum Thema Projektlaufzeiten. Ein FPGA-Design erstellt man ja nicht des FPGA Willen, sondern aus der "Not" heraus, bestimmte Dinge in Hardware abbilden zu müssen, wofür ein Controller oder Prozessor zu schlapp ist. Oder, um eine höhere Integrationsdichte und/oder Flexibilität zu erlangen. Diese Anforderungen leiten sich aus den Anforderungen des Systems ab, in dem der FPGA ein kleines Rädchen ist. Bei kompletten Neuentwicklungen eines komplexen Systems (nicht nur eines Boards), kann man planen, so lange und viel man will, es ergeben sich IMMER während der Entwicklungsphase Änderungen an den Anforderungen. Entweder weil man festgestellt hat, dass gewisse Dinge nicht gehen, oder aus Kostengründen, oder weil man erkannt hat, dass man mit einer kleinen Anpassung einen deutlichen Wettbewerbsvorteil erlangen kann. Diese geänderten Anforderungen können sich natürlich dann auch auf das FPGA durchschlagen. Die Entwicklung eines gänzlich neuen Systems wird immer im gewissen Rahmen ein iterativer Prozess sein. Projekte, die man spezifiziert, daraus die Spezifikation für HW, SW, FPGA, PCB und Mechanik ableitet, dann jeder vor sich hinwerkelt und nach einer gewissen Zeit steckt man alles zusammen und es spielt fehlerfrei, existieren entweder in den Köpfen realitätsfremder Projektleiter, deren Kenntnisstand der Materie sich auf Power-Point-Präsentationen beschränkt, oder die Prjekte bestehen zu 90% aus bereits bekannten Methoden, Komponenten etc... Innovative Neuentwicklungen ganzer Produktlinien sind nur sehr grob planbar. In unserer Firma arbeiten in der Regel die Teams an einer kompletten Neuentwicklung mehrere Jahre. Und bei unseren Mitbewerben sieht das auch nicht anders aus. Aber da wird eben ein Unterschied sein, zu einem Ingenieurbüro, welches für einen speziellen Kunden eine Auftragsarbeit macht. Vergleich es doch mal mit dem Smartphone.. Ich glaube nicht, dass das erste IPhone von Null zur Serienreife in nem halben Jahr entwickelt wurde. Die Nachfolgenden Smartphones anderer Hersteller waren dann ruckzuck auf dem Markt. Man wusste ja dann im Prinzip, wie es geht und auf was es ankommt. Wir kommen aber vom eigentlichen Thema ab. Der TO hat ein Tutorial erstellt, um dem interssierten Hobby-Bastler einen Einstieg in die FPGA-Welt zu ermöglichen und wollte wissen, ob das, was er da ins Netz gestellt hat, gut ist. Ob der Hobby-Elektroniker einer kleinen FPGA-Bastelei erstmal ein komplettes Projektmanagement überstülpen muss, ist fraglich ;-) Und jemand, der professionell FPGAs designen wird, wird wohl kaum sein Wissen aus irgendwelchen Youtube-Videos ziehen. Soviel Geld sollte dann schon vorhanden sein, den Kollegen auf ne vernünftige Schulung zu schicken..
Schlumpf schrieb: > Vergleich es doch mal mit dem Smartphone.. Ich glaube nicht, dass das > erste IPhone von Null zur Serienreife in nem halben Jahr entwickelt > wurde. Die entwickeln heute nach an ihrem ersten serienreifen Gerät. > Soviel Geld sollte dann schon vorhanden sein, den Kollegen auf ne > vernünftige Schulung zu schicken.. Na ob es da mit einer Schulung getan ist? > Irgendwie werde ich den Eindruck nicht los, dass viele hier FPGA-Design > gleichsetzen mit High-Speed-Systemintegratrions-Gedöns Den Eindruck werde ich auch nicht los und zwar deshalb, weil die Haltung richtig ist. FPGAs sind genau dafür gemacht: Für high-speed-systeme. Fürs andere "gedöhns" nimmt man einen AVR tiny. Das muss natürlich nicht bedeuten, dass der Anfänger nicht mit einfachen Dingen beginnt und dazu auch solche vorgefertige Anleitungen und Platinen nutzt. Man sollte nur nicht den Eindruck erwecken, dass die FPGA-Welt so einfach wäre.
Klaus L. schrieb: > Die entwickeln heute nach an ihrem ersten serienreifen Gerät. grins > Na ob es da mit einer Schulung getan ist? Mit Sicherheit nicht nur. Aber als Einstieg vermutlich geeigneter, als ein Youtube-Tutorial (Das wollte ich damit sagen) > Den Eindruck werde ich auch nicht los und zwar deshalb, weil die Haltung > richtig ist. FPGAs sind genau dafür gemacht: Für high-speed-systeme. > Fürs andere "gedöhns" nimmt man einen AVR tiny. Soso... Dann muss ich daraus schlussfolgern, dass alles > 10-20 MHz für dich High-Speed ist. Ich für meinen Teil würde die Grenze da deutlich höher ansetzen. Außerdem hast du meine Aussage aus dem Kontext gelöst, da ich nie behauptet habe, dass FPGAs dafür nicht gemacht sind, sondern ich habe gesagt, dass sie nicht ausschließlich dafür gemacht sind. Versuche doch mal mit deinem AVR tiny einen Manchester Datenstrom mit 50 MBit/s zu erzeugen. Ich denke, da wirst du dich schwer tun. Aber mit High-Speed hat das noch lange nichts zu tun. > Man sollte nur nicht den Eindruck erwecken, dass die > FPGA-Welt so einfach wäre. Hier stimme ich dir voll zu. Nichts anderes ist der Inhalt meiner Ausführungen. Aber ich wollte zum Ausdruck bringen, dass es nicht notwendig ist, sich mit komplexen PCBs zu befassen, auf denen dann echte High-Speed-Designs laufen, um ein Verständnis von FPGAs zu erlangen. Im Gegenteil: Wenn ein Anfänger von NULL an ein einfaches Design, wie z.B. ein SPI o.Ä. beschreibt und dabei wirklich "sieht", welche Register und Logik er hier wie verschaltet hat, dann hat er meiner Meinung nach mehr über FPGAs gelernt, als jemand, komplexere Systeme aus irgendwelchen fertigen IP-Cores zusammengeklickt hat.
Also, es bleibt dabei: Ein paar LEDs blinken zu lassen, ist keine echte Anwendung und es zeigt auch nicht, warum man sowas ausgerechnet in einem FPGA machen sollte. Ich geb mal ein Beispiel, was nicht wirklich zu kompliziert ist, aber dennoch in die Thematik einführen könnte: ein FPGA nebst einem RAM als eigenständiger Grafikcontroller für TFT-Displays, anzuschließen an den (hoffentlich) herausgeführten Bus eines ARM-Controllers (sind ja z.Z. sehr in Mode). Sowas hätte einen echten Nutzwert - im Vergleich zu einr blinkenden LED. Ein fertiges Demoboard herzunehmen, zeigt auch nicht auf, wie man für eine echte Anwendung ein echtes FPGA auf eine echte Leiterplatte bekommt und mit den dafür benötigten Konfig-Daten versieht. Und schlußendlich ist ein ausdruckbares PDF-Dokument, das man sich auf den Basteltisch legen kann und dort nachschlagen kann, wirkungsvoller als eine Video-Vorführung. W.S.
@ W.S. (Gast) >Ein paar LEDs blinken zu lassen, ist keine echte Anwendung und es zeigt >auch nicht, warum man sowas ausgerechnet in einem FPGA machen sollte. Du willst es nicht verstehen. Auch die längste Reise beginnt mit dem ersten Schritt. >Ein fertiges Demoboard herzunehmen, zeigt auch nicht auf, wie man für >eine echte Anwendung ein echtes FPGA auf eine echte Leiterplatte bekommt >und mit den dafür benötigten Konfig-Daten versieht. Du brichst es genauso übers Knie wie der der Herr engineer. >Und schlußendlich ist ein ausdruckbares PDF-Dokument, das man sich auf >den Basteltisch legen kann und dort nachschlagen kann, wirkungsvoller >als eine Video-Vorführung. Diesen Kritikpunkt hatten wir bereits mehrfach bestätigt, der war schon lange nicht mehr strittig.
..... Ein paar LED blinken zu lassen, sowie die UART Kommunikation herzustellen ist natürlich keine echte Herausforderung für FPGA. Das könnte man auch mit Attiny machen. Aber irgendwie muss man doch die FPGA "Programmierung" lernen, und man lernt natürlich an solchen simplen Beispielen. Genau dafür gibt es für jeden µC/FPGA ein fertiges Dev. Board. Ich finde solche Dev.Boards sind besser für den Einstieg als ein nacktes Breadboard.Außerdem würde ich gerne sehen, wie man ein FPGA in BGA-Gehäuse auf ein Breadboard kriegt;) Außerdem zeige ich wie man FUNCTIONS, PROCEDURES, COMPONENTS etc verwendet. Oder meinst du,ein Einsteiger soll sich sofort mit DDRAM und FFT auseinandersetzen? Das Videoformat hat deutlich mehr Vorteile als PDF: Man sieht jeden Schritt. Oft sind es einfache, selbstverständliche Sachen, an denen ein Neuling stecken bleibt...und das gilt für jeden Fach. Außerdem wie soll ich bitte meine Tutorials als PDF verbreiten? Irgendwo hochladen? Und wer findet sie dann? Bei Videos auf Youtube ist es anders, dort werden solche Sachen regelmäßig aus aller Welt gesucht, und gefunden;)
Böser Kommunist schrieb: > Außerdem wie soll ich bitte meine Tutorials als PDF verbreiten? > Irgendwo hochladen? Und wer findet sie dann? Na, das ist aber jetzt kein Argument. Auf Youtube findest Du auch nichts, es sei denn der Ersteller macht in einem Forum, wie diesem, per link darauf aufmerksam. Genau so liessen sich auch PFs verbreiten. > Projekte, die man spezifiziert, daraus die Spezifikation für HW, SW, > FPGA, PCB und Mechanik ableitet, dann jeder vor sich hinwerkelt und > nach einer gewissen Zeit steckt man alles zusammen und es spielt > fehlerfrei, existieren entweder in den Köpfen realitätsfremder > Projektleiter Darum geht es nicht. Die Tatsache, dass Anforderungen ändern, heisst nicht, dass man auf Planung verzichten kann sondern im Gegenteil, dass man eine um so bessere braucht um jederzeit zu wissen, wohin die Reise geht. Nur wenn alle auf ein Ziel zuarbeiten, wird es auch von allen erreicht und dazu muss es genau bekannt sein. Wie will man denn bitte Änderungen einfliessen lassen, wenn man nicht weiss, wie das Projekt strukturiert ist, wo man steht und welchen Aufwand die Änderung erzeugt. Änderungen sind ja auch oft mögliche Einsparungen an Zeit und Verkürzungen, weil z.B. ein anderer Chip herauskommt. Ohne eine genaue Struktur und Planung der Schaltung hat man nur Code. Deshalb laufen die Projekte ja so chaotisch. Sein müsste das nicht unbedingt. Man kann Änderungen auch gezielt ins System eintreiben und kontrolliert berücksichtigen.
Falk Brunner schrieb: > Auch die längste Reise beginnt mit dem ersten Schritt. Aber möglichst mit einem richtigen und durchdachten. Ins fertige Evalboard reinzuhüpfen, wo alles vorgegeben ist und funktioniert und drei LEDs blinken zu lassen, ist genauso, wie aus dem Heli im Urwald abzuspringen und einen Schmetterling aus der Falle zu holen und dann von sich zu denken, man sei der grosse Urwaldbiologe. Beim Lernen geht es ja auch um das Einordnen des Wissens in einen grösseren Kontext. Ich kann die Kritik von W.S. schon nachvollziehen.
FPGA-Progger schrieb im Beitrag #3312878: > Na, das ist aber jetzt kein Argument. Auf Youtube findest Du auch > nichts, es sei denn der Ersteller macht in einem Forum, wie diesem, per > link darauf aufmerksam. Genau so liessen sich auch PFs verbreiten. Wie nichts? Einfach nach "FPGA UART" in Youtube suchen=> tada, mein Tutorial auf Platz 3. oder einfach "FPGA tutorial"=> alle meine Videos auf der Seite 1 und 2:) Sowas findet man sehr leicht. >...und >drei LEDs blinken zu lassen... Auf die Idee, dass man nach den blinkenden LED einen komplizierteren Projekt starten kann bist du aber nicht gekommen?
> FPGA-Progger schrieb im Beitrag #3312878: >> Na, das ist aber jetzt kein Argument. Auf Youtube findest Du auch >> nichts, es sei denn der Ersteller macht in einem Forum, wie diesem, per >> link darauf aufmerksam. Genau so liessen sich auch PFs verbreiten. > > Wie nichts? > > Einfach nach "FPGA UART" in Youtube suchen=> tada, mein Tutorial auf > Platz 3. Dazu muss man erst mal wissen, dass überhaupt was da ist.:-) In google geht das auch (und der findet auch jedes PDF im Netz)
Böser Kommunist schrieb: > Ein paar LED blinken zu lassen, sowie die UART Kommunikation > herzustellen ist natürlich keine echte Herausforderung für FPGA. Das > könnte man auch mit Attiny machen. Aber irgendwie muss man doch die > FPGA "Programmierung" lernen, und man lernt natürlich an solchen simplen > Beispielen. Nein. Man lernt eben nicht an Baby-Beispielen, auch nicht an Kindergarten-Beispielen - sondern nur dann, wenn es eine angemessen gehaltvolle Aufgabe gibt. Was bleibt, ist was ganz untechnisches, nämlich das Streben nach Selbstdarstellung - und das Üben selbiger. Je nachdem, was man sich für seinen weiteren Lebensweg so vornimmt, ist sowas tatsächlich nicht von der Hand zu weisen - aber bitte nicht auf Kosten meiner Nerven. Du verstehst sicherlich. W.S.
> Nein. > Man lernt eben nicht an Baby-Beispielen Ausnahmslos jedes Tutorial fängt aber so an. Das liegt ganz einfach in der Natur der Sache: "Jede Wanderung beginnt mit einem ersten Schritt" Zudem lassen sich große Projekte in viele kleine Elemente unterteilen, die für sich genommen leicht verstehbar sind. Und am Anfang muss man eben die Elemente erstmal kennenlernen. Prinzipien lassen sich schön an Hand von einfachen Beispielen verdeutlichen. Aber - und hier gebe ich dir Recht - irgendwann braucht man dann ein richtiges Projekt, welches einen herausvordert und erst dann geht die Sache auch in Fleisch und Blut über.
W.S. schrieb: > Man lernt eben nicht an Baby-Beispielen, auch nicht an > Kindergarten-Beispielen - sondern nur dann, wenn es eine angemessen > gehaltvolle Aufgabe gibt. Ich wette du hast es seinerzeit "richtig" gelernt, und deswegen nimmst du andere Lernwege nicht ernst. Deswegen solche Sprüche wie Kindergarten, baby etc... Du bist genau so wie die Assembler Fanatiker, die denker auch :"Als ich jung war, hab eich alles auf dem Breadboard gemacht, und in Assembler programmiert. Alle diese fertige Dev.Kits und C-Programmierung ist für Kinder..." Ich denke es macht keinen Sinn diese Diskussion weiterzuführen, denn jeder bleibt immer bei eigener Meinung.
W.S. schrieb: > Böser Kommunist schrieb: >> Ein paar LED blinken zu lassen, ... >> und man lernt natürlich an solchen simplen Beispielen. > Nein. > Man lernt eben nicht an Baby-Beispielen, auch nicht an > Kindergarten-Beispielen - Ganz am Anfang und ohne Tutorial ist schon eine dimmbare LED eine große Aufgabe. Und bei deren alleiniger Bewältigung lernt man ziemlich viel. Nur muss heute keiner mehr sowas alleine "lernen", weil es jede Menge vorgekauter Beispiele gibt. Ich selber versuche irgendwas erst mal selber, und schaue dann mal nach, wie andere das gemacht haben. Dann fallen mir Abkürzungen und Umwege recht deutlich auf, und ich lerne daraus. Viele meinen aber offenbar, wenn sie eine LED nach einer Vorlage oder einem Video zum Blinken gebracht haben, sie hätten dabei was gelernt. Und das glaube ich nicht, denn sie haben nur gesehen, dass es geht, was andere gemacht haben. Zum Lernen gehört mehr: da gehört dazu, dass man selber mal eine halbe (oder auch eine ganze) Nacht nach einem "kleinen" Fehler sucht und ihn nicht findet! Da gehört auch dazu, dass man mal was hinkritzelt und viola: es läuft... > sondern nur dann, wenn es eine angemessen gehaltvolle Aufgabe gibt. Ich vermute, dass viele EVAL-Kits und Projekte in der Ecke liegen, weil sich der geneigte Käufer damals(tm) zuviel vorgenommen hatte, und wegen der nötigen großen Schritte schon über die einfachsten Dinge gestolpert ist...
ehemaliger Ingenieur in der Autobranche schrieb: >> (Mit Leuten die Doktortitel haben) > Ausgerechnet auf die würde ich mich nicht verlassen. Die laufen den > ganzen Tag nur durch die Gegend, scheuchen die anderen umher und lassen > Robert Bosch einen guten Mann sein. Bosch ist ein gutes Stichwort. Ich bin eines der Opfer, das in Reutlingen sein Dasein fristen muss und ausser der Firma mit den grossen B gibt es hier absolut nichts. Der Zustrom ist entsprechend und alle prügeln sich um die wenigen guten Stellen. In der Vergangenheit wurden die Budgets ziemlich zusammengestrichen und Figuren eingestellt, die - sagen wir mal - "suboptimale" Vorraussetzungen und Vorbildung für den Job hatten. Vor allem im Bereich digitaler Elektronik und FPGA haben wir einige, die ihr Wissen ganz offensichtlich aus irgendwelchen Internettutorials haben und sich die Geschichte durchs Basteln selber beigebracht haben. Ich will die Tutorials nicht verteufeln und es steckt ja sicher einge gute Absicht dahinter, aber am Ende kommt man um das richtige Lernen nicht herum. Wenn ich vergleiche, was man an der FH schon an Wissen beigebracht bekommt, ist das durch noch so viel Selbstbildung nicht auszugleichen. Ich glaube, FPGA ist eines der Themen, wo längere Zeit ein grösserer Mangel an Bearbeitern herrschte und wie in der Software vor 20 Jahren, jeder, eine Tastatur bedienen konnte, genommen wurde und viele da so reingerutscht sind.
ach was ich eigentlich schreiben wollte: Die Quintessenz aus der Betrachtung ist aus meiner Sicht, dass durch die Flut an Tutorials, noch mehr sich berufen fühlen, da einzusteigen und am Ende auf der Strasse liegen, wie die C-Programmierer, die den Absprung verpasst haben. >Nur muss heute keiner mehr sowas alleine "lernen", weil es jede > Menge vorgekauter Beispiele gibt. Genau und ich meine sogar, dass es schwieriger ist, das Richtige herauszusuchen, womit man lernt. Am Ende ist das Tutorial immer so aufgebaut wie der Verfasser denkt und nicht, wie die Mehrheit der Schüler. Lehren und Lehrmaterial verfassen ist nämlich auch etwas, was man lernen muss und vor allem Erfahrung ist da von Nöten. Ob da eine Anleitung von Studenten für Studenten sinnig ist, sei dahingestellt.
Lothar Miller schrieb: > Nur muss > heute keiner mehr sowas alleine "lernen", weil es jede Menge vorgekauter > Beispiele gibt. Ja. eben. Ach Lothar, sag mal selber, was dabei herauskommt, wenn neue Generationen von Entwicklern ihre fachliche Entwicklung derart absolvieren. Diese Frage hatte ich dem TO schon weiter oben gestellt, ohne Antwort. Stattdessen muß ich solche Worte wie "mal Lust auf FPGA's bekommen" usw. lesen. Obendrein wird man mit unsachlichen Beschimpfungen bedacht, siehe ein bissel weiter oben. OK, der TO ist noch ein Jungspund, der nicht gern zuhören will, sei's drum. Das wirklich große Problem ist hier wie auch in anderen Fällen (von denen dieses Forum voll ist), daß die Leute vehement nach eben diesen fertigen Lösungen schreien und eben nicht mehr das selbständige Denken erlernen. Das hat man nicht von Geburt an, sowas muß man wirklich sich erarbeiten, sonst hat man es eben nicht. Das ist der Unterschied zwischen einem, der ein Problem analysieren kann und daraus eine Lösung erdenken kann und einem anderen, der ein Problem nur mit bereits geübten Beispielen vergleichen kann und wenn eines paßt, die damalige (vorgefertigte) Lösung hervorkramen kann. In vielen Fällen werden beide Leute zu einem Ziel kommen, aber der zweite ist letztendlich eben nur angelernt, quasi dressiert, er hat nicht den Überblick. Aber das Analysieren von Problemen und das Erdenken von Lösungen muß man lernen und das ist mühsam - und wird ewig mühsam bleiben. Da führt kein Weg drumherum und wer diesen Weg nicht gehen will, muß entweder sich anderen Themen zuwenden oder als Scharlatan sein Leben fristen. OK, so mancher Scharlatan hat es zu Reichtum gebracht, aber das wird langsam OT. Man muß auch bedenken - um wieder zum Thema des Threads zurückzukommen - daß VHDL und programmierbare Logik für viele eben nicht zentraler Teil ihres Berufslebens ist, sondern nur ein kleinerer Teilaspekt, und daß genau deswegen eher die zu bewältigende Entwicklungsaufgabe im Vordergrund steht als das Erlernen einer speziellen Kenntnis wie z.B. das Bedienen eines speziellen Programms, das Erlernen einer speziellen Sprache usw. Da sind Prioritäten zu setzen, aber eines bleibt: das analytische Denken, das in manchen Fällen eben auch zu ganz anderen Lösungen führt. (kleines Beispiel: ich hatte ein blödes Problem auch nicht in VHDL lösen können, hab also VHDL bleiben lassen und das Problem in Verilog mit nem Fünfzeiler erledigt. In manchen Fällen geht das, in anderen nicht. Wäre auch das nicht gegangen, hätte ich es mit Schematics gemacht, das geht immer, sofern man eben was von Schaltungstechnik versteht.) Lothar Miller schrieb: > Ganz am Anfang und ohne Tutorial... Ja, was ist im konkreten Falle der Anfang? Das führt auf die Frage nach der Vorbildung des jeweiligen Akolythen. Sind mathematische Kenntnisse vorhanden? Und Schaltungstechnik? sowohl theoretisch als auch praktisch? Kann derjenige das Hardwaremanual des ins Auge gefaßten Chips auch verstehend lesen oder fehlen da Vorkenntnisse? Grundsätzlich gilt, daß ein jedes Tutorial eben nicht das Erlernen des selbständigen Denkens erbringen kann. Nürnberger Trichter? nee, ist nicht. Und gerade die Jugendjahre sind es, wo man es erlernen kann, später wird es schwieriger. Alles, was in jungen Jahren der angeborenen Faulheit Beihilfe leistet, ist deswegen schlecht auf lange Sicht - wenngleich auf kurze Sicht das ganz anders aussieht. so, genug für heut abend W.S.
Du hast so Recht, W.S, wie man nur haben kann, und ich pflichte Dir auch absolut bei. Ich erlaube mir nur, zu einer geringfügig anderen Schlussfolgerung zu kommen: Während Du Dein Augenmerk auf das Wohl der künftigen FPGA-Progmmierer legst und zu Recht anmerkst, wie wichtig es ist, die digitale Elektronik drum herum komplett in ihrer Ganzheit zu verstehen, denke ich auch noch an die jetzigen FPGA-Programmierer und die wenigen, die es richtig können: Je mehr Menschen es gibt, die FPGA-Entwicklung für einfach halten, desto mehr gibt es, die das machen und desto mehr Projekte werden von solchen von wenig Knowhow gemacht und desto mehr gibt es anschliessend zu reparieren. Man glaubt gar nicht, wieviele verschlumperte FPGA-Designs es da draussen in der Welt gibt, die in irgendeiner Form gegen die Wand gelaufen sind und wo irgendwas nicht richtig geht und ein Feuerwehrmann benötigt wird. Da kommen dann die echten Experten zum Zuge!
anonymer Andi schrieb: > Je mehr Menschen es gibt, die FPGA-Entwicklung für einfach halten, desto > mehr gibt es, die das machen und desto mehr Projekte werden von solchen > von wenig Knowhow gemacht und desto mehr gibt es anschliessend zu > reparieren. Man glaubt gar nicht, wieviele verschlumperte FPGA-Designs > es da draussen in der Welt gibt, die in irgendeiner Form gegen die Wand > gelaufen sind und wo irgendwas nicht richtig geht und ein Feuerwehrmann > benötigt wird. Dazu würden mich aber jetzt mal Zahlen interessieren! Ich habe einen Thread aufgemacht: Beitrag "Wieviele FPGA-Designs sind im Markt unterwegs?" > Da kommen dann die echten Experten zum Zuge! Die kommen woher? Aus der o.g. Abschätzung werden nur etwa 3000-6000 Personen insgesamt benötigt. Ist die Tendenz steigend? Wie stark? ich schätze jetzt einfach mal 500 alte Entwickler raus, 500 die was anders machen, +500 neue hinzu, macht 1500 FPGA-Neulinge im Jahr. Produzieren die Hochschulen genug?
anonymer Andi schrieb: > Da kommen dann die echten Experten zum Zuge! Naja, ist wohl nicht die Arbeit, die von einem echten Experten gerne gemacht wird: Reverse-Engineering und Pflege von FPGA bei denen die Original-Entwickler entweder nicht mehr da sind oder nicht mehr durchblicken.
> 1500 FPGA-Neulinge im Jahr (benötigt) > Produzieren die Hochschulen genug? Heute kann jeder zweite Abgänger VHDL. Die Frage ist nur, wieviel Firmen es gibt, die Anfängern eine Chance geben, sich damit zu befassen und im Laufe der Zeit das Knowhow aufzubauen, dass sie zum Experten brauchen. Der Ingenieur wird ja nicht durch das Diplom zum guten Entwickler. Wenn immer mehr Firmen auf fertige Entwickler setzen, gibt es keinen mehr, der ausbildet
> Komplexität von FPGA-Entwicklung wird unterschätzt Dazu passt vielleicht die folgende interessante Erkenntnis: Meine Firma führt regelmässig Bewertungen der Projektplanung in Form von Projektreviews durch bei denen geprüft wird, inwieweit die vor dem Projekt geplanten Kosten, Zeiten und Aufwände mit den sich nachher ergebenden Tatsachen übereinstimmen. Insbesondere werden die realen Anteile für Planung, Entwicklung und Test untersucht, um herauszubekommen, ob Projekte mehr Planungsanteil, Konzeptphasen oder Vorstudien erfordert hätten. Diese Vorgehen ist jeder Firma nur zu empfehlen, denn es liefert erstaunliche Ergebnisse: Je grösser die Projekte werden, desto mehr Planungsaufwand hätte geleistet werden müssen, was im Grunde jedem klar ist, aber von den Meisten nicht umgesetzt wird. Das Resultat sind unterplante Projekte mit wachsender Länge, die gerade zum Ende hin mehr und mehr aus dem Ruder laufen. Insbesondere bei der Softwareentwicklung laufen die Projekte weit dem Terminplan hinterher und produzieren bei Unterplanung, Zeitdruck und Oberflächlichkeit während der Planungsphase und der Entwicklung nachher in der Integrationsphase und dem Test überproportionalen Mehraufwand. Firmwareprojekte, die auf DSPs und FPGAs laufen stechen dabei besonders hervor: Hier ergeben sich z.T. abenteuerliche Diskrepanzen zwischen den Zeitabschätzungen für die gedachten Fertigstellungen und der späteren Realität. Projekte, die im Prinzip zu 90% fertig waren, brauchten für das Finden des letzten bugs oftmals nochmal so lange wie für die Realisation der ersten 90 benötigt wurde. Nicht selten kommen dann Projektlaufzeiten zustande, die mehr nicht den üblichen Faktor 2 aufweisen, sondern gerne auch 3 oder 4 mal länger dauerten, als zunächst geplant. Die highlights bei der Überschreitung der Projektdauer sind indes mehr und mehr die FPGA-Entwicklungen, weil dort nicht einfach nur Fehler gefunden werden müssen, sondern in nicht wenigen Fällen der Fertigstellungsgrad von 99% auf 50% herunterpurzelt, wenn sich nämlich am Projektende herausstellt, dass aufgrund von Resourcenmangel oder eines Planungsfehlers die Funktionen geändert-, weite Teile des Designs überarbeitet- oder gänzlich andere Bausteine eingesetzt werden müssen. Ein grosses Problem ist hier die sinkende Übertragbarkeit der VHDL-Designs: Da diese immer Chip-spezifischer werden, muss bei einer Migration ein immer grösserer Teil weggeworfen werden. Eine sehr wichtige Erkenntnis, die aus solchen Untersuchungen gezogen werden kann, ist, dass der jeweilige Entwickler der allerletzte Ansprechpartner sein sollte, den man nach der ungefähren Fertigstellungszeit fragt, denn diese können das, warum auch immer, am aller Schlechtesten einschätzen. Wenn, dann immer den ominösen Faktor 2 draufschlagen - bei Software und FPGA-Entwicklungen 3..4 :-) In einem Fall hat einer der Projektleiter einst den Schluss gezogen, dass am Besten komplett auf FPGAs verzichtet werden sollte. Der Kosten wegen. grins
@Tommiw: Finde ich sehr interessant, was Du da schreibst. Wäre es möglich, dass Du solche Untersuchungsergebinsse in irgendeiner Form zur Verfügung stellst?
T. W. schrieb: > Projekte, die im Prinzip zu 90% fertig waren, brauchten für das Finden > des letzten bugs oftmals nochmal so lange wie für die Realisation der > ersten 90 benötigt wurde. Die Betriebswirtsschaftler nehmen ein wenig andere Zahlen und nennen das Ganze dann "Pareto-Prinzip": http://www.beyourbest.de/erfolgsgrundsaetze/das-pareto-prinzip/ Leider vergessen sie dann dabei immer, dass das ebenfalls nur eine grobe Faustformel und keineswegs eine Naturkonstante ist...
Ich zitiere daraus: > Du wirst feststellen, dass es wider Erwarten gar nicht so viele Dinge > sind, die absolut kritisch für das Projekt sind. Eine Vielzahl kleinerer > Aktivitäten kannst Du streichen, ohne dass das Gesamtprojekt gefährdet > ist. Vielleicht hättest Du es in 30 Tagen noch besser hinbekommen. Aber > überleg Dir mal, wie viel Zeit Du gerade dadurch gespart hast! Wenn Du > für ein Jahr 12 Projekte á 30 Tage eingeplant hast und nach diesem > System vorgehst, bist Du Mitte März komplett fertig. Was wunderbar unter den Tisch gerwischt wird: Manchmal braucht man die reslichen 20%, die dann 80% der Zeit (oder wieviel auch immer) kosten, eben doch auch noch... ...vielleicht etwas altmodisch und erst noch ein Kinderbuch, aber für den Autor hätte ich einen Literaturtipp: Momo von Michael Ende
:
Bearbeitet durch User
anonymer Andi schrieb: > Vor allem im Bereich digitaler Elektronik und FPGA haben wir > einige, die ihr Wissen ganz offensichtlich aus irgendwelchen > Internettutorials haben und sich die Geschichte durchs Basteln selber > beigebracht haben. Wie würde denn Deiner Meinung nach eine gute Einarbeitung in FPGA-Technologie stattfinden (sollen)? An den FHs gibt es da doch nicht viel ausser ein paar Praktika und an den Unis erst Recht nicht. Tommi. W. schrieb: > Die highlights bei der Überschreitung der Projektdauer sind indes mehr > und mehr die FPGA-Entwicklungen, weil dort nicht einfach nur Fehler > gefunden werden müssen, sondern in nicht wenigen Fällen der > Fertigstellungsgrad von 99% auf 50% herunterpurzelt, wenn sich nämlich > am Projektende herausstellt, dass aufgrund von Resourcenmangel oder > eines Planungsfehlers die Funktionen geändert-, weite Teile des Designs > überarbeitet- oder gänzlich andere Bausteine eingesetzt werden müssen. Das unterschreibe ich, zumindest in vielen mit bekannten Fällen. Da kommt dann am Ende doch wieder raus, dass VHDL-Endwickler nicht gleich Elektronikentwickler ist.
T. W. schrieb: >> Komplexität von FPGA-Entwicklung wird unterschätzt > Ein grosses Problem ist hier die sinkende Übertragbarkeit der > VHDL-Designs: Da diese immer Chip-spezifischer werden, muss bei einer > Migration ein immer grösserer Teil weggeworfen werden. Das muss nicht sein. Hängt aber eben von der Philosophie des Hauses ab. Mit jedem Projekt wächst der Pool an Komponenten. Hier muss man die Komponenten so entwerfen, dass man sie auch in spätere Projekte verwenden kann. Wenn eben der VHDL-Code aus einem Highendtools als Spagetticode herausfällt, dann ist das nicht wartbar und wiederverwendbar. Ich fahre auch eine andere Linie, ein Softcore-CPU in den FPGA zum programmieren mit C. Dann kann der Softwareprogrammieren bestehenden C-Code mit nutzen und es muss ein geringerer Teil in VHDL geschrieben werden. Warum Soft-CPU? Genau es ist herstellerunabhängig. Ist auch preislich interessant, da FPGAs mit HardCPU erst > 100Euro beginnen.
Jürgen Schuhmacher schrieb: >>Außerdem glaube ich an Karma > Ich auch. Da ist aber kein FPGA drin sondern ein DSP: > http://www.korg.de/produkte/fruehere-modelle/karma-produktinfo/karma-produktinfo-2.html Ich glaube unser guter Kommunist meinte das ethisch-esotherische "Karma" :-) Böser Kommunist schrieb: > Du bist genau so wie die Assembler Fanatiker, die denker auch :"Als ich > jung war, hab eich alles auf dem Breadboard gemacht, und in Assembler > programmiert. Alle diese fertige Dev.Kits und C-Programmierung ist für > Kinder..." Früher gab es auch fertige Evaluations-Elektroniken zu kaufen. Ich habe selber mit solchen Systemen begonnen. Zunächst auf einer 8085-Plattform und dann einer C166-Plattform, viel später mit HC08 und seinen Nachfolgern. Das alles ist nicht "old school" oder gar veraltet sondern sehr aktuell: Sieh Dir mal heutige DSP-Systemsoftware an: Nicht wenig dvon ist gutes altes Assembler. Zu den vielen Beiträgen kann ich nur noch eines sagen: Hier prallen wohl mehrere Welten aufeinander ud sicher auch Generationen. Den Neulingen täte diesbezüglich ein Blick nach hinten ganz gut. Den Blick nach vorn, wiederum den alten Hasen, wobei die den in der Regel haben.
René D. schrieb: > Hängt aber eben von der Philosophie des Hauses ab und > Ich fahre auch eine andere Linie Sowas ärgert mich. Erstens bauen die Hersteller nicht ohne Grund spezielle Features in ihre Chips ein, sondern wollen damit diese Chips fit machen für Aufgaben, die ohne dieses den besagten Aufgaben nicht gewachsen wären. Damit sind de facto Projekte immer mehr chipspezifisch und zunehmend schlechter portierbar. Wenn du sagst, daß das von der Philosophie abhängt, dann ignorierst du die Ökonomie. Zu deiner anderen Linie, in ein FPGA auch noch einen µC einzubauen, muß man mal ganz deutlich sagen: Nichts ist teurerer als dieses. Es ist in so ziemlich JEDEM Falle ökonomischer, einen dedizierten µC einzusetzen und dafür ein entsprechend kleineres FPGA zu nehmen. Vom Environment (Softwarepool, Tools..) mal ganz abgesehen. Jaja, ich erinnere mich noch ganz gut, daß die Vertreter von NIOS mir selbigen schmackhaft machen wollten, ist ja auch ne wirklich nette Spielerei, aber deutlich TEUER - mir ZU TEUER. Sowas leisten sich nur Leute, die nicht auf's Geld achten müssen - womit wir bei außertechnischen Kriterien wären. W.S.
W.S. schrieb: > womit wir bei außertechnischen Kriterien wären. Platz ist hoffentlich kein solches, denn dieses ist der meistvorliegende Grund für die Nutzung eines Prozessors im FPGA. Bandbreite ist hoffentlich auch kein solches "nichttechnisches Kriterium", denn zwischen den beiden Power-PCs im Virtex lassen sich ganz schön fette Bandbreiten etablieren, bei beachtlich geringer EMI. Beim NIOS und anderen SoftCores gebe ich Dir aber Recht. Das macht eigentlich nur Sinn, wenn sehr wenig CPU-App-Anteil vorliegt und das FPGA wirklich kleiner nicht auszulegen ist und noch Fläche hat. Ein dickes Linux auf dickem NIOS mit fetter APP im vergleichsweise kleinen FPGA habe ich schon mehrfach gesehen - teilweise sogar als main app! - aber so richtig nachvollziehen konnte ich es nicht.
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.