Forum: FPGA, VHDL & Co. Implementierung eines Encoder Interface mit FPGA

Der ist aber schwer prellanfällig wie mir scheint(?). Da werden nur 
Änderungen der Eingangssignale betrachtet, die sich aus alten und neuen 
Werten ergeben. Diese wiederum werden mit dem Systemtakt eingetaktet, 
als viel zu schnell. Da muss wenigstens ein Zähler hinein, der das 
abremst!

Jens W. schrieb:
> Keiner schreibt hier wie hoch der Systemtakt sein muss/soll. Du gehst
> einfach mal von einigen MHz aus.

... was bei FPGAs aber nicht so ganz ungewöhnlich ist, oder?
Wie niedrig muss der Takt denn sein, dass es funktioniert?

Und wieso dann überhaupt einen FPGA?

Christian R. schrieb:
> Naja, selbst wenn es prellt, wackelt es höchstens +-1 Schritt herum,
> aber zählt insgesamt korrekt.
Na geil.

>Ich halt die Variante für sehr robust,
Eine neue Definition von "robust"

Habe es kurz simuliert: Ja, der Zähler zählt richtig, aber er springt:

- 100 MHz Taktfrequenz
- 5 ms Nachschwingen
- Dreh von 200 ms

Bei 10 MHz sieht es kaum besser aus

FPGA-Experte schrieb im Beitrag #7353979:
> Habe es kurz simuliert: Ja, der Zähler zählt richtig, aber er springt:
Signalnamen wären ganz hilfreich!
Das Netz für up_dn, ce und err hinter den registrierten Encodersignalen 
darf natürlich glitchen. Und der Clock muss f_max erfüllen bzw. setup, 
hold und delays entsprechend klein sein.

Verstehe jetzt das Bild. Zuerst wird ein prellendes Encodersignal 
gebastelt und wenn der Clock schnell genug ist, wird das Prellen 
eins-zu-eins weitergereicht.
Um das wegzubekommen, darf man erst einen 2er-Abstand durchreichen. 
Beispiel einer digitalen Entprellung:
5-6-5-6-6-6-6-6-7-6-7-7-6-7-7-7-7-8-7-8-8-8-8-8... =>
5-5-5-5-5-5-5-5-6-6-6-6-6-6-6-6-6-7-7-7-7-7-7-7...

Läuft auch unter dem Begriff Hysterese oder Mitkopplung.

dfIas schrieb:
> Das Netz für up_dn, ce und err hinter den registrierten Encodersignalen
> darf natürlich glitchen.
Eben und das tun sie, bei 100,10 und 1 MHz.
Nur wenn der Takt so langsam ist, dass er das Prellen überliest, dann 
verschwindet der Effekt. Er zählt aber dann falsch, denn er bekommt nur 
Teile des Prellens mit, was zu dem bekannten springen führt.

Lothar M. schrieb:
> aber je schneller er abgetastet wird, umso mehr entspricht
> es der (schlechten) Realität.
Das ist aber die Kontakt-Realität. Was benötigt wird, ist die 
Dreh-Realität. Man sollte den Code erweitern oder den Nutzer darauf 
hinweisen.

dfIas schrieb:
> Zuerst wird ein prellendes Encodersignal
> gebastelt und wenn der Clock schnell genug ist, wird das Prellen
> eins-zu-eins weitergereicht
Erst wird das nichtprellende Signal erzeugt, dann das Prellen addiert
unten ist der Zähler, der aufbund abwaerst läuft.

dfIas schrieb:
> m das wegzubekommen, darf man erst einen 2er-Abstand durchreichen.
> Beispiel einer digitalen Entprellung:
Was heisst "2-er Abstand"?

Eigentlich macht man das ganz anders und baut die Decodierung in die 
state machine ein, indem eine erkannte Richtung mit implementiert wird.

FPGA-Experte schrieb im Beitrag #7354430:
> dfIas schrieb:
>> Das Netz für up_dn, ce und err hinter den registrierten Encodersignalen
>> darf natürlich glitchen.
> Eben und das tun sie, bei 100,10 und 1 MHz.
> Nur wenn der Takt so langsam ist, dass er das Prellen überliest, dann
> verschwindet der Effekt. Er zählt aber dann falsch, denn er bekommt nur
> Teile des Prellens mit, was zu dem bekannten springen führt.
Du verwechselst aber den Glitch, der durch Racing Conditions im 
Schaltnetz entsteht und den man durch eine CLK-Registrierung wegbekommt, 
mit dem Nutzsignal. Das Netz glitcht, das Nutzsignal prellt!
FPGA-Experte schrieb im Beitrag #7354430:
> Erst wird das nichtprellende Signal erzeugt, dann das Prellen
> addiert
> unten ist der Zähler, der aufbund abwaerst läuft.
Ja, und das macht er ganz korrekt. Glitch ist in dieser Auflösung nicht 
erkennbar und/oder wird auch vom Zähler nicht erkannt, nur das 
konstruierte (sehr langsame im Verhältnis zur Logik) Prellen.
Alles ok. Wie man so einen Zähler entprellt, hatte ich beschrieben. 
Benutze einen bidirektionalen Schleppzeiger, den du bei 2er-Abstand um 
einen Schritt weiterbewegst. Ein 2er-Abstand bedeutet, dass du erst beim 
angedeuten Wechsel des alternierenden Encoder-Signals (erste Flanke des 
prell-Bursts ist hinreichend) sicher bist, um mindestens 90° 
weitergerückt zu sein (denn du bist bereits bei 180° angekommen).
Und natürlich baut man alles in ein einziges Schaltwerk ohne externes 
Extra. Das ist in diesem verlinkten Beispiel tatsächlich sehr schlecht 
realisiert, insbesondere, da das Schaltnetz nicht frei von Racing ist. 
CE kann/wird früher oder später umschalten als UP_DN und muss zwingend 
auf CLK synchronisiert werden. Eigenständig ohne externe Registrierung 
ist das Signal-Tripel dort nicht konsistent. (Was ein CE und ein UP_DN 
zwar nicht müssen, aber wenn man nur den VHDL-Code betrachtet, fällt das 
sofort ins Auge.)

Lothar M. schrieb:
> iel interessanter wird es, wenn der (hier recht unwahrscheinliche) Fall
> eintritt, dass die Register a_in bzw. b_in dupliziert werden, denn dann
> hat man auf einmal zwei unterschiedliche z.B. a_in Signale.
Ganz sicher nicht: Wenn die Schaltung sinnvoll constrained wurde (und 
dazu gehört das Schützen eines IO-FFs vor dem wegbewegt werden) ist das 
nur sehr theoretisch der Fall, wenn dieses FF metastabil sein sollte, 
was es bei modernen FPGAs zu 99,9999% nicht ist. Nur dann würden 
divergente Informationen weitergetaktet werden und selbst dann hätte man 
einen theoretischen Verzähler, der sicher unerheblich ist, gegenüber 
einer manuellen Fehlbedienung des Encoders.

Etwas anderes ist es bei eingetakteten Resets. Bei denen würde ich das 
Argument noch zulassen, dass man noch ein FF dazu setzt. Entscheidend 
ist jedenfalls, dass das IO-FF genutzt wird. Ansonsten eben zwei FFs mit 
"don't touch" gegen Anfassen schützen.


Lothar M. schrieb:
> Zusätzliche Synchronisationsregister für diese
> ausgangssignale brächten da nur Ressourcenverbrauch und einen Takt
> Latency.
Klar, das geht natürlich nicht. 2 LUTs für 2 Signale sprengen den FPGA 
und einen ganzen Takt Latenz fällt bei 3 Mikrosekunden, in denen 
Superman den Regler dreht, natürlich sofort auf.  :-)

Jetzt mal zum Eigentlichen:

Wir sprechen doch von etwas anderem: Wir drehen (oder lassen drehen) 
einen physikalischen Geber nach vorne und der Zählerwert springt hin und 
her. Kein Mensch braucht das. Ich möchte ein Signal haben, das sagt 
"zähle eines hoch" und ein zweites "zähle eins runter".

Mit einem einfachen diskreten Filter lässt sich das leicht beheben und 
die Werte ohne großes TamTam direkt interpretieren, sofern nicht schon 
ein RC-Glied an den Pins montiert wurde. Es braucht natürlich einen 
alten Wert, um eine Richtung zu erkennen und einen Zähler zu bedienen.

Eine solche CASE-FSM hat 4 Eingänge und genau 8 Optionen von 16*15 
möglichen Übergängen, die durch Schalten, Prellen, miese Kontakte oder 
EMV auftreten können. Die anderen sind Error und werden ignoriert.

Die Schaltung ist einfach kein gutes Code-Beispiel. Schon auch deshalb, 
weil sie encoder heißt, aber eigentlich ein Decoder ist.

Was es eigentlich bräuchte, wäre ein fertige Decoder-IP, die die 
Drehbewegung analysiert, die Beschleunigung berechnet, den Zähler 
entsprechend bedient und auch ausgibt.

Wenn man sich gegen ´Verzählen´ durch Störungen absichern möchte, kann 
man das Encoder-Signal direkt für die beiden unteren Bits des Zählers 
übernehmen (Gray => Binary) und sich nur noch um die Überträge kümmern. 
Man nutzt so quasi die Redundanz in den beiden unteren Stellen aus.
In dem verlinkten Beispiel werden ungültige Wechsel mit ERR geflagt. Ich 
habe dort nicht weitergelesen, wie dieses ERR später ausgewertet wird. 
Ohne Störeinflüsse wäre ERR ja ein Zeichen dafür, dass die Abtastung mit 
der Sensorfrequenz nicht mehr standhält. Ansonsten entscheidet die Länge 
eines Störbursts, ob der Fehler behebbar ist oder nicht. Ähnliche 
Betrachtungen gibt es bei der Sicherung serieller Codes. Aus dem Stand 
würde ich sagen, dass +/-1 behebbar ist, ab +/-2 geht die 
Richtungsinformation verloren, wenn man nicht weitere Redundanz 
heranzieht. Als weitere Redundanz wäre die Stetigkeit in der Bewegung zu 
sehen - also mechanische Redundanz, da Massen bzw. Momente nicht Null 
sind. Man müsste sich dazu mal ansehen, wie digitale Messschieber so 
arbeiten.

FPGA-Experte schrieb im Beitrag #7354878:
> Ganz sicher nicht: Wenn die Schaltung sinnvoll constrained wurde (und
> dazu gehört das Schützen eines IO-FFs vor dem wegbewegt werden) ist das
> nur sehr theoretisch der Fall, wenn dieses FF metastabil sein sollte,
> was es bei modernen FPGAs zu 99,9999% nicht ist.
Solange du mit einem asynchronen Signal auf ein einzelnes IO-FF gehst, 
geht es in der Tat nur noch um Metastabilität. Allerdings hat man sehr 
häufig auch asynchrone Signale innerhalb eines FPGA (z. B. mehrere Clock 
Domains für dies und jenes). Bei hohen Fanouts neigen einige 
Synthese-Tools gerne zur sogenannte Replication. Um hier ebenfalls ein 
einzelnes FF zur Abtastung zu erzwingen, müssen spezielle 
Signalattribute für die Synthese in den Code gesetzt werden. (Ich meine, 
dass man das nicht zu den sonst üblichen Constraints zählt.)
Ein Syntax-Beispiel aus einer FIFO-Implementation:

1

...

2

library synplify;

3

use synplify.attributes.all;

4

...

5

  -- preserve *_oppog from replication

6

  attribute syn_preserve of wr_oppog : signal is true;

7

  attribute syn_preserve of rd_oppog : signal is true;

8

...

dfIas schrieb:
> In dem verlinkten Beispiel werden ungültige Wechsel mit ERR geflagt.
Nee, wird es interessanterweise nicht, wie die Simuation zeigt. Das 
Springen und Wackeln ist danach ein gültiger Vorgang. Das err kommt nur 
am Anfang ein paar mal, wenn die Signale noch gleiche Werte haben. Das 
kann real eigentlich nur dann passieren, wenn eine Leitung tot geht.

dfIas schrieb:
> Solange du mit einem asynchronen Signal auf ein einzelnes IO-FF gehst,
> geht es in der Tat nur noch um Metastabilität
Die Thematik ist mir bestens bekannt und ich hatte auch erklärt, wie es 
verhindert wird, nämlich mit EINEM FlipFlop in der IO-Zelle, das nicht 
wegbewegt werden darf. Danach kannst du duplizieren, bis du blau wirst.

META als solches ist kein reales Problem, weil in der Praxis nicht 
vorkommend. Wenn es vorkäme, würde es zu einem Verzählen in 100.000 
Jahren führen. Kann man sich sparen. Dass in kritischen Anwendungen 
trotzdem Angst-FlipFlops gesetzt werden, hatte ich angefügt.

dfIas schrieb:
> Man müsste sich dazu mal ansehen, wie digitale Messschieber so
> arbeiten.
Die haben z.B. Schwingungen auf der Welle, die im Bremsbetrieb wegen 
rutschender Reibung massive Störungen machen, jedenfalls auf eng 
tolerierten optischen Scheiben.

FPGA-Experte schrieb im Beitrag #7355560:
> dfIas schrieb:
>> In dem verlinkten Beispiel werden ungültige Wechsel mit ERR geflagt.
> Nee, wird es interessanterweise nicht, wie die Simuation zeigt. Das
> Springen und Wackeln ist danach ein gültiger Vorgang. Das err kommt nur
> am Anfang ein paar mal, wenn die Signale noch gleiche Werte haben. Das
> kann real eigentlich nur dann passieren, wenn eine Leitung tot geht.
Ach, was schreibst du denn da zusammen?!
Ja klar, ist das Prellen eines einzelnen Bits kein Fehler. Ungültig wäre 
hingegen ein (in Bezug zur Abtastung) gleichzeitiger Wechsel von mehr 
als einem Bit (Gray-Code!), also hier von 00=>11, 01=>10 usw. Das 
passiert im störungsfreien System nur, wenn die Abtastfrequenz zu klein 
für die Bewegung ist. Bei gesteigertem Missverhältnis entsteht Aliasing, 
bei dem Fehler nur noch quasi statistisch auftreten. Analogie hierzu:
Beim Film werden gerne fahrende Autos mit einer Bildfrequenz 
aufgenommen, bei der sich die Räder scheinbar rückwärts drehen.

dfIas schrieb:
> Aus dem Stand würde ich sagen, dass +/-1 behebbar ist, ab +/-2 geht
> die Richtungsinformation verloren,
Wieso sollte das passieren?

Die Richtungsinformation ergibt sich eindeutig aus der Differenz des 
alten und des neuen Zustands. Es muss lediglich ein stabiles Signal 
abgewartet werden, bevor eine neue Weitergabe eines Wertes erfolgt.