Protokoll Abtasten und Auswerten

[Max S. (prisherious)]

Guten Morgen an alle,

Ich komm direkt zur Sache:

Protokoll Analyse mittels FPGA lautet die Aufgabe, soweit.
Das Protokoll besitzt 2 Leitungen, Daten und Clock.
Ich muss die steigende sowie die fallende Flanke erkennen, da die Clock 
eine Frequenz von 25 MHz aufweißt muss ich ja mit 100 MHz 
abtasten.(Abtasttheorem)

aber irgendwie erscheint mir folgende überlegung sehr komisch:

Pseudocode:

clk = 100 mhz
Protokoll_clk = 25 mhz

process(clk,Protokoll_clk)
begin
 if(Steigende_Flanke(clk) then
    if(fallende_Flanke(Protokoll_clk)) then
       Schieberegister Code
     elsif(steigende_Flanke(Protokoll_clk)) then
       Schieberegister Code

end process

Ich kann doch nicht in einem Prozess 2 Clocks abfragen.
Aber ich hab momentan auch einfach keine andere Idee wie ich das angehen 
soll.

Habt ihr da eine Idee dazu wie sowas normalerweise gelöst wird?

Grüße

Max

[Bitwurschtler (Gast)]

Max S. schrieb:
> Habt ihr da eine Idee dazu wie sowas normalerweise gelöst wird?

man zeichnet einen groben Schaltplan aus FF und Logic-blöcken.

[Chris K. (chris_k)]

Moin!
Die 'Protokoll_clk' brauchst du doch gar nicht auf die 
steigende/fallende Flanke untersuchen. Du kannst einfach den aktuellen 
Wert auslesen ('1' oder '0'). Und mit Hilfe des Schieberegisters kannst 
du die Flanken vom zu untersuchenden Protokoll erkennen.

Außerdem brauchst du 'Protokoll_clk' nicht in der Sensibilitätsliste.

Beste Grüße

[Max S. (prisherious)]

Chris K. schrieb:
> Du kannst einfach den aktuellen
> Wert auslesen ('1' oder '0'). Und mit Hilfe des Schieberegisters kannst
> du die Flanken vom zu untersuchenden Protokoll erkennen.



du meinst quasi ein 2 Bit Register für die Flanke und wenn es [0 1] ist 
wars die fallende Flanke und umgekehrt ?

Bitwurschtler schrieb:
> man zeichnet einen groben Schaltplan aus FF und Logic-blöcken.

Ja das ist schon passiert. Genau da ist mir aufgefallen das in ein FF 
einfach keine 2 clocks passen. Deswegen ja die Frage wie man 2 clocks in 
dem Zusammenhang händelt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Max S. schrieb:
> Deswegen ja die Frage wie man 2 clocks in dem Zusammenhang händelt.
Man taktet das Signal in Flipflops ein und macht eine Flankenerkennung:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung

Und zum Thema "mehrere Takte": im einem Anfängerdesign gibt es genau 1 
einzigen Takt. Der kommt vom Quarz. Alle Flipflops werden damit 
getaktet. Und alle externen Signale darauf einsynchronisiert.

[Max S. (prisherious)]

Lothar M. schrieb:
> Max S. schrieb:
>> Deswegen ja die Frage wie man 2 clocks in dem Zusammenhang händelt.
> Man taktet das Signal in Flipflops ein und macht eine Flankenerkennung:
> http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
>
> Und zum Thema "mehrere Takte": im einem Anfängerdesign gibt es genau 1
> einzigen Takt. Der kommt vom Quarz. Alle Flipflops werden damit
> getaktet. Und alle externen Signale darauf einsynchronisiert.

Danke dir Lothar für deine vielen, sehr Hhilfreichen Beiträge ! (Keine 
Ironie, mein voller Ernst !).
Deine Internet Seite hat mir wirklich schon oft in vielen Bereichen 
weiter geholfen.

Dennoch muss ich da nochmal nachfragen.

Den FPGA Takte ich ja intern mit 100 MHz. Nun brauche ich den externen 
25 MHz Takt aber unverfälscht und in Echtzeit. Eintakten ist da eher 
nicht möglich da dieses ja durchaus Delta Zyklen generiert (oder hab ich 
da ein Denkfehler ?)
ich muss in Echtzeit den Takt auf steigende und fallende Flanke mit 100 
MHz abtasten um gleichzeitig die Datenleitung auswerten zu können.

ach und der externe 25 MHz Takt liegt übrigens nicht konstant an. Nur 
wenn eine Nachricht über den Bus geschickt wird.
Ablauf sieht quasi so aus:
1. Takt schaltet sich auf und hat zwischen 10-15 Zyklen vorlauf.
2. Botschaft kommt auf fallende und steigende Flanken
3. Takt und Botschaft enden gleichzetig und Busruhe herrscht.

[Dr. Sommer (Gast)]

Max S. schrieb:
> Ich muss die steigende sowie die fallende Flanke erkennen, da die Clock
> eine Frequenz von 25 MHz aufweißt muss ich ja mit 100 MHz
> abtasten.(Abtasttheorem)

Besagt das Theorem nicht, dass die Abtastrate größer als die doppelte 
Frequenz sein muss...?! Weil was passiert, wenn du immer exakt im 
Umschaltmoment abtastest? Und nur geringfügig größere Abtastrate als 
doppelte Frequenz ist m.W. auch wenig praktikabel.

[Max S. (prisherious)]

Dr. Sommer schrieb:
> Max S. schrieb:
>> Ich muss die steigende sowie die fallende Flanke erkennen, da die Clock
>> eine Frequenz von 25 MHz aufweißt muss ich ja mit 100 MHz
>> abtasten.(Abtasttheorem)
>
> Besagt das Theorem nicht, dass die Abtastrate größer als die doppelte
> Frequenz sein muss...?! Weil was passiert, wenn du immer exakt im
> Umschaltmoment abtastest? Und nur geringfügig größere Abtastrate als
> doppelte Frequenz ist m.W. auch wenig praktikabel.

ja völlig richtig.... Min. 100 MHz...interne Clock ist auf 154 MHz 
momentan geroutet.

[chris (Gast)]

>Besagt das Theorem nicht, dass die Abtastrate größer
>als die doppelte Frequenz sein muss...?!

Da sagst Du was Wahres. In vielen Lehrbüchern steht nämlich größer 
gleich und das ist falsch. Ich glaube, die schreiben voneinander ab ...

[Dr. Sommer (Gast)]

Das Ganze klingt ein bisschen nach Ethernet, sollte es dafür nicht jede 
Menge Beispiele geben? Bei der hohen Frequenz scheint es nötig zu sein 
die Eingangs-Flipflops doch mit dem Bus-Takt zu versorgen, und dann eine 
komplizierte Übergabelogik an den internen Takt zu nutzen. Vielleicht 
könnte man auch eine PLL oder DLL nutzen welche sich auf die Präambel 
synchronisiert um einen saubereren Takt zu erhalten...

[Max S. (prisherious)]

nein Ethernet ist es nicht ;) Leider darf ich über das Protokoll selbst 
nichts sagen.
PLL hab ich schon versucht. Die brauch zu lange um sich aufzuschalten. 
leider gescheitert.

[VHDL hotline (Gast)]

Das Problem ist mir nicht ganz klar. Wenn Protokolltakt und 
Protokolldaten synchron sind, kannst du die mit dem Systemtakt abtasten 
und hast dann in der Systemtaktdomäne, was du brauchst. Echtzeit ist 
gegeben, da du eine garantierte maximale Zeit hast, in der du die Flanke 
erkennst. Oder geht es dir bei "Echtzeit" um die Größe der Latenz an 
sich? Je höher dein Systemtakt, desto "schneller" erkennst du eine 
Flanke im Protokolltakt und kannst zeitnaher darauf reagieren. Um ein 
Einsynchronieren kommst du in keinem Fall drumrum, wenn du mit den 
Protokolldaten etwas in der Systemtaktdomäne anfangen willst.

[Schlumpf (Gast)]

Max S. schrieb:
> Nun brauche ich den externen
> 25 MHz Takt aber unverfälscht und in Echtzeit.

Was heißt das?
Du taktest doch Daten und Takt ein, somit werden beide gleichermaßen 
zeitlich  "verschoben".
Die zeitlich Verschiebung zwischen Daten und Takt gegenüber dem Original 
kann maximal einen FPGA-Takt betragen. Kannst du damit leben?


Wie sieht dein Protokoll aus?
Takt = 25 MHz

Max S. schrieb:
> 2. Botschaft kommt auf fallende und steigende Flanken

Das heißt, die Daten kommen mit 50MBit/s angerauscht.

Wann findet der Datenwechsel relativ zu den Flanken statt?

Mit den Flanken?

    ----    ----
----    ----
AAAABBBBCCCCDDDDD

oder zwischen den Flanken?

    ----    ----
----    ----
  AAAABBBBCCCCDD

Das Ganze ist ja dann auch noch mit einem Skew bedingt durch das Routing 
beaufschlagt.

Man müsste also etwas mehr Informationen haben, um eine Lösung zu 
finden.

Prinzipiell kann man auch die Sampleregister für die Daten mit dem Takt 
des Bus betreiben und dann immer "häppchenweise" Pakete parallel in die 
Taktdomäne des FPGA übertragen. Aber dazu braucht es ein wenig 
Hirnschmalz und ist definitiv nichts für Anfänger.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Schlumpf schrieb:
> Prinzipiell kann man auch die Sampleregister für die Daten mit dem Takt
> des Bus betreiben und dann immer "häppchenweise" Pakete parallel in die
> Taktdomäne des FPGA übertragen
Ich würde es so machen, wenn die Daten tatsächlich synchron mitsamt 
ihrem Takt kommen. Dann muss man den Taktdomänenübergang nicht ganz so 
hektisch gestalten...

[Max S. (prisherious)]

Guten Morgen alle miteinaner,

Also ich deke ich habe das Problem jetzt weitestgehend im Griff.
Tatsächlich habe ich es jetzt so gelöst das ich einsynhronisiere um den 
Takt und die Daten dann auszuwerten.
Die Simulation sieht soweit auch anständig aus. jetzt noch ein paar 
kleine Feinheiten und wir sehen mal ob das System solide läuft.

@Schlumpf. Ich weiß weitere Informationen währen von Hilfe jedoch darf 
ich da nicht weiter darauf eingehen. jedoch ging es mir nur um das 
Problem mit den 2 Clocks, wie die Daten dann genau erfasst werden passt. 
Es ist sogar sehr ähnlich mit deiner idee mit den Sample registern.

Ich bedanke mich an dieser Stelle sehr für euere Hilfe !
Ihr habt mir gute Ideen zugeworfen die hoffentlich zum Erfolg führen 
werden ! =)

Schönen Arbeitstag euch noch !
Gruß
Max