www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Über das Verwenden "fertiger" Komponenten


Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: Sabb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.


Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
">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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.