Hallo zusammen,
ich "entwickle" zur Zeit für einen Bekannten ein digitales Mischpult.
Der Grund ist, dass es ein Mischpult mit 64 Kanälen sein muss, welches
vom Anschaffungspreis her einfach jeden erträglichen Rahmen sprengt.
Außerdem ist es für mich als "Hifi-Freak" ein tolles Projekt, wo man
sich richtig austoben kann.
Zum Problem:
Die Eingangsmodule (jeweils 4 Kanäle), welche aus dem ADC bzw. digitalem
Receiver, sowie EQ und anderen Effektgeräten bestehen, sind fertig
entwickelt und auch schon einzeln erprobt. Da das Mischpult bis zu 64
Kanäle haben soll, müssen also bis zu 16 Eingansmodule irgendwie
verbunden werden.
Der Plan sieht so aus, dass jedes Modul einen "serial data output"
besitzt, der im TDM4 Modus läuft.
Nun sollen alle 16 dieser seriellen Datenströme in einen FPGA geleitet
werden, welcher nun jeden der Kanäle auf die Ausgänge verteilt. Es gibt
insgesammt 24 Ausgänge, weshalb 64*24 Multiplikationen pro Sample
erfolgen müssen. Bei geplanten 48kHz müssten es also ca. 75 MMAC´s sein.
DSP scheiden leider aus, da sie meist nicht genügend Eingänge bieten.
Da ich mich auf dem Gebiet der FPGA´s nicht auskenne, würde ich von euch
gerne wissen, ob FPGA´s für so etwas geeignet sind und ob so etwas als
Anfänger möglich ist?
Zu erfüllende Punkt:
- 16 SDI´s im TDM4 Modus
- 75 MMAC´s mit mindestens 32x28 Bit
- 6 SDO im TDM4 Modus
Würde mich über eure Hilfe freuen!
Gruß Tobias
> ob FPGA´s für so etwas geeignet sind
Sicher. Die Multiplier-Units werden sich aber ziemlich langweilen und
besonders viele Pins werden auch nicht benutzt ;)
> und ob so etwas als Anfänger möglich ist?
Prinzipiell ja, weil es alles sehr regelmässige Strukturen und Timings
sind. Das macht das Design recht einfach, wenn man ein paar Regeln
beachtet, zB. nur genau EINEN Takt zu benutzen, zB. 48kHz*2048=98.34MHz,
das ist für neue FPGAs (Spartan6&Co) noch eher gemächlich. Der Takt ist
dann auch die Basis fürs ADC-Timing. Die müssen im Slave-Mode laufen,
d.h. MCLK/SCK/LRCK gehen vom FPGA zu den ADCs. Mastermode (vom
FPGA-MCLK) geht zwar auch, braucht aber mehr Logik, um sich darauf zu
synchronisieren. Der SCK sollte als echter Takt im FPGA nicht benutzt
werden, Clock-Domain-Crossings sind als Anfänger eher frustrierend.
Allerdings solltest du dir noch überlegen, wie die Koeffizienten
eigentlich ins FPGA kommen ;)
Vorneweg:
Tobias schrieb:> Der Grund ist, dass es ein Mischpult mit 64 Kanälen sein muss, welches> vom Anschaffungspreis her einfach jeden erträglichen Rahmen sprengt.
Das kann niemals ein Grund sein. Denn wenn du die Funktionen eines
solchen Mischers brauchst, diese alle fehlerfrei implementieren und das
Ganze dann noch in ein ansehnliches Gehäuse bauen mußt, dann wird dich
dein Eigenbau hinterher garantiert mehr kosten.
Wenn du gesagt hättest: die am Markt erhältlichen sind zu groß oder zu
energiehungrig oder überladen, dann wäre eine Eigenentwicklung evtl.
sinnvoll. Aber nur wegen des Preises: niemals.
Zur Sache:
Tobias schrieb:> ob FPGA´s für so etwas geeignet sind
Ja. Du kannst darauf die Hardwareanbindung in Hardware und die
Signalverarbeitung als Softcore-CPU laufen lassen.
> und ob so etwas als Anfänger möglich ist?
Klar. Allerdings bist du, wenn das dann läuft, garantiert kein Anfänger
mehr. Auch die Lernkurve ist ziemlich steil...
> Bei geplanten 48kHz müssten es also ca. 75 MMAC´s sein.
Da reichen wesetlich weniger aus, denn du kannst die Berechnungen ja
pipelinen. D.h. ein MAC rechnet erst mal den einen Kanal, dann andere,
und insgesamt so viele, wie im 48kHz Raster möglich sind.
> DSP scheiden leider aus, da sie meist nicht genügend Eingänge bieten.
Du könntest ein (kleines) FPGA ja auch einfach zur Harewareanbindung
deiner IO-Module verwenden, und dieses FPGA dann per DMA an einen DSP
anklinken...
> Da reichen wesetlich weniger aus, denn du kannst die Berechnungen ja> pipelinen. D.h. ein MAC rechnet erst mal den einen Kanal, dann andere,> und insgesamt so viele, wie im 48kHz Raster möglich sind.
Hm, seine Rechnung passt doch. Wenn er 24 getrennte Ausgänge hat, die je
einen beliebigen Downmix der 64 Eingänge haben sollen, sind es 24*64
Multiplikationen (das A lass ich mal weg, das interessiert nur Leute mit
echtem DSP ;). Und das im 48kHz-Raster, also umara 74Mio pro s. Das
können mittlere DSPs ala Blackfin auch noch.
Ein FPGA hätte aber schon ein paar Vorteile, insb. wenn man noch
SPDIF/ADAT-Ausgänge haben will (SPDIF-Coding ist simpel) oder evtl. doch
noch ein paar Summeneffekte. Gerade bei den potentiellen IOs ist ein
FPGA viel flexibler als ein DSP.
Das ist zu anspruchslos für ein postmodernes lowcost FPGA mit
.5-10GMac/s.
Da müssen noch ein paar Spektrumanalyzer, Effektgeräte, Klangsynthese
und ein physical Modeling Klangerzeuger mit rein.
Wenn es nicht aus der Stimme von Dieter Bohlen die von Peter Hofmann
macht ist das FPGA nicht ausgereizt.
Dogbert schrieb:> s ist zu anspruchslos für ein postmodernes lowcost FPGA mit> .5-10GMac/s.
Naja, ein Realtime Mischer mit Entjitterung auf Datentaktebene im
MHz-Bereich braucht schon ein FPGA, das ordentlich taktet. So ganz
trivial ist das nicht. Und ausgelastet ist es auch, zumindest
timingmässig.
> Da müssen noch ein paar Spektrumanalyzer, Effektgeräte, Klangsynthese> und ein physical Modeling Klangerzeuger mit rein.
Bitte sehr:
http://www.96khz.org/cyclone3platform.html> Wenn es nicht aus der Stimme von Dieter Bohlen die von Peter Hofmann> macht ist das FPGA nicht ausgereizt.
Das geht mit keinem FPGA der Welt :-)
Wenn, dann würde ich auch nicht nach Hofmann, sondern nach Renee
Fleming convertieren. Das schalte ich mir dann als plugin dazwischen,
wenn ich wieder mal eine Nachwuchssopranistin produziere :-)
Jürgen Schuhmacher schrieb:> Naja, ein Realtime Mischer mit Entjitterung auf Datentaktebene im> MHz-Bereich braucht schon ein FPGA, das ordentlich taktet. So ganz> trivial ist das nicht. Und ausgelastet ist es auch, zumindest> timingmässig.
Oh, da hab ich ja gar nich dran gedacht, wo doch der OP von nur 64*24
MACS pro Sample sprach.
Von TBC/Resampling/Synchronisation keine Rede?
Naja, vielleicht lebt er in einer synchronen Welt.
Aber mit so einem total audiophilen TBC/Resampler kann man bestimmt
jedes FPGA füllen, oder?
Dogbert schrieb:> Jürgen Schuhmacher schrieb:>> Naja, ein Realtime Mischer mit Entjitterung auf Datentaktebene im>> MHz-Bereich braucht schon ein FPGA, das ordentlich taktet. So ganz>> trivial ist das nicht. Und ausgelastet ist es auch, zumindest>> timingmässig.>> Oh, da hab ich ja gar nich dran gedacht, wo doch der OP von nur 64*24> MACS pro Sample sprach.
Von welchen Frequenzen sprecht ihr hier?
64x24 Multiplikationen und einige Additionen erfordern für 48kHz gerade
um die 80MHz, wenn man es total sequenziell macht und die schafft ein
mittelmässiger FPGA ohne grosse Verrenkungen. Und wenn es schneller sein
muss, nimmt man 4 units und packt auch die angestrebten 192kHz bequem
mit moderaten FPGA-Taktfrequenzen.
Mit audiophil hat das wenig tun tun - eher schon mit Mathe :-)
Beseitigung von Jitter ist ein anderes Thema. Das braucht man nur für
externe Quellen. Umgekehrt braucht es dafür aber dann einen hochgenauen
Takt im FPGA.
Tobias schrieb:> Da ich mich auf dem Gebiet der FPGA´s nicht auskenne, würde ich von euch> gerne wissen, ob FPGA´s für so etwas geeignet sind und ob so etwas als> Anfänger möglich ist?
Ohne intensive Einarbeitung: Nein.
Zwei Dinge sind wichtig:
1. Arbeite dich gut in das Prinzip der FPGA-Entwicklung ein: Synchrones
Schaltungsdesign, Finite State Machines, Trennung von sequentieller und
kombinatorischer Logik, Trennung von Daten- und Kontrollpfad, usw.
2. Achte darauf, eine gute Testumgebung aufzubauen! Testbench,
Simulator, notwendige Skripts, um Testdaten zu generieren und
auszuwerten.
Wenn du dich da seriös herantastet, dann ist das Projekt schon machbar.
Bevor man sich an zeitkritische Anwendungen macht, sollte man das FPGA
Design wirklich beherrschen, oder mit was Anderem beginnen. Ich gehe
aber mal davon aus, dass der TE nicht ganz unbefangen ist. Rund um's
FPGA gäbe es da aber noch ein wenig mehr zu tun. Diese SDI Interfaces
scheinen mir auch nicht Ohne!
Audio Hans schrieb:> 64x24 Multiplikationen und einige Additionen erfordern für 48kHz gerade> um die 80MHz,
32 x 28 Bit braucht aber 2 MULs und etwas Addition und das geht nur in
schnellen FPGAs in einem Takt. pipeline Argument greift nicht, weil die
Kanalsumme gebildet werden muss, also muss komplett fertig gerechnet
werden, bevor es in den nächsten Kanal geht.
Mit einem Spartan 3 oder Cyclone III ist das gar nicht und mit einem
S6/C4 gerade so zu machen. Sagen wir mal besser 2 Takte in 50MHz x 1500
OPs = 60us. Für eine 192kz data rate sind es schon >8 parallele
Einheiten + post Summation. Beim S3 würden da die Multiplier schon gar
nicht mehr reichen.
Dogbert schrieb:> Da müssen noch ein paar Spektrumanalyzer, Effektgeräte,
Nehmen wir mal einen guten EQ auf der Basis eines linearphasigen
FIR-Filters:
Die in einem Spartan 6 verfügbaren 18x25 Bit Multiplier reichen singulär
nur für 16 Bit Audio, wegen der erforderlichen Koeffizientenbreite.
Diese muss ausreichend hoch sein, damit die Fehler nicht aufgrund der
hohen TAP-Zahl kummulieren und mehr digitale Fehler induziert werden,
als das Filter eigentlich hätte.
Grob gerechnet kann man von der Wurzel der TAP-Zahl ausgehen, bei 1024
also 5Bit oder mehr besser mehr, sagen wir 7. Wir hätten also einen
16x24 Bit Multiplier je Kanal. Das packt ein Spartan 3 bei 50 MHz locker
und berehnet je Sample einen solchen EQ in der Mastersumme.
Für 24 Bit Audio und 128kHz brauchen wir aber die 8fache Leistung!
Theoretisch arbeitet der S6 z.B. auch 200MHz, aber nicht mehr für 2
verkette Multiplier-Addierer, die wir aber brauchen, wegen 24 Bit x 32
Bit.
Also so ganz easy und entspannt ist das auch in FPGAs nicht :-)
