Konstanten Datenstrom erzeugen

[Manuel D. (manuel_d82)]

Hallo, bin Anfänger und möchte einen konstanten Datenstrom erzeugen. 
Zuerst sollten die Nutzdaten gesendet werden, danach die BCH-Prüfbits 
(generiert durch ein Generatorpolynom). Nun zur Verständnisfrage: Die 
Berechnung der Prüfbits brauch ja seine Zeit, wenn ich also über einen 
Interrupt heraus springe um die Prüfbits zu berechnen und dann wieder 
zurück um diese dann in dem Datenstrom zu senden, erreiche ich ja keine 
konstante Übertragung.

Nutzbits und Prüfbits sollten exakt in gleicher Geschwindigkeit gesendet 
werden.

Wie lässt sich sowas bewerkstelligen?

[Cyblord -. (cyblord)]

Datenstrom langsam genug senden um die Prüfbits zu berechnen ohne den 
nächsten Zeitslot zu verpassen. Alternativ Controller auswählen der 
schnell genug ist.

[Max D. (max_d)]

Prüfbits vorher berechnen?
Prüfbits in einer Schleife (nebenher) berechnen und am Ende dranhängen?

Für genauere Antworten genauere Infos liefern.
Wo kommen die Daten her?
Wie schnell kommen die an?
Wie schnell gehen die raus?
Auf welcher Hardware?

Usw...

[Manuel D. (manuel_d82)]

Als Hardware dachte ich an ein Altera Cyclone II EP2C5T144 FPGA.

Das ganze ist sehr komplex. Um es kurz zu fassen, die Daten sind 
digitalisierte Audio/Ton-Signale. Der Frame hat 314 bit und wird mit 
32Khz wiederholt, somit gute 10 MBit. Das ganze soll 2x parallel 
ablaufen, also 2 Datenströme, je 10 MBit.
Davor oder danach die Prüfbits berechnen wäre somit egal, denn die 
Tonsignale laufen ja ständig ohne Pause.

1 bit hat eine Dauer von 31,25 µs, das wäre also der Zeitslot in der die 
Berechnungen stattfinden müssten.

Schafft das die Hardware und wenn ja wie gut ?

[Achim S. (Gast)]

Manuel D. schrieb:
> Der Frame hat 314 bit und wird mit
> 32Khz wiederholt, somit gute 10 MBit.

Du meinst "10 Mbit/s"? Oder tatsächlich 32 kbit/s, wie es aus folgender 
Angabe folgen würde:

Manuel D. schrieb:
> 1 bit hat eine Dauer von 31,25 µs

[Manuel D. (manuel_d82)]

Sorry, also der Frame besteht aus 320 Bits. Die Wiederholfrequenz ist 32 
kHz, die daraus resultierende Datenrate 10,24 Mbit/s. 31,25 µs ist die 
Bitdauer. Dieser Datenstrom sollte doppelt erzeugt werden, also 2 x 
10,24 Mbit/s.

[HildeK (Gast)]

Nein, die Bitdauer wären rund 100ns, der Frame hat 32μs.
Oder ist es doch anders? Dann bringe die Angaben mal in Einklang!

[Theor (Gast)]

Irgendwas stimmt an der Rechnung nicht:

32Khz Bitrate ergibt bei Berechnung von 1/34kHz eben 32 Mikrosekunden.

320 Bit lange Frames mit einer Framerate von 32kHz ergibt ein 
Bitrate 10,24MiBit/s. Bei Berechnung von 1/10,24MiBit/s ergeben sich 
rund 100ns pro Bit .

[Manuel D. (manuel_d82)]

Ach ja klar, natürlich. Genau so ist es. 97,6 ns ist die Bitdauer. Jetzt 
ist alles im Einklang, wäre noch die Frage zu klären, ob meine 
ausgesuchte Hardware das gut schafft und wenn ja, steckt die das locker 
weg oder ist die damit überfordert?

[K. S. (the_yrr)]

nur Daten erzeugen sollte der schaffen, aber woher kommen die und was 
macht der damit?
schreib doch mal ein testprogramm und versuch es für den FPGA zu 
synthetisieren, wenns klappt ist gut, wenn nicht dann 
größeren/schnelleren.
danach kaufst du den dann erst.

[Manuel D. (manuel_d82)]

Also der FPGA läuft auf 250 Mhz, bei einer Bitdauer von 100ns wären das 
max. 25 Befehle je Unterprogramm bevor ich wieder in den Hauptframe 
springen muss, damit eine CRC Prüfung z.B. durchzuführen wird schon 
knapp.. :(

[Purzel H. (hacky)]

Mit einem Controller kann man mit einigen Befehlen pro byte einen CRC 
berechnen, das waere dann ueber die Tabellenmethode.
In einem FPGA wuerde man zur seriellen Methode greifen, und ein Bit pro 
Clock raushaemmern.

[Falk B. (falk)]

Manuel D. schrieb:
> Also der FPGA läuft auf 250 Mhz, bei einer Bitdauer von 100ns wären das
> max. 25 Befehle je Unterprogramm bevor ich wieder in den Hauptframe
> springen muss, damit eine CRC Prüfung z.B. durchzuführen wird schon
> knapp.. :(

[ ] Du hast Ahnung von FPGAs

Einen läppischen 10 Mbit/s Datenstrom incl. Schickimicki ala CRC und 
sonstas macht dir jedes 08/15 FPGA, dazu braucht es auch keine 250 MHz 
Takt. Es ist KEIN serieller Prozessor wie normale CPUs sondern parallel 
arbeitende Hardware. Die kann, wenn man es richtig macht, Dutzende Dinge 
in einem Takt parallel berechnen und verarbeiten. Das ist der Witz am 
FPGA und Hardwarelogik. PARALLELE Datenvererbeitung anstatt serieller.

[Manuel D. (manuel_d82)]

Danke für eure Antworten!!

[Dergute W. (derguteweka)]

Moin,

Hier in dem Thread gibts nen Link auf die SMPTE299 Spec:

Beitrag "AES Preamble bei nicht-biphase Uebertragung"

In der Spec. wird auch drauf eingegangen, wie mit einem rueckgekoppelten 
Schieberegister Fehlerkorrekturbits erzeugt werden koennen. Dafuer 
braucht man bloss ein paar Flipflops und XOR-Gatter. Also genau das, was 
in FPGAs zum Saufuettern drinnen ist.

Gruss
WK