Ableitung von D-Latch auf Zedboard innerhalb von Vivado Error

Was hier passiert, ist, dass die Tools Ihr Enable-Signal als Takt interpretieren. (Sie können Ihr implementiertes Design im Tool anzeigen, um dies zu überprüfen.) Wenn Sie versuchen, eine asynchrone Logik zu entwerfen, bemühen sich die Tools im Allgemeinen sehr stark, einen Takt zu finden, da FPGA-Timing-Modelle von einem synchronen System ausgehen.

Sie erhalten also die CLOCK_DEDICATED_ROUTE-Warnung, weil die Tools glauben, dass das Aktivierungssignal eine echte Uhr ist. Wenn es sich um eine echte Uhr handelt, sollten Sie die speziellen Taktstifte auf dem FPGA verwenden, die direkt mit Takt-Routing-Ressourcen verbunden sind. (Diese sind mit MRCC und SRCC für Multi-Region bzw. Single-Region gekennzeichnet.) Da Ihre Signale jedoch von physischen Schaltern kommen, spielt das nicht ideale Routing für die Zwecke Ihres Experiments keine Rolle.

Eine Sache, die Sie tun könnten, ist ein Earle-Latch, das eine Form von D-Latch ist, das ein UND-ODER mit drei Begriffen verwendet. Es sollte von Ihrem Synthesetool nicht als sequentielle (getaktete) Logik erkannt werden. Siehe Wie kann ich einen einfachen D-Latch nur für Q mit VHDL implementieren? .

Ohne einen zweiten Latch für auszudrücken Qbar:

library ieee;
use ieee.std_logic_1164.all;

entity dlatch is
    port (
        D:      in  std_logic;
        Enable: in  std_logic;
        Q:      out std_logic;
        Qbar:   out std_logic
    );
end entity;

architecture fum of dlatch is
    signal QQ:   std_logic;
begin
    process(D, enable, QQ) 
    begin
        QQ <= (Enable and D) or 
              (not Enable and QQ) or
              (D and QQ);          -- consensus term
        Q <= QQ;
       Qbar <= not QQ;
    end process;
end architecture;

Dies sollte synthesefähig sein.

Und hier ist eine Testbench, um festzustellen, ob die drei Begriffe richtig sind:

library ieee;
use ieee.std_logic_1164.all;

entity dlatch_tb is
end entity;

architecture test of dlatch_tb is
    signal D:       std_logic := '0';
    signal Enable:  std_logic := '0';
    signal Q:       std_logic;
    signal Qbar:    std_logic;

    component dlatch is
        port (
            D:      in  std_logic;
            Enable: in  std_logic;
            Q:      out std_logic;
            Qbar:   out std_logic
        );
    end component;

begin
DUT:
    dlatch
        port map (
            D => D,
            Enable => Enable,
            Q => Q,
            Qbar => Qbar
        );
STIM:
    process
    begin
        wait for 10 ns;
        Enable <= '1';
        wait for 10 ns;
        Enable <= '0';
        wait for 10 ns;
        d <= '1';
        wait for 10 ns;
        Enable <= '1';
        wait for 10 ns;
        Enable <= '0';
        wait for 10 ns;
        wait;
    end process;
end architecture;

Auf der anderen Seite "- Macht nichts"

Ich verwende Benutzer-E/A für die Einschränkungen für die Ein-/Ausgänge. Die Eingänge weise ich zwei SWITCH-Pins und die Ausgänge zwei LED-Pins zu.

Und

Wie finde ich einen taktfähigen Eingang, den ich wie auf dem Schalter drücken/bewegen kann?

Wenn Sie Schalter verwenden, um Ihr Latch zu bedienen, sollten Sie sich nicht um ein suboptimales Routing kümmern, und das Festlegen der Einschränkung „CLOCK_DEDICATED_ROUTE“ in der .xdc-Datei, um diese Nachricht zu einer WARNUNG herabzustufen, ist vollkommen gültig.

Es ist höchst unwahrscheinlich, dass Sie beide Schalter so nahe beieinander umschalten können, dass Sie riskieren, den "falschen" Zustand mit einiger Sicherheit zu speichern, in welcher Reihenfolge sie umgeschaltet haben. Wir sprechen von einem suboptimalen Routing in der extrem engen Größenordnung einer Nanosekunde, wenn man die geringe kapazitive Belastung berücksichtigt.