VHDL: Signalvergleiche für die Synthese optimieren

Als Vorwort werden in VHDL/Verilog bestimmte Codierungsstile verwendet, die den Synthesewerkzeugen helfen, auf unterschiedliche Hardware zu schließen (einige sind leistungsstärker als die anderen). Beispielsweise würde die Verwendung einer If-Else-If-Leiter auf eine Reihe von Muxen schließen, während eine Case-Anweisung auf einen einzelnen breiten Multiplexer schließen würde. Diese Codierungsstile sind nicht signifikant, wenn nur eine funktionale Simulation durchgeführt wird, aber wesentlich, wenn die RTL für die ASIC- oder FPGA-Implementierung angestrebt wird. Im Fall von FPGAs definiert die CLB-Architektur (konfigurierbarer Logikblock) die Fähigkeiten, die unter Verwendung von RTL erreicht werden (wie die LUT-Eingabebreite).

Kommen wir zur Frage: Ich habe viele Fälle gesehen, in denen zwei n-Bit breite Signale möglicherweise in VHDL verglichen werden müssen. Und ich brauche einen Rat zur Hardware-Inferenz. Ich werde das folgende Code-Snippet verwenden, um die Frage weiter einzugrenzen.

signal counter_a: unsigned(31 downto 0);
signal counter_b: unsigned(31 downto 0);
signal clk, trigger_en, count_b_en : std_logic;

counter_a_gen: process (clk) begin
    if(rising_edge(clk)) then
        counter_a <= counter_a + 1; -- free running counter
    end if;
end process;

counter_b_gen: process (clk) begin
    if(rising_edge(clk)) then
        if(count_b_en = '1') then
            counter_b <= counter_b + 1;
        else 
            counter_b <= (others => '0');
        end if;
    end if;
end process;

-- compare the counters to generate some logic
trigger_gen: process (clk) begin
    if(rising_edge(clk)) then
        if(counter_a = counter_b) then
            trigger_en <= '1';
        else 
            trigger_en <= '0';
        end if;
    end if;
end process;

Das obige Snippet hat zwei 32-Bit-Zähler counter_a und counter_b, die in einem sequentiellen Block verglichen werden müssen. Wenn ich eine LUT mit 4 Eingängen in einem FPGA betrachte, würde der Vergleich mehrere Logikebenen erfordern. Ein derartiger Pfad würde es aufgrund der enormen kombinatorischen Verzögerungen schwierig machen, das Timing einzuhalten. Meine Frage ist also, wie machen wir es optimiert? In diesem Fall um die Leistung zu steigern?