www.mikrocontroller.net

Forum: FPGA, VHDL & Co. BiPhaseMark, clk und halbe Periode


Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

für die BPM Kodierung benötigt man bei einem Datensignal einen 
Zustandswechsel auf der fallenden Taktflanke.
Wenn ich allerdings so etwas aufbaue (also ein:
if (CLK'event and CLK='1') then [...]
gefolgt von einem
elsif (CLK'event and CLK='0') then [...]

bekomme ich Fehlermeldungen (asynchronous load...)bei der Synthese.

Hat jemand Hinweise, wie es richtig umzusetzen ist?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Manuel Neumann (wight)

>für die BPM Kodierung benötigt man bei einem Datensignal einen
>Zustandswechsel auf der fallenden Taktflanke.

Naja, diese Formulierung und Denkweise ist verbreitet, aber sehr 
unglücklich gewählt.

>bekomme ich Fehlermeldungen (asynchronous load...)bei der Synthese.

Weil ein synchroner Prozess nur auf EINE Flanke reagieren kann.

>Hat jemand Hinweise, wie es richtig umzusetzen ist?

Ganz einfach, man generiert den Datenstrom mit dem doppelten Takt.

MFG
Falk

Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Manuel Neumann (wight)
>
>>für die BPM Kodierung benötigt man bei einem Datensignal einen
>>Zustandswechsel auf der fallenden Taktflanke.
>
> Naja, diese Formulierung und Denkweise ist verbreitet, aber sehr
> unglücklich gewählt.
>
Und wie lautet sie korrekter?

>>bekomme ich Fehlermeldungen (asynchronous load...)bei der Synthese.
>
> Weil ein synchroner Prozess nur auf EINE Flanke reagieren kann.
>
>>Hat jemand Hinweise, wie es richtig umzusetzen ist?
>
> Ganz einfach, man generiert den Datenstrom mit dem doppelten Takt.
>
> MFG
> Falk

Genau das habe ich gemacht. Puh, ich dachte schon, ich hätte etwas ganz 
elementares übersehen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Manuel Neumann (wight)

>Und wie lautet sie korrekter?

BiPhase Mark Code codiert eine Null des Eingangsdatenstroms als 01 Folge 
im Ausgangsdatenstrom mit doppelter Baudrate (hier = Bitrate) bzw. eine 
Eins im Eingangsdatenstrom als 10 Folge im Ausgangsdatenstrom.

MFG
Falk

Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und die erhöhte Bitrate erreiche ich nur durch eine verdoppelte clock 
Geschwindigkeit?

Danke.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Manuel Neumann (wight)

>Und die erhöhte Bitrate erreiche ich nur durch eine verdoppelte

> clock Geschwindigkeit?

Was für ein Wort! AUA!!!

Ja, man braucht die doppelte Taktrate. Macht 10 Mbit/s Ethernet so, dort 
war immer ein 20 MHz Quarz drauf.

MFG
Falk

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und die erhöhte Bitrate ...
Wie hoch soll die denn überhaupt sein?
Was willst du denn machen?

Sowas wie
   process (clk) begin
      if rising_edge(clk) then
         :
      elsif falling_edge(clk) then
         :
      end if;
   end process;   
geht mit FFs im FPGA nicht. Die haben nur 1 Takteingang, und der kann 
nur auf entweder die steigende oder die fallende Flanke reagieren.

Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk Brunner:

Danke.

[clock Geschwindigkeit: Du hast Recht, es war spät und der BEitrag 
sollte noch fertig werden ;) ]

@Lothar Miller:

Momentan speichere ich den Eingang zwischen und generiere damit einen 
Ausgangsstrom.
Den wollte ich dann eben je nach Dateneingang doppelt oder halb so 
schnell ausgeben.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Neumann wrote:
> Den wollte ich dann eben je nach Dateneingang doppelt oder halb so
> schnell ausgeben.
Meine Frage zielte auf einen Absolutwert ab, z.B. 10kBit/s oder 
100MBit/s ;-)

Wenn die Geschwindigkeit eher langsam ist, könntest du mit einem sehr 
viel höher getakteten FPGA das Ganze einsynchronisieren und so 
weiterverarbeiten.

Wenn die Geschwindigkeit hoch ist, mußt du aus dem Bitstrom erst mal 
einen Takt extrahieren. Spannend dürfte dann aber werden, wenn der 
Bitstrom nicht kontinuierlich kommt.

Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller wrote:
> Manuel Neumann wrote:
>> Den wollte ich dann eben je nach Dateneingang doppelt oder halb so
>> schnell ausgeben.
> Meine Frage zielte auf einen Absolutwert ab, z.B. 10kBit/s oder
> 100MBit/s ;-)
>
Die erste Fassung soll mit 40 MHz arbeiten, da BPM bitorientiert ist, 
sind wir also bei 40Mbit/s.



> Wenn die Geschwindigkeit eher langsam ist, könntest du mit einem sehr
> viel höher getakteten FPGA das Ganze einsynchronisieren und so
> weiterverarbeiten.
>
> Wenn die Geschwindigkeit hoch ist, mußt du aus dem Bitstrom erst mal
> einen Takt extrahieren. Spannend dürfte dann aber werden, wenn der
> Bitstrom nicht kontinuierlich kommt.

Gibt es denn einen Trick, mit dem ich die Ausgangsclock doppelt so 
schnell laufen lassen kann? Eine zusätzliche Clock und ein eigener 
Prozess vielleicht (VHDL)?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem höheren Takt abtasten sollte doch möglich sein, dann reicht 
eine einfache Flankenerkennung per FlipFlop. Ich denke bei 40MBit/s 
kannst du mit 100...200MHz abtasten. Takt-Rückgewinnung aus dem 
asynchronen Eingangssignal wäre wieder eine ganz andere Baustelle....

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Manuel Neumann (wight)

>Gibt es denn einen Trick, mit dem ich die Ausgangsclock doppelt so
>schnell laufen lassen kann? Eine zusätzliche Clock und ein eigener
>Prozess vielleicht (VHDL)?

In VHDL direkt nicht, in den modernen FPGAs schon. Sog. DDDR-Register, 
Dual Datarate Register. Die können Daten auf der steigenden und 
fallenden Flanke ausgeben. Dazu haben sie zwei Daten- und Takteingänge.

MFG
Falk

Autor: Manuel Neumann (wight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, encoder und decoder funktionieren in Simulation, aber leider nur 
fast in Hardware.

Z. Zt. taste ich den kodierten Datenstrom mit dreifacher Frequenz ab und 
ein Synchronisationssignal zeigt, dass das syncpattern gefunden wird.
Aber der dekodierte Datenstrom sieht nicht so aus, wie er soll sondern 
springt immer noch von in kurzen Peaks nach 1, auch wenn eine 0 als 
Originaldatum anliegt.

Liegt das an Phasenungleichheiten?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manuel Neumann (wight)

>Liegt das an Phasenungleichheiten?

Keine Ahnung, wir kennen doch nicht deinen Dekoder. So ein Takt- und 
Datenrückgewinnung (Clock & Data recovery , CDR) ist nicht ganz trivial.

MFG
Falk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.