Hallo zusammen. Ich habe beim Aufräumen noch einige TMS320 DSP und DSKs gefunden. Alles Querbett, bei den DSKs ist der C6416 drauf mit 720 MHz Takt und der C6416T mit 1 GHz. Das muss alles so Stand 2003/4 gewesen sein. Auf jeden Fall hatten wir damals viel Spaß und haben zum Beispiel Zerhacker (Audio und Video) für Funksysteme implementiert. Das ist lange her und wenn ich heute schaue welche Taktraten normale Mikrocontroller haben, geht ja in die gleiche Richtung, siehe STM32H7 oder Teensy 4... dann finden die mit der Leistung heute ja auch Anwendungen die eigentlich sehr DSP lastig sind! Hat der TMS320 da überhaupt noch einen Marktanteil im Vergleich zur Konkurrenz? Denn billig war die Sache damals ja nicht, heute glaube ist das CCS zumindest für "Privat" kostenlos? Wer von Euch hatte denn das letzte mal beruflich oder im Hobby noch mit dem TMS320 zu tun? Bin gespannt ob es da noch welche gibt und was waren Eure Anwendungen auf dem DSP von TI? Gruß Harri
Nur so aus Interesse, heutzutage sind FPGAs teilweise recht günstig und haben auch eine hohe Rechenleistung. Gibt es da noch eine Nische für reine DSPs?
FPGAs sind über die Jahre natürlich auch preiswerter geworden, aber ich glaube MCUs und DSPs sind da doch noch etwas günstiger und bieten möglicherweise einen geringeren Entwicklungsaufwand.
Ich hab erst letztes Jahr ein 20kW SMPS mit einem TMS320F28032 in Serie übergeben. Der rechnet dort zwei 100kHz Current Loops, eine 6kHz Voltage Loop, diverse Filter zweier und dritter Ordnung und macht das Housekeeping. Unschlagbar finde ich die schnellen ADCs die es mit dem Drumherum als single IC Lösung (adc+DSP+PWM+Flash) so nicht oft gibt. Ich bin begeisterter Nutzer!
> schnellen ADCs [x] > begeisterter Nutzer Hier auch (2808/2809/5410/5416/5502/5509/5535/...). > beim Aufräumen noch einige TMS320 DSP und DSKs gefunden @Harald: Die wuerden hier auch ein neues Zuhause finden. Bevor sie bei dir noch Rost ansetzen. Ich wollte mal einen baufreundlichen aus der 64er Serie samplen und selber bauen, aber irgendwas kam immer dazwischen.
Harald schrieb: > Denn billig war die Sache damals ja nicht, > heute glaube ist das CCS zumindest für "Privat" kostenlos? Für mich war das damals der Grund, mich mit FPGAs zu beschäftigen. Bei TI hatte ich nie den Eindruck, das die neue Nutzer für ihre DSP suchen.
Ja den Eindruck hatte ich auch eine lange Zeit! Aber es ist schön zu lesen das der DSP doch noch ein paar Entwickler hat, ich dachte schon der Markt für den 320 ist nicht mehr vorhanden. Von dem DSK mit 6416 habe ich noch 12 Stück liegen, von dem 6414T noch 7 Stück. Ein paar kleinere DSKs sind auch noch reichlich da. Ich liste die mal noch auf. Meint ihr mit den DSPs könnte man den Nachwuchs noch begeistern oder dürfen es hier nur Projekte mit Arduinos oder Lego Mindstorm sein? Also mich haben damals so etwas wie digitale Filter oder Signalübertragung ja noch fasziniert. Aber mit dem Taschengeld und Ferienarbeit war ich weit davon entfernt mir ein solches Board, geschweige denn einen passenden PC leisten zu können. Aber wenn sich heute nichts mehr bewegt, raucht oder Licht macht ist es wahrscheinlich bei dem Nachwuchs uninteressant? LG Harri
Harald schrieb: > Meint ihr mit den DSPs könnte man den Nachwuchs noch begeistern Eher nicht. Es gibt mehr als genug µC mit DSP-Einheiten. Wenn man also DSP braucht (oder das auch nur glaubt) wird man einen solchen wählen... Es gibt also zumindest kaum einen Grund mehr, mit externen DSPs rumzuhampeln...
Harald schrieb: > Nachwuchs noch begeistern Man konnte den Nachwuchs früher mit DSPs begeistern? Das war doch eher ein recht teurer Spaß mit teuren PCs und Messtechnik. Ich denke nicht, dass es früher (90-00er) viele gab die privat mit DSP oder FPGA gearbeitet haben, da war ein 8051 oder Atmel ja schon eher was spezielles.
F. M. schrieb: > Harald schrieb: >> Nachwuchs noch begeistern > > Man konnte den Nachwuchs früher mit DSPs begeistern? > Das war doch eher ein recht teurer Spaß mit teuren PCs und Messtechnik. > Ich denke nicht, dass es früher (90-00er) viele gab die privat mit DSP > oder FPGA gearbeitet haben, da war ein 8051 oder Atmel ja schon eher was > spezielles. Atari Falcon... ^^
> Ich denke nicht, dass es früher (90-00er) viele gab die privat mit DSP > oder FPGA gearbeitet haben, da war ein 8051 oder Atmel ja schon eher was > spezielles. Als die c't noch kein mac-Kaeseblatt war, gab es dort mal einen Artikel der sich mit den 56002 naeher befasste (Romeo und Julia). Ich habe damals den "einfachen" Weg gewaehlt und mir ein 56002-Kit kommen lassen statt den Vorschlaegen der c't zu folgen. Und ich wurde auch nicht enttaeuscht. Fuer den Neuling sind die TI 64er DSPs in der Tat eher nichts. Zumeist wird auch ein eher teuerer JTAG-Adapter benoetigt. Ein mir bekannter Kollege versuchte darauf mal ein wirklich simples FIR-Filter zum laufen zu bringen. Beim Versuch ist es geblieben. Wenn man massiv parallel arbeiten will, sind FPGAs sicherlich heute das Mass der Dinge. Aber um Algorithmen einfach mal praktisch zu testen, ist man mit dem DSP einfach schneller. > Bei TI hatte ich nie den Eindruck, das die neue Nutzer für ihre DSP suchen. TI hat Entwickler mit Samples und auch kostenlosen Lizenzen abseits der Vertriebswege unterstuetzt. Deinen Eindruck kann ich also nicht teilen. > Ich liste die mal noch auf. Mach mal :-).
Larry schrieb: > Fuer den Neuling sind die TI 64er DSPs in der Tat eher nichts. > Zumeist wird auch ein eher teuerer JTAG-Adapter benoetigt Na zumindest bei den DSKs waren die JTAG-Programmierer auf den Board mit drauf! Ansonsten stimmt das natürlich schon, billig waren diese JTAGs nicht. Muss mal schauen was man heute für ein xds100 hinlegen muss! Aber bei den schnellen uC heute denke ich auch es wird sich keiner mehr auf die 320er stürzen. Das sehe ich auch irgendwo so. Und nur weil ich damit tolle Projekte hatte, muss ich die Nachwelt damit nicht quälen, allein schon wegen des historischen CCS der den DSKs beigelegt ist. Ich werde wohl von jedem DSK ein Exemplar aus sentimentalen Gründen für mich erhalten und mir in die Vitrinen lege und den Rest nach /dev/null umleiten. Danke für Eure Einschätzungen die ich im Prinzip ja auch teile. VG Harri
Harald schrieb: > > Ich werde wohl von jedem DSK ein Exemplar aus sentimentalen Gründen für > mich erhalten und mir in die Vitrinen lege und den Rest nach /dev/null > umleiten. Tu das bitte nicht. Ich wuerde Dir gerne von den DSKs jeweils einen abkaufen, ich habe hier schon ein paar und spiele auch gelegentlich damit rum. Wie kann man Dich denn erreichen falls Du welche von DSKs verkaufen würdest?
Mit einem > xds100 wird man mit den 64er DSPs wohl Probleme haben. XDS510 und XDS560 sind da wohl angezeigter. > den Rest nach /dev/null umleiten. :-(
Larry schrieb: > Ein mir bekannter Kollege versuchte darauf mal ein wirklich > simples FIR-Filter zum laufen zu bringen. > Beim Versuch ist es geblieben. Wo war das Problem? Die heutigen Chips kommen doch alle mit massenhaft LIBs zunm Copy und Paste.(?) Früher musste wir noch alles selber machen. War auch irgendwie einfacher, wenn man drüber nachdenkt. Die heutigen TMS sind mit den damaligen auch kaum zu vergleichen: http://www.96khz.org/oldpages/vamodelling2.htm Das passt heute z.B. in einen "normalen" UC.
Ich würde die DSKs noch ein paar Tage, Wochen beherbergen, falls die jemand wirklich noch haben will soll er hier schonmal virtuell die Hände heben, ansonsten fliegen die spätestens mit Semesterstart in den Müll. Der Grund dafür: Corona! Ich stand gestern für einen Einschreibbrief 2 Stunden in der Schlange, denn im riesigen Postamt (altes kaiserliches Telegrafenamt, also richtig groß) mit bestimmt 500qm Schalterraum dürfen nur zwei Kunden auf einmal rein und es gab nur einen Schalterbeamten. Ihr könnt Euch die Schlange kaum vorstellen, wenn die Leute ihre Amazon-Pakete abholen oder wieder zurückschicken! Und in diese Wartegesellschaft möchte ich mich nicht wegen jedes DSK einzeln einreihen und zwei Stunden warten müssen. Die Pakete von DHL abholen zu lassen ist auch keine Alternative. Wenn Dir mir sagen sie kommen zwischen 8-18 Uhr, dann ist das ja eine verkappte Quarantäne, sprich man kommt gar nicht vor die Tür! Also die 64er DSKs finden hier noch Abnehmer? Die C5535 ezdsp Bretter und anderes kleines Gemüse ist wahrscheinlich nicht mehr so gefragt? Ja xds100 macht ja nur denn C64+, aber die DSKs haben alle einen JTAG Emulator drauf, ein USB-Kabel reicht da also aus und liegt dem DSK bei. So auch das passende Netzteil und CDs mit zahlreichen PDFs zum DSP und dem sehr alten Code Composer Studio, glaube Version 2 oder 3. Also mit Win10 läuft da nichts mehr, eher Windows NT4 oder 2000. Vielleicht läuft das noch in einer Virtualbox oder man muss sich einen alten Gebrauchten bei Harlander und Kompanen holen und da so ein Altsystem drauf installieren. Gruß Harri
Beitrag #6347053 wurde vom Autor gelöscht.
Harald schrieb: > > Also die 64er DSKs finden hier noch Abnehmer? > Die C5535 ezdsp Bretter und anderes kleines Gemüse ist wahrscheinlich > nicht mehr so gefragt? Also ich wäre an einem von jedem der DSKs interessiert. Gerne auch die alten, ich habe öfters mal in älteren Geräten mit solchen DSPs zu tun und da ist es manchmal ganz praktisch wenn man für Experimente ein externes Board mit dem DSP hat. Ein altes Windows auf dem die Software läuft ist kein Problem ;-) Dass Du nicht bei der Post anstehen willst verstehe ich gut, ich warte gerne bis sich die Situation entspannt. Alternativ: ich würde natürlich auch die höheren Versandkosten zahlen wenn Du die Lieferung von DHL bei Dir zuhause abholen läßt.
> hier schonmal virtuell die Hände heben Ich hab zwar schonmal, aber sicher ist sicher: [x] Es ist auch keine Eile geboten. > xds100 macht ja nur denn C64+ Ich hab hier einen BH560m. Der sollte den C64+ sicher auch koennen. Und einen umgeschnurzelten MSP430-JTAG mit angepasster DLL fuer CCS. > anderes kleines Gemüse Wenn da ein CCS dabei ist, dass noch den TMS320C25/26 unterstuetzt... Die Version CCS3.3 mag den nicht mehr. Div. TMS320C15 und TMS320C31 warten hier bei mir auch noch. Danke fuer deine Aufmerksamkeit.
Ich würde Dir auch eins von den größeren und auch den kleineren Boards abnehmen. Ein konkretes Projekt schwebt mir nicht vor, aber thematisch interessiert mich das schon länger. Bitte nichts wegschmeißen, wäre schade drum. Und wenn es nur als Lernplattform dienen kann. Ich kenne jemanden der macht an der Schule Elektronik/ Programmierung - AG, da kann damit schon noch was anfangen
Wir nutzen den TMS320C28343 noch sehr regelmäßig im bereich der Messtechnik. Der sammelt die AD-Wandler-Daten mit 32kHz ein und filtert die per FIR runter auf ~4kHz. Dazu eben noch Verrechnung mit entsprechenden Kalibrierwerten und Transformation vom rotierenden ins feststehende Koordinatensystem. Vorteil soweit wir das bisher gesehen haben im vergleich zu den ARMs (z.B. Atsamd51) ist der größere Speicher und die spezielleren/schnelleren MAC-Befehle.
Ich fand den TMS320 seinerzeit eher grauslich und nur mit dem C-Compiler zu ertragen. Ich bin mit fliegenden Fahnen zum Analog Devices SHARC übergelaufen. Der Beaglebone AI soll aber 2 TI DSPs enthalten, zusammen mit 2 "großen" ARMs und mehreren "kleinen". Ich hab's noch nicht näher angesehen, mir reicht zur Zeit noch der Beaglebone Black. Ich würde vermuten, dass die beiden DSPs aufgemotzte Nachfahren des TMS320 sind. Ihre nötige Infrastruktur dürfte wohl komplett vorhanden sein, inclusive Anbindung an das Debian Linux auf den ARMs. Vermutlich ein Einstieg ohne große Hürden und vergleichsweise billig. Laptop und USB-Kabel reicht. Ich habe seinerzeit mal eine Diplomarbeit mit einem 56K betreut. Nach der Prüfung hat der Student schlagartig jegliches Interesse an dem Ding verloren, mit etwas Glück könnte es noch in meinem Keller verstauben. Gruß, Gerhard
:
Bearbeitet durch User
Bevor ich Ende der Woche in den Urlaub fahre um meine persönliche Portion Corona abzuholen, wollte ich nochmal kurz sagen das ich jedes DSK als Einzelpaket für 7.50 Euro mit DHL in der Originalverpackung verschicken würde. In das größte Paketset passen somit nur 2 DSK und gewichtsseitig kommt man damit knapp über die 5 Kilo-Grenze. Das 10 Kilo-Paket kostet aber schon 10.50 Euro plus das Paketset. Kommt also letztendlich fast aufs Gleiche und somit lohnt sich für mich jetzt nicht das Anstellen für die Paketsets und dann nochmal fürs verschicken. Ich habe auch noch drei gebrauchte, aber funktionierende Altera Ep2S60 Devkits für NIOS2. Hat nichts mit TMS320 zu tun, aber da ich beim Aufräumen bin würde ich die für 25 Euro Stück + Porto verschicken. Die 25 Euro gehen an ein Hospiz für unheilbare Kinder. Ich lasse das hier einfach mal laufen und dann gibt es nach dem Urlaub eine Mail. Über die könnte Ihr mir dann per Paypal das Porto bezahlen und die Lieferadresse bekannt geben. Die restlichen DSK gehen dann abschließend nach /dev/null weil der Platz für andere Sachen gebraucht wird. Einen schöne Sommerurlaub, bleibt gesund Harri
Ich würde Interesse anmelden, an einem TMS320 DSK allerdings mit Versand nach AT, Kosten übernehme ich natürlich, würde auch großzügig aufrunden. Interessant wäre für mich der C6416 würde natürlich noch mehr aufnehmen:) Ich habe hier im Labor ein Thinkpad T30 mit XP für die ganze 2000er Agilent/RuS SW darsuf sollte die SW eigl. laufen. LG und schönen Urlaub
Also ich würde auch mal Interesse an einem der C6416 und einem der Stratixe anmelden. Ich habe aber kein PayPal, ich würde vorab überweisen wollen wenn möglich.
Ich hätte wie schon weiter oben geschrieben Interesse an jeweils einem der TMS320 DSKs (Du hast ja gschrieben dass Du verschiedene Varianten davon hast). Ich würde auch eines von den Ep2S60 Devkits nehmen, falls noch eines davon übrig ist. Das mit dem Einzelversand in der Orignalpackung passt, Bezahlung per PayPal ebenso.
Hat von Euch jemand eine controlCARD? z.B. TMDSCNCD28069 https://www.mouser.de/ProductDetail/Texas-Instruments/TMDSCNCD28069 Evtl. mit isoliertem USB-Interface drauf? z.B. TMDSCNCD28035ISO https://www.mouser.de/ProductDetail/Texas-Instruments/TMDSCNCD28035ISO Ich habe ein TMDSHVMTRPFCKIT (High Voltage Motor und PFC Kit) und kann nicht debuggen, evtl. ist der Jtag-Isolator auf dem Mainboard defekt. https://www.mouser.de/ProductDetail/Texas-Instruments/TMDSHVMTRPFCKIT
> evtl. ist der Jtag-Isolator auf dem Mainboard defekt. Das sollte sich ja messtechnisch eingrenzen lassen. Das Piccolo-Launchpad (28027) hat ebenfalls einen isolierten JTAG. Ob der fuer deine (Spannungs-)Ansprueche reicht? > Beaglebone AI > dass die beiden DSPs aufgemotzte Nachfahren des TMS320 sind. Der Urvater war der TMS320C10. Dessen Architektur findet man in den 16 Bit Nachfahren wieder. Die beiden DSPs im Beaglebone sind im Gegensatz dazu: "very-long-instruction-word (VLIW) architecture". > gibt es nach dem Urlaub eine Mail Da bin ich ja mal gespannt. (Wie das gehen soll.)
Larry schrieb: >> gibt es nach dem Urlaub eine Mail > > Da bin ich ja mal gespannt. (Wie das gehen soll.) Hallo Larry, so wie Du den Beitrag Text reinschreibst kann das doch auch eine für diesen Zweck erstellte Mailadresse sein über die per Paypal bezahlt wird und über die der Bezahler nochmal seine genaue Lieferadresse mitteilt? Wo ist da das Problem? Harri
> eine für diesen Zweck erstellte Mailadresse
Damit wuerde es wohl gehen.
Sowas brauch ich sonst nie...
Schoenen Urlaub noch.
Falls was über ist, würde ich auch noch was nehmen, bevor es verschwindet. Ist wirklich schade drum. Übrigens kam gerade diese Woche dieselbe Frage in der Music.DSP-Gruppe hoch, was so alles mit TMS320-Prozzis entwickelt wurde. Schon interessant.
Beitrag #6360643 wurde von einem Moderator gelöscht.
Beitrag #6360645 wurde von einem Moderator gelöscht.
Beitrag #6378212 wurde von einem Moderator gelöscht.
Generell sind die spezialisierten DSP`s nicht schlecht gegenüber FPGA-Varianten. Alles ist bereits verkabelt und man kann sofort loslegen mit dem programmieren. Bei den FPGA`s muss man erst alles konfigurieren, synthetisieren, implementieren,generieren. Dann bekommt man etliche Timingfehler und wenn mal ein Hardware-Projekt steht, dann sollte man daran tunlichst keine Veränderungen mehr machen. Weil dann intern wieder anders geroutet wird und wieder Timingfehler etc. entstehen. Erst dann geht es an die Programmierung. Die verbauten ADC`s sind eh für viele Anwendungen kaum nutzbar und wenn doch, dann ist der Chip ggü. DSP/ADC-Lösung um einiges teurer. Zudem sind manche Tools Bug behaftet, weil anscheinend die Chips zu komplex geworden sind. Letztlich hat ein spezialisierter DSP parallele Pipelines für die Befehlsausführung, was ein DSP-Core im FPGA oft nicht besitzt. Allein die Ausführung von FFT`s direkt in Hardware hat aufgrund der Parallelisierung Geschwindigkeitsvorteile. Aber DSP`s für Mobilfunkanwendungen - z.B. StarCore von NXP - haben mittlerweile alles mögliche an Bord und kosten nicht die Welt. Die Eingangsfrage, ob der DSP heute noch eine Bedeutung hat, kann man zwar mit "Ja" beantworten, aber es ist z.Zt. einfach schick, FPGA`s zu benutzen.
> Letztlich hat ein spezialisierter DSP parallele Pipelines für die > Befehlsausführung, was ein DSP-Core im FPGA oft nicht besitzt. Wenn man zu doof ist, bei einem FPGA die Multiplizierer und/oder MACs parallel bei Laune zu halten, kann man das nicht dem FPGA anlasten. Das Gegenteil ist richtig: Der FPGA hat weitaus mehr parallel verfuegbare Ressourcen.
@Klugscheisser: Wie programmierst Du denn z.B. in C Deinen FPGA? Doch nicht in der Hardware. Dafür nimmst Du VHDL. Es geht jetzt auch nicht um die parallelen Strukturen in der Hardware, sondern um den DSP-Core im Processing System. Und dort wird weit weniger parallel an Befehlen abgearbeitet, als im reinen DSP.
DSPASM schrieb: > Generell sind die spezialisierten DSP`s nicht schlecht gegenüber > FPGA-Varianten. Alles ist bereits verkabelt und man kann sofort loslegen > mit dem programmieren. Ja, richtig. Dafür fehlt die Freiheit fehlende Opcodes nachzurüsten. > Bei den FPGA`s muss man erst alles konfigurieren, > synthetisieren, implementieren,generieren. Dann bekommt man etliche > Timingfehler und wenn mal ein Hardware-Projekt steht, dann sollte man > daran tunlichst keine Veränderungen mehr machen. Weil dann intern wieder > anders geroutet wird und wieder Timingfehler etc. entstehen. Timingfehler entstehen nur, wenn das Design nicht richtig constraint, extrem auf Kante genäht oder das FPGA zu mehr als 80% voll ist. Da hat jemand offensichtlich seine Werkzeuge nicht im Griff. > Die verbauten ADC`s sind eh für viele > Anwendungen kaum nutzbar und wenn doch, Welche verbauten ADCs? Wenn ich eine FPGA-Lösung wähle, dann kommen da die passenden ADC's ran. Abtastraten, Bitbreite, Zahl der Kanäle und die Wahl der Schnittstelle, für ein FPGA gibt es da keine Einschränkungen. > dann ist der Chip ggü. > DSP/ADC-Lösung um einiges teurer. Das mag sein. Ist am Ende auch eine Frage von Stückzahlen und Entwicklungskosten. > Zudem sind manche Tools Bug behaftet, > weil anscheinend die Chips zu komplex geworden sind. Und die DSP-Tools sind alle fehlerfrei? Komisches Argument. > Letztlich hat ein spezialisierter DSP parallele Pipelines für die > Befehlsausführung, was ein DSP-Core im FPGA oft nicht besitzt. Quatsch.
Bernd schrieb: > Ja, richtig. Dafür fehlt die Freiheit fehlende Opcodes nachzurüsten. Bei einem DSP braucht man keine Befehle nachrüsten. Es gibt vielleicht ein paar must haves, die sind aber mit vorhandenen Codes umsetzbar. > Timingfehler entstehen nur, wenn das Design nicht richtig constraint, > extrem auf Kante genäht oder das FPGA zu mehr als 80% voll ist. Da hat > jemand offensichtlich seine Werkzeuge nicht im Griff. Wir sprechen hier auch von Takten höher 800MHz und mehrere angeschlossene ADC mit Deserializer etc. Und wenn ich bei 80% Füllgrad bereits den nächst größeren Chip kaufen darf, weil nix mehr geroutet werden kann, damm freuen sich Xilinx&Co und der Kunde quängelt. > Und die DSP-Tools sind alle fehlerfrei? Komisches Argument. Programmiere in Assembler und Du bist frei von Warnings und Errors, die aufgrund von Compilerschaltern und Multi-Pass Durchläufen erst im C-Compiler entstehen. Jetzt warte ich auf das Argument, wer programmiert noch in Assembler und das dauert doch um einiges länger. Der schaue im Internet nach, wo Firmen bereits im Zuge von verbesserter Rechenleistung und Energiesparsamkeit damit werben. > >> Letztlich hat ein spezialisierter DSP parallele Pipelines für die >> Befehlsausführung, was ein DSP-Core im FPGA oft nicht besitzt. > Quatsch. Nenn mir einen DSP-Core für FPGA's, der mehr als 3 parallele Befehle abarbeiten kann. Und zuletzt braucht ein FPGA oft etliche Versorgungsspannungen, die zudem im richtigen Rhythmus eingeschaltet werden müssen. Ich will die FPGA's nicht schlecht machen, aber DSP's haben durchaus eine Bedeutung.
Oh, da werden Erinnerungen wach. Ich habe um 2005 rum wirklich viel Spaß mit den DSPs gehabt. Wenn man die acht Execution-Units voll ausnutzt und per DMA die Daten vom Hauptspeicher in das interne RAM schaufelt (so das es keine Cache-Misses gibt) hat der DSP eine brachiale Rechenleistung. Zumindest für 2005 Verhältnisse. Die DSP Cores tauchen immer wieder als Co-Prozessoren in den TI SoCs auf (OMAP, Sitara). Gern auch mal getarnt unter dem Namen IVA-HD Subsystem. Der Beagle-Bone AI hat damit drei DSPs an Board. Wenn man sich das Datenblatt reinzieht gibt es übrigens einige Überraschungen zu entdecken: Vielen der C64x+ Varianten haben eine Video Acceleration Peripherie. Da findet man unter dem ominösen Namen Sequencer ein kompletten ARM9 Core, der als Co-Pro zum DSP läuft. Hat eigenes RAM, läuft also komplett ohne Cache-Misses. Und Zugriff auf EDMA3 hat er auch. Damit bekommt man DMA Speicher Zugriffs Patterns in den Griff, die der eh schon gute EDMA3 alleine nicht hin bekommt. Habe mir mal den Spaß gemacht das Teil zu booten. Ich hab noch 'ne schöne Fixed-Point CORDIC Implementierung für Umwandlung von Cartesischen auf Polare Koodinaten hier, die ich mal in Assembler geschrieben habe. Läuft mit 1.5 Cycles pro Cordic Iteration (8 Umwandlungen zeitgleich). Wenn die einer sehen will poste ich die gerne..
> Nenn mir einen DSP-Core für FPGA Was soll denn der Unsinn. Bereits ein strunzig alter Cyclone 2 (der allerkleinste) kann 13 mal parallel 18 bit mit 18 bit multiplizieren. Der groesste hat 150 von diesen Multiplizierern. Die sich auch zu anderen Wortbreiten zusammenschalten lassen. Und auf denen spielt die Musik. Nicht auf einem ominoesen "DSP-Core". Und der Cyclone 2 ist nun wahrhaftig nicht das Flaggschiff der FPGAs zur Signalverarbeitung. > Programmiere in Assembler und Du bist frei von Warnings und Errors Auch das taeuscht maechtig. Allein die TI-DSPs der TMSC5xyz-Serie haben mehrere "Silicon Revisions" durchlaufen, in denen z.B. Abhaengigkeiten (aka Fehler) in der Codeausfuehrung bereinigt wurden. Stellenweise wurde/wird da auch noch im Assembler nachgeholfen. > ein FPGA oft etliche Versorgungsspannungen Das gibt genug DSPs bei denen das auch so ist. Den Core mit anderen (kleineren) Spannungen laufen zu lassen als IO, ist ja auch irgendwo sinnvoll.
Klugscheisser schrieb: > Bereits ein strunzig alter Cyclone 2 (der allerkleinste) > kann 13 mal parallel 18 bit mit 18 bit multiplizieren. > Der groesste hat 150 von diesen Multiplizierern. > Die sich auch zu anderen Wortbreiten zusammenschalten lassen. > Und auf denen spielt die Musik. Nicht auf einem ominoesen > "DSP-Core". Und der Cyclone 2 ist nun wahrhaftig nicht > das Flaggschiff der FPGAs zur Signalverarbeitung. Nimm z.B. zwei Signale mit je einer Tiefe von 1024...8192 Wörtern und meinetwegen 18Bit Breite auf und korreliere die dann. Da kommst Du mit dem strunzigen Cyclone nicht weit. Dafür brauchst Du schon etwas mehr an Zellen oder DSP-Slices, um das zu berechnen. Dann musst die die Originalsignale natürlich noch im internen Speicher vorhalten, die Korrelationskurve evtl. auch noch zwischenspeichern, vielleicht noch Platz für einen µC oder DSP-Core (falls man nicht extern einen anbauen will) usw. Kostet alles Platz und Geld.
> Da kommst Du mit dem strunzigen Cyclone nicht weit. Ei sicher wird es Aufgabenstellungen geben, in denen schlicht mehr gefragt ist. Darum ging es mir ja gar nicht. Ich kann bei meinen Aufgaben fast immer parallelisieren und vom Vorhandensein mehrerer Funktionsbloecke profitieren. Und das in einem weitaus hoeherem Mass, als parallele Adressrechnungen, mehrere Datapaths und multiple Instruktionen es bei einem DSP zulassen wuerden. Daher ist fuer mich der Gedanke an einen "DSP-Core" im FPGA voellig abwegig, der irgendwo einen oder von mir aus auch mehrere DSP emuliert. Weil mich das auf genau das Niveau zurueckwirft, wo ich vorher ohne FPGA war. Natuerlich kann man einen Softcore (NIOS2 etc.) benutzen, um Dinge die fuer den eigentlichen Algorithmus/men zeitunkritisch sind, ablaufen zu lassen. Aber eben nicht als signalverarbeitender DSP. In "meiner" Ziel-HW steckt ein Cyclone 3 EP3C25 nebst 8 MB RAM und den Codecs. Und da brauche ich mir was die verfuegbaren Ressourcen angeht, im Moment noch ueberhaupt keine Gedanken machen.
Max H. schrieb: > Ich hab noch 'ne schöne Fixed-Point CORDIC Implementierung für > Umwandlung von Cartesischen auf Polare Koodinaten hier, die ich mal in > Assembler geschrieben habe. Läuft mit 1.5 Cycles pro Cordic Iteration (8 > Umwandlungen zeitgleich). Wenn die einer sehen will poste ich die > gerne.. Klar, stell sie mal hier rein.
DSPASM schrieb: > Nenn mir einen DSP-Core für FPGA's, der mehr als 3 parallele Befehle > abarbeiten kann. Was ist denn ein "DSP-Core"? Man bekommt aktuell recht preiswert FPGAs mit >100 DSP Slices, das geht hin zu weit über 1000 DSP Slices in einem Chip die natürlich alle zeitgleich rechnen können. https://www.xilinx.com/support/documentation/user_guides/ug579-ultrascale-dsp.pdf Ich verwende aktuell einen Artix7 100, und nutze da drinnen 235 von den 240 DSPs. Die arbeiten bei 250 MHz gibt also 58*10^9 Multiplikationen/s. In klein und preiswert bei < 2 W Verlustleistung. > Und zuletzt braucht ein FPGA oft etliche Versorgungsspannungen, die > zudem im richtigen Rhythmus eingeschaltet werden müssen. > Ich will die FPGA's nicht schlecht machen, aber DSP's haben durchaus > eine Bedeutung. Jo, braucht er. 1.0 V, 1.8 V, 2.5 V, 3.3 V. Und? Ich beachte da keine besondere Reihenfolge und es funktioniert wunderbar.
Lowlevel schrieb: > Klar, stell sie mal hier rein. Gerne. Hier das Highlight vom Compiler: Loop Carried Dependency Bound(^) : 7 Unpartitioned Resource Bound : 12 Partitioned Resource Bound(*) : 12 ii = 12 Schedule found with 2 iterations in parallel Das C Äquivalent (für ein Complex Value): void cordicXY2RT ( int x, int y, int *r, int *theta) ///////////////////////////////////////////////////// { int i; int z = 0; for (i=0; i<16+3; i++) { int xa,ya; int angle = atantab[i]; int shift = i-2; if (shift < 0) shift = 0; ya = y >> shift; xa = x >> shift; if (y < 0) { x -= ya, y += xa, z -= angle; } else { x += ya, y -= xa, z += angle; } } *r = fixmul16 (x, scaleK); *theta = z; } Der Trick war, die Conditionals loszuwerden. Da ich 8 Werte gleichzeitig umwandel reichen die Conditional Register nicht. Zudem sitzen die D und M Units die ganze Zeit faul rum. Über cmplt erzeuge ich mir eine Zahl zwischen 0 und 1 für den Vergleich. Über addah wandel ich das in -1 oder 1 um (geht durch die D Unit). Das geht dann in die M-Unit. Die Conditionals sind danach nicht mehr notwendig, die L und S Units entlastet. So kommt man auf die 12 Cycles für 8 Werte Parallel.
Harald schrieb: > Wer von Euch hatte denn das letzte mal beruflich oder im Hobby noch mit > dem TMS320 zu tun? Bin gespannt ob es da noch welche gibt und was waren > Eure Anwendungen auf dem DSP von TI? 2000 Diplomarbeit im Bereich Avionik.
Harald schrieb: > Hat der TMS320 da überhaupt noch einen Marktanteil im Vergleich zur > Konkurrenz? TI würde sich sonst nicht die Mühe machen, neue Modelle rauszubringen: https://www.ti.com/prod-list/new-products#Microcontrollers%20%28MCU%29
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.