Hallo, Ich will (gerne) Meinungen und Kommentare über das Verwenden fertiger Komponenten erfahren -- Ich bin gerade ziemlich genervt vom Xilinx CoreGenerator. FYI: Ich kenne nur den Xilinx CoreGenerator. Die anderen Hersteller haben ganz sicher ähnliche Programme in ihrem Repertoire. Ich habe noch nie einen "Core" gekauft. Was ich sagen will: ich bin unerfahren. ;-) Der große Vorteil ist, dass die Komponenten auf die entsprechende Architektur maßgeschneidert sind und so eine optimale Implementierung garantiert ist. Ausserdem nimmt das natürlich viel Arbeit ab -- so es denn funktioniert. Bei selbst-implementierten Komponenten ist immer die Gefahr, dass die Synthese suboptimal arbeitet (ich denke nur an die Spezialitäten der verschiedenen FPGAs). Nachteilig ist, dass die Komponenten schwarze Kästen sind. Man muss "Vertrauen" (in diesem Fall) zu Xilinx haben, dass allerdings beim nächsten Absturz der ISE (mindestens) halbiert ist. Man begibt sich in eine Abhängigkeit. Die Komponentenbibliothek ist unvollständig und die bestehenden Komponenten passen leider nicht immer genau. Was mir z.B. gefällt sind die FP-Operationen, bei denen man die Bitbreite (relativ) frei wählen kann. Dummerweise unterstützen diese keine Fließbandverarbeitung (nur als Beispiel, ich werde keine FP-Operationen benötigen). Ich bin bei arithmetischen Operationen eher geneigt, eine fertige Komponente zu instanziieren, als einen VHDL-Operator (z.B. "+") zu verwenden. Da fühle ich mich wohler. Damit schränke ich aber die Möglichkeiten der Synthese ein. Mit dem Verwenden fertiger Komponenten bewegt sich die Entwicklungsmethode Richtung Makrozellenentwurf. Man instanziiert ein paar Komponenten, verdrahtet sie entsprechend, und voila, das Design steht... ganz so einfach ist es natürlich nicht. Der Punkt ist: die Entwicklungsmethode verändert sich. Habe ich einen Aspekt vergessen? Was bieten "CoreGeneratoren" anderer Hersteller? Wie findet ihr euch im "Core-Dschungel" zurecht? ... Mit der Zeit wird man wohl seine persöhnliche Komponentenbibliothek haben, auf die man sich verlassen kann. -- stefan
Überall wo man ohne Cores auskommt benutze ich auch keine. Die Synthese macht schon das richtige daraus. Wenn ich flexibilität möchte dann schreibe ich VHDL-Module die sich durch generics anpassen lassen. Die Synthese ist in der Lage zu erkennen, ob die Ressourcen des FPGA ausreichen, und versucht diese bestmöglich zu nutzen. Falls die Ressourcen nicht ausreichen, selber schreiben oder optimieren so weit es geht. Man sollte auch die zeitliche Komponente nicht vergessen. Alles was für mich mit einem beträchtlichen Arbeitsaufwand verbunden ist und der Coregenerator das passende Gegenstück zur Verfügung stellt nehme ich das vom Hersteller. Ich kenne bis jetzt nur den CoreGen von Xilinx und 99 % der Cores die ich benutze sind Fifos,Ram,Rom sämtlicher Ausführungen. >Die Komponentenbibliothek ist unvollständig und die bestehenden >Komponenten passen leider nicht immer genau. 100% Ackn, selber schreiben macht doch viel mehr Spaß >Mit dem Verwenden fertiger Komponenten bewegt sich die >Entwicklungsmethode Richtung Makrozellenentwurf. Man instanziiert ein >paar Komponenten, verdrahtet sie entsprechend, und voila, das Design >steht... ganz so einfach ist es natürlich nicht. Der Punkt ist: die >Entwicklungsmethode verändert sich. Die volle Kontrolle geht verloren, ich muss darauf vertrauen das die Komponente funktioniert. Wenn irgendwas nicht funktioniert ist es mir lieber ich habe den Fehler gemacht, alls blinde Kuh zu spielen, weil in der Simulation alles funktioniert und nach der Synthese nichts mehr.
Ich kenne die Xilinx Werkzeuge nicht. Bisher kam ich mit der schematischen Darstellung durch. Das Altera Tool, Quartus, erlaubt auch Komponenten zu verwenden, die mit einem Wizard konfiguriert werden. Bisher hatte ich noch keine Probleme. Wichtig ist allerdings eine Simulation vor dem Download. Ohne Simulation ist irgendwie eh nichts. Ploetzlich tauchen wieder Spikes in der Simulation auf, und die will man in der Realitaet nicht.
@ Stefan Hanke >Ich will (gerne) Meinungen und Kommentare über das Verwenden fertiger >Komponenten erfahren -- Ich bin gerade ziemlich genervt vom Xilinx >CoreGenerator. Man muss unterscheiden zwischen Bugs in Software und dem prinzipiellen Verfahren. >denn funktioniert. Bei selbst-implementierten Komponenten ist immer die >Gefahr, dass die Synthese suboptimal arbeitet (ich denke nur an die >Spezialitäten der verschiedenen FPGAs). Klar, man muss wissen was man tut. Bin ich Anfänger, muss ich wohl oder über davon ausgehen, dass die fertigen Module besser als selbstgestrickte arbeiten. Bin ich Profi, kann es anders herum sein. >Nachteilig ist, dass die Komponenten schwarze Kästen sind. Man muss Das ist der Sinn der Sache. Stichwort Abstrahierung, Kapselung. >"Vertrauen" (in diesem Fall) zu Xilinx haben, dass allerdings beim >nächsten Absturz der ISE (mindestens) halbiert ist. Man begibt sich in >eine Abhängigkeit. Das Crashen von ISE ist ein anderes Problem, was mit VHDL-Komponenten bzw. IP-Cores wenig zu tun hat. >Ich bin bei arithmetischen Operationen eher geneigt, eine fertige >Komponente zu instanziieren, als einen VHDL-Operator (z.B. "+") zu Das würde ich nicht machen. Macht den Coe unübersichtlich. Die Synthesizer sind schlau genug, solche Operationen optimal in die Zielhardware umzusetzen. >steht... ganz so einfach ist es natürlich nicht. Der Punkt ist: die >Entwicklungsmethode verändert sich. Naja, Modularisierung ist nicht wirklich neu. >Wie findet ihr euch im "Core-Dschungel" zurecht? Wo ist das Problem? SOOOOO viel Cores gibts ja nun nicht, und im Core-generater sind sie ja halbwegs geordnet. >Mit der Zeit wird man wohl seine persöhnliche Komponentenbibliothek >haben, auf die man sich verlassen kann. Jain. So schlecht sind die nicht. Allerdings lässt die Qualtität von ISE seit längerer Zeit zu wünschen übrig. MfG Falk
OK, ich sehe, ich bin mit meinem Standpunkt (fast) auf der richtigen Seite. Ich will '+' nicht verwenden, weil ich noch von der verwendeten Arithmetik abstrahieren will. Von der Bitbreite kann man leider weniger abstrahieren, da z.B. Speicher einem Beschränkungen auferlegen. Da kann man höchstens die Bitbreite auf 32 setzen und dann halt nur einen Bruchteil davon verwenden. Stichwort Core-Dschungel: Ich denke da eher an OpenCores, irgendwelche VHDL-Archive oder was auch immer. Zum "Prinzip": Ganz am Anfang habe ich auch alles schön hierarchisch aufgebaut. Aber wenn man nicht 100% vorher weiss, wie das funktionieren soll/kann, dann ist das ein Heiden-Mehraufwand, weil man ständig die Deklarationen anpassen muß. Dann lieber erstmal alles in eine Architecture schmeißen und hinterher Module extrahieren. Tobias, für RAM/ROM nehme ich die Vorlagen aus dem "Language Templates". Der Vorteil, den ich für RAM/ROM-Cores sehe, ist, dass man mittels COE-Files Initialwerte setzen kann (und natürlich, dass man relativ "beliebige" Größen spezifizieren kann). Mit instanziierten Primitiven geht das zwar auch (INIT_XX Generics), aber danach ist einen Neusynthese erforderlich. -- stefan
@ Stefan Hanke >Ich will '+' nicht verwenden, weil ich noch von der verwendeten >Arithmetik abstrahieren will. Von der Bitbreite kann man leider weniger ??? Was willst du denn da abstrahieren? >Stichwort Core-Dschungel: Ich denke da eher an OpenCores, irgendwelche >VHDL-Archive oder was auch immer. >Zum "Prinzip": Ganz am Anfang habe ich auch alles schön hierarchisch >aufgebaut. Aber wenn man nicht 100% vorher weiss, wie das funktionieren >soll/kann, dann ist das ein Heiden-Mehraufwand, weil man ständig die >Deklarationen anpassen muß. Dann lieber erstmal alles in eine >Architecture schmeißen und hinterher Module extrahieren. Sehe ich nicht so. Die eigentliche Kodierung ist sowieso ziemlich am Schluss. Erstmal muss ich ein klares, gutes Konzept haben, mit Blockschaltbildern, teilweise mit detailierten Signale. Wenn ich das dann konsequent umsetzte, muss ich während der Kodierung nur wenig anpassen, vielleicht hier und da mal ein paar Signale noch eintragen. Von Heidenaufwand kann da keine Rede sein. Ausserdem arbeite ich meist Bottom-Up, sprich die Module der untersten Ebenen zuerst, dann nach oben in der Hierachie. Damit wächst das System relativ gut und mit wenig Änderungen. Alles erstmal in eine Architektur zu schmeissen halte ich für einen schlechten Ansatz. MfG Falk
Falk wrote: > ??? > Was willst du denn da abstrahieren? Ich will die benötigte Festkomma-Arithmetik in einem Modul haben. > Sehe ich nicht so. Die eigentliche Kodierung ist sowieso ziemlich am > Schluss. Erstmal muss ich ein klares, gutes Konzept haben, mit > Blockschaltbildern, teilweise mit detailierten Signale. Wenn ich das > dann konsequent umsetzte, muss ich während der Kodierung nur wenig > anpassen, vielleicht hier und da mal ein paar Signale noch eintragen. > Von Heidenaufwand kann da keine Rede sein. Da spricht der Profi :-) Ich bin momentan leider noch sehr auf die reine Implementierung fixiert. Das, was ich als nächstes implementieren will, überlege ich mir vorher mit Hilfe von Papier und Bleistift. Das Gesamtkonzept ist "intuitiv" klar, aber da mir die Erfahrung mit Hardware und speziell mit diesem Board fehlt, kann ich schlecht vorher ein Konzept entwerfen, dass dann hinterher keiner größeren Änderungen bedarf. > Ausserdem arbeite ich meist Bottom-Up, sprich die Module der untersten > Ebenen zuerst, dann nach oben in der Hierachie. Damit wächst das System > relativ gut und mit wenig Änderungen. In der eigentlichen Fachdomäne fühle ich mich zuhause, im FPGA-Entwurf nicht. Ich gehe momentan so vor, dass ich mein kleines Design schrittweise verfeinere, bis die Gesamtfunktionalität steht (Themenbereiche wie das SDRAM habe ich vorsichtshalber auf später verschoben, wenns wirklich sein muss, momentan übernehmen BRAMs). > Alles erstmal in eine Architektur zu schmeissen halte ich für einen > schlechten Ansatz. Zitat meines DA-Betreuers: "Hauptsache, es funktioniert...". Als Referenz dient mir (funktionierender) VHDL-Code, in dem es genau eine selbstgeschriebene Architecture gibt. Dokumentation? Rate mal. Aber das Notwendigste kann man sich rausziehen, ist nicht allzu schwierig. Ich weiss gar nicht mehr, warum ich eigentlich mit dem Hierarchisieren aufgehört habe. Diesen Fehler werde ich revidieren. -- stefan
@ Stefan Hanke >> Was willst du denn da abstrahieren? >Ich will die benötigte Festkomma-Arithmetik in einem Modul haben. Ja und? Das geht genauso mit den normalen + Operator. >Zitat meines DA-Betreuers: "Hauptsache, es funktioniert...". Als OHHHHHJEEE!!! Kein Wunder dass Software heute als die elfte Plage der Menschheit gilt, wenn Studenten SOOO was vermittelt wird. Das wäre für mich fast ein Kündigungsgrund! Ich war als Schüler auch ein ziemlicher Chaot was das Programmieren angeht (und auch andere Dinge ;-) Das hat sich aber spätestes dann schlagartig gewandelt, als ich im Job war. Wenn man in seinem eigenen Zeug nicht mehr durchsieht, wenn man über eigentlich simple Dinge stolpert, welche mit solider Arbeitsweise einfach zu vermeiden sind, dann kommt man schon ins Grübeln. Am Ende ist eine solide Arbeitsweise einfacher, schneller und eben solider. Und verbringt nicht 99% seiner Zeit mit Debugging. >Ich weiss gar nicht mehr, warum ich eigentlich mit dem Hierarchisieren >aufgehört habe. Diesen Fehler werde ich revidieren. Tu das. Du wirst es nicht bereuen. MFg Falk
>>Zitat meines DA-Betreuers: "Hauptsache, es funktioniert...". Als >OHHHHHJEEE!!! >Kein Wunder dass Software heute als die elfte Plage der Menschheit gilt, >wenn Studenten SOOO was vermittelt wird. Dem stimme ich absolut zu! Meines Erachtens sollte man den Stundenten das richtige Arbeiten, also Methodik beibringen, statt sie zu Ergebnissen zu prügeln. Leider zählt nur das Ergebnis, was dazu führt, daß schlechter Arbeitsstil mit Zeitmehraufwand gegenkompensiert wird. Im Arbeitsleben ist die Zeit aber begrenzt, daher ist dann auch der output limitiert und hat man sich die Schlamperei erstmal angewöhnt, ist es nicht mehr abzustellen. Ergebnis: Die meisten Firmen schlampen bei der Arbeit und investieren im Nachhinein Ziet in das Zurechtkorrigieren!
Anmerkung: ---------- www.opencores.org Dann muss man nicht auf eine Black-Box vertrauen und kann sehen, was das Design so treibt. Bei Bedarf kann man sich das Teil auch anpassen.
1) Ich werde hier nicht geprügelt ;) 2) Ich habe gesagt, dass mein Betreuer das so sieht. Ich finde es ehrlich gesagt schon leichter, zuerst mal was zusammenzuhacken, und dann schön neuzuschreiben. Nicht vergessen, ich bin Anfänger. Mein Ziel ist, den Code in einem solchen Zustand zu haben, dass die Nachwelt hier was davon hat. Eventuell werde ich (irgendwann) Teile hier reinposten, dann könnt ihr mit eurer konstruktiven Kritik meinen Stil ändern. Ausserdem: Ich kann mich noch zu gut an meine ersten Perl-Programme erinnern. :) Da stehen mir jetzt noch die Nackenhaare zu Berge. -- stefan
Man muss eben zwischen Hobby/Uni oder professionellem Ansatz unterscheiden. Ersteres soll vor allem Spass machen, da kann man dann auch mal einen Irrweg gehen oder Fehler im Betrieb fixen. Im Beruf ist es absolut tödlich, wenn nach 10000 produzierten Baugruppen ein Fehler auftaucht. Dafür muss man dann den harten Ansatz gehen. Wir haben früher bei der ASIC Entwicklung teilweise den Code fertig von Hand evaluiert bevor der simuliert werden durfte. In der FPGA Evaluierung durfte eigentlich kein Fehler mehr auftauchen. Was übrigends einer der Gründe ist, warum ich ferige Cores zunehmend ungerne einsetze. Man weiss nicht, was drin ist, man kanne s nur schwer simulieren und man kann es gar nicht portiere z. B. Xilinx -> Altera oder gar aufs ASIC. Gruss Axel
@ Axel >Man muss eben zwischen Hobby/Uni oder professionellem Ansatz >unterscheiden. Ersteres soll vor allem Spass machen, da kann man dann >auch mal einen Irrweg gehen oder Fehler im Betrieb fixen. Nicht ganz! Vor allem würde ich zwischen Uni und Hobby einen Unterschied machen. Die Uni soll/muss Fähigkeiten für die Praxis vermitteln und hat damit ein Qualitätskriterium. Hobby kann ineffizent sein bis zum Horizont, erlaubt ist was gefällt. >Im Beruf ist es absolut tödlich, wenn nach 10000 produzierten Baugruppen >ein Fehler auftaucht. Dafür muss man dann den harten Ansatz gehen. Das Problem ist nicht allein das "nach 10000 produzierten Baugruppen". Allein der Designprozess ist WESENLICH länger, weil man vor allem seinen eigenen Murks permanent debuggen muss. Da muss man nr mal ie Augen offenhalten was da teilweise in Firmen abläuft . . . :-0 >Wir haben früher bei der ASIC Entwicklung teilweise den Code fertig von >Hand evaluiert bevor der simuliert werden durfte. ??? Wie ist das zu verstehen? >Was übrigends einer der Gründe ist, warum ich ferige Cores zunehmend >ungerne einsetze. Naja, das hiesse aber ein grosser Schritt zurück! Und ist damit praktisch nicht praktikabel. Modularisierung ist nicht neu, "Cores" werden überall seit langem eingesetzt, geht auch gar nicht anders. Sei es als Logik in FPGAs oder als Bibliothek in Software. Das Prinzip ist das Gleiche. Und die Probleme sind ähnlich. Blackbox, die hoffentlich gut getestet ist. Man muss ein gewisses Vertrauen zur Quelle haben. Und die Quelle muss sich bewähren. >Man weiss nicht, was drin ist, man kanne s nur schwer >simulieren und man kann es gar nicht portiere z. B. Xilinx -> Altera Kommt immer auf den Level an. Blankes VHDL kann man meist sehr gut portieren, compilierte Netzlisten so gut wie gar nicht. Ist aber in den wenigsten Fällen das entscheidene Kriterium. MFG Falk
Axel wrote: > Man muss eben zwischen Hobby/Uni oder professionellem Ansatz > unterscheiden. Ersteres soll vor allem Spass machen, da kann man dann > auch mal einen Irrweg gehen oder Fehler im Betrieb fixen. Also ein bisschen mehr Professionalität hätte ich schon erwartet. Wirklich wichtige Informationen sickern an mich im Wochentakt heran. Da macht das Basteln doch richtig Spass. :-/ > Was übrigends einer der Gründe ist, warum ich ferige Cores zunehmend > ungerne einsetze. Man weiss nicht, was drin ist, man kanne s nur schwer > simulieren und man kann es gar nicht portiere z. B. Xilinx -> Altera > oder gar aufs ASIC. Das war ein weiter Bogen zum Thema, vielen Dank :) -- stefan
">Wir haben früher bei der ASIC Entwicklung teilweise den Code fertig von >Hand evaluiert bevor der simuliert werden durfte. ??? Wie ist das zu verstehen?" Der Code wurde geschrieben, in Gedanken und mit Flussdiagrammen überprüft und dann einem Gremium vorgestellt. Erst wenn sich alle sicher waren, dass er funktioniert und der Spezifikation entsprach, wurde er simuliert. Die ASICs sind dann weitestgehend fehlerfrei gewesen. So eine Quelle galt dann auch als "vertrauenswürdig". "Naja, das hiesse aber ein grosser Schritt zurück!" Manchmal muss man einen neuen Anlauf nehmen :-) "Modularisierung ist nicht neu, "Cores" werden überall seit langem eingesetzt, geht auch gar nicht anders. Sei es als Logik in FPGAs oder als Bibliothek in Software. Das Prinzip ist das Gleiche. Und die Probleme sind ähnlich. Blackbox, die hoffentlich gut getestet ist. Man muss ein gewisses Vertrauen zur Quelle haben. Und die Quelle muss sich bewähren." Das mit dem "bewähren" oder "vertrauen" ist ja in der Theorie ganz schön. Tatsächlich habe ich erlebt, dass Cores aus einer eigentlich vertrauenswürdigen (und teuren) Quelle sich als Zukaufteile aus Indien, bei der der Entwickler nicht mehr greifbar war, herausgestellt haben. Oder das bei Cores, die angeblich "Silicon proven" sind, zufällig gerade der Modus, den man nutzen will, niemals zuvor eingesetzt wurde. Und spätestens bei komplizierteren Cores nützt es auch nicht mehr, wenn man das VHDL hat. Man kann das zwar in der Regel auf eine andere Technologie mappen, aber Änderungen oder gar Fehler zu reparieren, ist fast unmöglich, weil man Quereffekte nicht ausschliessen kann. "Ist aber in den wenigsten Fällen das entscheidene Kriterium." Nee, welcher Ing. würde auch zugeben, dass er sich in eine Sackgasse manövriert hat. Da wird dann lieber auf dem Einkauf rumgehackt, wenn das Produkt dann zu teuer ist, und der Einkauf keine Chance hat, den Preis zu drücken. Gruss Axel
@ Axel >Der Code wurde geschrieben, in Gedanken und mit Flussdiagrammen >überprüft und dann einem Gremium vorgestellt. >Erst wenn sich alle sicher waren, dass er funktioniert und der >Spezifikation entsprach, wurde er simuliert. ??? "Erst wenn sich alle sicher waren, dass er funktioniert" SICHER ist an der Stelle noch gar nix. OK, man kann sagen ob das Konzept plausibel und realisierbar erscheint, und ob die allgemeine Struktur (Datenfluss, Steuerfluss etc.) brauchbar aussieht. Aber SICHER ist da noch nix. Letztendlich hab ich sowas auch gemacht, wenn gleich nur allein mit ein klein wenig Rückkopplung von Kollegen. >Die ASICs sind dann weitestgehend fehlerfrei gewesen. So eine Quelle >galt dann auch als "vertrauenswürdig". Naja, also alles was auf dem eigenen Mist gewachsen ist. Klar. Aber das löst nicht das Problem der fremden Cores. >>"Naja, das hiesse aber ein grosser Schritt zurück!" >Manchmal muss man einen neuen Anlauf nehmen :-) Der da wäre? MFG Falk
Zum Thema Modularisierung: Ist es OK, dass die Busse zu einer internen Komponente etwas breiter (Größenordnung 100-200 bit) sind, oder macht das beim Implementieren Probleme? -- stefan
@ Stefan Hanke >Ist es OK, dass die Busse zu einer internen Komponente etwas breiter >(Größenordnung 100-200 bit) sind, oder macht das beim Implementieren >Probleme? Nein. MFG Falk
"SICHER ist an der Stelle noch gar nix. OK, man kann sagen ob das Konzept plausibel und realisierbar erscheint, und ob die allgemeine Struktur (Datenfluss, Steuerfluss etc.) brauchbar aussieht. Aber SICHER ist da noch nix." Natürlich nicht. Aber jeder war halt so sicher wie es geht. "Letztendlich hab ich sowas auch gemacht, wenn gleich nur allein mit ein klein wenig Rückkopplung von Kollegen." Es ist was ganz anderes, ob man seinen Code selbst durchschaut, oder ob man ihn Zeile für Zeile den Kollegen erklären muss. Ich fand es immer interessant, wie häufig Kollegen Zeilen noch drin hatten, weil sie nach x Änderungen sich nicht mehr getraut haben, die zu Entfernen, aber auch nicht mehr erklären konnten, wofür die eigentlich drin waren. "Naja, also alles was auf dem eigenen Mist gewachsen ist. Klar. Aber das löst nicht das Problem der fremden Cores." Nein, manchmal kommt man nicht drum herum. Aber nach meiner Erfahrung wird der Aufwand (vor allem langfristig) beim Einsatz fremder Cores in der Regel drastisch unterschätzt. Gruss Axel
>Ich finde es ehrlich gesagt schon leichter, zuerst mal >was zusammenzuhacken, und dann schön neuzuschreiben. Das wird Dir dann späater keiner keiner mehr erlauben, sondern sagen, daß es gut ist, wenn es funktioniert. Das Ergebnis ist eine schlecht erweiterbare Software. Ich bin im Übrigen ausdrücklich nicht der Meinung, daß das schöner ist, "etwas reizuhacken", da man sich da bei größeren Projekte rasch verläuft. Einen Rahmen braucht es schon, um vernünftig arbeiten zu können und der wird vorher festgelegt. Und genau diese Informationsmenge ist es, die zum Arbeiten nötig ist - wird die unterschlagen, läuft man aus dem Optimum raus - auch wenn mancher es nicht merkt oder zugeben will. Ich will nicht bestreiten, daß man die Übersicht auch alleine im Kopf entwickeln und behalten kann, aber es stehen zwei Grünmde dagegen, es zu tun: 1) In den Fällen, in denen es schadlos möglich war, handelte es sich um einfache und triviale Projekte. Das sind die Ausnahmen, wobei auch solche dazu angetan sind, einem Ärger zu machen, wenn man sie unterschätzt. 2) In den (meisten) Fällen ist Struktur von oben absolut erforderlich und seie s, daß man sie sich selber gibt. Wie wil man aber dann danach arbeiten, wenn man es nicht bei den einfachen Projekten geübt hat? STRUKTURIERTES ARBEITEN MIT EINEM EFFIZIENTEN ERGEBIS LERNT MAN NUR SEHR LANGSSAM. Das kann man nicht einfach "einschalten" wenn man es mal gerade zu brauchen glaubt und weglassen, wenn es mal "schnell" gehen soll.
Matthias wrote: > Das wird Dir dann späater keiner keiner mehr erlauben, sondern sagen, > daß es gut ist, wenn es funktioniert. Das Ergebnis ist eine schlecht > erweiterbare Software. Ja, das klingt plausibel. In diesem Fall aber Hardware ;) > Ich bin im Übrigen ausdrücklich nicht der > Meinung, daß das schöner ist, "etwas reizuhacken", da man sich da bei Ich habe nicht gesagt, dass es schöner ist, sondern leichter, da ich immer alle Signale an der Angel habe. Wenn ich falsch modularisiere, dann muss ich schon an ein paar mehr Stellen das Flicken anfangen. > größeren Projekte rasch verläuft. Einen Rahmen braucht es schon, um > vernünftig arbeiten zu können und der wird vorher festgelegt. Und genau > diese Informationsmenge ist es, die zum Arbeiten nötig ist - wird die > unterschlagen, läuft man aus dem Optimum raus - auch wenn mancher es > nicht merkt oder zugeben will. Nein, der Rahmen ist bei meinem Projekt fest. Ich muss vielmehr vorraussetzen, dass der Rahmen bekannt ist. Ausserdem werde ich mich nicht verlaufen, der Weg ist gerade, leicht abschüssig ;) Das Optimum werde ich sowieso nie hinbekommen, dazu exisitiert hier viel zu wenig Dokumentation. Ich bin in der Beziehung mittlerweile schon soweit, dass ich Teile des Boards nicht benutzen werde. > Ich will nicht bestreiten, daß man die Übersicht auch alleine im Kopf > entwickeln und behalten kann, aber es stehen zwei Grünmde dagegen, es zu > tun: > > 1) In den Fällen, in denen es schadlos möglich war, handelte es sich um > einfache und triviale Projekte. Das sind die Ausnahmen, wobei auch > solche dazu angetan sind, einem Ärger zu machen, wenn man sie > unterschätzt. Nein, einfach und trivial passt, glaube ich, nicht ganz auf meine Arbeit. Ich kenne aber kein Real-Life-Projekt zum Vergleich. Ich schätze mal, am Ende sind es so knapp 2000 Zeilen VHDL, kann aber auch mehr sein. > 2) In den (meisten) Fällen ist Struktur von oben absolut erforderlich > und seie s, daß man sie sich selber gibt. Wie wil man aber dann danach > arbeiten, wenn man es nicht bei den einfachen Projekten geübt hat? > > STRUKTURIERTES ARBEITEN MIT EINEM EFFIZIENTEN ERGEBIS LERNT MAN NUR SEHR > LANGSSAM. > > Das kann man nicht einfach "einschalten" wenn man es mal gerade zu > brauchen glaubt und weglassen, wenn es mal "schnell" gehen soll. Also, weil ich den VHDL-Code reinhacke, arbeite ich unstrukturiert? Es geht nicht. Ich kann als Anfänger einfach noch nicht abschätzen, wie es am Ende aussehen wird. Das fehlt es schlicht an Erfahrung. Ausserdem habe ich ja noch gar nicht gesagt, wie mein reingehackter Code eigentlich aussieht. Die VHDL-Prozessabstraktion ist doch recht nett. Dann noch ein Kommentar dazu, welche Signale der Prozess treibt oder noch ein wenig abstrakter, und die Sache sieht doch ganz gut aus. Was mich wirklich anödet, ist die miese/nicht vorhandene Unterstützung der VHDL-Editoren. Die SW-Welt ist da ein paar Generationen vorraus. VHDL-Refactorings? Pustekuchen. Nichtmal umbennenen eines Signales wird unterstützt (ISE; und nein, Search&Replace ist nicht das Gleiche!). Von fortgeschritteneren Sachen will ich lieber gar nicht anfangen. -- stefan
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.