Flankendetektor - geht das so?

Gast #1577327
Lesenswert?

Hallo zusammen,

ich arbeite mich gerade in FPGAs ein und merke nebenbei, dass ich in 
Digitaltechnik auch nicht mehr ganz fit bin. Folgende Aufgabe:

Ich möchte einen Flankendetektor bauen. Wie das in VHDL geht, habe ich 
in der Artikelsammlung gefunden. Ich möchte es gerne grafisch lösen. 
Kann ich das so wie im Anhang dargestellt machen? Oder werde ich später 
Timing Probleme bekommen? In der Simulation funktioniert's.

Beide FF reagieren auf die gleiche steigende Flanke. Sollte das rechte 
FF diese Flanke aber auch nur einen Moment später bekommen, so dass der 
Ausgang des linken FF schon den Eingang übernommen hat, funktioniert der 
Detektor nicht.

Wie macht man's also richtig?

Grüße
Steffen
Angehängte Dateien:
Gast #1577502
Lesenswert?

Danke für Deine Antwort, supachris. Was aber ist mit meinem Einwand?

Das Timing steht und fällt mit der Laufzeit der FF. Sollte sich das 
Taktsignal zu einem der FF um die Laufzeit des anderen verzögern, 
funktioniert die Schaltung schon nicht mehr. Wer garantiert mir, dass 
das nicht passiert? Ist das eine allgemeingültige Regel, von der man 
immer ausgehen kann?
Moderator (Firma: Titel) Persönliche Seite #1577521
Lesenswert?

Steffen Hausinger schrieb:
> Beide FF reagieren auf die gleiche steigende Flanke. Sollte das rechte
> FF diese Flanke aber auch nur einen Moment später bekommen, so dass der
> Ausgang des linken FF schon den Eingang übernommen hat, funktioniert der
> Detektor nicht.
Keine Sorge. Prinzipiell hast du dieses Problem in jedem synchronen 
Design.

> Wer garantiert mir, dass das nicht passiert?
Dass genau diese Race-Condition nicht auftritt, dafür haben die 
Entwickler von CPLDs und FPGAs gesorgt. Dafür gibt es in einem FPGA z.B. 
speziell ausgelegte Taktnetze, im CPLD gibt es dafür spezielle 
Takteingänge.
#1577555
Lesenswert?

So ist es. Solange sich das innerhalb des CPLD oder FPGA mit dem 
gleichen Takt, der auf einem Clock-Netzwerk liegt, abspielt, kann man 
davon ausgehen, das alle FF gleichzeitig schalten. Du hast ja schon 
völlig richig das 1. FF zum einsychronisieren des asynchronen Eingangs 
eingebaut, mehr kannst du nicht tun. Nach dem 1. FF ist das Signal 
garantiert synchron zum internen Takt. Kann halt nur je nach Lage der 
Flanke auch einen Takt später als das asynchrone Ereignis kommen, wenn 
die Setup-Zeit verletzt wird. Damit musst du leben.
Gast #1580861
Lesenswert?

Hallo,

es stellt sich nur noch die Frage, was du mit den 3 gewonnenen Signalen 
anfängst, da theoretisch bedingt durch unterschiedlichen Gatter- und 
Netzlaufzeiten Spikes auf deinen 3 Ausgängen auftreten könnten. Man muß 
die Weiterverarbeitung der Signale im Auge behalten, wenn man 
kombinatorische Logik zwischen dem letzten Flipflop und einem Ausgang 
hat.

Der Besucher
#1580880
Lesenswert?

Der Besucher schrieb:
> Hallo,
>
> es stellt sich nur noch die Frage, was du mit den 3 gewonnenen Signalen
> anfängst, da theoretisch bedingt durch unterschiedlichen Gatter- und
> Netzlaufzeiten Spikes auf deinen 3 Ausgängen auftreten könnten. Man muß
> die Weiterverarbeitung der Signale im Auge behalten, wenn man
> kombinatorische Logik zwischen dem letzten Flipflop und einem Ausgang
> hat.

Naja, notfalls noch ein FF hinter jedes Signal dann sind die Glitches 
weg. Im FPGA wird das allerdings kaum nötig sein, die 3 Signale werden 
bestimmt alle in der gleichen LUT abgebildet.
#1581023
Lesenswert?

Lothar Miller schrieb:
>> Im FPGA wird das allerdings kaum nötig sein, die 3 Signale werden
>> bestimmt alle in der gleichen LUT abgebildet.
> Öhmmm.... eine LUT mit 3 Ausgängen?
> Halb so schlimm, jeder hat mal seinen lichten Moment ;-)

Achje. Naja, wurde Zeit für Feierabend. Ich meinte eigentlich auch 
den/das Slice. Aber die meisten da haben auch nur 2 
LUTs/Slice....naja...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren