Probleme mit asynchronem Signal bei CPLD

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Hallo,

ich verwende hier einen XILINX-Coolrunner XCR3064XL.
Es soll eine Art digitales, nicht retriggerbares Monoflop
realisiert werden, dessen Start natuerlich um die Taktperiode
jittert.

Ausschnitt aus dem VHDL-Code:
start ist das Eingangssignal, clk der dazu asynchrone Takt,
run zeigt an, dass die Zeit laeuft, bloc verhindert das
Retriggern, wenn start nach Ablauf der Zeit noch high sein
sollte.

process (clk)
begin
    if (rising_edge(clk)) then
       if (start = '1') and (run = '0') and (bloc = '0') then
          run <= '1';
       end if;

      if (run = '1') then      -- zähle delay runter
          delay_cnt <= delay_cnt - 1;
          bloc <= '1';
       end if;

       if (delay_cnt = "0000000000") then
          run <= '0';
          delay_cnt <= delay_time;
       end if;

       if (start = '0') then
          bloc <= '0';         -- Blockadesignal wird erst geloest,
                               -- wenn start wieder low ist
       end if;
    end if;
end process;

Normales timing sieht so aus:

clk     --__--__--__--__--__--__--__--__--__--

start   _____--------------------------______

run     ________------------_________________

bloc    ____________--------------------_____


Durch Erreichen eines metastabilen Zustandes des run-Flip-Flops
passiert es manchmal, dass das bloc-Signal kommt, obwohl das
run-Signal low ist. In diesem Fall geht mir ein Trigger-Ereignis
verloren

Weiss jemand, wie man so etwas verhindern kann?

Mathias Weierganz


Re: Probleme mit asynchronem Signal bei CPLD
: Hallo,

: ich verwende hier einen XILINX-Coolrunner XCR3064XL.
: Es soll eine Art digitales, nicht retriggerbares Monoflop
: realisiert werden, dessen Start natuerlich um die Taktperiode
: jittert.

: Ausschnitt aus dem VHDL-Code:
: start ist das Eingangssignal, clk der dazu asynchrone Takt,
: run zeigt an, dass die Zeit laeuft, bloc verhindert das
: Retriggern, wenn start nach Ablauf der Zeit noch high sein
: sollte.

: process (clk)
...
:        if (start = '1') and (run = '0') and (bloc = '0') then
...
:        if (start = '0') then
Du verwendest "start" an zwei Stellen. Da Start asynchron ist, wird es
irgendwannmal bestimmt  an der Taktflanke an einer Stelle schon gesetzt
sein, and der anderen Stelle aber noch nicht. Und dann kracht es.

Setze mit "start" ein FF, dass Du zuruecksetzt, wenn Du den Start in der
anderen Clockdomaene erkannt hast.

Bye

--
Uwe Bonnes                 snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
We've slightly trimmed the long signature. Click to see the full one.
Re: Probleme mit asynchronem Signal bei CPLD

Quoted text here. Click to load it
Das koennte natuerlich Probleme bereiten, tut es hier aber nicht.

Mein Problem ist, dass manchmal das bloc-Signal kommt, obwohl das run-Signal

low ist. Meine Erklaerung waere, dass run in den Metastabilen Zustand kommt

und "etwas" high wird. Das bloc-Flipflop sieht dieses high und der Clock
fuer dieses Flipflop ist minimal spaeter als fuer das run-Flipflop.
Ergebnis: bloc ist und bleibt high, run faellt wieder runter auf low.
Das ist genau das, was ich auch messen kann: bloc kommt zu frueh und
auf run ist eine kleine Erhebung.

Als Loesung habe ich versucht, run mit der positiven Flanke zu triggern,
  bloc aber mit der negativen: Das hat merkwuerdigerweise aber nichts
gebracht.

 

Interessanterweise kam das Problem erst jetzt auf, nachdem ich von
Xilinx Webpack4.1 auf 4.2 gewechselt habe. Aber generell will ich
wissen, wie ich so eine Schaltung sicher machen kann.

Mathias Weierganz
Physikalisch Technische Bundesanstalt
FB Neutronenstrahlung




Re: Probleme mit asynchronem Signal bei CPLD
Quoted text here. Click to load it

1) Ich würde trotzdem "start" sauber einsynchronisieren!

2) passen die timing-constraints für deinen clock? werden sie eingehalten?


Quoted text here. Click to load it

wenn dein Start in der Nähe deiner Clockflanke umschalten kann, dann werden
setup und hold-Zeiten verletzt -> im schlimmsten Fall ist das Verhalten
nicht vorhersagbar - auch die Simulation merkt das nicht!

Die Synthese/Map/Routing kann nur synchrone Abläufe analysieren (eben von
einer Clockflanke zur nächsten) - die Beziehung der Eingangssignale zum
Clock ist hier schwer zu erfassen ...



Gegen Metastabile Zustände kann man meines Wissens nach nichts tun - sie
werden nur durch mehrstufiges Einsynchronisieren unwahrscheinlicher. Ich
glaube jedoch nicht, dass die hier das Problem sind ...



bye,
Michael


Re: Probleme mit asynchronem Signal bei CPLD
Moin Mathias,

Quoted text here. Click to load it

Du könntest dafür sorgen, dass 'run' nur an einer Stelle (z.B. if)
zugewiesen wird.
Bei deinem Code könnten laufzeitbedingt beide zuweisungen erfolgen,
so dass Dein Problem auftritt.

Grüsse
  Robert

Re: Probleme mit asynchronem Signal bei CPLD
Quoted text here. Click to load it

Üblicherweise durch synchronisieren des Inputs mit Clk durch
Schieberegister.
[normalerweise sieht man den IC als Synchron und externe Signal
asynchron dazu an :)]

start_sr<=start_sr(1 downto 0)&start;
-- start_sr(2) sollte keine Metastabilitaet sehen.
 
bye Thomas

Re: Probleme mit asynchronem Signal bei CPLD

Quoted text here. Click to load it

Dazu gab es vor einiger Zeit mal eine (Riesen-) Diskussion in
der US-Forth-Newsgroup. Einer der Artikel hat folgende Header-
Zeilen:

Newsgroups: comp.lang.forth
Subject: Re: Is "meta-stability" a non-issue
         [was in thread of Re: Timer on PC  with uS resolution.]
Date: Sat, 09 Nov 2002 06:59:24 -0500
Organization: Arius, Inc
Lines: 42

Bernd Paysan (aus D) hat dazu die Meinung vertreten, dass Meta-
stabilität _heute_ kein Problem mehr sei; einige andere Teilneh-
mer bestanden vehement darauf, dass dieses 'Grundgesetz' der
Schaltungstechnik nicht zu vernachlässigen sei...

Viel Zeit beim Lesen wünschend, Holger

Site Timeline