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...
Du kannst das alles sequenziell innerhalb eines Audio-Samples mischen. Einen FPGA dazu zu nehmen ist overkill.
> 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.
Herold schrieb: >> SPDIF-Coding ist simpel > > opensorurce hat einen core Hast Du den eingesetzt? Erfahrungen?
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 :-)
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.