Wo und wie wird das eigentlich gelehrt? Reicht es den FHs und Unis, den Studies beizubringen, wie die Sprache funktioniert und wie man die Konstrukte anwendet, oder wird da mehr getan? Meine Frage nämlich lautet: Wie konstruiert man sinnvolle Schaltungen??? Beides sind 2 unterschiedliche Dinge und das eine impliziert noch nicht das andere, wie ich gerade wieder erfahren muss! Ich sitze an einem VHDL-Code, der von einem Physiker geschrieben wurde: - tolle komplexe Konstrukte - hoch dynamische und flexible Struktur - viele generics - aufs bit genau optimiert - jedes sample ausgenutzt Ein genialer Code, von einem Topmann, wie er auch intern gesehen wird. Problem: Der Code funktioniert nicht richtig in der realen Umgebung. Irgendwas passt mit dem Timing nicht. Denn leider: - wurde ein viel zu komplizierter Ansatz verwendet - glänzt der Code vor Fifos, wo keine gebraucht werden - es gibt vertrackte Bitopmitierungen mit LUTs und SRs - die Signale sind alle abstahiert und haben anonyme Namen - der code ist praktisch komplett undokumentiert - es gibt keine richtigen Testbenches - der Topmann ist wech Wie kommt man dem bei? Wie erklärt man dem Auftraggeber, dass dieser tolle, intelligente Code nicht zu debuggen ist, jedenfalls nicht in vertretbaren Zeiträumen.(?) Warum ist es immer noch so, dass immer wieder Wert auf die Sprache VHDL, nicht aber auf das Designen gelegt wird? Warum bringt man den Leute nicht mal bei, dass man testfreundlich entwicklen muss, teamfähigen- und lesbaren Code erzeugen muss und es nicht darauf ankommt, besoners geniale Struturen zu erdenken? Und warum hängen überall Leute rum, die sich das offenbar selber beigebracht haben und aus der Art geschlagenen Code abliefern?
Der Typ könnte glatt bei Xilinx anfangen ;) Aber so absonderlich oder VHDL-spezifisch ist das nicht, das gibts genauso auch bei "normaler" Programmierung. Vor lauter OO-Tricks und supertollen Datenstrukturoptimierungen blickt dann auch kein anderer mehr durch.
Wenn ich schon lese dass es keine ordentliche Dokumentation gibt, dann ist meine erste Frage immer: gibt es specification-documents? Wenn nein: Prima, alles was das Design macht, ist korrekt! Das Problem hat jemand anders Willst du jetzt wissen warum die Menschen so sind, wie sie sind? Arbeiten Programmierer nicht in einem strikten Team mit einem "Aufseher" der auf Guidelines achtet geht das garantiert schief. Sobald Programmierer/Entwickler die Freiheiten bekommen, zu tun und zu lassen was sie wollen, solange am Ende das raus kommt, was erwartet wird, denkt der Entwickler zu Anfang, er hat einen Traumjob gefunden. Und dann kommt man da an wo du jetzt stehst! Mein Job fing auch so an, ein Jahr lang VHDL entwickeln wie ich es gerade wollte solange hinten rauskam was erwartet wurde. Und meine 2 Kollegen ebenso. Dann wurde der eine lange krank, die Deadline kam naeher und ich musste seinen Code debuggen und verstand: NICHTS! Nicht eine kommentar-Zeile, Signale die Namen von Mitarbeitern tragen und alles schrecklich kryptisch und kompliziert gebastelt. Es lief darauf hinaus dass ich beinah alle Module neu schreiben musste, weil das schneller ging als sie aufzuraeumen und durchzutesten. Aber erst seit wir in dieser Zeit einen externen "Aufseher" (Project Manager) dabei geholt haben hat sich bei uns eine strukturierte Arbeitsweise etabliert, in der sich an strikte design regeln gehalten wird. Sicher ist es nicht so toll erst ein Designdocument zu schreiben, Testbenches aufzuziehen und DANN erst anzufangen zu programmieren, aber es spart am Ende einen Haufen Zeit, Schweiss, manchmal Traenen und man versteht es einfach viel besser. Erst dokumentieren und dann programmieren erleichtert beides! Das tolle "Code fummeln bis es funktioniert" macht leider nur rund 10% des Jobs aus. Zu deinem Problem, wie man dem beikommt: Zuerst alles rauskicken was unnoetig ist (z.B. die FiFos), und dann mit Modelsim Stueck fuer Stueck alles durchrechnen, bis du den Fehler hast. Wenn es Timing probleme sind und der Code an sich funktioniert, musste mit Timing Constraints eben alles durchanalysieren. Ist das VHDL modul auch fuer die entsprechende Hardware geschrieben worden oder eigentlich fuer irgendwas viel schnelleres? Wenn du zumindest weisst was vorn reingeht und hinten rauskommen muss, dann kannste dich da durch wuehlen. Das kostet sicher Zeit und Muehe, macht auch vielen keinen Spass (mir schon), ist aber das Sinnvollste. Und dann dem Kunden sagen dass er seine Programmierer/Physiker/wasauchimmer aufn VHDL Basiskursus schicken soll um was ueber Coding und Design Guidelines zu lernen. So Top kann der Mann uebrigens nicht sein wenn sein VHDL Konstrukt a) nicht vernuenftig tut was es tun soll und er b) zu faul war oder sich zu geil fand ordentlich zu dokumentieren. Code kompliziert machen kann so ziemlich jeder, ihn einfach/verstaendlich/uebersichtlich halten ist die Kunst
Berater schrieb: > Problem: Der Code funktioniert nicht richtig in der realen Umgebung. > Irgendwas passt mit dem Timing nicht. Das ist der übliche ausgangspunkt für eine wochenlange Fehlersuche... ;-) > Wie erklärt man dem Auftraggeber, dass dieser tolle, intelligente Code > nicht zu debuggen ist, jedenfalls nicht in vertretbaren Zeiträumen.(?) Wurden mehrere Takte verwendet? Wurden asynchronen Resets verwendet? Kommen evtl. sogar kombinatorische asynchrone Resets vor? Wenn sowas auftaucht, dann stelle ich SOFORT jede Lobhudelei in Frage, und kann mit simpelsten Beispielen die Qualifiktaion des Lobgehuldeten zunichte machen. Und ab diesem Zeitpunkt ist das nicht eine Fehlersuche, sondern ein grundlegendes Redesign. > Warum ist es immer noch so, dass immer wieder Wert auf die Sprache VHDL, > nicht aber auf das Designen gelegt wird? Weil viel Know-How zu FPGAs erst in den letzten Jahren aufgebaut wurde, die Bücher aber schon lange vorher verfasst wurden. Und für viele Faustregeln gibt es noch keine ausreichend dokumentierte Mathematik, so dass lieber die alte abstrakte Automatentheorie gelehrt wird, als die praktische Umsetzung eines Zählers in Hardware... > - der Topmann ist wech Das war offenbar genu der richtige Zeitpunkt zum Absprung... ;-) > - der Topmann ist wech > Wie kommt man dem bei? Vermisstenmeldung an die Polizei? ;-)
> Sicher ist es nicht so toll erst ein Designdocument zu schreiben, > Testbenches aufzuziehen und DANN erst anzufangen zu programmieren, > aber es spart am Ende einen Haufen Zeit Exakt meine Haltung. Ich gehe sogar noch einen Schritt weiter und leite die Funktionalität, die man für die Tests und Validierungen in den SPECs definiert, direkt in Punkt-für-Punkt Abläufe in Exceltabellen. Aus denen kann man dann nicht nur den Datenstom für Modelsim-Filereader sondern auch den Ablauf von pipes und statemachines rausziehen und automatisch generieren lassen - inklusive Timing. Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule gelernt hat, wie man: - wann und wie (nicht) einsynchronsiert - physische von logischen "sets" und "resets" trennt - asynchron rettet und wann man es bleiben lässt - eine pipeline entwirft und dokumentiert - serielle ind parallere Strukturen umdesiged - die Balance zwischen serial und parallel ermittelt - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert - eine Iteration über Zeit-Flächen-Struktur realisiert - eine Rekursion implementiert - eine Formel so umstellt, dass sie VHDL-tauglich wird - einen Algo so zerlegt, dass er parallelisierbar wird - synthetisierbarer testcode implementiert und wann - testbenches optimieren und automatisieren kann - eine Resource in verschiedenen Zeitebenen mehrfach nutzt Es geht also nicht um das VHDL, sondern grundsätzlich darum, wie man eine digitale Schaltung optimal aufteilt und aufbaut, dass das Gesamtergebnis passt und zwar letztlich auch noch unter Berücksichtigung von: - Designaufwand am Arbeitsplatz + Abstimmungsbedarf im Team - Verifikations- und Validierungsaufwand während Design - Implementierungsaufwand im FPGA oder später mal ASIC oder anderes FPGA - Integrationsaufwand des FPGA-Systems in der Umgebung / im System - Test- und Inbetriebnahmeaufwand des Systems im Feld Je nachdem, ob man einen Prototypen baut oder einen Kleinserie, eine Komponente o.ä. gibt es hier doch recht starke Verschiebungen. Das alles kommt natürlich erst mit der Erfahrung, aber Digitaldesign im eigentlichen Sinne, scheinen die Wenigsten systematisch wirklich erlernt zu haben.
Juergen S. schrieb: >> Sicher ist es nicht so toll erst ein Designdocument zu schreiben, >> Testbenches aufzuziehen und DANN erst anzufangen zu programmieren, >> aber es spart am Ende einen Haufen Zeit > Exakt meine Haltung. Ich gehe sogar noch einen Schritt weiter und leite > die Funktionalität, die man für die Tests und Validierungen in den SPECs > definiert, direkt in Punkt-für-Punkt Abläufe in Exceltabellen. Aus denen > kann man dann nicht nur den Datenstom für Modelsim-Filereader sondern > auch den Ablauf von pipes und statemachines rausziehen und automatisch > generieren lassen - inklusive Timing. Das klingt interessant. Doch Excel finde ich mittlerweile grausam, da ich alles unter Excel gesehen habe, was nicht in Excel sollte. > Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule > gelernt hat, wie man: > > - wann und wie (nicht) einsynchronsiert > - physische von logischen "sets" und "resets" trennt > - asynchron rettet und wann man es bleiben lässt > - eine pipeline entwirft und dokumentiert > - serielle ind parallere Strukturen umdesiged > - die Balance zwischen serial und parallel ermittelt > - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert > - eine Iteration über Zeit-Flächen-Struktur realisiert > - eine Rekursion implementiert > - eine Formel so umstellt, dass sie VHDL-tauglich wird > - einen Algo so zerlegt, dass er parallelisierbar wird > - synthetisierbarer testcode implementiert und wann > - testbenches optimieren und automatisieren kann > - eine Resource in verschiedenen Zeitebenen mehrfach nutzt fast null. Alles selbst erlernt. was meinst du eigentlich mit den Punkten? > - physische von logischen "sets" und "resets" trennt > - eine Iteration über Zeit-Flächen-Struktur realisiert da muss ich passen, oder es läuft unter einem anderen Begriff bei mir > Es geht also nicht um das VHDL, sondern grundsätzlich darum, wie man > eine digitale Schaltung optimal aufteilt und aufbaut, dass das > Gesamtergebnis passt und zwar letztlich auch noch unter Berücksichtigung > von: > > - Designaufwand am Arbeitsplatz + Abstimmungsbedarf im Team > - Verifikations- und Validierungsaufwand während Design > - Implementierungsaufwand im FPGA oder später mal ASIC oder anderes FPGA > - Integrationsaufwand des FPGA-Systems in der Umgebung / im System > - Test- und Inbetriebnahmeaufwand des Systems im Feld > Das sind alles Fragen nach der Wirtschaftlichkeit. Ich würde die Aussage etwas unterteilen. VHDL st keine Programmierung für eine CPU, sonder es wird Hardware geschaffen. Das ist Digitaltechnik!! Auf der geschaffenen Hardware kann unter Umständen auch Software laufen. Wie der Schnitt Software Hardware gehalten werden sollte ist eine ganz schwierige Frage und beeinflusst das Design gewaltig. Die Algorithmen passen nicht 1:1 mehr, weil Prozesse synchronisiert werden müssen und Daten noch eine Gültigkeitsdauer haben. VHDL wird of als Nebenfach angeboten. Mal bei den Informatikern und mal bei den Elektrotechnikern und alles bleibt in den Grundlagen stecken. Die Dokumentation ist dann immer noch weit entfernt. Auch mathlab ist keine Dokumentationsebene. Am besten wäre UML als Dokumentionsgrundlage -
René D. schrieb: >> Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule >> gelernt hat, wie man: >> >> - wann und wie (nicht) einsynchronsiert >> - physische von logischen "sets" und "resets" trennt >> - asynchron rettet und wann man es bleiben lässt >> - eine pipeline entwirft und dokumentiert >> - serielle ind parallere Strukturen umdesiged >> - die Balance zwischen serial und parallel ermittelt >> - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert >> - eine Iteration über Zeit-Flächen-Struktur realisiert >> - eine Rekursion implementiert >> - eine Formel so umstellt, dass sie VHDL-tauglich wird >> - einen Algo so zerlegt, dass er parallelisierbar wird >> - synthetisierbarer testcode implementiert und wann >> - testbenches optimieren und automatisieren kann >> - eine Resource in verschiedenen Zeitebenen mehrfach nutzt > > fast null. Alles selbst erlernt. So ist es. Dafür werden noch massiv Logikminimierungsverfahren gelehrt. Tom
Thomas Reinemann schrieb: > René D. schrieb: >>> - wann und wie (nicht) einsynchronsiert >>> - physische von logischen "sets" und "resets" trennt >>> - asynchron rettet und wann man es bleiben lässt >>> - eine pipeline entwirft und dokumentiert >>> - serielle ind parallere Strukturen umdesiged >>> - die Balance zwischen serial und parallel ermittelt >>> - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert >>> - eine Iteration über Zeit-Flächen-Struktur realisiert >>> - eine Rekursion implementiert >>> - eine Formel so umstellt, dass sie VHDL-tauglich wird >>> - einen Algo so zerlegt, dass er parallelisierbar wird >>> - synthetisierbarer testcode implementiert und wann >>> - testbenches optimieren und automatisieren kann >>> - eine Resource in verschiedenen Zeitebenen mehrfach nutzt >> >> fast null. Alles selbst erlernt. Kann ich nur bestätigen, habe mir das meiste aus dieser Liste auch durch Praxisaufgaben erarbeitet.
> Es geht also nicht um das VHDL, sondern grundsätzlich darum, wie man > eine digitale Schaltung optimal aufteilt und aufbaut, dass das > Gesamtergebnis passt und zwar letztlich auch noch unter > Berücksichtigung von: <...> Wobei mir das (als Informatiker) auch etwas kurz gedacht vorkommt. Wenn es eine Interaktion mit SW gibt (nicht immer, aber oft hängt das Zeug ja an irgendeiner CPU), sehe ich das Hauptproblem beim Design darin, die Schnittstellen für beide Ebenen effizient zu gestalten. Das bedingt eine gute Interaktion der HW- und SW-Fuzzies bei der Spezifikation, die es oft aber nur bei kleinen Klitschen zwangweise (überspitzt "jeder kann alles") gibt. Ich habe es bei Designs schon öfters gesehen, dass da sehr viel Mühe in HW-Teile gesteckt wurde, die mit einer Handvoll C-Zeilen in 2min ohne Performanceverlust auch machbar gewesen wären. Aber genauso gibt es Designs, wo mir der SW-Entwickler leid tut, der die HW-Ansteuerung ausbaden muss ;) > So ist es. Dafür werden noch massiv Logikminimierungsverfahren gelehrt. Naja, so ein bisschen Rumspielen mit boolscher Algebra, KV und Quine-McCluskey sollte man in 1-2 Vorlesungsstunden schon machen, damit man mal gesehen hat, was das Zeug kann und wo die Limits liegen. Das sollte dann aber auch reichen, ausser man hat Schwerpunkt "Logiksynthese" oder sowas...
Thomas Reinemann schrieb: > So ist es. Dafür werden noch massiv Logikminimierungsverfahren gelehrt. Und Halbaddierer auf RTL-Ebene beschrieben und zu Volladdierern verknotet. Dabei wird dann aber nicht auf die Wichtigkeit der Carry-Chain, deren geschwindigkeitslimitierende Funktion und die Umsetzung der Kette in FPGAs eingegangen... Georg A. schrieb: > Naja, so ein bisschen Rumspielen mit boolscher Algebra, KV und > Quine-McCluskey sollte man in 1-2 Vorlesungsstunden schon machen, damit > man mal gesehen hat, was das Zeug kann und wo die Limits liegen. Es sollte aber abschliessend der Hinweis kommen, dass diese ganze Optimiererei bei bis zu 4 (bzw. 6) Eingängen in FPGAs unnötig ist, weil die LUT (oder neu: der Funktionsgenerator) das sowieso direkt abbilden kann...
Das klingt als bräuchten wir eine Selbsthilfegruppe. Ich gebe auch Georg A. recht, es gibt auch überzogene Hardware Ausführungen, was besser in eine CPU gepasst hätte. Hier ist es wichtig eine Projektleitung zu haben, da die Sachen von mehreren Kollegen entwickelt werden. Wie kann projektübergreifend diskutiert werden? Daran krankt es. Das sind Diagramme und als Schiedsrichter Testbenches. Eine Testbench in einem zu frühen Stadium ist etwas überzogen.
> Das klingt als bräuchten wir eine Selbsthilfegruppe.
Die anonymen VHDoLiker
;-)
Ob da der Projektleiter der Richtige ist, weiss ich nicht. Es muss jemand sein, der breit und tief ausgebildet und lange Erfahrung in allen Bereichen hat. Typisch macht das ein Senior System Engineer: Wenn man solche Systeme hinstellen und partitionieren will, dann gelangt man nur zu einer klugen Aufteilung von HW und SW, bzw HW-Abläufen und SW-Abläufen, zu Schnittstellen und Interaktionen, wenn man beide Welten sehr gut kennt. Und ja, er muss sie studiert haben! Denn, wenn ich eins in all den Jahren gelernt und gesehen habe, dann das, dass es in der Softwarelandschaft (C, Algorithmik und VHDL-basierte Abläufe) ein großer Haufen an Mist zusammengeschustert wird. Da gibt es die abenteuerlichsten Konstrukte mit tollen Tricks und "Realisationen", für die es längst schlüsselfertige, intelligente Lösungen in der Schublade gibt, von denen man unbedingt profitieren und Gebrauch machen muss, wenn man einfach, effektiv und stabil entwickeln will. Das kann man sich nicht alles selber beibringen, weil man das meiste nicht irgendwo in der Anschauung sieht oder sich selber ausdenken kann. Man muss es gesehen haben, BEVOR man es braucht. Man muss wissen, dass es das gibt und ungefähr sehen und schätzen, was es an Zeit und Aufwand kostet und was damit möglich ist. Ich habe immer wieder Leute gesehen, die aus fremden Bereichen der Wissenschaft in die Programmierung einsteigen und dann schnell an limits kommen. Umgekehrt bekommen selbst eingeschleischte Softwareentwickler es einfach nicht hin, in die strukturelle Ebene hineinzudenken. Wenn man 5 Jahre Maschinenbau studiert hat, kennt man keine Digitalschaltungen und deren Eigenheiten und Details bleiben einem verborgen. Typische Synch-, Phasen- und Taktprobleme hat man auch nur verinnerlicht, wenn man reale Chips vor Augen hat, denn Abstraktheit hin oder her: Am Ende klickern da drinnen analoge Transistoren, die nur in der vereinfachten Betrachtung diskrete Funktionen aus LUTs darstellen. Und genau dieses Wissen sorgt dafür, dass man manche Sachen u.U. eben nicht in SW nachbilden kann, ein FPGA im Einzelfall nicht taugt oder umgekehrt aus technischen Gründen ein "langsamer" DSP verwendet werden muss.
>Excel Ich benutze das als schlaues Karopapier. Andere malen sich was auf den Zettel- ich zeichne Wiederverwendbares. Das gemeinsame Editieren von Varianten, Abläufen und Verzweigungen für physische oder virtuelle Derivate und Versionen geht mit COPY&PASTE schneller, als das Malen von Bäumchen in Visio :-) Und Planen und Automatisieren geht auch simpel und einfach, weil man leicht Umkopieren, Löschen und Duplizieren kann. Und: Man kann Dinge, mit miteinander verknüpft sind, als harte oder weiche Verknüpfung belassen und sich eine Alternativversion auf Nachbarblättern durchrechnen lassen, bzw Änderungen in der V1-Version automatisiert weitergeben, um Konsistenz aufrecht zu erhalten, wo sie nötig ist. Ein Beispiel aus dem FPGA-Bereich wäre das Halten und Planen der Verdrahtungstruktur von Bussen über Platinen und FPGA-Grenzen hinweg, inklusive der Namen der Signale an den Stecker, Ports, Entities etc. sowie die Versionsplanung für verschiedene Ausbaustufen oder die Migrationsplanung unter Nutzung von Chips unterschiedlicher Hersteller. Ein reales Beispiel mit geänderten Zahlen: Man denke sich mal eine Struktur aus z.B. 3 x 4 FPGAs, wo sich 10 davon 50 ähnliche Funktionen teilen, 5 davon weitere 200 Leitungstreiberfunktionen, wobei jeweils 40 dieser Leitungen durch jeweis andere FPGAs redundant getrieben werden können müssen, wegen Minderbestückung und alle 12 zusammen auch 1 bestimmte Funktion verteilt leisten, manche FPGAs aber auch nur eine einzige Funktion leisten, die nur sie beherrschen. Das Ganze dann für 2 verschiedene Versionen von Boards, wo sich die Zuordnungen der Pins teilweise physisch ändern und 2 verschiedene Prozessoren / Ansteuerungen, wo sich die Busse und die Timings ändern = 4 Versionen! Man darf aber nur 3 verschiedene, jeweils unterschiedliche FPGA-images verwenden, weil das Flash auf den alten board-Versionen zu klein ist und die boards plug-and-meassure fähig sein müssen, alles selber erkennen müssen und überall passen sollen. Das gibt eine Matrix mit wenigstens 4 Dimensionen mit divergenten und konvergenten Überlappungen, deren Funktionsvielfalt genau so auf virtuelle FPGA-Funktionen gemappt werden muss, dass am Ende jedes FPGA eines von 3 images bekommt, welche in Summe die Vereinigungsmenge aller Funktionen können, aber pro FPGA jeweils nur die Teile funktionieren, die in diesem FPGA benötigt werden, die Summe der so zusammenarbeitenden FPGAs aber die gesamt Teilfunktion kann. Das kompliziertes FPGA nutzt dann aus seinem Image, welche z.B. 40 Teilfunktionen könnte, z.B. 13, dessen Nachbar nur 7. Macht in Summe 20 Funktionsteile (4 unterschiedliche) von insgesamt >70 insgesamt auf dem board. Und dann bitte bis Ende der folgenden Woche eine Planungsmethode entwickeln, wo alle Funktionen enthalten-, übersichtlich geordnet-, und so gruppiert sind, dass die daraus notwendigen virtuellen Verdrahtungsoptionen ersichtlich sind und die Vollständigkeit sichergestellt werden kann. Ok, hab' ich gemacht. Ergebnis: Mehrere Designingenieure inkl Projektleiter mit Kinnlade unten, automatisch erzeugte "set_location's" für's UCF ohne Tippfehler, automatische Summierung der Funktionen, Teilfunktionen, Pins je FPGA, Busbreitenwerte für Derivateoption und Darstellung der Zuordnung der realen physischen Pins zu virtuellen Kanälen der Software -> Programmiertabelle ausleitbar ... und ein Dr. der Mathematik, der sich ein halbes Jahr lang bereits mit der Planung des Systems befasst hatte und zu dem Schluss gekommen war, man brauche mindestens 2 verschiedene boards mit insgesamt 5 verschiedenen images. Meine reale Aufgabe war im Ürigen noch etwas komplexer. Wenn ich mir überlege, was man davon in den heutigen SOC-builder-Systemen und System-Generator-blocksets oder HDL-Designer abbilden kann, dann happy digit!
Juergen S., so gut wie du möchte ich auch gerne mal werden...
absolut.... War eigentlich ein guter thread, jetzt bin ich raus. Gibt halt Sympathieträger und Nieten ;-)
Juergen S. schrieb: > Man denke sich mal eine Struktur aus z.B. 3 x 4 FPGAs, > wo sich 10 davon 50 ähnliche Funktionen teilen, 5 davon weitere 200 > Leitungstreiberfunktionen, wobei jeweils 40 dieser Leitungen durch > jeweis andere FPGAs redundant getrieben werden können müssen, wegen > Minderbestückung und alle 12 zusammen auch 1 bestimmte Funktion verteilt > leisten, manche FPGAs aber auch nur eine einzige Funktion leisten, die > nur sie beherrschen. Zum Glück habe ich solche Probleme nicht (und ich vermute: auch die wenigsten anderen)... ;-) Aber ich möchte auch behaupten, dass man da einfach auch mal Glück haben darf und zum richtigen Zeitpunkt die zündende Idee. Nur: DAS zu lehren kann man jetzt wirklich nicht von den Schulen verlangen... :-o
in der tat schrieb: > War eigentlich ein guter thread, jetzt bin ich raus. Gibt > halt Sympathieträger und Nieten ;-) Wie, wegen mir etwa?
nein ganz und gar nicht wegen dir, sondern weil ich selbstverliebte Fatzkes auf den Tod nicht ausstehen kann..... Und ich war doch wieder im Thread ;-)
> Zum Glück habe ich solche Probleme nicht (und ich vermute: auch die > wenigsten anderen)... ;-) Schon richtig, es ging mir nur darum, einmal zu zeigen, dass man mit Excel durchaus einiges machen kann. War vielleicht ein wenig zu ausführlich. Es ging mir aber auch darum, zu verdeutlichen, dass die Komplexität bei Entwicklungen mehr in der Planung und im Denkansatz liegt und es nicht reicht, einfach nur irgendeine wissenschafliche Ausbildung zu haben und sich das Programmieren angeeignet zu haben. Der Hase ganz woanders im Pfeffer. > Juergen S., so gut wie du möchte ich auch gerne mal werden... Ja, ja ich weiss schon, wenn man D Fakten auspricht, fühlen sich einige gleich wieder angegriffen. Nur: ständig auf understatement machen, bringt nichts voran. Manchmal muss man auch mal ein wenig Tacheles reden und wo sollte man das, wenn nicht in einem Forum? Im direkten Umgang mit Kollegen kann man schlecht auf den Putz hauen und der Threadersteller ist gut beraten, vorsichtig mit Kritik an Kollegen zu sein. Was ich zu dem Thema Studium geschrieben habe, sehen viele meiner Kollegen aber genau so, besonders, wenn sie sich mit der mittelmäßigen Qualität von Zulieferern herumärgen müssen. Heute kommt doch jeder zweite Computerbediener auf die Idee, er sei ein guter Softwareentwickler, weil er eine Programmiersprache gelernt hat. Seien wir mal ehrlich: C-Programmieren könnte so ziemlich jeder, wenn er sich damit befasst. Mit Jedermann-Qualität kann man aber keine Systeme in den Markt bringen, die um soviel besser sind, als das, was anderorts gemacht wird, dass man gut verkaufen kann.
http://www.spiegel.de/karriere/berufsleben/0,1518,748287,00.html P.S. "Im direkten Umgang mit Kollegen kann man schlecht auf den Putz hauen" Warum? Doch nicht der tolle Hecht oder keine Eier? Konstruktiv darf und soll man das. Nur sich selber über alles stellen kommt halt schlecht an.
> Doch nicht der tolle Hecht oder keine Eier? Nein, sozialkompatibel, freundlich und nett zu Kollegen. Mit Eiern hat das nichts zu tun. Wir sind nicht im Rabaukenland. > Konstruktiv darf und soll man das. Tue ich, keine Sorge. Ich tue es aber durchs Vorleben, weniger durch Diskutieren, weil ich gelernt habe, dass keiner gerne auf die Füsse getreten bekommt und es geht auch nur peu a peu voran. In den harten Fällen, wo man wirklich den Hebel ansetzen müsste und nicht drüber hinwegsehen dürfte, ist eh nichts zu machen, weil man niemandem im Nachinein eine andere Ausbildung, ein anderes Wissen und nicht einmal mehr eine andere Programmier- oder Arbeitstechnik beibringen oder auferlegen kann. Man muss dann mit denen klarkommen, die man nebenbei hat :-) Die Kritik setzt weiter vorne an, z.B. bei denjenigen, die immer weniger auf Ausbildung schauen, Studienzeiten verkürzen oder "verbatcheln" und bei Einstellungen den billigen Jakob bevorzugen. Ich beziehe mich dabei in jüngster Zeit immer öfters auf Beauftragungen an Dienstleister und Drittanbieter, wo man gezwungen ist, den Billigsten zu nehmen, der dann seinerseits nur noch leben kann, indem er die billigen Quereinsteiger und Anfänger beschäftigt, während andere gut ausgebildete Ingenieure und Softwareexperten, (die ich auch zuhauf kennengelernt habe) aufgrund ihrer angeblich hohen Gehaltsforderungen nichts bekommen und zu ebensolchen Billigtarifen anbieten müssen. Dies leistet dann somit der allgemeinen Verbilligung Vorschub und es lohnt sich immer weniger, eine fundierte Ausbildung anzustreben. Ich kenne in der Tat viele sehr gute Entwickler, die sich genau aus diesen Gründen aus diesem Bereich abseilen. Qualität ist nicht mehr gefragt in diesen Tagen.
Ich kann dich schon verstehen - ich gebe dir sogar teilweise Recht. Aber entweder oder - sich in einem Forum über alle anderen stellen aber im persönlichen Kontakt gegenüber nicht durch den 'ich bin besser' Gedanken leiten zu lassen das geht meiner Ansicht nach nicht. Du hast doch bei allen möglichen Gelegenheiten im Hinterkopf mal eben die Arbeit eines halben Jahres des Herrn Dr. in einer Woche abreißen zu können. Daß dies sozialkompatibel bleibt kann ich mir echt nicht vorstellen. Was heißt 'vorleben'.... Du fühlst dich mindestens eine Stufe besser. Bist das vielleicht sogar, dann versuche etwas abzugeben. Dafür sind Kollegen eben da. ( und zwar solltest du dich dabei auf Augenhöhe sehen und nicht als den Besseren. Göttlich bist auch du sicher nicht ) Die universitäre Ausbildung und die Ausbildung auf der Fachhochschule kann praktische Arbeit und Erfahrung ja schlecht vermitteln sie soll dienlich sein, von erfahrenen Leuten weiterlernen zu können. Auch Lücken sind in meinen Augen keine Schande. Die sind durch Erfahrung zu stopfen. Aber deine Zeilen triefen nur so vor Selbstverliebtheit. Und das erkennt man bei seinem Gegenüber. Und davon bekomme ich Ausschlag denn das ist extrem unsympatisch. Zumal es sich keiner Leisten kann. Wer ist schon so perfekt? P.S Wann hast du vor dir selber zuletzt einen Fehler eingestanden? Falls ich dir unrecht tue und die wirklich ein umgänglicher, hilfsbereiter Kollege bist tut mir das aufrichtig leid. Dann entschuldige ich mich für die Schublade in die ich dich gepackt habe
Du scheinst ja wirklich etwas "selbstreflektiert" zu sein, wenn Du in Betracht ziehst, vorschnell geurteilt haben zu können :-) Ich halte mich durchaus nicht für omnipotent. Schwächen habe auch ich auch genug, aber dort präsentiere ich mich nicht als Experte oder Ideengeber und überlasse die Führung anderen. Dies tue ich genau weil ich gesehen haben, dass ich mir das eine oder andere zwar locker zutraue und auch leisten könnte, aber eben nur "auch" und nicht "en top". Mithin ist das Beispiel des "Dr." genau das Passende, den ihm oblag die Führung und Planung im Projekt, weil man dachte, die Promotion macht es schon. Denken können reicht. Nochmal eines zu den Überfliegern: Sicher ist es richtig, dass es besser läuft, man von einem homogenen Team ausgeht. Das Team muss aber hohes Niveu und nicht Mittelmäßigkeit darstellen. Daher halte ich den link von oben für äusserst unstimmig. > Beim Intelligenzquotienten zum Beispiel wird der Mittelwert als 100 definiert. > Die große Mehrheit der Menschen weist einen IQ zwischen 85 und 115 auf. Das sind ALLE Menschen, aber nicht alle Fachkräfte. Bei MINT-Studenten finden sich sehr wohl Mittelwerte um die 115 - bei manchen Fachbereichen auch noch mehr. > Genies .. gibt es nur sehr wenige; Experten schätzen den Anteil auf jeweils zwischen zwei und fünf Prozent. 5% heisst immerhin jeder 20., also einer pro Schulklasse. In der Bevölkerung wären es 400.000 Personen. Das würde ich noch nicht "Genie" nennen. Angeblich sind 2% aller Menschen "Hochbegabt", haben also einen IQ von >130. Das klingt schon eher nach Genie, heisst aber auch nur wieder "jeder 50te". Jetzt rechnen wir mal: Im Moment machen etwa 35% eines Jahrgangs Abitur und von denen schließen wiederum 30% ein Studium ab, also 10% der Bevölkerung. Damit wäre jeder 5. Absolvent "hochbegabt". Bei den MINT dürfte der Anteil noch höher liegen, sagen wir 25%? - Da nur die oberen 3/4 der MINT-Absolventen in ihrem Job arbeiten, haben rund ein Drittel der Ingenieure einen IQ von >130. Selbst wenn die geschätzten Zahlen nicht 100% stimmen, sollte der wahre Anteil nicht weit davon weg liegen. Also nix mit "Mittelmass = gut". Trotzdem hin ich nach wie vor ein Fan einer umfangreichen und fundierten Ausbildung. Das Problem: Wer's nicht hat, kennt es nicht und weiss manchmal nicht, was ihm fehlt :-)
>Trotzdem hin ich nach wie vor ein Fan einer umfangreichen und >fundierten Ausbildung. Vollkommen d'accord. Es scheint heute aber irgendwie Mode geworden zu sein, dass branchen- und ausbildungsfremd gearbeitet wird, während jedoch eine spezifische Ausbildung eigentlich immer wichtiger wird, weil die Anforderungen immer komplexer werden. Ich frage mich überhaupt, was es für einen Sinn machen soll, Studiengänge wie Elektrotechnik und Informatik haarklein in einzelne Studienrichtungen aufzuspalten, wenn die Elektronik und Software dann von "artfremden" Maschinenbauern geschrieben wird. Im IT-Bereich, wo ich inzwischen tätig bin, tummeln sich unendliche Zahlen von MB-Absolventen, die mal Werkstoffkunde, Kraftwerkstechnik und was weiss ich erlernt haben, nun aber nur noch Datenbanken bezaubern und SW entwickeln. Ich habe mir das ganz langsam, beginnend mit einem Elektronikstudium und embedded Controllern aufgebaut, bin dann über die PC-Anbindung Stück für Stück in die abstrakte C++ - Landschaft migriert. Ich hatte auch in all den Jahren zahlreiche Kurse und Seminare. Trotzdem behandle ich das Thema noch recht oberflächlich, weil ich eher plane und keine kritischen Apps selber mache. Das überlasse ich den Spezialisten. Als Projektleiter stehe ich aber genau vor dem beschriebenen Problem, dass budgetbedingt wenigerqualifizierte Quereinsteiger einen Grossteil der kritischen Apps machen und ein Zeug zusammenfummeln, dass es die Wildsau graust, wie man hier sagt. Das betrifft C und VHDL in gleichen Teilen. Als Maschinenbauer oder Physiker hat man eben nicht die erweiterten Grundlagen parat und machen tun die das ja auch nur, weil sie in ihrem Bereich keinen Job bekommen-, und keine Lust aufs Taxi haben:-) In Deutschland muss ich sagen, geht es aber noch. Ich bin wieder mal für eine Firma in Asien tätig und muss mitansehen, wie umgeschulte Landeier mit Kartoffelbackground Flugzeugtechnik verkabeln, Hausfrauen zwischen den Malzeiten Pfostenstecker einlöten, und 23-jährige Bübchen komplizierte Steuersofware basteln, welche angeblich "Master of Engineering" sind. > wurde ein viel zu komplizierter Ansatz verwendet Mein täglich Brot. Wenn die Jungens ein wenig nachdenken würden, kämen ganz andere Module heraus und wir hätten deutlich weniger Aufwand - vor allem beim Fehlersuchen.
Juergen S. schrieb: > Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule > gelernt hat, wie man: > > - eine pipeline entwirft und dokumentiert > - serielle ind parallere Strukturen umdesiged > - die Balance zwischen serial und parallel ermittelt > - eine Formel so umstellt, dass sie VHDL-tauglich wird > - einen Algo so zerlegt, dass er parallelisierbar wird Das gab's bei mir Studium. Technische Informatik an einer TU, mit entsprechender Vertiefungsrichtung, noch nicht zu lange her. Aber natürlich lässt sich das theoretische Wissen nicht sofort in die Praxis übersetzen. Einem Absolventen fehlt einfach die Erfahrung, deswegen ist er ja auch günstiger als alte Hasen. Wer aber nach 5 Jahren immer noch keine Ahnung hat, muss sich schon fragen lassen, ob er seinen Job wirklich gut macht. (Und selbstkritischerweise muss ich auch sagen, dass ich mich intensiver mit Methodik und Strukturen beschäftigen könnte - es "läuft" halt im derzeitigen Job auch ohne). > - wann und wie (nicht) einsynchronsiert > - physische von logischen "sets" und "resets" trennt > - asynchron rettet und wann man es bleiben lässt Das wird verschiedentlich in aktuellen Lehrbüchern behandelt. > - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert > - eine Rekursion implementiert > - synthetisierbarer testcode implementiert und wann > - testbenches optimieren und automatisieren kann > - eine Resource in verschiedenen Zeitebenen mehrfach nutzt Das durfte man sich mit entsprechendem Engagement selbst in Praktika beibringen, oder man lernt es auf die harte Tour nach dem ersten fehlgeschlagenen Projekt. Es gibt auch ganz hervorragende VHDL-Kurse z.B. von Doulos, die gerade auf die Testbench-Geschichten eingehen. Und Testbenches stellen bekanntlich 90% des VHDL-Codes. > - eine Iteration über Zeit-Flächen-Struktur realisiert Meinst Du Design-Space-Exploration? > Das alles kommt natürlich erst mit der Erfahrung, aber Digitaldesign im > eigentlichen Sinne, scheinen die Wenigsten systematisch wirklich erlernt > zu haben. Auf jeden Fall muss da viel mehr passieren, vor allem seitdem FPGAs omnipräsent sind.
Ras Funk schrieb: >> - wann und wie (nicht) einsynchronsiert >> - physische von logischen "sets" und "resets" trennt >> - asynchron rettet und wann man es bleiben lässt > Das wird verschiedentlich in aktuellen Lehrbüchern behandelt. Welche? Beispiele? Solange da noch jeder Prozess so aufgebaut ist:
1 | if reset='1' then |
2 | --
|
3 | elsif clk'event and clk='1' then |
4 | --
|
5 | end if; |
Dann ist da noch nichts von aktuellen FPGAs und deren internen Strukturen zu erkennen. Das geht sogar soweit, dass Synthesewerkzeuge solche Konstrukte von sich aus (per Schalter) in synchrone Resets umwandeln... :-o > Und Testbenches stellen bekanntlich 90% des VHDL-Codes. Diese Zahl und ihre Bekanntheit wage ich anzuzweifeln... > Und Testbenches stellen bekanntlich 90% des VHDL-Codes. Wenn ich mir die allgemein gültige falsche Beschreibung eines Taktes ansehe, kann das so nicht stimmen. Wofür gibt es eine Funktion rising_edge(), die auch den Zustand vor der Pegeländerung berücksichtigt, wenn dann der obige Konstrukt mit 'event genommen wird? Mit (clk'event and clk='1') wird z.B. die Simulation bei einem Wechsel von 'H' nach '1' einen Takt ausführen. Die Hardware aber nicht... Kurz: die Simulation entspricht nicht der Hardware und ist damit falsch.
Hallo Lothar, ohne einen Reset-Streit vom Zaun brechen zu wollen ;-) aber Altera empfiehlt "synchronized asynchronous resets", und die würden in VHDL so aussehen wie Dein Beispiel. clk'event bzw. rising_edge mal aussen vor, ebenso low/high Aktivität. Siehe Seite 21 in www.altera.com/literature/hb/qts/qts_qii51006.pdf Wegen der Bücher schau ich heute abend nochmal in meine Bibliothek und sage Dir die genauen Titel und was empfohlen wird. Herzliche Grüße!
Ras Funk schrieb: > aber Altera empfiehlt "synchronized asynchronous resets", Und genau DAS und der (mögliche) Unterschied zu anderen FPGA-Herstellern wird in keinem der Bücher (soweit mir bekannt) explizit dargestellt... > aber Altera empfiehlt "synchronized asynchronous resets", Ja, blöd nur, dass man sich das nicht unbedingt immer merkt und dann z.B. sowas schreiben könnte, weil die asynchronen Resets ja so schön sind:
1 | if reset='1' or cnt=17 then -- der ultimative Gipfel: ein asynchroner kombinatorischer Reset. Wehe, da kommt ein Glitch! |
2 | cnt <= 0; |
3 | elsif clk'event and clk='1' then |
4 | cnt <= cnt+1; |
5 | end if; |
Wenn ich mir zudem die Übersicht zur ALM dort ansehe http://www.altera.com/literature/hb/stratix-v/stx5_51002.pdf dann erkenne ich nur, dass an den FFs zwar ein CLR angeschlossen ist, aber nicht, wie die Verteilung da aussieht, und mit welchem Slack ich rechnen muß. In das selbe Horn stossen auch die Altera-Gurus: http://www.alterauserforums.net/forum/showthread.php?p=3802 http://alteraforum.org/forum/showthread.php?p=16965 Wenn das globale Reset-Netzwerk zu langsam ist, dann geht schon das Verlassen des Reset-Zustands schief. Es ist ganz einfach so, dass der Reset z.B. eines Zählers/einer FSM und der Reset eines FPGAs nichts miteinander zu tun haben. Und auch dem verlinkten Dokument kann ich keinesfalls entnehmen, dass bei Altera ein Zähler asynchron zurückgesetzt werden sollte. Ein FPGA braucht sowieso keinen Reset. Das hat nach Anlegen der Spannung loszulaufen und so lange seine Arbeit zu verrichten, bis die Spannung wieder weggenommen wird. Ein Reset kommt in dieser Aufgabenbeschreibung nicht vor. > Wegen der Bücher schau ich heute abend nochmal in meine Bibliothek > und sage Dir die genauen Titel und was empfohlen wird. Ich bin gespannt... ;-) Wenn dabei aber sowas rauskommt, wie in diesem speziell dem Spartan 3 gewidmeten Buch im Beitrag "Re: Suche VHDL Buch", dann dankesehr... :-/
Hallo Lothar, das Buch, das ich meinte, heisst "Advanced FPGA Design" von Steve Kilts. Da werden die Resets genau auseinandergenommen, mit Empfehlungen wie bei Altera. Na gut, der Author arbeitet auch bei denen... Das zweite Buch such ich Dir auch noch raus. Zum Thema "FPGA braucht kein Reset" - stimmt! Normalerweise braucht man das nicht. Sobald man aber mehrere Clock-Domains hat, und einzelne Clocks (z.B. zum Stromsparen) an- und abschalten will, dann sind Resets doch sehr lohnenswert. (bevor Diskussionen entstehen: ja, clock gating natürlich nur über CCB etc.) Oder auch, wenn das Design später auf Asics laufen soll. Spätestens da kommt man um asynchrone Resets nicht herum. Im Normal- und Regelfall bin ich völlig bei Dir.
Ras Funk schrieb: > Oder auch, wenn das Design später auf Asics laufen soll. Spätestens da > kommt man um asynchrone Resets nicht herum. Zum Glück haben die wenigsten mit ASICs zu tun. Denn dort müsste ich dir mit den 90% Simulationsaufwand wieder recht geben.. ;-)
Hallo zusammen, gut zu erfahren, dass ich wohl lieber Taxi fahren sollte (chefdesigner) oder hochkomplexe Codes verfasse, die niemand versteht (Berater) :-D @chefdesigner: Gut wenn man klar definierte Feindbilder hat oder.. Versteh ich dich richtig, dass es die E-Techniker nach dem Studium automatisch mit C und VHDL draufhaben? Die meisten die ich kennenlernen durfte, hatten z.B. leider mit Software Revision Control nix am Hut. Da hat man irgendwann mal ein zip abgelegt.. Will sagen, egal ob man aus dem Ingenieur- oder naturwissenschaftlichen Bereich kommt, im Endeffekt zählt im Job was man sich selbst über das Studium hinaus angeeignet. Im Studium sollte man vor allem gelernt haben, wie man sich selbst schnell in neue Sachverhalte einarbeitet. Das lernt man in einem breitgefächerten Fach wie Physik auf jeden Fall. @Berater: >- tolle komplexe Konstrukte >- hoch dynamische und flexible Struktur >- viele generics >- aufs bit genau optimiert >- jedes sample ausgenutzt sample oder cycle? Na egal, wo ist das Problem? Ich sehe eigentlich nur das Problem, dass es wahrscheinlich keine Spec und keine Doku gibt. Wahrscheinlich hat dann a) das Projektmanagment versagt, weil man b) nicht genuegend Zeit und Geld hatte oder c) schnell Ergebnisse sehen wollte "die spec schreiben wir später, wir müssen dem Kunden schnell was zeigen können". Ich war schon in diversen Projekten, wo genau das, das Problem war. Bei Hinweis auf fehlende Spec und nötige Zeit für Dokumentation war dafür eben keine Zeit. Wahrscheinlich war auch nicht genügend Zeit für die Inbetriebnahme eingeplant. Ist ja nichts besonders neues, dass Code in der Simulation gut funktioniert, aber in der HW nicht. Ich hatte am Anfang meiner "FPGA-Karriere" sogar einen Chef, der Testbenches und Simulation als Spielerei bezeichnet hat (war auch Physiker, allerdings primär Softwareentwickler). Ich kenne übrigens auch keine Informatiker, der durch eine Vorlesung C, C++ so gut erlernt hätte, dass er damit direkt als Profi im Job anfängt. Welches Personal an der Uni soll das auch liefern? Jeder muss wohl erst mal ein paar konkrete Projekte in der Industrie gemacht haben um zu sehen, worauf es ankommt. Nochmal zum Anfang, was ist "aus der Art geschlagener Code" ? VHDL ist eine Hochsprache und als Entwickler sollte man auch von ihren Mögliochkeiten Gebrauch machen, sonst kannste dich auch hinsetzen und die Schaltungen wieder diskret aufbauen, viel Spass.. Als Berater solltest Du doch eigentlich selbst am besten wissen, wie man dem Auftraggeber "beikommt" :-) Vielleicht erstellst Du jetzt erst mal Coding und Design Guidelines für den Kunden.
> Will sagen, egal ob man aus dem Ingenieur- oder > naturwissenschaftlichen Bereich kommt, im Endeffekt zählt im > Job was man sich selbst über das Studium hinaus angeeignet Da muss ich widersprechen. Ich habe ein Studium der Elektrotechnik in Richtung Datenverarbeitung. Wir haben spezielle Themen des Multitaskings auf MCUs und auch CPUs behandelt und auch Unterschiede verdeutlicht. Das möchte ich nicht missen. Da gibt es einige Dinge, die man sich nicht so einfach aneignen kann. Die muss man schon wissen, bevor man sie einsetzt, damit man mit ihnen planen und designen kann. Ausserdem finde ich es an dem Notwendigen vorbei studiert, wenn man sich Wissen anschafft, dass man später kaum braucht, während man das, was man braucht, erst hinter lernen will. Wozu Phyik studieren, wenn man Elektronik und Software bauen will? Physiker sind eher im Systemfesign und Modelling gefragt. > als Entwickler sollte man auch von ihren Mögliochkeiten Gebrauch machen Auch da habe ich eine andere Meinung. Viele Entwickler sehen nur das Coden und nicht die Aufwände in der Fehlersuche, der Tests, der Prüfung und der Notwendigkeit, dass andere den Code in eigenen Projekten mal wiederverwenden sollen. Da ist Einfachheit und Standardisierung gefragt. >Coding und Design Guidelines Bei uns in der Firma haben wir sowas! Und es hat sich mit der Zeit auch bezahlt gemacht, weil Neue sich leichter einarbeiten können und nach Erlernen der guides auch den alten Code besser verstehen. Und unsere guides besagen z.b: auf komplexe geniale Konstrukte zu verzichten und lieber ausdrücklich auszuprogrammieren. Das sieht manchmal hölzern aus, verschwendet mitunter auch Resourcen und Taktzyklen, aber ist zehnmal besser portierbar- vor allem Teile und Module des Codes und dies obwohl es vorher nicht geplant war, weil das Projekt noch gar nicht zu erkennen war. >lernt man das an der UNI? Bei uns durchaus. Wir haben in der VL Softwaredesign sog. Designstudien angefertigt zu genau diesen Themen. U.a. mit o.g. Ergebnissen! Optimierbarkeit, Portierbarkeit und Validierbarkeit unter Beachtung von Standards sind heute Gegenstand von Forschung. Da gibt es noch viel zu tun!
Wenn man mal rechnet, dass wenigstens 50% des Studiums fachspezifisch ist (auch der Elektriker studiert ja Physik und Mathe und Grundlagen) dan hat einer immerhin über 2000 Lernstunden Vorsprung gegenüber einem anderen Fachgebiet, den es erstmal aufzuholen gälte. Das sind im Beruf, wenn man nicht nur lernen will, schon einige Jahre. Kommt halt darauf an, was einem fehlt. Es gibt dabei aber noch eine andere Komponente: Warum stellen Firmen denn jemanden an eine Arbeit dran, wenn er wenig Kompetenzen hat und nicht die richtige Ausbildung? Letztlich zahlen die Firmen nicht gerne für Inkompetenz sondern schreien ja den ganzen Tag nach praktischer, also ergebnisorientierter Ausbildung.
Lothar Miller schrieb: > Ein FPGA braucht sowieso keinen Reset. Das hat nach Anlegen der Spannung > loszulaufen und so lange seine Arbeit zu verrichten, bis die Spannung > wieder weggenommen wird. Ein Reset kommt in dieser Aufgabenbeschreibung > nicht vor. Nicht immer von Xilinx auf alle anderen Hersteller schließen. Wenn ich zB einen PCI-Core im FPGA habe, wird der PCI-Reset natürlich verwendet. Außerdem gibt es auch Synthesewerkzeuge und FPGAs, denen man keinen Initialwert für Signale im Code mitgeben kann bei der Signaldefinition, die müssen dann quasi sowieso noch in einen definierten Zustand, also "resettet" werden.
Und genau das kann man am Einfachsten synchron machen. Auch bei Asics ist es nicht wirklich nötig, unbedingt asynchron zu arbeiten.
Torsten M. schrieb: > wird der PCI-Reset natürlich verwendet. Latürnich wird er verwendet. Ohne jede Frage... :-/ Nur: ist er auch nötig und wo ist er sinnvoll? > Außerdem gibt es auch Synthesewerkzeuge und FPGAs, denen man keinen > Initialwert für Signale im Code mitgeben kann bei der Signaldefinition, Die sind aber schon älter oder von Actel... > die müssen dann quasi sowieso noch in einen definierten Zustand, also > "resettet" werden. Auf jeden Fall wird bei jedem SRAM-basierten FPGA (und mittlerweile auch den meisten CPLDs) beim Laden jedes Flipflop per Handschlag auf einen definierten Wert gesetzt. Und alle aktuellen Synthesizer können diese Möglichkeit der Initialisierung verwenden (wenn die Hardware es hergibt). Diese Initialisierung ist ganz einfach eine Ressource auf dem FPGA wie z.B. ein Multiplizierer oder ein RAM. Und die verwendest du doch auch, wenn es dir Vorteile bringt. Oder nicht? > Nicht immer von Xilinx auf alle anderen Hersteller schließen. BTW: Lattice kann die Initialisierungswerte jetzt auch, seit sie den Synthesizer gewechselt haben.
Lothar Miller schrieb: > Die sind aber schon älter oder von Actel... Treffer (Actel) ;-) Damit erübrigt sich auch die Verwendung von irgendwelchen HW-Einheiten (außer BRAMs), weil keine vorhanden sind, außer ein 1kbit User-Flash, den ich aber nicht benötige, weil er viel zu klein ist :-(
Also halten wir mal fest, dass es bei manchen FPGAs nötig sein könnte, Resets und Inits anders zu formulieren. Damit ergibt sich die Notwengikeit einen herstellerabhängigen Teil und einen unabhängigen Teil des Designs zu definieren, womit wir wieder beim Thema *strukturiertes VHDL* wären. Wird bei euch sowas regelmäßig gemacht?
Wenn nur FPGAs eines einzigen Herstellers eingesetzt werden, ergibt sich nicht die Notwendigkeit, herstellerunabhängigen Code zu Schreiben. Was nichts daran ändert, dass, bis auf die BRAMs und die oben angesprochenen Resets, der von mir "verbrochene" Code auch auf FPGAs anderer Hersteller laufen dürfte. Strukturiertes Design heißt für mich eher, dass man das Design zB in kleine, überschaubare Funktionseinheiten aufteilt, diese modular, lesbar und verständlich beschreibt und dann in überliegenden Einheiten miteinander verbindet. Dass man diese einzelnen Einheiten nach Möglichkeit ausgiebig mit jeweils einer eigenen Verifikationsumgebung im Simulator testet. Dass man die Einheiten alle mit einem gleichartigem Portprotokoll ausstattet, damit man sie schnell und unkompliziert zusammenstöpseln kann. Usw. usf ...
Torsten M. schrieb: > Lothar Miller schrieb: >> Die sind aber schon älter oder von Actel... > Treffer (Actel) ;-) Also Microsemi... http://www.actel.com/company/acquisition/ Bin gespannt, was daraus noch wird.
> Wenn nur FPGAs eines einzigen Herstellers eingesetzt werden, > ergibt sich nicht die Notwendigkeit, herstellerunabhängigen Code > zu Schreiben. Das ist natürlich sehr geistreich gedacht. Wenn man nur Bananenbrei kochen will braucht man dann folglich auch keine Sortiermöglichkeit nach Obstsorten. Der Punkt ist nur der, dass man nie weiss, womit man in 3 Jahren arbeitet.
Lothar Miller schrieb: > Also Microsemi... > http://www.actel.com/company/acquisition/ > Bin gespannt, was daraus noch wird. Wir hatten letztens einen leitenden Ingenieur von Microsemi da, und was er vorgestellt hat, sah sehr vielversprechend aus. Vieles schon als HW integriert von dem, womit wir uns heute noch in VHDL und als Softcore herumschlagen müssen. Das ging viel weiter, als ich erwartet hatte :-) Berater schrieb: > Der Punkt ist nur der, dass man nie weiss, womit man in 3 Jahren > arbeitet. Und was, wenn man das schon weiß? Außerdem sind die Teile, die herstellerspezifisch sind, größtenteils IP-Cores und so nicht zu ändern, weil auf den FPGA angepasst ...
Torsten M. schrieb: > Berater schrieb: >> Der Punkt ist nur der, dass man nie weiss, womit man in 3 Jahren >> arbeitet. > > Und was, wenn man das schon weiß? Außerdem sind die Teile, die > herstellerspezifisch sind, größtenteils IP-Cores und so nicht zu ändern, > weil auf den FPGA angepasst ... Ich denke auch, dass es heutzutage kein einziges FPGA Design geben kann, das wirklich Hersteller unabhängig sein kann. Jedes Design in unserer Firma verwendet DCMs, Fifos aus dem Core Generator usw. und es wäre wirklich unsinnig darauf zu verzichten. Wichtig ist, so wie Du geschrieben hast, eine Struktur des Designs, bei der man anzupassende Details leicht identifizieren kann. Meine Sorge bei den benutzten Designs ist aber nicht die Portierbarkeit, sondern die Wartbarkeit. Es ist viel wahrscheinlicher dass jemand anderer ein bestehendes Design warten und verstehen muss, als dass ich es von Xilinx auf z.B. Altera migrieren muss. Letztendlich aber hilft eine vernünftige Struktur bei beidem. Ob man aber einem Programmierer oder Ingenieur wirklich beibringen kann, eine Struktur ins Programm zu bringen, bezweifle ich ein bischen. Ich glaube, da ist vieles Talent, so wie ein Zeichentalent. Der eine hat's, der andere nicht ...
> kein einziges FPGA Design ... wirklich Hersteller unabhängig Naja, man kann schon mal die RAMs und die IOs kapseln, damit man einzelne wrapper tauschen muss und kann. Auch sollten state machines in eigene design files. Besonders wichtig ist die Trennung bon Prozessen und Verschaltung. Alles, was Komponenten verschaltet bitte in ein design, was Signale modifiziert, in ein anderes. >Ob man aber einem Programmierer oder Ingenieur wirklich beibringen kann Kann man, kann man! Bei uns haben einige gespukt, gesehen, gelernt, gemurrt und gejammert, aber o ganz allmählich gelernt, die Vorzüge zu geniessen. Aber es muss von der Designleitung, dem QM und der Entwicklungsabteilungen kommen. An den Hochschulen wird es offenbar kaum gemacht. Wieso auch, der Prof hat meistens nie industrielle SW gemacht.
> Alles, was Komponenten verschaltet bitte in ein > design, was Signale modifiziert, in ein anderes. Super, das ist genau die Art von §$%&-Coding Style, der die Xilinx-IP-Cores so absolut undurchschaubar macht. Wenn man das wie Xilinx noch mit nichtsagenden quasi-automatisch-generierten Kommentaren verbindet, hat man also Code in "Industriequalität".
> Alles, was Komponenten verschaltet bitte in ein design,
Das ist aber Standard. Das eine ist Struktur, das andere Funktion. Die
Struktur kann man in ein grafisches Design überführen, oder aus einem
solchen beziehen.
ich denke, es ist auch nicht die aufgabe der hochschule, solche sachen zu lehren. das ist viel zu kompliziert, um es den studenten beizubringen
lotte schrieb: > ich denke, es ist auch nicht die aufgabe der hochschule Die der Baumschule vielleicht, oder der Fahrschule, oder wie oder was? > das ist viel zu kompliziert, um es den studenten beizubringen Ich hoffe zuversichtlich, das war ironisch gemeint! Allerdings fehlt dann ein Augenzwinkern... :-/ Junge Leute, die voll "im Saft stehen" sollten so was eigentlich aufsaugen können wie ein Schwamm. Später im Berufsleben wird so ein Lernprozess mindestens um den Faktor 4 verlangsamt, weil man ja noch was anderes machen sollte... Und wenn sie das schon als Student nicht kapieren, dann taugen sie auch nicht als Ingenieur (und da können einige wenige Ausnahmen bestenfalls die Regel bestätigen). Was Hänschen nicht lernt, lernt Hans nimmermehr. Stimmt zwar nicht ganz, aber Hans tut sich recht schwer.
>BTW: Lattice kann die Initialisierungswerte jetzt auch, seit sie den >Synthesizer gewechselt haben. Diese Aussage ist nicht richtig. Lattice gibt keine Garantie dafür, dass Initialisierungswerte nach jedem Power-Up greifen. VG, IsKlar
> Junge Leute, die voll "im Saft stehen" sollten so was > eigentlich aufsaugen können wie ein Schwamm. Das wollte ich aber acuh gesagt haben!!! Wo denn, wenn nicht in der Uni lernt man die komplexen Dinge? > Später im Berufsleben wird so ein Lernprozess mindestens um > den Faktor 4 verlangsamt, weil man ja noch was anderes Wenn man überhaupt Zeit hat / bekommt, zu lernen. Und dann müsste es ja auch noch einen geben, von dem man das Lernen kann. Also braucht es wieder ein VHDL-Training.
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.