Umgang mit abgeleiteten Uhren während der RTL-Synthese

Ich versuche, ein Design in VHDL mit dem Synplify Pro-Tool in ein ProASIC3-FPGA zu synthetisieren. Der Synthesebericht gibt mir die folgende Warnung zu abgeleiteten Uhren.

@W:MT420 :  | Found inferred clock counter_unit| pstate_inferred_clock[1with period 10.00ns. Please declare a user-defined clock on object "n:bcu_ins.ctr_ins.pstate[1]"

Ich habe zu dem Teil des Codes zurückverfolgt, an dem die Warnung generiert wird, und das Gleiche wird hier als Referenz wiedergegeben.

p_fsm_clk : process(reset_n_in, clk_25mhz_in)
begin
    if (reset_n_in = '0') then
        pstate <= s0;
    elsif rising_edge(clk_25mhz_in) then
        pstate <= nstate;
    end if;
end process p_fsm_clk;

p_fsm : process(pstate,restart_ctr,enable_ctr2,sys_fail)
begin
    start_ctr1 <= '0';
    start_ctr2 <= '0';

    case pstate is
        when s0 =>
        --Reset state. All counters are reset
            if (sys_fail = '0' and restart_ctr = '1') then
                nstate <= s1;   --move to start counter1
            else
                nstate <= s0;
            end if;

        when s1 =>
            start_ctr1 <= '1';  --Initiate counter1
            if (restart_ctr = '1') then
            --restart the counters
                start_ctr1 <= '0';  --reset counter1
                nstate <= s1;
            elsif (enable_ctr2 = '1') then
            --move to start counter2
                nstate <= s2;
            else
                nstate <= s1;
            end if;

        when s2 =>
        --Save the counter1 value and start counter2
            start_ctr2 <= '1';  --assert flag to start counter2
            if (restart_ctr = '1') then
            --restart the counters
                nstate <= s1;
            else
                nstate <= s3;
            end if;

        when s3 =>
            start_ctr2 <= '1';
            if (sys_fail = '1') then
                nstate <= s0;
            elsif (restart_ctr = '1') then
            --restart the counters
                nstate <= s1;
            else
                nstate <= s3;
            end if;

        when others =>
            nstate <= s0;

    end case;
end process p_fsm;

--counter1
p_ctr1 : process(reset_n_in, clk_25mhz_in)
begin
    if (reset_n_in = '0') then
        ctr1 <= 0;  --value on reset
    elsif rising_edge(clk_25mhz_in) then
        if (start_ctr1 = '1') then
        --flag is asserted to start counter1
            ctr1 <= ctr1 + 1;   --increment counter
        else
        --flag de-asserted
            ctr1 <= 0;  --reset the counter
        end if;
    end if;
end process p_offset_cnt;

--save the value of counter1
offset_val <= ctr1 when pstate = s2;

Die Logik enthält zwei Zähler – ctr1und ctr2. Die Zähler werden ausgeführt, wenn keine Systemfehler vorliegen. In der ersten Phase ctr1wird ausgeführt, die dann von gefolgt wird ctr2. ctr1stoppt die Zählung, wenn ctr2aktiviert ist. Der Wert von ctr1bestimmt, wie viel später ctr2gestartet wird (in Bezug auf die 25-MHz-Taktperiode), was als Offset bezeichnet wird. Dieser Offsetwert wird in einem Signalvektor gespeichert, wie in der letzten Zeile des Codes zu sehen ist. Der Status s2wird verwendet, um den Wert von zu erfassen ctr1, bevor er auf 0 zurückgesetzt wird.

offset_val <= ctr1 when pstate = s2;

Mir wurde klar, dass diese Zuweisungsanweisung die abgeleitete Uhr im Design verursacht (aber ich weiß nicht warum). Wenn ich dieselbe Anweisung in einen getakteten Prozess einfüge, verschwindet die abgeleitete Uhrwarnung. Allerdings funktioniert meine Logik nicht richtig.

Ich bitte um ein paar Klarstellungen in dieser Hinsicht.

  1. Warum gibt es in diesem Design eine abgeleitete Uhr auf pstate[1]?
  2. Ist es in Ordnung, solche Aussagen im Design zu haben? Deutet das Vorhandensein abgeleiteter Uhren auf eine schlechte Designpraxis hin?
  3. Wenn es nicht in Ordnung ist, abgeleitete Uhren im Design zu haben, wie kann ich dies beheben, indem ich die Logik anders codiere?
  4. Wenn es in Ordnung ist, abgeleitete Uhren zu haben, wie kann ich das Tool darüber informieren? Welche Periodenbeschränkung kann ich für solche abgeleiteten Uhren bereitstellen? Wie kann ich einen sinnvollen Zeitraum für solche abgeleiteten Uhren bestimmen?

Antworten (1)

Sie haben ein Tag hinzugefügt FPGA, daher werde ich aus FPGA-Perspektive antworten. Wenn Sie einen ASIC erstellen oder einen anderen Flow verwenden, gilt möglicherweise eine andere Antwort.

pstate[1]1. Warum ist in diesem Design eine abgeleitete Uhr eingeschaltet ?

offset_val <= ctr1 when pstate = s2;

Diese Zeile beschreibt nichts, was passiert, pstatewenn nicht s2 . Dies bildet einen Gate-Latch. In jedem FPGA, das ich verwendet habe, wird dies implementiert, indem ein "Latch" -Modus in einem normalen Flip-Flop aktiviert wird, wobei der "Clock" -Pin als "Gate" verwendet wird. Ihr Gate-Signal verwendet an diesem Punkt Taktressourcen, wird aber letztendlich von einem anderen "Daten" -Signal abgeleitet, im Gegensatz zu einer "echten" Uhr.

2. Ist es in Ordnung, solche Aussagen im Design zu haben? Deutet das Vorhandensein abgeleiteter Uhren auf eine schlechte Designpraxis hin?

Latches sollten im Allgemeinen vermieden werden, es sei denn, es gibt einen triftigen Grund, sie zu haben, da sie normalerweise eine schlechte Timing-Leistung bieten und leichter zu Gefahren und Rennen im Design führen können. Ein Beispiel, bei dem Latches verwendet werden müssen, wäre, wenn eine externe Schnittstelle einen pegelempfindlichen Eingang irgendeiner Art verwenden müsste. In Ihrem Fall sieht es so aus, als ob es ziemlich einfach sein sollte, eine Verriegelung zu vermeiden.

3. Wenn es nicht in Ordnung ist, abgeleitete Uhren im Design zu haben, wie kann ich dies beheben, indem ich die Logik anders codiere?

Verwenden Sie einen getakteten Prozess, der die Zuweisung enthält. Dies wird ein Flip-Flop für ableiten offset_val. Sie müssten Ihr Design simulieren oder an Bord testen, um sicherzustellen, dass die Funktion in Ihrem speziellen Fall äquivalent ist, aber die grundlegende Philosophie im FPGA sollte sein, dass jede andere Zuweisung als einfach ist a <= b and c;oder some_vec <= smaller_vec & another_bit;einen getakteten Prozess verwendet. Auf diese Weise erhalten Sie vorhersagbare Timing-Ergebnisse und erleichtern das Schreiben von Einschränkungen. Es gibt Ausnahmen, aber das sollte der Ausgangspunkt sein.

4. Wenn es in Ordnung ist, abgeleitete Uhren zu haben, wie kann ich das Tool darüber informieren? Welche Periodenbeschränkung kann ich für solche abgeleiteten Uhren bereitstellen? Wie kann ich einen sinnvollen Zeitraum für solche abgeleiteten Uhren bestimmen?

Im Fall einer externen Schnittstelle hat der pegelempfindliche Eingang eine gewisse minimale Impulsbreite, und Sie können dies verwenden, um eine Periodenbeschränkung zu erstellen, die den schlimmstmöglichen Fall darstellt, wie dieses Signal umschalten könnte. Für alle internen Schnittstellen würde ich daran arbeiten, den vorhandenen Latch überhaupt zu vermeiden, aber die gleiche Technik könnte gelten. Indem Sie Latches ganz vermeiden, vermeiden Sie es, über diese Art von Problem nachdenken zu müssen.


Darüber hinaus ist das in Ihrem Code gezeigte Zustandsmaschinendesign mit zwei Prozessen nicht erforderlich. Sie können die gesamte Maschine und die Zustandsübergänge in einen getakteten Prozess packen. Der resultierende Prozess würde Ihrem zweiten Prozess oben sehr ähnlich aussehen, wobei alles in ein verpackt if (rising_edge(clk)) thenund jedes Vorkommen von nstateersetzt wird durch pstate. Sie sollten in der Lage sein, vorhandene Antworten zum Zustandsmaschinendesign entweder hier auf EE oder über das VHDL-Tag von Stack Overflow zu finden .

+1. Eine einzelne Prozesszustandsmaschine vermeidet so viele potenzielle Fallstricke und ist kürzer und einfacher. Es lohnt sich zu lernen.
Das war recht informativ. Mir ist jetzt klar, dass das Tool für diese Aussage auf einen Latch geschlossen hat. Das Tool hat dafür jedoch keine „inferred-latch“-Warnung generiert. Der Bericht zeigt nur eine Warnung auf der abgeleiteten Uhr an . Irgendeine Idee warum?
Das hast du erwähnt If you are creating an ASIC or using some other flow, a different answer might apply. Wie würde die Synthese bei einem ASIC anders aussehen? Ist das Vorhandensein von abgeleiteten Latches hier kein Problem?
@rvkrysh Verschiedene Tools geben unterschiedliche Warnungen aus, und ich habe Synplify Pro noch nie verwendet, daher weiß ich es nicht. Ich habe erwähnt, dass möglicherweise eine andere Antwort zutrifft, da ich weiß, dass Latches in einigen Designs anstelle von Registern verwendet werden können, um die Leistung in einem streng kontrollierten Teil des Designs zu verbessern, aber ich habe keine Erfahrung mit ASIC Ich habe es als "vielleicht"-Aussage belassen.