Hallo, ich habe eine Archtitektur in Verilog für einen FPGA geschrieben. Wie würdert ihr diese modellieren (für die Dokumentation der Abschlussarbeit). Also mit gehts primär um die Technik. - SDL - UML - Statecharts - usw... Vielleicht hat da schon jemand Erfahrung und würde diese gerne teilen. Mit freundlichen Grüßen Pink
Da sind wir wieder beim alten Problem: Code vorhanden, jetzt dokumentieren. Warum ist das nur so, dass erst das Ergebnis hingehackt wird, um dann Dokumente nachzuschieben? Eigentlich sollten Architekturbeschreibung, Struktur, state machine, Prozesse und Handlungsabläufe, Modi sowie auch eine Strategie der Umsetzung VOR Beginn des codierens fertig sein. Dies wäre auch so zu dokumentieren, will heissen, zu Beginn Deiner Arbeit sollte ein Konzept da gwesen sein, wann Du was machen willst. Dann solltest Du dich dran gehalten haben, eine Planung Deiner Arbeit (s.o.) vollzogen und diese DANACH umgesetzt haben, um festzustellen, was an der Planung falsch war, was bei der Umsetzung schief gegangen ist, was geklappt hat, wo man wann was nacharbeiten und testen musste. DAS ist die eigentliche Aufgabe einer Diplomarbeit etc und nicht, einfach ein Ergebnis zu produzieren, das dann für die Galerie oder wen auch immer noch in irgendeiner Form ein zweites mal in eine Doku gelangt. Warum schreiben die "Entwickler" ihre Gedanken nicht auf und managen sowohl design, als auch die komplette Entwicklung allein im Kopf oder rein intuitiv? Wer in einem Team arbeiten will, kommt nicht umhin, sich VOR Arbeitsaufnahme mit anderen zu synchronisieren und Konzepte zu machen. Ich stelle fest, dass solche grundlegenden Arbeitstechniken nach wie vor an Hochschulen nicht gelehrt werden, obwohl sich diese ja angeblich bemühen, "praxisnah" auszubilden. Oder liege ich falsch?
Hallo, gut ich möchte nicht alles kommentieren aber hier nur ein paar Punkte. 1. Ich habe mir vorher ein Konzept überlegt und dieses notiert. Mit diesen Aufzeichnungen wurden auch Diskussionen im Team geführt. Diese Notation ist aber nicht Standardkonform und gibt nicht alle Eigenheiten der Sprache Verilog wieder. 2. Dieses Konzept wurde auch DANACH umgesetzt und Fehler wurden beseitigt. 3. Prinzipiell ging es mir nur um die Erfahrung anderer mit verschiedenen Techniken, um "meine" Notizen in ein richtiges, für "andere" verständliches Format zu übertragen. 4. Diese "grundlegenden" Arbeitsweisen werden durchaus gelehrt. Sehr ausführlich. Dabei kann aber nicht auf jede Winzigkeit eingegangen werden. Da ich mich in dem eingebetteten Bereich als Neuling bewege, habe keine großen Erfahrung im Modellierungssprachen. Deswegen dieser Thread. Also bitte ruhig bleiben. Gruß Pink
Was sagt(e) denn das team zu den Entwürfen? Wie gesagt, wenn es richtig gemacht wird, ist es fertig, bevor angefangen wird (damit in einem Team auch andere mitanfangen könnten!) und dann ist man damit durch. Entweder es ist auf einem verständlichen Niveau gewesen, sodass andere mitdiskutieren konnten, oder es war nicht so (dann konnten sie auch nicht wirklich mitdiskutieren). Sind das denn im team keine Erfahrenen, die aussagen können, was u.U. fehlt? / gefehlt hat?
Mir geht es doch nur um verschiedene Beschreibungstechniken. Welche wurden schon einnmal angewandt? Unabhängig von meinem Code/Design/Projekt. Ich benutze momentan eine Mischung aus Shematic Symbolen (für einzelne Verilog Module) und Zustandsdiagrammen (UML, für inneren Abauf im Modul). Aber wie beschreibt man zum Beispiel reine always Blöcke, die in Abhängigkeit von Signalen andere Signale setzen. Hier gibt es ja keine Zustände.
UML , selbst seit es einen UML-Variante für Echtzeit gibt, wird so standardisiert nicht in der FPGA Praxis eingesetzt. Hier dominieren mit Visio/Dia/Word gezeichnete Block/Flußdiagrammme. Wenn es sein muss auch mal eine Statemachine. Für letzteres gibt es dedizierte FSM-Maldiagramme, die einen den Ärger mit Pfeilspitzen etc abnehmen. Textfiles in einer Hardwarebeschreibungssprache zählen üblicherweise auch zur Dokumentation. RTL (Registertransfers) kann man gut in Kästchen beschreiben. Also die Funktion eines Jump -befehles kann man auch so beschreiben Programmcounter: <- Opcode[15 ...0] Flags: not modified ALU: no Operation dann gibt e natürlich noch Wahhreitstabellen, logische Gleichungen etc.. Manche malen zur Beschreibung strukturdiagramme mit SimuLink o.ä.. Andere schreiben viel text. Schau dir doch mal die Doku eines Mikrocontrollers (AVR) und lass dich von dieser inspirieren. MfG,
Ok, vielen Dank, das hilft mir weiter. Eine Frage hätte ich aber noch. Wenn ich ein Blockdiagramm eines Funktionsblocks male, wie würden die Ein- und Ausgänge dargestellt? Oder sollten diese separat dargestellt werden.
C. E. schrieb: > Ok, vielen Dank, das hilft mir weiter. > > Eine Frage hätte ich aber noch. Wenn ich ein Blockdiagramm eines > Funktionsblocks male, wie würden die Ein- und Ausgänge dargestellt? Oder > sollten diese separat dargestellt werden. Was meinst du mit Funktionsblock? eine Funktion die mehrmals benutzt wird? Die würde man im Blockschaltbild als Instanz (Kasten) darstellen. Ein/Ausgänge kennzechnat man gern anhand der Richtung des Datenflußes, also wenn die Daten v. l. n.r. laufen dann sin die Eingänge links und die Ausgänge rechts, Steuersignale (clk,rst,busy) dann an der oberen oder unteren Kante. Ebenso verdeutlichen Pfeilspitzen Ein/Ausgänge, zeigt die Spitze eines Pfeils drauf ist es ein Eingang, andernfalls Ausgang. MfG,
Fpga Kuechle schrieb: > Ärger mit Pfeilspitzen Ich benutze für sowas immer Visio. Da hat man nicht so viel Ärger mit :)
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.