Hallo ihr! ich moechte gerne die Periodenlaenge von einem binären Bitstream bestimmen. Nun war meine Idee es nicht unnötig schwer zu machen und einfach 2 Schieberegister zu verwenden. Das erste Schieberegister fuelle ich anfangs mit dem Bitstream. Ist das Schieberegister komplett belegt, lasse ich die Bits so drinnen gespeichert. Darauffolgend beginne ich das zweite Schieberegister durch den selben Bitsream aufzufuellen. Dabei vergleiche die diese beiden Schieberegister. Ist das erste mal das erste Schieberegister gleich dem zweiten Schieberegister, gebe ich einen Impuls aus und lass einen counter zählen, bis ich wieder ein Impuls erhalte und habe so meine Periodenlänge ermittelt. Nun jedoch zu meinem Problem: Die Periodizitaet der Bitsequenz betraegt ca. 2000 bits. Heißt das, ich benoetige wirklich ein ca. 2000 Bit-Schieberegisger??? Und wenn dem nicht so ist, wie viele Schieberegister benoetige ich denn dann und wie wird das errechnet? Und wenn dem so ist, habt ihr evtl. eine bessere Lösungen einen solch lange binäre Periode zu bestimmen? Vielen Dank! NewHere84
NewHere84 schrieb: > Nun jedoch zu meinem Problem: > Die Periodizitaet der Bitsequenz ...muss nicht bis aufs letze Bit EXAKT gleich sein... :-o Diese (augenscheinlich) simple Vergleicherei greift vermutlich zu kurz. Oder mal andersrum gefragt: was ist die Quelle dieses Bitstroms?
Lothar Miller schrieb: > Oder mal andersrum gefragt: was ist die Quelle dieses Bitstroms? Zum testen wird es erstmal einfach eine pseudo zufaellige bit sequenz sein... Lothar Miller schrieb: > NewHere84 schrieb: >> Nun jedoch zu meinem Problem: >> Die Periodizitaet der Bitsequenz > ...muss nicht bis aufs letze Bit EXAKT gleich sein... :-o Aber so wie es sich anhoert, muss dass ShiftRegister elend lang werden?! Gäbe es eine andere einfache ressourcensparendere Lösung?
Bei 2000 Bit sind das 250 x 8 Bit. NewHere84 schrieb: > Gäbe es eine andere einfache ressourcensparendere Lösung? Kleiner Mikrocontroller z.B. ATiny und ein entsprechendes Programm.
Blinky schrieb: > Kleiner Mikrocontroller z.B. ATiny und ein entsprechendes Programm. klingt interessant... aber wo liegt der vorteil am Microcontroller? Sorry... hatte nie sonderlich viel mit Microcontrollern zu tun.. Blinky schrieb: > Bei 2000 Bit sind das 250 x 8 Bit. Wie meinst du das???
NewHere84 schrieb: > Blinky schrieb: >> Kleiner Mikrocontroller z.B. ATiny und ein entsprechendes Programm. > > klingt interessant... aber wo liegt der vorteil am Microcontroller? > Sorry... hatte nie sonderlich viel mit Microcontrollern zu tun.. > > Blinky schrieb: >> Bei 2000 Bit sind das 250 x 8 Bit. > > Wie meinst du das??? 250 Byte
Blinky schrieb: > Kleiner Mikrocontroller z.B. ATiny und ein entsprechendes Programm. Das hängt davon ab, wie schnell das laufen muss. Ein kleiner Mikrocontroller ist da eher überfordert.
Kommt draufan, wie gut zufällig deine Bits sind, bzw. die Länge deines "Golden Code". Wenn sich keine Sequenzen innerhalb deiner Bitwelle wiederholen, kannst Du den "Match" auch mit weniger Bits erreichen. Damit brauchst Du nicht alle Bits speichern. Falls Du viele Fehler erwartest und doch den ganzen Strom mithilfe irgend einer Fehlerkorrektur (Forward Error correction, o.ä.) validieren musst, kannst Du die Daten immer noch in ein Blockram puffern. Ansonsten sollte es aber keine riesen Sache sein, ein 2000-Bit SR anzulegen. Nur würde ich keine 2000 Bit "brute force" autokorrelieren und eher zu "divide et impera"-Tricks greifen, wenn viele Bitfehler erwartet werden. Ich weiss nicht, warum manche Leute in FPGA-Foren immer auf die Idee kommen, dass solche Probleme mit 8-Bit uCs einfacher zu lösen seien... also auf deutsch: den uC-Ansatz kann man hier definitiv knicken, gerade wenn Fehlerkorrektur mit im Spiel ist.
NewHere84 schrieb: > Heißt das, ich benoetige wirklich ein ca. 2000 Bit-Schieberegisger??? wie schnell kommen denn die bits rein? Oder andersrum: Wieviele FPGA-Takte hat denn ein Bit?
Fitzebutze schrieb: > den uC-Ansatz kann man hier definitiv knicken, gerade > wenn Fehlerkorrektur mit im Spiel ist Und die Anzahl gespeicherter Bits würde sich de facto auch nicht verringern, nur weil sie im RAM des uC gespeichert sind...
Fitzebutze schrieb: > Ich weiss nicht, warum manche Leute in FPGA-Foren immer auf die Idee > kommen, dass solche Probleme mit 8-Bit uCs einfacher zu lösen seien... > also auf deutsch: den uC-Ansatz kann man hier definitiv knicken, gerade > wenn Fehlerkorrektur mit im Spiel ist. Da stimme ich zu. Das ist letztlich nichts anders als eine Fehlerkorrektur / Parityaufgabe. Sowas hat man früher mit mini PLDs gelöst, wenn es nichts anderes zu tun gab.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.