Hallo,
Ich habe eine Verstädnisfrage zum generellen Aufbau einse VHDL Codes.
Vor einigen Tagen habe ich ebenfalls ein Thema im Forum aufgemacht
welches sich speziell auf meine Ausarbeitung bezieht und bei den
Antworten gemerkt das mir etwas für das Grundverstädnis fehlt. Um es
plastisch und beispielhaft zu halten, beziehe ich mich auf die
angehängte Darstellung.
Ist es richtig, dass (vermutlich ein möglicher Lösungsansatz) ich für
die Kodierung der Darstellung die "enitity", "architecture Struktur
(beinhaltet "component sowie port map"), sowie "architecture Verhalten"
brauche?
Kurze Erläuterung zu meiner Herangehensweise:
- entity definiert mir die Ein- und Ausgänge
- architecture Struktur -> component definiert mir die Ein- und Ausgänge
von BS1, BS2, BS3
- architecture Struktur -> Signal definiert mir die Bezeichnungen der
Verbindungen zwischen BS1, BS2, BS3
- Architecture Stuktur -port map definiert mir die Verbindungen zwischen
BS1, BS2, BS3
Nach dem nun alle Ein- und Ausgänge, sowie deren Zusammenhänge
deklariert wurden, geht das die Funktion von BS1, BS2, BS3 zu
beschreiben
-architecture Verhalten: der hier befindliche Code ist nur exemplarisch
und soll nur meine Herangehensweise verdeutlichen. Jetzt wo zuvor die
Grundstruktur definiert wurde, kann ich mich im archtecture Verhalten um
die definition von BS1, BS2 und BS3 kümmern.
Sehe ich das ganze so richtig?
Ja, wobei ich hier wieder einige Dinge erkenne, die in die falsche
Richtung führen können, daher nur soviel:
Wie du die arch nennst, ist egal. Das behavio(u)ral ist nur ein
lapidarer Hinweise. Man nutzt es zum Kennzeichnen, weil man an eine
entity auch mehrere austauschbare arch binden kann / könnte.
Die Reihenfolge, die Du da so schön aufziehst, ist ebenfalls belanglos.
Wie Du VHDL-Code aufbaust, vor allem in Sachen Hierarchien, wird sich an
der Aufgabe anlehnen.
Was man tun sollte, ist Physik von Logik zu trennen und damit gleichsam
die oft harten herstellerspezifischen- und bausteinspezfischen
Funktionen von den soften Funktionen zu trennen, die optimiert werden
können und anwendungsspezifisch verwendet werden.
Zudem Thema könnte man aber Bücher schreiben.
da siehst du schon einiges richtig.
ohne vollständig zu sein:
Nennen wir es das Modul "ordnung", dann hast du es schonmal richtig
angegangen eine Entity "ordnung" für die Ein- und Ausgänge zu
beschreiben. Richtig auch der Inhalt "struktur" als architecture.
Ein Fehler ist "signal clk". Denn "clk" ist bereits schon als Signal
durch die entity bekannt.
Wie du es auch richtig darstellst, setzt du Untermodule (BS1,..) in
deine Beschreibung "struktur" ein. Diese machst du in deiner
Beschreibung bekannt durch component .. end component; und durch die
Instanziierung.
Was noch fehlt ist die entity für BS1, BS2 und BS3. Denn jedes Modul hat
eine entity und mindestens (in der Regel jedoch meist) eine
Architecture. "Component" ist nur für den Aufruf des Moduls da, das
Modul muss jedoch weiterhin vollständig beschrieben werden.
Klakx schrieb:> Was noch fehlt ist die entity für BS1, BS2 und BS3. Denn jedes Modul hat> eine entity und mindestens (in der Regel jedoch meist) eine> Architecture. "Component" ist nur für den Aufruf des Moduls da, das> Modul muss jedoch weiterhin vollständig beschrieben werden.
Vielen Dank soweit für die Antworten.
Klakx, du erwähnst die entities für BS1, BS2 und BS3. Sehe ich das
richtig, wenn ich die Entities ergänze, dass ich die "Components"
weglassen kann? Sonst wäre es doppelt gemoppelt.
Eine weitere Frage, die mir gerade aufkommt, betrifft die architecture
Verhalten.
In den jeweiligen architectures von BS1, BS2, BS3 deklariere ich signale
wie "c" und "x". Diese kommen in BS1 und BS2 doppelt vor. Stellt es ein
Problem dar? Wohl eher nicht, weil die architectures für sich
geschlossen wirken, richtig?
Meth J. schrieb:> Vielen Dank soweit für die Antworten.>> Klakx, du erwähnst die entities für BS1, BS2 und BS3. Sehe ich das> richtig, wenn ich die Entities ergänze, dass ich die "Components"> weglassen kann? Sonst wäre es doppelt gemoppelt.
Bitte schön. Nein, in diesem Fall brauchst du sie. Entitys sind die
Interface-Beschreibung des Moduls und Architectures sind die Inhalte des
Moduls. Wenn du ein anderes Modul aufrufen willst, dann musst du es dem
Hauptmodul bekannt machen.
In etwa so:
ordnung (entity,architecture)
bs1(entity,architecture)
bs2(entity,architecture)
bs3(entity,architecture)
das sind vier Module, die ohne weitere Informationen voneinander
unabhängig sind.
Es ist auch eine geläufige Methodik diese in 4 Dateien zu separieren.
Manche Compiler verlangen das sogar von dir.
Nun instanzierst du ein Modul vom Typ BS1 nämlich B1. Aber woher weiß
"Ordnung" wie das Interface aussieht? --> durch die
Componentbeschreibung.
Ja es wirkt doppelt-gemoppelt. Erste Abhilfe wäre die
Componentbeschreibung in ein Package auszulagern (Das macht z.B. Xilinx
mit den unisim-Modulen). In der Regel schreib ich die
Componentbeschreibung hin.
Meth J. schrieb:> Eine weitere Frage, die mir gerade aufkommt, betrifft die> architecture> Verhalten.>> In den jeweiligen architectures von BS1, BS2, BS3 deklariere ich signale> wie "c" und "x". Diese kommen in BS1 und BS2 doppelt vor. Stellt es ein> Problem dar? Wohl eher nicht, weil die architectures für sich> geschlossen wirken, richtig?
richtig. Die Deklarationen von c und x in der Architecture gelten nur
dort.
zwei Sachen noch :)
Pro-Tipp: Das sind viele Grundlagenfragen, die frei in Netz mehrfach in
pdfs und powerpoints erklärt werden.
Pro-Tipp 2: Hol dir eine Entwurfsumgebung. Wie z.B. Xilinx-Webpack. Der
Syntax checker und die herangehensweise helfen dir an dich Sache
praktischer ranzugehen.