Hallo zusammen, ich habe das Thema "Realisierung eines Video-Decoder (nach Wahl) auf Xilinx-FPGA unter Verwendung von NoC Kommunikation" für meine Bachelorarbeit erhalten. Letzte drei Wochen habe ich mich mit der FPGA-Welt und VHDL beschäftigt, sodass ich jetzt einige Vorkenntnisse habe. Leider bin ich aber mit Videokodierung und -dekodierung nicht vertraut. Meine Frage wäre, ob es hier jemanden gibt, der sich schonmal mit der Realisierung eines Dekoders mit FPGA beschäftigt hat. Wie soll ich da vorgehen? Welchen Dekoder muss ich am besten auswählen? Welche Literatur oder Links würdet ihr mir empfehlen? Für jede Rückmeldung würde ich euch sehr dankbar sein! Schöne Grüße Usam
:
Bearbeitet durch User
Versuch dein Vorhaben nochmal genauer zu beschreiben.. Welches Kodierungsverfahren? Welcher Durchsatz soll angestrebt werden? Wo kommt dein Stream her? Wo geht er hin? (Sink/Source)
:
Bearbeitet durch User
Also für eine Bachelorarbeit ist das meiner Meinung nach in der kurzen Zeit ohne sehr viel Vorwissen nicht machbar. Ausnahme vielleicht wenn Du das nur in dem Text schreiben aber nicht in Hardware umsetzen musst. Also es Deine Aufgabe ist grundsätzlich in der Arbeit Vor- und Nachteile vom FPGA und grobe Dinge zum Videodecoding zu erzählen.
Motion JPEG könntest Du im Rahmen einer BA Arbeit schaffen. Schau Dir das mal an. (fast) alle anderen Videocodes sind Weiternetwicklungen mit Bewegungs oder Objekterkennung und und und. Hab so einen Codec mal vor Jahren auf nem Altera FPGA gemacht. Les dich ein in JPEG, DCT und vor allem gibt es bei DCT optimierte Verfahren, die dann sehr sehr einfach in nem FPGA realisiert werden können. (Namen fällt mir grad nicht mehr ein). Gibt viele Papers dazu.
>vor allem gibt es bei DCT optimierte >Verfahren, die dann sehr sehr einfach in nem FPGA realisiert werden >können. http://www.wseas.us/e-library/conferences/austria2004/papers/482-293.pdf
Nohchi V. schrieb: > Hallo zusammen, > > ich habe das Thema "Realisierung eines Video-Decoder (nach Wahl) auf > Xilinx-FPGA unter Verwendung von NoC Kommunikation" für meine > Bachelorarbeit erhalten. Schau mal bei Opencores unter video controller: http://opencores.org/projects Gustl B. schrieb: > Also für eine Bachelorarbeit ist das meiner Meinung nach in der kurzen > Zeit ohne sehr viel Vorwissen nicht machbar. Zustimmung. MfG,
coodec schrieb: > Motion JPEG könntest Du im Rahmen einer BA Arbeit schaffen. > Schau Dir das mal an. > Schon alleine einen robusten JPEG-Codec zu bauen, braucht min. 3 Monate, wenn mans in pur VHDL oder Verilog macht/testen muss, dauerts min. 1.5x länger. Bevor du dir hier Rat holst und dir zig Leute was unterschiedliches erzählen, würde ich erst mal schauen: a) Wer betreut mich dabei, und was kann mir derjenige beibringen b) Was ist bereits an Framework vorhanden Dabei ist auch zu beachten, dass manche Dozenten eine Menge Ideen haben und die Messlatte zu hoch stecken, so dass man sich als ambitionierter Student gerne verheizt oder die Frustration gross wird, wenn es nicht klappt. Vom akademischen Standpunkt her würde ich mir am ehesten noch h264 raussuchen (da gibts von Zexia einen netten Codec) und mich auf ein P-Frame-Prediction-Modul fokussieren. Den hardh264 in die Simulation zu stopfen, ist übrigens auch recht spannend (Stichworte GHDL und Cosimulation). Die Codec-Sache wird grade im Rahmen der GSOC von einigen Studenten auf der Basis von MyHDL angegangen. Vielleicht inspiriert das ja. Gruss, - Strubi
> Bachelorarbeit erhalten. Letzte drei Wochen habe ich mich mit der > FPGA-Welt und VHDL beschäftigt, sodass ich jetzt einige Vorkenntnisse > habe. Leider bin ich aber mit Videokodierung und -dekodierung nicht > vertraut. drei Wochen FPGA!!! Keine Change > Meine Frage wäre, ob es hier jemanden gibt, der sich schonmal mit der > Realisierung eines Dekoders mit FPGA beschäftigt hat. Ja. > Wie soll ich da vorgehen? Welchen Dekoder muss ich am besten auswählen? > Welche Literatur oder Links würdet ihr mir empfehlen? Versuche erst einmal einen einfachen Punkt an der richtigen Stelle auf dem Bildschirm aus zugeben. Da nach einen Buchstaben.
Strubi schrieb: > Dabei ist auch zu beachten, dass manche Dozenten eine Menge Ideen haben > und die Messlatte zu hoch stecken, so dass man sich als ambitionierter > Student gerne verheizt oder die Frustration gross wird, wenn es nicht > klappt. Das will ich meinen! Die Projekte werden immer komplexer und dabei werden die Grundlagen übergangen. Am Ende kommt wieder etwas raus, was nach einem enormen Projekt aussieht, aber nicht verwendbar ist, weil es nicht effizient, nicht normengerecht oder sonst wie am Bedarf vorbei entwickelt wurde. Warum bringt man den Studenten nicht einfach mal bei, ein einfaches Projekt zu machen, dass sie selber im Griff haben und ihrem Kenntnisstand entspricht, wo sie nicht erst das gesamte Internet durchforsten müssen, um eine Idee zu bekommen, wie sie starten können. Wichtiger, als aufgeblasene Projekte wäre ein geordneter Arbeitsstil mit einem Konzept, einer Anforderungspezifikation und einer Darlegung der möglichen Realisierungen mit "Für" und "Wider", eine Realisationsstrategie, einer Teststrategie und einer soliden Umsetzung des Projektes mit einem sinnvollen time management. DAS wäre es, was Absolventen für die Industrie qualifiziert. Wenn er irgendwo anfängt, baut er keinen ansprochsvollen Decoder zurecht sondern wird erstmal mit einfachen Aufgaben betraut, die aber perfekt mit anderen verzahlt werden müssen. Von daher wäre das Erlernen eines kompatiblen Artbeitstils, wie er heute in der Industrie angewendet wird, wichtiger, als tolle Inhalte. > Vom akademischen Standpunkt her würde ich mir am ehesten noch h264 > raussuchen Machen denn BA-Ansolventen später akademische Projekte? Diese Überlegung wäre wohl eher etwas für den Master oder die Dissertation. Da haben wir aber das Problem, dass schon bei der BA Thesis "akademisch" = nichtindustriellbastelnd gearbeitet wurde und dann die Arbeitstechnik auf die Masterzeit übernommen wird. Damit entfernt man sich immer mehr von dem, was heute gesucht ist. So langsam verstehe ich die Kritik vieler Firmen an den Fähigkeiten der Absolventen.
Ich denke es geht eher um die Decodierung eines CVBS oder PAL Signals. Das sollte machbar sein. Alles andere was irgendwie mit JPEG oder gar MP4 zu tun hat -> imho in der Zeit unmöglich.
Manuel K. schrieb: > Ich denke es geht eher um die Decodierung eines CVBS oder PAL Signals. Ein bekannter hatte vor 15 Jahren einen Macrovision decoder mit CPLD als Bac Abschluß realisiert. Scheint mir aber a bisserl billig für eine Abschlussarbeit. http://www.xedox.de/elektronik/macrovision/index.php
LM 1881 ist doch "nicht viel mehr" als ein Komparator und ein paar Monoflops.
Gustl B. schrieb: > Also für eine Bachelorarbeit ist das meiner Meinung nach in der kurzen > Zeit ohne sehr viel Vorwissen nicht machbar. Ich würde mir als Betreuer nicht trauen, so ein Thema an einen unerfahrenen Aspiranten zu vergeben. Auch wenn der sich immerhin schon 3 Wochen "eingearbeitet" hat. Oder einfach andersrum: ich kenne VHDL und FPGAs schon lange und werde trotzdem noch oft genug überrascht... Strubi schrieb: > Schon alleine einen robusten JPEG-Codec zu bauen, braucht min. 3 Monate, > wenn mans in pur VHDL oder Verilog macht/testen muss, dauerts min. 1.5x > länger. Im ersten Schritt klicken sich die Burschen das im Matlab einfach mal zusammen. Interessant wird es dann, wenn dann die Implementierung "ziemlich gut" und "eigentlich fast immer" läuft. Das ist dann das Stadium, wo die unstrukturierte Fehlersuche beginnt, weil sich der Betreuer auch nicht mehr auskennt. Markus W. schrieb: > Die Projekte werden immer komplexer und dabei werden die Grundlagen > übergangen. Es wird oft auf etwas "aufgebaut", was schon die letzten beiden Bacheloranden nur zu 80% fertig bekommen haben. Und lustigerweise geht es dann auf den fehlerhaften 20% weiter... Nohchi V. schrieb: > Letzte drei Wochen habe ich mich mit der FPGA-Welt und VHDL > beschäftigt, sodass ich jetzt einige Vorkenntnisse habe. Welches Vorwissen hast du? Theoretisch? Praktisch? Toolchain? > Für jede Rückmeldung würde ich euch sehr dankbar sein! Kannst du dir noch eine andere Arbeit aussuchen? Eine, für die du schon fundiertes Wissen hast?
Markus W. schrieb: > Wie wurde denn damals der LM 1881 in VHDL gemcht? An Details kann ich mich leider nicht erinnern, der Bekannte sprach von Mitzählen der Syncs und "auf Null ziehen" des Signals. Wenn ich die Beschreibung des Macrovision-systems auf http://cs.stanford.edu/people/eroberts/cs181/projects/1999-00/dmca-2k/macrovision.html richtig interpretiere. genügt es wohl die Zeilen mit dem Videosignal unverändert zu übetragen und für die Zeilen ausserhalb des sichtbaren Bereichs nachzugenerieren so dass das "Kopierschutzsignal" entfernt wird. Die Schaltung enstammt nicht der Abschlussarbeit, die hab ich nur verlinkt um die Komplexität diese Codierung darzustellen. Und ein bißchen Analogkram wird auf der Platine auch gewesen sein. Schwerpunkt der Arbeit war wohl die Entwcklung der Platine (Schematic,Layout,Inbetriebnahme). MfG,
> ich habe das Thema "Realisierung eines Video-Decoder (nach Wahl) auf > Xilinx-FPGA unter Verwendung von NoC Kommunikation" Wenn dort irgendetwas in Richtung MPEG oder JPEG gemeint ist, kannst du dir den Strick nehmen. Der Prof sollte nach Afghanistan ausgewiesen werden.
Selbst an einem FBAS zu irgendetwas wirst du in der vorgebenen Zeit und deinem Vorwissen (bitte nicht als Herabwürdigung verstehen) rein garnichts auf die Reihe bekommen.
René D. schrieb: > drei Wochen FPGA!!! Keine Change > Muss man die ganze Funktionalität vom Dekoder vom Anfang an selbst in VHDL implementieren oder kann man für die bestimmten Kompontenten, z.B. variable Längenkodierung, inverses Abtasten, inverse Quantisierung usw., schon bereits implementierte VHDL-Lösungen finden? >> Meine Frage wäre, ob es hier jemanden gibt, der sich schonmal mit der >> Realisierung eines Dekoders mit FPGA beschäftigt hat. > > Ja. > Was für einen Dekoder war denn das? Wie langen hat es bei dir gedauert? Hattest du schon vorher solide Kenntnisse für so eine Arbeit? Ich habe die Arbeit noch nicht aufgenommen und angemeldet. Man kann auch eigene Vorschläge zum Thema machen, oder ein alternatives Thema anbieten. Welche Fragen sollte ich erstmal unbedingt bei meinem Betreuer (ist kein Prof. oder Dr., sondern ein Dipl.Ing) klären, bevor ich das Thema akzeptiere. Oder wäre auch ein ähnliches Thema, was weniger anspruchsvoll ist, möglich? Grüße Usam
Ich habe jetzt in meiner oberen Antwort nur den User "dose" zittert und ihm beantwortet. Aber die ihm gestellten Fragen würde ich an allen Benutzern adressieren, die sich hier gemeldet haben. Vielen Dank im Voraus! Schöne Grüße Usam
:
Bearbeitet durch User
Nohchi V. schrieb: > Realisierung eines Video-Decoder (nach Wahl) auf > Xilinx-FPGA unter Verwendung von NoC Kommunikation Wenn ich mir das Thema so anschaue, würde ich sagen, der Schwerpunkt liegt absolut auf "NoC Kommunikation". "Xilinx-FPGA" steht da nur drin, weil halt die zugehörige Infrastruktur (Boards, Tools, etc.) schon vorhanden ist und welcher Video-Decoder eingesetzt wird, ist ja auch egal. Meiner Meinung nach sollte es reichen einen existierenden (freien) (M)JPEG-Decoder sinnvoll zu partitionieren und auf eine geeignete NoC-Architektur aufzuteilen. Vielleicht reicht es aber auch schon, den Decoder als "Black Box" zu betrachten und in eine zu erstellende NoC-Architektur einzubinden - also anbindung von Quelle(n) und Senke(n) per NoC.
mh schrieb: > Wenn ich mir das Thema so anschaue, würde ich sagen, der Schwerpunkt > liegt absolut auf "NoC Kommunikation". > Die NoC-Arichtektur ist bereits vorhanden. Das Thema bauet sich auf einem bereits implementierenden Projekt auf. Im Projekt wurde eine Hardware-Lösung in form von einem Router, Routingtabellen und noch einem Protokoll implementiert. Jeder Router im Netz besitzt genau vier Kommunikationskanäle um mit seinen Nachbarn Daten austauschen zu können. Der Hardwarerouter besitzt noch einen zusätzlichen Kanal, um mit dem angeschlossenen Microblaze kommunizieren zu können. Quellcode und all notwendigen Dateien zur Integration des Routers ins Xilinx Platform Studio sind auch vorhanden. >welcher Video-Decoder eingesetzt wird, ist ja auch egal. > Welcher wäre für mich als Neulinge in diesem Bereich gut geeignet? > Meiner Meinung nach sollte es reichen einen existierenden (freien) >(M)JPEG-Decoder sinnvoll zu partitionieren und auf eine geeignete > NoC-Architektur aufzuteilen. Das ist auch der Sinn von meinem Thema. Die NoC-Infraktur wurde entwickelt und ich muss jetzt diese anwenden. In meinem Fall wäre es die Aufteilung des Dekoders in die Komponenten, sodass diese dann durch die MicroRouters ihre Daten austauschen, wenn ich überhaupt richtig verstanden habe:) Grüße Usam
:
Bearbeitet durch User
Da du mich direkt erwähnst, muss ich dir auch antworten. >> drei Wochen FPGA!!! Keine Change >> > Muss man die ganze Funktionalität vom Dekoder vom Anfang an selbst in > VHDL implementieren oder kann man für die bestimmten Kompontenten, z.B. > variable Längenkodierung, inverses Abtasten, inverse Quantisierung usw., > schon bereits implementierte VHDL-Lösungen finden? Farbraumtransformation ,IDCT (Cosimustransformation), Bildkacheln zusammenschieben, Dastenstromkontrolle Labels im Datenstrom erkennen nicht ganz vergessen Und dann muss alles zusammenspielen. VHDL Sourcequelle sind sehr schwer zufinden. Und dann muss das alles noch in dein System passen mit Busbreiten, und Taktzyklen. Handshaking. Lizenzrechte auch nicht ganz vergessen. > Was für einen Dekoder war denn das? Wie langen hat es bei dir gedauert? > Hattest du schon vorher solide Kenntnisse für so eine Arbeit? Ich habe den Huffman decoder speziell für JPG geschrieben. Der ist auch im Netz zu finden.Wie lange ich dafür gebraucht habe kann ich nicht mehr sagen. Ich kann dir aber aus Erfahrung sagen, so als Faustformel: Ein Problem in VHDL zu lösen dauert ungefähr 10 mal länger als in Software. Ja, ich hatte vorher Digitaltechnik intensiv betrieben. Und auch VHDL für andere Zwecke genutzt. Für Video war es das erste mal. Video ist eine zweidimensionale Mathematik. Das Projekt lebt und stribt auch wie fit du in VHDL-Simulationstechniken bist. > Ich habe die Arbeit noch nicht aufgenommen und angemeldet. Man kann auch > eigene Vorschläge zum Thema machen, oder ein alternatives Thema > anbieten. > Welche Fragen sollte ich erstmal unbedingt bei meinem Betreuer (ist kein > Prof. oder Dr., sondern ein Dipl.Ing) klären, bevor ich das Thema > akzeptiere. Oder wäre auch ein ähnliches Thema, was weniger > anspruchsvoll ist, möglich?
Nohchi V. schrieb: > Welcher wäre für mich als Neulinge in diesem Bereich gut geeignet? Wie geschrieben würde ich auf MJPEG setzen, der sollte der Einfachste sein, da eben "nur" die Einzelbilder JPEG komprimiert werden. Bei den verschiedenen MPEGs geschieht die Kompression über mehrere Bilder, die Kompression benötigt also ein Gedächtnis. Ein Startpunkt wäre hier: http://opencores.org/project,mjpeg-decoder Da ist sogar gleich die Abhandlung als PDF mit dabei...
Moin, > > Wie geschrieben würde ich auf MJPEG setzen, der sollte der Einfachste > sein, da eben "nur" die Einzelbilder JPEG komprimiert werden. Bei den > verschiedenen MPEGs geschieht die Kompression über mehrere Bilder, die > Kompression benötigt also ein Gedächtnis. MJPEG würde ich nur nicht in purer Hard-Logik (Statemachine) machen. Aber da der TO ja bereits offenbar auf ein NOC Framework aufsetzen kann, ist es ev. mit einem cleveren Encoder-Design möglich, die Sache schritteise die Loop zu stecken, d.h. Softcore schmeisst faktisch nur rechtzeitig die DMA-Streams für den JPEG-Decoder an und verarbeitet die JPEG-Header. Für die dazu etwa äquivalente Encoderlösung habe ich ca. 3 Monate gebraucht, aber dabei gehörig tricksen müssen, in pur VHDL braucht das doppelt so lang. Allerdings könnte man den Ansatz in einem Mehrkern-SoC hochskalieren, z.B. erst mal Quantizer und eine Hard-DCT in die Soft-Routine reinschleifen (wie hier angerissen: http://tech.section5.ch/news/?p=181). Den Anspruch an eine Full-HD-Streaming-Lösung sollte man aber dabei nicht stellen, es gibt da einige Flaschenhälse zu lösen, die viel Zeit kosten. Läuft dann also wohl eher auf einen JPEG-Beschleuniger als richtigen Encoder raus. Grüsse, - Strubi
Lothar M. schrieb: > Es wird oft auf etwas "aufgebaut", was schon die letzten beiden > Bacheloranden nur zu 80% fertig bekommen haben. Und lustigerweise geht > es dann auf den fehlerhaften 20% weiter... oder es wird die Aufgabe gesteigert, weil der vorherige Bachelorant es (mit Hilfe von Foren, Kollegen und Geld) zu leicht und zu schnell fertig bekommen hat. Ich bekomme so rund 3 Anfragen im Monat an mein Ingenieurbüro, ob ich nicht gegen Bezahlung jemandem bei seiner VHDL-Arbeit helfen kann. Offenbar greift es immer mehr um sich, dass man sich die Leistung kauft, statt sie sich durch Lernen selber zu erarbeiten. Ich bin da nun mal drauf eingegangen: Es handelte sich um eine Dame mit reichem Papi, die Elektrotechnik studiert und sozusagen "Nachhilfe" haben wollte. Konkret musste das Projekt in 6 Wochen statt der eigentlich noch zur Verfügung stehenden 10 Wochen abgehandelt werden, weil die Dame mittendrin noch 3 Wochen in die USA auf Urlaub wollte. Es wäre also darauf hinausgelaufen, dass ich die Sachen im Wesentlichen mache, zumindeste den qualitativen Anteil. Abgesehen davon, daß es mir etwas widerstrebt, beim Betrügen zu helfen, wären 4 Wochen Ingenieursstunden dann auch dem reichen Papi etwas zuviel gewesen. Ich gehe davon aus, dass das nun ein anderer Studi macht und sich ein paar Tausender verdient. So langsam wird mir klar, woher die ganzen großartigen Projekte kommen, die manche (speziell Damen) auf ihrem Xing-Profil haben, wenn sie als Frischlinge in Firmen einsteigen und Karriere machen. Da wirkt ein "FPGA-gesteuertes Automatisierungsystem für XXX" sicher sehr repräsentativ. Weiß ja niemand, daß es Kaufwissen ist, wenn man dann als Juniorprojektleiterin einsteigt.
Moin, >> Es wird oft auf etwas "aufgebaut", was schon die letzten beiden >> Bacheloranden nur zu 80% fertig bekommen haben. Und lustigerweise geht >> es dann auf den fehlerhaften 20% weiter... > oder es wird die Aufgabe gesteigert, weil der vorherige Bachelorant es > (mit Hilfe von Foren, Kollegen und Geld) zu leicht und zu schnell fertig > bekommen hat. > > Ich bekomme so rund 3 Anfragen im Monat an mein Ingenieurbüro, ob ich > nicht gegen Bezahlung jemandem bei seiner VHDL-Arbeit helfen kann. > Offenbar greift es immer mehr um sich, dass man sich die Leistung kauft, > statt sie sich durch Lernen selber zu erarbeiten. > Dann bin ich wohl nicht der einzige, der das Gefühl hat, dass sich diese Tendenz verstärkt. Vor 10 Jahren waren noch Anfragen wie "please Sir, help me to write an mp3-Encoder" normal in den Foren, aber sie kamen immerhin weniger aus dem europäischen Raum. Unsere letzte Bildungsdeform scheint das nun auch zu ändern. > > So langsam wird mir klar, woher die ganzen großartigen Projekte kommen, > die manche (speziell Damen) auf ihrem Xing-Profil haben, wenn sie als > Frischlinge in Firmen einsteigen und Karriere machen. Da wirkt ein > "FPGA-gesteuertes Automatisierungsystem für XXX" sicher sehr > repräsentativ. Weiß ja niemand, daß es Kaufwissen ist, wenn man dann als > Juniorprojektleiterin einsteigt. Das wird langsam echt zu einem Problem in der hiesigen Hightech-Branche. Ich bin das letzte Jahr bei einigen hochgejubelten Technologieträgern auf derart hochstapelnde Vertreter der nichtproduktiven Kaste gestossen, dass ich mich frage, wie man hierzulande den Traum vom kreativen Silicon Valley (ist es dort überhaupt noch so wie damals?) realisieren will, wenn sich die HR-Abteilung nur noch auf Linkedin- und Xing-Überfliegerprofile fixiert. Früher dachte ich noch, dass sich das Problem spätestens nach der Probezeit von selber löst. Leider ist es inzwischen so, dass Firmen, die einer unflexiblen Management-Matrix huldigen, ihren HR-Fehler selten erkennen. Das beste ist dann, dass die Protagonisten, deren Engineering-Karriere man eigentlich als "gescheitert" deklarieren müsste, im Management oder HR (noch schlimmer, dann stellen sie nämlich ihresgleichen ein) munter weiterwursteln dürfen. Wenn es dann kracht, macht mich mein insgeheimes "I told you so" auch nicht wirklich glücklich - schade um die Technologie. Und der amerikanische Eigner sagt dann: Ach, die kriegen das in Europa halt einfach nicht so hin wie wir. So, mein Wochenend-Rant gehört aber eigentlich nicht zum Thema.. Grüsse, - Strubi
Schlimmer noch: Die XING und Linked-In Dampfplauderer, die Du ansprichst, haben inzwischen die Mehrheit in den Firmen und akzeptieren vermehrt nur noch Ihresgleichen. Wenn dann da jemand mit tatsächlichem Wissen reinkomt, dann kriegen sie schnell Angst und drängen einen raus. Leistungsfähige Ingenieure sind nur nach als externe Dienstleister gefragt.
Nohchi V. schrieb: > Welche Fragen sollte ich erstmal unbedingt bei meinem Betreuer (ist kein > Prof. oder Dr., sondern ein Dipl.Ing) klären, bevor ich das Thema > akzeptiere. Ich würde ihm diesen Thread zeigen. Die einzige Frage, die du dann noch stellen musst ist: "Glauben Sie immer noch, dass ich in der Lage bin, halbwegs selbstständig eine Bachelorarbeit durchzuführen?"
Jan schrieb: > Ich würde ihm diesen Thread zeigen. Die einzige Frage, die du dann noch > stellen musst ist: "Glauben Sie immer noch, dass ich in der Lage bin, > halbwegs selbstständig eine Bachelorarbeit durchzuführen?" Ich weiß nicht so recht. Jeder Diplomand, egal ob Bachelor oder Master, sollte wissen, was er sich zutraut und eine Arbeit nur nach einer ausreichenden Sichtung annehmen.
Strubi schrieb: > Das wird langsam echt zu einem Problem in der hiesigen Hightech-Branche. Das kommt auf die Sichtweise an. Für die Etabierten in den Firmen und der Branche ist das weniger ein Problem, weil sie benötigt werden. Wenn die Dampfplauderer ein Projekt wieder mal so richtig schön an die Wand gefahren haben, kommt der Feuerwehrmann und repariert kostenpflichtig. Ich meine, es ist doch eine durchaus akzeptabel Strategie, preisgünstige Projektleiter und ebenso unerfahrene Entwickler zu beschäftigen und nur dann, wenn es mal schief geht, einen teueren zu holen, der nacharbeitet.
In einer ehemaligen Firma wurde ein solche MPEG-L2 Decoder in einem FPGA realisiert, geprototyped und in einen ASIC verfrachtet. Dauer 5 Monate mit 4 Personen, rund 30% Auslastung. Wenn es einer machen sollte und wir nehmen mal nur den FPGA, sehe Ich da >6 Monate Arbeit, bis es 100% stabil läuft. Markus W. schrieb: > Warum bringt man den Studenten nicht einfach mal bei, ein einfaches > Projekt zu machen, dass sie selber im Griff haben und ihrem > Kenntnisstand entspricht, wo sie nicht erst das gesamte Internet > durchforsten müssen, um eine Idee zu bekommen, wie sie starten können. Weil die Universitäten sich gegenseitig mit hochkarätigen Absolventen und Projekten überbieten, um als Eliteuni gelten zu können, denn nur dann gibt s richtig Geld!
Also ich persönlich erreichte erst mit 30+ Jahren eine brauchbare geistige Leistungsfähigkeit um diverse Projekte brauchbar angehen zu können. Warum sie wohl junge Leute so stressen ? Naja... vielleicht sind sie früher reif als ich :-)
Edi M. schrieb: > In einer ehemaligen Firma wurde ein solche MPEG-L2 Decoder in einem FPGA > realisiert, geprototyped und in einen ASIC verfrachtet. Dauer 5 Monate > mit 4 Personen, rund 30% Auslastung. Wenn es einer machen sollte und wir > nehmen mal nur den FPGA, sehe Ich da >6 Monate Arbeit, bis es 100% > stabil läuft. Hat du einen Tipp wie man die inverse Consinustransformation schreibt? Ich habe das mathematisch verstanden. Es gibt diverse Optimierungen, diese sind alle für eine CPU optimiert. Im FPGA kann man dafür eine spezielle Hardware bechreiben. Leider habe ich noch nicht den Ansatz es ordentliche zu beschreiben. Aktuell artet es in eine riesige Codeschreiberei aus. Weil VHDL einfach Sachen fehlen, um sich mehrfache Schreibarbeit zu ersparen.
Mein Tip: MyHDL und ein paar Dekoratoren, dann kann man die Rechnung quasi im HLS-Stil verfassen. In VHDL kann man es sonst auch als parallelisierten Mikrocode abstrahieren, dann ist es etwas kompakter und die Schreibarbeit muss man nur noch für die Vektor-MAC-Units machen. Lohnt aber nur, wenn man öfters verschiedene Transformationsrechnungen dieser Art machen muss.
Mich düngt, das Thema ist durch. Das halbe Jahr für die "bachelthese" ist rum.
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.