Altera + VHDL

Dein VHDL code sollte so funktionieren, zumindest wenn du
Reset vorerst mal fest auf 0 laesst.

Was erzeugt dein Clock? Prellender Taster?

Cheers, Roger

Hast du schon mal das Clock Signal angeschaut?
Ein Emulator als Taktquelle klingt nicht sehr ueberzeugend.
Du benutzt schon den dedicated clock Eingang deines EPM3032?

Cheers, Roger

Als du dich noch mit dem Schema auseinandergesetzt hattest, waehre das 
Einfachste gewesen, du haettest ein lpm_counter instanziert, anstatt 
deinem FF aufbau.
Koenntest du jetzt immer noch wenn du das VHDL anzweifelst, jedoch ist 
die 4bit counter beschreibung korrekt. WIe Axel beschrieben hat, lass 
vorerst reset und enable weg, um deinen clock zu debuggen.

Das Pattern wie auch deine Beschreibung deutet auf ein Problem mit dem 
Clock Signal hin. Pegel, Anstiegs-/Abfallzeit sowie 
Ueber-/Unterschwinger, oder halt auch ein Softwareproblem zusammen mit 
dem debugger.

Da du ja mit LEDs debuggen tust scheint die Clockfrequenz irrelevant, 
also kannst du dein bestehendes Signal mal mit einem Schmitt-Trigger 
buffern (HC14),
oder den Clock mit einem entprellten Taster generieren.

Cheers, Roger

Das möcht ich aber nun auch wissen. (?)

Bei XP muss nichts installiert werden, da die Software den Treiber 
selber findet. Bei den anderen muss der JTAG-Server mitlaufen. Das geht 
sogar bei Win98.

Normalerweise würde man ja zweimal sampeln und vergleichen. Da sich der 
Zähler auch unter NOrmalbedingungen geändert haben kann, reicht ein 
Vergleich nicht aus.

Eine Möglichkeit wäre, den Konstanzvergleich nur über die Bits zu 
ziehen, welche sich in einem typischen Intervall nicht ändern. Bei einem 
aufwärts zählenden Zähler könnte man auf größer prüfen, bzw neue 
Zählerstände antizipieren oder zumindest bei der Ausgabe extrapolieren.

Einen gewissen Gewinn erzielst Du, wenn Du auf der positiven und der 
negativen Flanke sampelst oder gleich mehrere Takte nutzt, die 
90/180/270 verschoben sind.

Dann hätte ich da noch 2 Spezialtricks, die ich noch nicht in der 
Literatur gefunden habe, die aber glänzend funktionieren. Leder personal 
IP :D

Wäre aber interesannt zu hören, wie andere das machen!

?

@  Jürgen ... (engineer)

>Normalerweise würde man ja zweimal sampeln und vergleichen. Da sich der

Und tappst damit in die gleiche Falle wie tausende vor dir.

>Wäre aber interesannt zu hören, wie andere das machen!

Dazu muss der OP schon mal ein klein wenig genauer das problem 
beschreiben.

MFG
Falk

Wenn beide erfassten Werte dieselben sind, war der Zahler über mehr, als 
eine Taktperiode konstant. Bei einem Zähler gibt es keine ungünstig 
gesampelten Interzustände, die direkt hintereinander auftreten.

Falls Du doch einen siehst, dann bBeschreibe mir bitte mal, was beim 
zweifach kaskadierten sampeln nicht funktioneren soll.

@  Jürgen ... (engineer)

>Wenn beide erfassten Werte dieselben sind, war der Zahler über mehr, als
>eine Taktperiode konstant.

Da wäre ich vorsichtig.

> Bei einem Zähler gibt es keine ungünstig
>gesampelten Interzustände, die direkt hintereinander auftreten.

HA! Das ist zu 100% falsch. Was glaubst du, warum asynchrone FIFOs 
Gray-Code für die Zähler nutzen? Was passiert, wenn z.B. ein 4 Bit 
Zähler von 0111 auf 1000 springt, aber die unteren Bits einen Tick 
langsamer sind als Bit#3? Dann liest du 1111, was VOLLKOMMEN daneben 
ist.

>Falls Du doch einen siehst, dann bBeschreibe mir bitte mal, was beim
>zweifach kaskadierten sampeln nicht funktioneren soll.

Es funktioniert schon mal nicht für den OP, da der externe Zähler 
schneller läuft als des FPGA. Allgemein könnte es funktionieren, 
allerdings muss der Zähler dann mindestens um den Faktor 2 langsamer 
laufen als die abtastende Logik. Bei einem asynchronen FIFO geht das nur 
in eine Richtung, womit die Methode aus dem Rennen wäre. Ausserdem hab 
ich dabei ein ungutes Gefühl, kann ich aber jetzt nicht genauer sagen 
warum.

MfG
Falk

Falk, gleich zum Dritten Punkt: Ich HABE habe geschrieben, daß man 
NORMALERWEISE ... und es in seinem Fall eben NICHT geht, ok ?

Zum zweiten : Du must auch hier hart an der Frage bleiben! Die 
Gray-Codierung ist lediglich eine Vereinfachung in der Abprüfung und 
sicher generell empfehlenswert.  Da wir aber hier einen externen Zähler 
mit unbekannter Codierung haben (ich bezog mich auf die Zwischenfrage) 
wird es eben komplizierter:

Solche Zähler sind zu behandeln, wie jede andere Datenstrecke, die nicht 
als einzelnes Signal, sondern als Bus daherkommt. Somit ergibt sich die 
Notwendigkeit der Abprüfung auf Konsistenz und das zweifache Samplen. 
Beim Beispiel Gray hätten wir das nicht, sondern müssten nur einmal 
sampeln, um Stabilität zu erzeugen und dann auf Veränderung eines der 
Signale prüfen.

Wie ich beschrieb, muss man hier mindestens zwei Werte Sampeln und auf 
Konsistenz prüfen, weil eben genau das passieren kann, was Du in Deinem 
Beispiel beschreibst. Durch den Vergleich zweier zetilich getrennter 
Werte werden solche "unsinnige" Daten zwar kurzzeitig in den 
Pufferregistern stehen, aber sie werden aben nicht verwendet. Das genau 
ist der Sinn der Prüfung auf Konsistenz im Gegensatz zur reinen 
Veränderungsabfrage.

Der designtechnische Unterschied ist die erhöhte Latzenz, die 1 CLock 
und ein bischen kombinatoriche Laufzeit schlechter ist.

Zum ersten : Ich bin genrell vorsichtig :-)  Ich habe aber genau solche 
Datenübernahmen sowohl in ASICs als auch FGPAs bereits mehrfach 
erfolgreich und HF-fest realisiert.

Genrell ist also erforderlich, daß man zweimal denselben Wert erwischt, 
bevor er sich regulär ändert. Das entspricht der Abtastproblematik. 
Selbstredend darf man auch keine zu langsam ändernden Zähler mit 
schlechten Flanken zu häufig abtasten, da man so die schlechten 
Zwischenwerte sieht. Einen solchen Fall hatte ich mal bei Audiosignalen 
(CLOCK und zugehörige SIGNALE) über Optokoppler: Die krochen derart 
langsam hoch, daß man mehrere clocks lang im FPGA fehlerhafte Daten sah.

Soweit sollte das also klar sein.

Es bleibt also wieder die Ursprungsfrage, wie man mit Zählern umgeht, 
die aus schneller taktenden Domänen stammen. In einem konkreten Beispiel 
hatte ich einen extern gepulsten Zähler, der eine Art 
Spannungsfrequenzwandlung macht und mit 1kU bis 100MHz pulst. Das FPGA 
lief intern auf 40 MHz.

Die Aufgabe war, so schnell wie möglich aktualisierte Zählerstände 
abzutasten. Ich konnte das mit 75ns maximaler Latenz lösen. Inklusive 
Zählerantizipation laufe ich dem Ergebnis je nach Steigung maximal 5 bis 
10ns hinterer.

Was wäre Deine Lösung, um solche Zähler zu erwischen?
(Datenkonsistent und einigermassen logisch reale Werte zeigend)

@ Jürgen ... (engineer)

>Zum zweiten : Du must auch hier hart an der Frage bleiben! Die
>Gray-Codierung ist lediglich eine Vereinfachung in der Abprüfung und

Nein, erst dadurch wird sie sinnvvoll und SICHER!

>Selbstredend darf man auch keine zu langsam ändernden Zähler mit
>schlechten Flanken zu häufig abtasten, da man so die schlechten
>Zwischenwerte sieht.

???

> Einen solchen Fall hatte ich mal bei Audiosignalen
>(CLOCK und zugehörige SIGNALE) über Optokoppler: Die krochen derart
>langsam hoch, daß man mehrere clocks lang im FPGA fehlerhafte Daten sah.

Ahhh, das ist aber was anderes als ein lansam ändernder Zähler. Ein 
Schmitt-Trigger ist hier das Mittel der Wahl.

>Was wäre Deine Lösung, um solche Zähler zu erwischen?
>(Datenkonsistent und einigermassen logisch reale Werte zeigend)

Nach Möglichkeit sollte man den Zähler mit dem schnellen Takt in den 
FPGA schreiben, und dann per Register und Flag in die andere Taktdomäne 
bringen.
Wenn der schnelle Takt nicht verfügbar ist bleibt nur die doppelte 
Abtastung wie du sie gemacht hast. Wobei das eher schwierig wird, weil 
man ja nie mit 40 MHz einen mit 100MHz laufenden Zähler ZWEIMAL gleich 
erfassen kann.

MfG
Falk

1) Du hast nicht immer Gray. Hake das mal ab.

2) JA, es war kein Zähler. Das Beispiel diente dazu, die linksseitige 
Problematik (Zu schnelles Samplen auf der Flanke) zu betrachten.

3) Ja, wird schwierig. Im Beispiel ist der Takt mal langsam und mal 
schnell. Einfach rücbersynchen geht also nicht. Nenne mir Deine Lösung. 
?

@ Jürgen ... (engineer)

>1) Du hast nicht immer Gray. Hake das mal ab.

Käse! Das hab ich ja wohl als FPGA-Entwickler in der Hand!

>3) Ja, wird schwierig. Im Beispiel ist der Takt mal langsam und mal
>schnell. Einfach rücbersynchen geht also nicht. Nenne mir Deine Lösung.
>?

Eine Lösung für ein unzureichend beschriebenes Problem? Was soll das?

MFG
Falk

Ach Mensch, lies doch mal: Es ging um ein xternes Modul, also was 
physikalisches.

Noch ein anderer Tipp: Du kommts kompetenter rüber, wen Du solche 
Sprüche wie "Unsinn, Quatsch" unterlässt. (Nur ein unverbindlicher Tipp 
und da heute Sonntag ist, sogar kostenlos)