BiPhaseMark, clk und halbe Periode

@ 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

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.

@  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

Und die erhöhte Bitrate erreiche ich nur durch eine verdoppelte clock 
Geschwindigkeit?

Danke.

@ 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

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

Sowas wie

1

   process (clk) begin

2

      if rising_edge(clk) then

3

         :

4

      elsif falling_edge(clk) then

5

         :

6

      end if;

7

   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.

@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.

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.

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)?

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....

@ 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

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?

@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