Ich habe habe gerade folgenden Satz in Reichardt/Schwarz gelesen: Jeder entity muss mindestens eine architecture zugeordnet sein. Das Wort mindestens gibt mir zu denken. Nun frage ich das Forum, welche Möglichkeit ich bis jetzt noch nie genutzt habe, da ich immer genau eine architecture einer entity zugeordnet habe. Wie kann ich mehrere architecture einer entity zuordnen? Leider wird in dem Buch, keine weiterführende Erläuterung gegeben. Welchen Sinn macht es mehrere architecture einzuführen?
> Wie kann ich mehrere architecture einer entity zuordnen? architecture v1 of and_gatter is... architecture v2 of and_gatter is... architecture v3 of and_gatter is... architecture weisswurst of and_gatter is... architecture lebkuchen of and_gatter is... Im Normalfall "gewinnt" die letzte analysierte Architektur und wird dann per Default hergenommen, wenn man nichts anderes sagt. Andere Versionen bekommt man, indem man Configurations anlegt, wo für jedes Entitylabel die passende Architecture angegeben wird. Man kann es auch bei der Instantiierung direkt machen. > Leider wird in dem Buch, keine weiterführende Erläuterung gegeben. > Welchen Sinn macht es mehrere architecture einzuführen? zB. verschiedene Varianten einer Implementierung, einmal mit allem Schnickschnack und nicht synthetisierbaren Konstrukten zum Erstellen eines Modells, einmal in RTL, einmal Gatterliste nach der Synthese. Dann alle in der Testbench parallel laufen lassen und schauen, ob sie übereinstimmen. Oder zur Beschleunigung der Simulation (behavioral statt gate level). Oder (insb. mit den vielfältigen Möglichkeiten der Configurations) als "Lager" verschiedener Ausstattungsvarianten eines Bausteins.
Du kannst verschiedene Architectures zu einer Entity anlegen. Z.B. könntest Du für ein Projekt anfangs eine sehr abstrakte, nicht synthetisierbare Beschreibung der Funktionalität. Mit dieser könnte man das erste Mal formal die Funktion zu beschreiben. Das ist dann später Deine Referenz für Vergleiche von neuen Implmentierungen. Danach erstellt man dann bspw. eine RTL-Beschreibung. Jetzt kannst Du entweder die abstrakte oder die RTL-Beschreibung für die Simulation benutzen und dadurch z.B. Simulationszeit sparen. Welche architecture einer entity zugeordnet ist, wird mit einer configuration festgelegt.
>Leider wird in dem Buch, keine weiterführende Erläuterung gegeben.
Da bist du wohl noch nicht bis Kapitel 7 gekommen.
Im unterkapitel 7.2.1.3 (Konfriguration zur Auswahl von
Modellarchitekturen)
wird beschrieben wie mit dem Befehl "use architectur" eine architectur
mit einer entity verknüpft wird.
Julia schrieb: > Im unterkapitel 7.2.1.3 (Konfriguration zur Auswahl von > Modellarchitekturen) > wird beschrieben wie mit dem Befehl "use architectur" eine architectur > mit einer entity verknüpft wird. So weit war ich noch nicht. Doch ich finde hier "use entity" und keine "use architecture" auch in dem verwiesenen Code 7.1 finde ich die architekture auch nur einmal vor. Nur die eingebundenen Componenten werden mit use entity spezifisch zugewiesen. Ich habe bis jetzt generate als Auswahlschalter benutzt und komme auf die gleiche Funktionalität. Bisher ist herausgekommen, es gibt entity und architecture immer als Paar. Wenn es doch mal mehrere architecture gibt, dann ist nur eine architecture aktiv. So wird die Paarung aufrechtgehalten.
>auch in dem verwiesenen Code 7.1 Wer hat auf den Code 7.1 verwiesen ? NIEMAND Du bist einfach im falschen Film >Doch ich finde hier "use entity" und keine "use architecture" Eine Architectur ohne entity bringt dich ja auch nicht weiter. Da die angabe von mehreren architecturen optional ist, ist logischerweise auch die angabe einer architectur bei "use entity" optional. Der architekturname wird in Klammern übergeben. siehe Code 7.3 Julia
> Ich habe bis jetzt generate als Auswahlschalter benutzt und > komme auf die gleiche Funktionalität. Oberflächlich ja. Generate ist aber eher ein #ifdef... Der Witz an den Configurations ist, das du (wenn nötig) in einer Konfiguration alle Instanziierungen in allen Hierarchien mit individuellen Architekturen versehen kannst. D.h. du beschreibst vom Top-Level absteigend für jede Instanziierung die passende Architecture (AFAIR gehen da auch generics) und kannst für die Instanziierungen dadrin wiederum alles festlegen etc. Sowas ist für automatisch erzeugte Konfigurationen ganz nett. Von Hand sind flache Konfigurationen sinnvoller, die sich dann auf schon fertige Konfigurationen drunter verlassen. Wenn es auch im täglichen VHDL-Leben eher selten benutzt wird, finde ich diese Art der Library-Verwaltung in der Sprache selbst schon ziemlich faszinierend. Insbesondere wenn man bedenkt, dass das seit 1987 so ist. Da haben viele ja noch in Assembler programmiert ;)
Georg A. schrieb: >> Ich habe bis jetzt generate als Auswahlschalter benutzt und >> komme auf die gleiche Funktionalität. > > > Oberflächlich ja. Generate ist aber eher ein #ifdef... Der Witz an den > Configurations ist, das du (wenn nötig) in einer Konfiguration alle > Instanziierungen in allen Hierarchien mit individuellen Architekturen > versehen kannst. D.h. du beschreibst vom Top-Level absteigend für jede > Instanziierung die passende Architecture (AFAIR gehen da auch generics) > und kannst für die Instanziierungen dadrin wiederum alles festlegen etc. > Sowas ist für automatisch erzeugte Konfigurationen ganz nett. Von Hand > sind flache Konfigurationen sinnvoller, die sich dann auf schon fertige > Konfigurationen drunter verlassen. Ja genau mit generics eine Variable festlegen und dann mit generate die Variable abfragen. So kann ich umschalten. VHDL hat keinen Preprocessor wie C. Automatische Konfigurationen habe ich noch nie benutzt. bis jetzt alles von Hand gecodet. > Wenn es auch im täglichen VHDL-Leben eher selten benutzt wird, finde ich > diese Art der Library-Verwaltung in der Sprache selbst schon ziemlich > faszinierend. Insbesondere wenn man bedenkt, dass das seit 1987 so ist. > Da haben viele ja noch in Assembler programmiert ;) Assembler war nie meine Sprache. Nur mit dem Z80 habe ich richtig Assembler geschrieben. Die Intel 8086..80286 habe ich dann in C oder Pascal gefüttert. Jetzt wird Assembler für mich wieder wegen einem Softprocessor interessant. Danke für die Infos. Es war sehr interessant. Auch Danke Julia. auch das Beispiel 7.3 hat auch nur eine architecture. Die Componenten werden mit use entity richtig eingehangen. Ich finde die Componeten Deklaration nur lästig. Die lasse ich ich häufig weg, dabei wird der Code auch übersichtlicher.
> VHDL hat keinen Preprocessor wie C. Manchmal nervend, aber manchmal auch gut. AFAIK war das eine absichtliche Design-Entscheidung, C und die Erfahrungen dazu gabs zu dem Zeitpunkt ja schon lang genug. Die Sache mit dem if..generate kann aber auch genauso wie in C zu einem ziemlichen Wald werden, den man nicht mehr überblickt (verschachtelt, unzählige #define-Abfragen, etc.). Da ist die "clean-slate" Methode mit einer neuen "frischen" Architektur dann überschaubarer. > Ich finde die Componeten Deklaration nur lästig. Das stimmt, die Code-Verdoppelung ist wirklich lästig, insb. wenn eine entity noch nicht steht und sich die Ports immer wieder mal ändern. Allerdings ist das in C und erst recht C++ mit den Prototypen/Klassen auch nicht wirklich besser. Ich versuch das beste draus zu machen und steck das Zeug in ein Package und da sind dann auch gleich diverse Test-Funktionen dabei (zB. Ansprechen von Bussen, etc.). Und wenn ich ganz gut drauf bin, auch schon etwas Doku ;)
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.