Beziehung zwischen RTL- und Verilog-Modulen

Zunächst einmal ist Verilog eine Hardwarebeschreibungssprache, die verwendet wird, um eine Sammlung digitaler Hardware zu beschreiben, und moduleist nur eine Möglichkeit, Ihre Beschreibung hierarchisch einzukapseln. Jede moduleGrenze kann physikalisch sein, wie die Pins eines FPGA oder IC oder einer Leiterplatte, oder sie kann logisch sein, wie ein Datenpfad oder Controller. In jedem Fall stellt ein Verilog moduleeine funktionale Komponente Ihres Designs dar, die von einem einfachen andTor (oder kleiner), das für das bloße Auge unsichtbar ist, bis zu einem System so groß wie ein Raum (oder größer) reicht. Aber im Allgemeinen nimmt der Inhalt eines Moduls eine gewisse Menge an physischem Platz sowie eine gewisse Menge an Stromverbrauch, Wärme usw.

Der Inhalt eines Moduls kann eine Sammlung anderer Modulinstanzen oder eine Beschreibung sein, die auf vielen verschiedenen Abstraktionsebenen geschrieben wurde, von denen RTL nur eine von vielen möglichen Ebenen ist. RTL oder Register Transfer Level ist ein Code, der leicht aus einem scheinbar prozeduralen Programm in digitale Hardware synthetisiert werden kann.

Eines der Probleme bei vielen Kursen ist, dass sie aufgrund des Zeitdrucks versuchen, Konzepte mit Problemen zu unterrichten, die zu klein sind, um diese Konzepte zu benötigen.

Ein Design ist im Grunde eine Hierarchie von Modulen. In der Synthese beschreibt Ihr Top-Level-Modul normalerweise "alles auf dem Chip"; Submodule beschreiben dann Teile des Designs. In der Simulation ist Ihr Top-Level-Modul normalerweise Ihr Testbench-Code, und dann wird der Code, den Sie testen möchten, als Submodul instanziiert.

Das Aufteilen eines Designs in Module hat mehrere Vorteile.

• Es kann logisch zusammenhängenden Code zusammen gruppieren.
• Synthesewerkzeuge werden normalerweise die Ressourcennutzung pro Modul darstellen. Wenn Sie Ihr Design nicht in Module aufteilen, können Sie nicht erkennen, welcher Teil Ihres Codes alle Ressourcen verbraucht.
• Es kann lokale Details kapseln, Signale sind lokal für ein Modul, es sei denn, Sie leiten sie explizit ein und aus.
• Es kann die Wiederverwendung von Codeblöcken ermöglichen.

Es gibt aber auch Nachteile.

• Das Routing von Signalen in und aus einem Modul erfordert die Verdrahtung von mehr Boilerplate-Code.
• Zu viele Abstraktionsebenen können es schwierig machen, zu erkennen, was vor sich geht.

RTL-Design enthält Datenpfad und Controller, das ist ok

RTL bedeutet, dass wir beschreiben, was mit jedem Register in jedem Taktzyklus passiert, indem wir eine Teilmenge der Sprache verwenden, mit der die Synthesewerkzeuge umgehen können.

Das Tool weiß oder kümmert sich meistens nicht darum, ob ein bestimmtes Register "Datenpfad" oder "Steuerung" ist, nur dass Sie definieren, was damit passiert, so, dass es es versteht.

Ist Controller beispielsweise ein Modul in Verilog?

Es liegt ganz bei Ihnen, Sie könnten den Datenpfad und den Controller in einem einzigen Always-Block zusammenführen. Sie könnten einen Always-Block für den Controller haben und dann Ihren Datenpfad aus einer Mischung von Assign-Anweisungen, Always-Blöcken und Submodulen aufbauen. Sie könnten ein Submodul für den Datenpfad haben, aber nicht für den Controller.

Was am besten funktioniert, hängt vom Problem ab. Wenn die Datenverarbeitung einfach ist, kann es am sinnvollsten sein, alles in einen Always-Block zu packen. Wenn die Datenverarbeitung komplexer wird, kann es sinnvoll sein, sie aus dem Always-Block zu verschieben und strukturierter zu beschreiben, um die Ressourcennutzung besser zu kontrollieren.

Persönlich würde ich den Controller und den Datenpfad nur dann in separate Module aufteilen, wenn ich einen guten Grund hätte, vielleicht sind sie sehr groß, vielleicht möchte ich einen Controller verwenden, um mehrere Kopien des Datenpfads zu fahren, so etwas in der Art.

Hmm... Nehmen wir an, ich möchte ein System auf Basys3 entwerfen. Zufällige LEDs blinken nacheinander und der Benutzer versucht, diese Sequenz zu wiederholen. Die Punktzahl des Benutzers wird für jede richtige Antwort erhöht. Wie kann ich ein solches System implementieren? Sollte ich versuchen, ein Controller-Datapath-System oder Verilog-Module zu entwerfen? Ich bin sehr verwirrt.

Lassen Sie uns das aufschlüsseln.

Zuerst brauchen wir eine Quelle für "Zufallszahlen". Der wahrscheinlich beste Weg, dies zu tun, ist ein kontinuierlich laufender Pseudo-Zufallszahlengenerator. Die Zeit, zu der der Benutzer die Starttaste drückt, wählt dann aus, welche "zufällige" Zahl und damit welches LED-Muster der Benutzer erhält.

Ich würde vorschlagen, den "Zufalls"-Zahlengenerator zu einem eigenen Modul zu machen, damit er in anderen Projekten wiederverwendet werden kann. Wahrscheinlich ist so etwas wie ein linear rückgekoppeltes Schieberegister ausreichend.

Sie benötigen wahrscheinlich auch einen Tastenentpreller, der die Signale von den Tasten aufnimmt und unordentliches Drücken in ein Signal umwandelt, das genau einen Taktzyklus lang hoch ist. Dies würde in ein Modul umgewandelt werden, damit mehrere Instanzen für die verschiedenen Schaltflächen instanziiert werden können.

Den eigentlichen Spielcode würde ich wahrscheinlich als einen einzigen Always-Block schreiben. Sie könnten versuchen, es aufzuteilen, aber meiner Meinung nach würde der Overhead des Handshakes zwischen verschiedenen Teilen wahrscheinlich die Gewinne überwiegen.

* Eine Ausnahme bilden Zustandsregister für Zustandsmaschinen. Wenn Sie den Standard-State-Machine-Idiomen folgen, übersetzt das Tool in der Regel die von Ihnen in Ihrem Programm verwendeten Statusnummern in eine Statuscodierung, die für die Syntheseeffizienz ausgewählt wurde (oft 1-hot).