VHDL: Architekturbenennung und -interpretation

Wie kann man beim Betrachten einer Entität das tatsächlich verwendete Architekturmodell ohne Hinweise aus dem Architekturnamen bestimmen?

Sie können nicht - wenn es instanziiert oder konfiguriert wird , kann die Architektur angegeben werden (wenn mehr als eine zur Auswahl steht) oder es wird ein Standard für Sie ausgewählt.

Wenn Sie mehrere Architekturen für eine einzelne Entität angeben (was meines Wissens möglich ist), geben Sie den Architekturen einfach unterschiedliche Namen in derselben Datei oder ...?

Sie geben ihnen verschiedene Namen. Es muss sich nicht in derselben Datei befinden (tatsächlich kümmert sich VHDL viel weniger darum, was sich in welcher Datei befindet, als Sie vielleicht denken)

Sind die Architekturnamen auf eine bestimmte Entität beschränkt (d. h. gibt es ein Problem mit "Namespaces", wenn derselbe Architekturname über mehrere Entitäten hinweg verwendet wird)?

Sie sind an eine Entität "angehängt", können also wiederverwendet werden.

Ich benutze oft a1als meine Architektur für alles Synthetische wie

• rtlimpliziert (für viele Leser) ein niedrigeres Niveau als das, auf dem ich schreibe.
• behaviouralimpliziert oft nicht-synthetisch (für einige Leser)
• synthwird vom Synthesizer für sein Modell verwendet (sonst hätte ich das verwendet)

a1war bisher konfliktfrei und stiftet keine Verwirrung ;)

Wenn ich tatsächlich mehr als eine Architektur habe, neige ich dazu, sie ausführlich zu benennen (zum Beispiel hard_multipliersund lut_multipliersfür einen Filter, der MUL18-Blöcke instanziiert - oder nicht).

Sehr oft hat man nur eine Architektur, also spielt es keine Rolle. Gute Entity-Namen sind viel wichtiger.

Es scheint, dass es einen Unterschied zwischen RTL und Verhalten gibt, aber wie oben erwähnt, sehe ich es in den Beispielen, die ich gesehen habe, nicht wirklich (oft sehe ich nur, dass eine Architektur definiert wird). Ist eine Architektur häufiger als die anderen?

Es ist historisch - Sie waren früher nicht in der Lage, "Verhaltenscode" zu synthetisieren (der an einem Punkt Dinge wie das Hinzufügen beinhaltete!) - also haben Sie eine RTL-Version erstellt, die Addierer und dergleichen instanziiert hat. (So ​​verstehe ich es - ich schreibe verhaltensorientierten (und dennoch synthetisierbaren) Code, seit ich ungefähr 1999 mit VHDLing begonnen habe!)

Hier sind die Architekturtypen:

Verhalten:

Allgemeine Hinweise:

• Traditionell keine Hierarchie (nur eine Datei, keine instanziierten Komponenten), obwohl dies je nach Tool unterschiedlich ist.
• Sehr schnell zu simulieren.
• Das Signalverhalten wird definiert.
• Wenn Verhalten nur zur Simulation verwendet wird, kann es nicht synthetisierbaren Code enthalten. Verhalten, das zur Synthese bestimmt ist, muss natürlich synthetisierbar sein.

Xilinx-spezifische Hinweise

• Im Allgemeinen sind Core-Generator-Modelle .vhd-Dateien vor der Synthese

Struktur:

Allgemeine Definition

• Instanziiert nur Komponenten und verdrahtet sie miteinander (hierarchisch).
• Langsamer zu simulieren als Verhalten.
• Keine wirkliche Definition des Signalverhaltens in der obersten Ebene.
• Nur synthetisierbarer Code.

Spezifische Anmerkungen von Xilinx

• Core-Generator-Modelle berücksichtigen kein Timing.
• Im Allgemeinen instanziieren Core-Generator-Modelle Netzlisten nach der Synthese

Die oben genannten sind im Grunde die traditionellen zwei Haupttiere der Architektur. Sehr häufig wird eine "gemischte" Definition verwendet, die Eigenschaften von beiden enthält.

RTL:

RTL, was am Ende des Tages tatsächlich auf dem FPGA steckt. Dies ist also synthetisierbarer Code, der das Verhalten des Systems definiert und aus einer Codehierarchie besteht:
Die unteren Schichten sind synthetisierbares Verhalten, wo das Wesentliche des Signalverhaltens definiert wird, und die oberen Schichten sind strukturell, wo die Verhaltenskomponenten werden miteinander verbunden, um ein großes "Blockdiagramm" auf oberster Ebene zu erstellen, wenn Sie so wollen.

Weiter zu mehreren Architekturen:

Architekturen können sich alle in einer Datei oder in mehreren Dateien befinden. Wichtig ist nur, dass zuerst die Entität kompiliert wird und die zu verwendende Architektur festgelegt wird.

Dieses Buch ist sehr praktisch und beschreibt diese Art von Dingen ziemlich gut.

Es gibt keine feste Regel darüber, wie die Dinge getan werden sollten, um unterschiedliche Verhaltens- und Strukturmodelle zu haben oder sie einfach zu mischen. Normalerweise ist es in großen Firmware-Designs (oder in großen Unternehmen, in denen Code geteilt und wiederverwendet wird) nützlich, zwischen den beiden zu unterscheiden, um die Dinge zu vereinfachen, aber am Ende des Tages kommt es darauf an, was für Sie funktioniert.

Erstens können reale Architekturentwürfe nicht so streng kategorisiert werden. Warum sich einschränken? Vielleicht möchten Sie andere Entitäten instanziieren und sie "strukturell" verbinden, aber fügen Sie hier und da einen Prozess oder eine gleichzeitige Zuweisung hinzu, um etwas "rtl" -Logik hinzuzufügen, und verwenden Sie vielleicht einige "Verhaltens" -Codierungsmuster, damit der Synthesizer einige davon herausfindet Details, die Sie nicht interessieren (wie das Hinzufügen, ohne einen Addierer mit Bereichs-/Pipeline-/Leistungsparametern speziell zu instanziieren), alles in derselben Architektur.

Noch wichtiger ist, dass Sie verstehen müssen, was in aktuellen Asic/FPGA-Technologien synthetisierbar ist und was nicht, und dies unabhängig vom Architekturmodell.

Eine Entität kann auf mehrere Arten implementiert werden, wobei sogar leicht unterschiedliche Verhaltensweisen möglich sind, sodass Sie möglicherweise mehrere Architekturen für dieselbe Entität haben. Darüber hinaus haben Sie möglicherweise eine Architektur nur für die Simulation (normalerweise nicht synthetisierbar), die möglicherweise schneller simuliert als die "echte" Version, was sich als nützlich erweisen kann, wenn Sie große Designs als Ganzes testen. Sie würden diesen Architekturen Namen geben, die Ihnen helfen, sich daran zu erinnern, was sie von den anderen unterscheidet, und einfach bhv/str/rtl ist normalerweise nicht genug oder genau, angesichts der hybriden Natur von Designs in der realen Welt.

In Bezug auf Ihre spezifischen Fragen ist die Architekturdeklaration an einen Entitätsnamen gebunden, sodass es keine Namespace-Probleme mit Architekturen mit demselben Namen für verschiedene Entitäten gibt. Verwenden Sie einfach unterschiedliche Namen für Architekturen für dieselbe Entität.

Architekturen können sich in verschiedenen Dateien befinden, Sie müssen nur sicherstellen, dass die Entity-Deklaration zuerst kompiliert wird.

Sie können auswählen, welche Architektur verwendet werden soll, wenn Sie die Entität instanziieren oder Konfigurationsanweisungen verwenden. Wenn Sie dies nicht tun, ist der Standardwert „normalerweise“ die letzte Architektur, die der Compiler für eine bestimmte Entity-Deklaration gesehen hat.