Forum: Digitale Signalverarbeitung / DSP / Machine Learning ADSP-21498, was für ein Compiler am besten?


von Andreas W. (andy_w)


Lesenswert?

Hallo,
ich würde gerne den ADSP-21489 für Audioprojekte verwenden, das werden 
sogar mehrere werden.

Um in die Materie reinzukommen, würde ich erst einmal das Evalboard 
besorgen, das ist hier beschrieben:
http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/21489-ezlite.html#eb-documentation

Eine IDE für die Softwareentwicklung ist dabei, der Preis für das 
"EZLITE" ist zwar recht hoch (über 500Euro), aber geht noch. Später will 
ich aber die DSPs einzeln kaufen und in eigenen Schaltungen verwenden. 
Leider läuft die IDE aber nur exklusiv mit dem Evalboard und soweit ich 
das auf den Seiten von Analog Devices sehe, kosten IDEs für normale 
Benutzung mehrere Tausend Euro...

Gibt es auch billigere Möglichkeiten, andere Compiler? Ich brauche dann 
ja keine Debugmöglichkeiten mehr, das kann ich vorher ja mit dem 
Evalboard klären, es reicht, den Code zu compolieren und hochzuladen.

Mit den Algorithmen kenne ich mich schon aus, als PC-Programme für 
Audioverarbeitung von WAV-Dateien läuft da schon was.

Gruß
Andy

von Mark B. (markbrandis)


Lesenswert?

Andreas W. schrieb:
> Gibt es auch andere Compiler?

Vielleicht von Green Hills Software oder Wind River Systems. Wenn die 
sowas nicht haben, dann bezeifle ich dass jemand anders was hat (außer 
Analog Devices selbst natürlich).

http://www.ghs.com/
http://www.windriver.com/

von ... (Gast)


Lesenswert?

Ich wuerde mir ein Monitorprogramm aka Debugger schreiben.
Damit man auf dem endgueltigem Zielsystem nicht ganz im Wald steht.

Und zum Compilieren/Assemblieren die Software des Evalkits nutzen.

Manche Evalkits lassen sich mit etwas Umbauaufwand an
ein externes Target anpassen.

Oder ist das in den Lizenzbedingungen ausgeschlossen?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Andreas W. schrieb:
> Ich brauche dann
> ja keine Debugmöglichkeiten mehr, das kann ich vorher ja mit dem
> Evalboard klären, es reicht, den Code zu compolieren und hochzuladen.

Das ist immer ein frommer Wunsch. Ich wuerde mich keinesfalls auf so 
einen Deal einlassen. Musst halt ausrechnen, was eine unkastrierte 
Entwicklungsumgebung umgeschlagen pro Board kosten wuerde. Wenn das zu 
viel ist - was bei kleinen Stueckzahlen schnell passieren kann, guck', 
dass du auf irgendeinen anderen Prozessor kommst, fuer den es 
guenstigere Enwicklungsumgebungen gibt.

Gruss
WK

von Andreas W. (andy_w)


Lesenswert?

Hallo,
noch habe ich das Evalboard nicht gekauft, ich habe das vor. Daher weiß 
ich nicht, wie die Softwarebeschränkung realisiert ist. Ob es nur in der 
Lizenz steht, ob sie nur exakt den einen DSP-Typ auf dem Bord 
unterstützt (dort ist ein BGA-Gehäuse, ich will einen mit TQFP 
verwenden, der hat ein paar Pins weniger) oder ob so eine Art Dongle auf 
dem Board ist, kann ich daher nicht sagen.

noch habe ich das Datenblatt vom DSP nicht durchgelesen, ich weiß nicht, 
ob die Software reingeflasht wird oder sich in einem externen Speicher 
befindet. Evtl. kann man in der Software auch eine Funktion mit 
hineinprogrammieren, die ihren eigenen Code über eine Schnittstelle 
ausgibt, wenn die Software keine entsprechenden Files mit Binärdaten 
anlegt.

Mal,sehen, ob AD vielleicht doch noch eine billigere Compilerversion 
hat, die dann weniger DSPs unterstützt und weniger Funktionen enthält.

Gruß
Andy

von Strubi (Gast)


Lesenswert?

Moin,

bist du denn auf die SHARCs (wegen Float) angewiesen?
Mit dem Fixpoint-Blackfin kann man auch ganz nette Audiosachen machen, 
man muss halt ein paar Assembler-Tricks nutzen, um die Performance für 
mehr als 16 Bit rauszukriegen.
Für den Blackfin gibt's nen gut funktionierenden GNU-Compiler (der ist 
IMHO besser als das Original von ADI).
Für den vollen SHARC-VDSP-Debugger-Arbeitsplatz musst du ansonsten schon 
min. 5k€ einrechnen.
Mit einigen ARMs kann man auch einiges an DSP-Power bewältigen, aber für 
längerfristige Investitionen ist bei mir der Blackfin trotz (oder 
gerade?) wegen seines Alters immer noch Geheimtip, also erste Wahl.

gruss,

- Strubi

von Andreas W. (andy_w)


Lesenswert?

Hallo,
16 Bit ist definitiv zu wenig, ich verarbeite 24 Bit Audio. Da sollte 
die Wortbreite eher sogar noch etwas größer sein, Floating Point wäre 
eben ideal. Dafür brauche ich das eher nur für ein schnödes FIR-Filter - 
allerdings mit 8191 Tabs, mindestens mit 4095 Tabs, sonst kann man im 
Baßbereich keine Filterkurven mehr realisieren. Bei 48kHz für 2 Kanäle 
(= ein I²S In-/Output) bin ich dann schon bei knapp 800 Millionen 
Multiply/Add Operationen/s. Man kann das auch auf z.B. zwei DSPs 
aufteilen, dann braucht man zwischen den Prozessoren zwei 
I²S-Verbindungen.

Ich brauche also richtig Rechenpower und möglichst >=24 Bit Wortbreite, 
wenn die Summe eine größere Wortbreite hat (oft ist die doppelt so groß 
wie die für Daten und Faktoren der Impulsantwort, die an die 
Multiplizierer gehen).

Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt, 
da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich 
mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen 
vorgesehen sind. Die Software und Datenblätter habe ich schon mal 
downgeloaded, es ist ein 24Bit Fixed Point DSP, also so gerade das 
Minimum, was für mich brachbar ist, könnte also klappen. Bei Texas bin 
ich gar nicht fündig geworden, keine DSPs für Audio gefunden und 
passende Software fand ich auf der chaotischen Seite erst einmal auch 
nicht.

Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung. 
Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch 
mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8 
Multiply/Add Operationen pro Takt parallel ausführen (Pipilining), auf 
zwei FPGAs aufgeteilt 4 Multiply/Add Operationen usw. Evtl. kann ich die 
FPGAs auch auf 200MHz hochprügeln, nach außen hin gibt es nur wenige 
I²S-Ports und einen SPI-Bus. Aber DSPs wären billiger und flexibler.

Gruß
Andy

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Andreas W. schrieb:
> Dafür brauche ich das eher nur für ein schnödes FIR-Filter -
> allerdings mit 8191 Tabs, mindestens mit 4095 Tabs, sonst kann man im
> Baßbereich keine Filterkurven mehr realisieren.

google z.B. mal nach "01200_Polyphase.pdf"
vielleicht brauchst du doch nicht so viele Taps, wie du glaubst.

Andreas W. schrieb:
> Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung.
> Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch
> mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8
> Multiply/Add Operationen pro Takt parallel ausführen (Pipilining),

Naja und? Der kleinste Spartan3 hat schon 12 dedizierte Multiplizierer 
eingebaut. Und der ist uralt und eben der allerkleinste...
Bevor du dich auf irgendeine (am End' sehr exotische IDE zu sehr 
exotischen Preisen) Architektur festlegst, koennte intensives Studium 
von Datenblaettern, Algorithmen, Programmier- und 
Hardwarebeschreibungssprachen und ihren Moeglichkeiten und Limitationen 
nicht schaden :-)

Gruss
WK

von Andreas W. (andy_w)


Lesenswert?

Hallo,
Polyphase geht nur bei solchen Tiefpässen. Ich mache aber eben eher 
Klangregler oder parametrische Equalizer, um Raumresonanzen wegzuregeln. 
Das bedeutet, daß praktisch beliebige Frequenzgänge realisierbar sein 
sollen und normalerweise auch bis zu 20kHz nicht völlig abregeln. 
Polyphase nutzt aber die Tatsache aus, daß nur noch sehr tiefe 
Frequenzen am Ausgang herauskommen sollen, so kann man unterabtasten. Da 
mache ich eine inverse FFT vom Frequenzgang, dann eine Fensterfunktion 
(z.B.Blackmanfenster) und erhält so die Filterkoeffizienten. Auf dem PC 
per Software mit WAV-Files funktioniert das schon einwandfrei. Auch, 
wenn mehrere Klangregler und Equalizer auf einmal verwendet werden 
sollten, braucht man nur das eine FIR-Filter, der Gesamtfrequenzgang 
wird zuerst berechnet, dann die Filterkoeffizienten daraus.

Einen Spartan habe ich mir auch schon seit längerem ausgesucht, ich 
brauche aber mehrere Multiplizierer, um eine Wortgröße von 24Bit zu 
erreichen. Evtl. reichen 16Bit für die Koeffizienten, das macht nur den 
Frequenzgang etwas ungenauer, beeinträchtigt jedoch nicht die 
Audioqualität und absolut phasenlinear bleibt es auch dann noch. Ich 
nehme den größten Spartan, den es noch in QFP- oder TQFP-Gehäuse gibt, 
da ich einiges an Speicher für die Filterkoeffizienten und auch für die 
Audiodaten brauche. Und das limitiert die Performance, die 
Multiplizierer schaffen das wohl schon. Ich schätze, daß ich zwei 
Spartans für ein Filter brauchen werde. Das war auch zuerst angedacht 
worden, DSPs wären nur etwas flexibler und vielleicht auch billiger, in 
VHDL habe ich schon einiges realisiert, sowohl beruflich als auch 
privat. Ich schätze, ich werde wohl bei der Spartanlösung bleiben, wenn 
ich das Datenblatt vom NXP-DSP gelesen habe...

Außerdem gibt es schließlich eine große Audiomatrix mit etlichen Ein- 
und Ausgängen, jeder Ausgang ist eine individuelle Linearkombination 
aller Eingänge, so ist der Verstärker softwaremäßig relativ frei 
konfigurierbar. Das geht nur mit einem FPGA wegen der vielen Ein- und 
Ausgänge, da sie alle I²S mit gemeinsamen Taktleitungen sind, nur die 
Datenleitungen sind getrennt, so daß es trotzdem nicht sooo viele Pins 
werden. Die Rechenleistung reicht da locker aus, da sind es viel weniger 
Multiply/Add Operationen als bei den Filtern.

Gruß
Andy

von Strubi (Gast)


Lesenswert?

Moin,

> 16 Bit ist definitiv zu wenig, ich verarbeite 24 Bit Audio. Da sollte
> die Wortbreite eher sogar noch etwas größer sein, Floating Point wäre
> eben ideal.

Die Wortbreite im Compiler ist bis 64 Bit. Ich verstehe das Problem 
schon, aber 32 Bit Audio zu verwursten ist mit dem Blackfin rechnerisch 
kein Problem, es geht halt nicht mehr mit einem Maschinenzyklus. Bei 600 
MHz Takt sind die paar zusätzlichen Ops für Audio ansich kein Problem, 
bei riesigen FFTs sieht's natürlich wegen der Dynamik anders aus, aber 
auch da kann man mit Normierungstabellen in Fixpoint gut tricksen

Also den Vergleich mit der 56k-Architektur würde ich nicht mehr machen 
:-)

>
> Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt,
> da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich
> mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen
> vorgesehen sind. Die Software und Datenblätter habe ich schon mal
> downgeloaded, es ist ein 24Bit Fixed Point DSP, also so gerade das
> Minimum, was für mich brachbar ist, könnte also klappen. Bei Texas bin
> ich gar nicht fündig geworden, keine DSPs für Audio gefunden und
> passende Software fand ich auf der chaotischen Seite erst einmal auch
> nicht.
>

TI hat sich bei seinen DSP-Hybriden etwas verzettelt, wenn ich ehrlich 
bin. Das Zeug hat eine Menge undokumentierter Bugs und ist vor allem auf 
Video ausgerichtet. Sobald man aber von den Standard-FAE-Apps abweicht, 
ist man auf sich alleine gestellt. Da würde ich eher schauen, dass du 
nen ARM mit DSP-Extensions herkriegst, damit lässt sich auch locker 
einiges an Audio mit machen.

> Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung.
> Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch
> mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8
> Multiply/Add Operationen pro Takt parallel ausführen (Pipilining), auf
> zwei FPGAs aufgeteilt 4 Multiply/Add Operationen usw. Evtl. kann ich die
> FPGAs auch auf 200MHz hochprügeln, nach außen hin gibt es nur wenige
> I²S-Ports und einen SPI-Bus. Aber DSPs wären billiger und flexibler.
>

Wieso solltest du da zwei FPGAs für brauchen? Schon auf dem kleinen 
Spartan6 hast du derart viele Multiplier, dass du da zwei bis vier 
DSP-Cores a la 56k locker draufkriegst, und die 18-Bit-MULs kaskadiert 
man eh zu 36 Bit, das macht die Toolchain sogar automatisch. Braucht 
zwar Entwicklungsaufwand, dafür bist du sehr flexibel und kannst deine 
eigene Fixpoint-Arithmetik implementieren (was bei manchen Filtern mit 
seinen Quantisierungsproblemen sehr nützlich sein kann), plus du kannst 
den ganzen Kram simulieren.
Nur: in VHDL würde ich das nicht mehr machen, es gibt nette 
DSP-Toolchains in der MyHDL community, da schreibst du dir keinen Wolf, 
und die Arithmetik ist sehr robust. Chris Felton hat da viel gemacht.


Grüsse,

- Strubi

von Kurt H. (Firma: KHTronik) (kurtharders)


Lesenswert?

Hallo Andy,
ich habe mich bei meinem Projekt KlarerTon (http://www.klarerton.de) mit 
dem ADSP21262 für den AD-Compiler entschieden. Der ist zwar nicht 
billig, aber wohl das Optimum für den Sharc. Der Support von AD ist 
einmalig gut, auch wenn Du keine Stückzahlen in Aussicht stellen kannst. 
Du erhältst eine 3-Monate Testlizenz, die auch mal um weitere 3 Monate 
verlängert wird. Schreib die einfach mal an. Auch in der 
Entwicklungsphase helfen die Mitarbeiter im Forum von AD mit hohem 
Einsatz weiter.
Bei meinem Projekt habe ich die ersten Entwicklungsschritte auf dem 
EvalBoard gemacht. Danach habe ich vom Steuer-Prozessor (ATMega 644A) 
per SPI gebootet. Diese Lösung hat sich bei mir sehr gut bewährt.
Da ich das Projekt nicht mehr weiter entwickle, ist die Lizenzpolitik 
von AD für den Compiler für mich optimal: Du kannst den Compiler/die IDE 
mit der einmal erworbenen Lizenz unendlich nutzen, erhältst aber nur mit 
einer aktualisierten Lizenz Updates. Das ist gerade für Einzelprojekte 
sehr fair.
Wenn Du an Informationen zu meiner Lösung Interesse hat, melde Dich.
Grüße, Kurt
PS: Das EvalBoard für den ADSP2126x liegt hier noch. Wenn Du es haben 
willst, melde Dich.

von Sharky (Gast)


Lesenswert?

Das EVAL board ist nicht zufällig noch zu haben?

von Kurt H. (Firma: KHTronik) (kurtharders)


Lesenswert?

Sharky schrieb:
> Das EVAL board ist nicht zufällig noch zu haben?

Doch, das liegt hier noch und wartet auf einen Nutzer. Einige andere 
nützliche Dinge könnten sich auch noch finden :-)

Du kannst mich unter kurt.harders@posteo.de kontaktieren.

von Hobbit (Gast)


Lesenswert?

@kurt:

Habe mir den thread zu deinem Projekt mal durchgelesen: Ist da 
eigentlich was bei rausgekommen?


Andreas W. schrieb:
> Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt,
> da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich
> mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen
> vorgesehen sind.
Die sind nicht mehr zeitgemäß. Es gibt immer noch welche, die denen 
nachhängen, aber es gibt Besseres:

Beitrag "Re: Emulation DSP56k für Audio Anwendungen"

Bitte 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
Noch kein Account? Hier anmelden.