So verwenden Sie die Port Map-Instanziierung in VHDL

Ein Modul ist eine eigenständige Einheit von VHDL-Code. Module kommunizieren mit der Außenwelt über die Entität . Hafenkarte ist der Teil der Modulinstanziierung, in dem Sie angeben, mit welchen lokalen Signalen die Ein- und Ausgänge des Moduls verbunden werden sollen.

In früheren Tutorials dieser Serie haben wir unseren gesamten Code in die Haupt-VHDL-Datei geschrieben, aber normalerweise würden wir das nicht tun. Wir erstellen Logik mit dem Zweck, sie in einem FPGA- oder ASIC-Design zu verwenden, nicht für den Simulator.

Ein VHDL-Modul, das für die Ausführung in einem Simulator erstellt wurde, hat normalerweise keine Ein- oder Ausgangssignale. Es ist völlig in sich abgeschlossen. Deshalb war die Entität unserer Entwürfe leer. Zwischen entity war nichts -Tag und die end entity; Tag.

Dieser Blogpost ist Teil der Reihe Basic VHDL Tutorials.

Ein Modul ohne Ein- oder Ausgangssignale kann in einem realen Design nicht verwendet werden. Sein einziger Zweck besteht darin, uns zu ermöglichen, VHDL-Code in einem Simulator auszuführen. Daher wird es auch als Testbench bezeichnet . Um ein Modul mit Ein- und Ausgangssignalen zu simulieren, müssen wir es instanziieren es in einer Testbench.

Module und Testbenches sind oft paarweise vorhanden und werden in verschiedenen Dateien gespeichert. Ein gängiges Namensschema besteht darin, die Testbench den Modulnamen mit angehängtem „Tb“ und die Architektur „sim“ zu nennen. Wenn das Modul „MyModule“ heißt, heißt die Testbench „MyModuleTb“. Folglich werden die Dateinamen „MyModuleTb.vhd“ und „MyModule.vhd“.

Mit Hilfe des Testbench-Codes können wir überprüfen, ob das Modul in einer Simulationsumgebung korrekt funktioniert. Das zu testende Modul wird üblicherweise als zu testendes Gerät bezeichnet (DUT).

Module können auch innerhalb anderer Module instanziiert werden. Durch die Partitionierung des Codes in Module kann er mehrfach instanziiert werden. Sie können mehrere Instanzen eines Moduls innerhalb desselben Designs erstellen und es kann in vielen Designs wiederverwendet werden.

Die Syntax für eine Entität mit einem Port in VHDL lautet:
entity <entity_name> is
port(
    <entity_signal_name> : in|out|inout <signal_type>;
    ...
);
end entity;

Die Syntax zum Instanziieren eines solchen Moduls in einer anderen VHDL-Datei lautet:
<label> : entity <library_name>.<entity_name>(<architecture_name>) port map(
    <entity_signal_name> => <local_signal_name>,
    ...
);

Die <label> kann ein beliebiger Name sein und wird im Hierarchiefenster in ModelSim angezeigt. Die <library_name> für ein Modul wird im Simulator festgelegt, nicht im VHDL-Code. Standardmäßig wird jedes Modul in work kompiliert Bibliothek. Die <entity_name> und <architecture_name> muss mit dem Modul übereinstimmen, von dem wir eine Instanz erstellen. Schließlich muss jedes der Entity-Signale einem lokalen Signalnamen zugeordnet werden.

Es gibt andere Möglichkeiten, ein Modul in VHDL zu instanziieren, aber dies ist die grundlegende Syntax für die explizite Instanziierung.

Übung

In diesem Video-Tutorial lernen wir, wie man ein Modul in VHDL erstellt und instanziiert:

Der endgültige Code für die MUX Testbench :

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity T15_PortMapTb is
end entity;

architecture sim of T15_PortMapTb is

    signal Sig1 : unsigned(7 downto 0) := x"AA";
    signal Sig2 : unsigned(7 downto 0) := x"BB";
    signal Sig3 : unsigned(7 downto 0) := x"CC";
    signal Sig4 : unsigned(7 downto 0) := x"DD";

    signal Sel : unsigned(1 downto 0) := (others => '0');

    signal Output : unsigned(7 downto 0);

begin

    -- An instance of T15_Mux with architecture rtl
    i_Mux1 : entity work.T15_Mux(rtl) port map(
        Sel    => Sel,
        Sig1   => Sig1,
        Sig2   => Sig2,
        Sig3   => Sig3,
        Sig4   => Sig4,
        Output => Output);

    -- Testbench process
    process is
    begin
        wait for 10 ns;
        Sel <= Sel + 1;
        wait for 10 ns;
        Sel <= Sel + 1;
        wait for 10 ns;
        Sel <= Sel + 1;
        wait for 10 ns;
        Sel <= Sel + 1;
        wait for 10 ns;
        Sel <= "UU";
        wait;
    end process;

end architecture;

Der endgültige Code für das MUX Modul :

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity T15_Mux is
port(
    -- Inputs
    Sig1 : in unsigned(7 downto 0);
    Sig2 : in unsigned(7 downto 0);
    Sig3 : in unsigned(7 downto 0);
    Sig4 : in unsigned(7 downto 0);

    Sel  : in unsigned(1 downto 0);

    -- Outputs
    Output : out unsigned(7 downto 0));
end entity;

architecture rtl of T15_Mux is
begin

    process(Sel, Sig1, Sig2, Sig3, Sig4) is
    begin

        case Sel is
            when "00" =>
                Output <= Sig1;
            when "01" =>
                Output <= Sig2;
            when "10" =>
                Output <= Sig3;
            when "11" =>
                Output <= Sig4;
            when others => -- 'U', 'X', '-', etc.
                Output <= (others => 'X');
        end case;

    end process;

end architecture;

Das Wellenformfenster in ModelSim, nachdem wir auf Ausführen gedrückt und die Zeitachse vergrößert haben:

Analyse

Wie wir aus der Wellenform ersehen können, funktioniert das Multiplexer (MUX)-Modul wie erwartet. Die Wellenform ist identisch mit der aus dem vorherigen Tutorial, die wir ohne die Verwendung von Modulen erstellt haben.

Jetzt gibt es eine klare Trennung zwischen dem Designmodul und der Testbench. Das Modul, das den MUX enthält, ist das, was wir in einem Design verwenden möchten, und der einzige Zweck der Testbench besteht darin, es uns zu ermöglichen, es in einem Simulator auszuführen. Es gibt einen Prozess in der Testbench, der wait verwendet Anweisungen zum Erzeugen künstlicher Zeitverzögerungen in der Simulation. Das Designmodul kennt keine Zeit, es reagiert nur auf äußere Reize.

Wir haben die Architektur der Testbench sim genannt , zur Simulation. Die Architektur des Designmoduls wurde rtl genannt , was für Register-Transfer-Level steht. Dies sind nur Namenskonventionen. Wenn Sie eine Datei mit einem solchen Namen sehen, wissen Sie sofort, ob es sich um eine Testbench oder ein Designmodul handelt. Unterschiedliche Unternehmen können unterschiedliche Namenskonventionen haben.

Imbiss

• Eingangs- und Ausgangssignale werden in der Entität eines Moduls spezifiziert
• Ein Modul ohne Ein-/Ausgangssignale wird als Testbench bezeichnet , und es kann nur in einem Simulator verwendet werden
• Ein Modul mit In/Out-Signalen kann normalerweise nicht direkt in einem Simulator ausgeführt werden

Weiter zum nächsten Tutorial »