Kennt sich jemand mit NIOS so gut aus, dass er mir eine Einschätzung liefern könnte, mit welcher Performance ich rechnen kann? Ich habe bisher etwas mit Microblaze gemacht, das sich aber auch einfache Steuerungen und FPGA-Zugriffe beschränkt. In einem vorliegenden Projekt geht es nun darum, auch rechenintensive Sachen zu realisieren, bei denen man eigentlich zu externen DSPs greift. Was kann denn da der NIOS? Ich habe mir die Doku angesehen und finde z.B. keine Float-Unterstützung, mathematische Funktionen (TriGo) etc. Gibt es da so etwas wie einen CoPro den man instanziieren könnte, oder alternativ: Was liesse sich als DSP-Core in einem FPGA implemtnieren? Gibt es überhaupt einen DSP-Core als VHDL? Macht es Sinn, mehrere SoftCores parallel zu nutzen? Von meiner DSP-Erfahrung her würde ich spontan sagen, dass die SoftCores eher noch nicht so weit gediehen sind, oder?
Hi, es gibt z.B. einen TI C54x DSP clone auf opencores.org. Habe ihn aber noch nicht benutzt. Sonst gibt es bei opencores einige CoProzessor-Implementierungen für div. Zwecke, zum Thema Trigo siehe auch CORDIC. Der NIOS ist eher so ein typischer Allrounder, schenkt sich wohl nicht viel zum microblaze, ausser dass der NIOS etwas etablierter scheint. Die Frage ist, wie komplex Deine Berechnungen sind (Audio, Video, Bittiefe, fixed point/float..) Wenn Du nur stupides Datencrunchen machst, lohnt es sich u.U. auch, einen eigenen stupiden Sequencer zu schreiben, heisst, einen speziell für den Zweck ausgerichteten "DSP" zu designen. Aber man muss vorher sehr genau festlegen, was man machen will und in die Opcodes und das Pipelining gut designen. Knifflig wird's, ein vernünftiges Debug-Interface (ein IMHO gewichtiger Knackpunkt) hochzuziehen, damit man seinen Code zeitsparend debuggen oder zumindest durchsteppen kann (habe ich mal für JTAG gemacht, könnte man auch ein OC-Project draus machen). Diesbezüglich würden mich auch einige Erfahrungsberichte mit OpenCores-Prozessoren interessieren.. Gruss, - Strubi
Gerald Hellinghaus schrieb: > Gibt es überhaupt einen DSP-Core als VHDL? Es gibt ein paar Projekte auf opencores.org... > Macht es Sinn, mehrere SoftCores parallel zu nutzen? Kommt drauf an. Wenn Du Deinen Algorithmus gut verteilen kannst und die FPGA-Features (frei Konfigurierbarkeit) auch nutzt, dann könnte e ssinnvoll sein einen FPGA zu verwenden. Sonst würde ich eher eine fertige Multitore-CPU einsetzten. > Von meiner DSP-Erfahrung her würde ich spontan sagen, dass die SoftCores > eher noch nicht so weit gediehen sind, oder? Würde ich auch sagen. Die Fragen sind u.a.: - Wie schnell muß das fertig sein? - Welche Fähigkeiten/Erfahrungen sind da? - Welche Ein-/Ausgabeschnittstellen werden benötigt? - Wie "fett" ist das Rechenproblem und wie gut läßt es sich auf FPGA/CPU/Multicore-CPU partitionieren? > Kennt sich jemand mit NIOS so gut aus, dass er mir eine Einschätzung > liefern könnte, mit welcher Performance ich rechnen kann? Laut http://en.wikipedia.org/wiki/Instructions_per_second ist der NIOS II/f mit 1.13 MIPS/MHz angegeben. Duke
Gerald Hellinghaus schrieb: > Von meiner DSP-Erfahrung her würde ich spontan sagen, dass die SoftCores > eher noch nicht so weit gediehen sind, oder? Du hast den Sinn eines FPGAs nicht verstanden. Einen Prozessor Softcore verwendet man in einem FPGA nur für Funktionen die keine Rechenleistung erfordern, aber dafür komplex sind. Wie z.B, das gelegentliche Dekodieren und Bauen von Datagrammen, hier grüßt die LwIP. Es ist völlig sinnlos, mit einen Prozessor-Softcore hochperformante Probleme lösen zu wollen, das kann jeder Prozessor besser und billiger. Weiterhin enthalten moderne FPGAs DSP-Cores, die benutzt man im eigenen Code direkt selber oder über Filter- und Numerik-Cores indirekt. Aber nicht über einen Prozessor-Softcore, außer der dort vorhandene Multiplizierer. Wenn du ein Problem mit rechenintensiven Anforderungen hast, musst du deinen Algorithmus mit VHDL oder Verilog direkt auf die Hardware des FPGAs bringen und nicht indirekt mit C/C++ über einen Prozessor-Softcore. Tom
Ich denke auch, dass das Anwendungsfeld für DSPs in FPGAs sehr begrenzt ist. Zwar hat eine interne Rechenarchitektur Vorteile im Bezug auf den Zugriff von FPGA-Resourcen oder die vom FPGA gesteuerten board-Resourcen, aber sobald die Applikation ein bischen größer und komplexer wird oder mehr RAM-Bedarf hat, ist die Lösung mit separierten DSPs in allen Belangen die Bessere. Ich sehe eigentlich nur den Anwendungsfall, wenn alte Systeme mit alten und leistungsschwachen DSPs kurzerhand in FPGAs gestopft werden und der DSP unter Beibehalt des Codes absobiert wird. Das ist z.B. dann der Fall, wenn man Lieferbarkeit sicherstellen will und Plattformen vereinheitlichen. So kann man z.B. abgekündigte Prozzis noch lange supporten und auch dessen SW pflegen, ohne bei der Umstellung schlagartig einen grossen Arbeitsbedarf zu haben. Ansonsten bleiben nur die stark "IO-lastigen" und Durchsatzfordernden Anwendungen, die ein FPGA erzwingen, in dem mehrere Recheneinheiten parallelisiert werden müssen. Sobald ein DSP von der grundsätzlichen Performance eine Anwendung schafft, ist er das Mittel der Wahl. Spezialisierte DSPs sind einfach unerhört schnell und auch vergleichsweise billig.
Moin, > Ich denke auch, dass das Anwendungsfeld für DSPs in FPGAs sehr begrenzt > ist. Zwar hat eine interne Rechenarchitektur Vorteile im Bezug auf den > Zugriff von FPGA-Resourcen oder die vom FPGA gesteuerten > board-Resourcen, aber sobald die Applikation ein bischen größer und > komplexer wird oder mehr RAM-Bedarf hat, ist die Lösung mit separierten > DSPs in allen Belangen die Bessere. > Das würde ich jetzt auch nicht mehr so bedingungslos unterschreiben (obwohl ich tendentiell - als erstes zumindest - auch eher zum DSP greife). Xilinx hat ja das angekündigt, was wir schon alle immer haben wollten (wieviel es kostet, ist dann die andere Frage): einen(zwei) ARM-Kern(e) mit frei konfigurierbarer Peripherie. Irgendwann wird es diese (so genannten) Zynqs auch hoffentlich so stromsparend geben, dass sie den üblichen LP-DSPs auch ernsthaft Konkurrenz machen (was die Virtexe nicht wirklich konnten). Ist halt immer eine Frage, an welchem Ende der Rechenspeed-Skala man arbeitet.. Bei einigen BildV.-Anwendungen bzw. Video-Encoding ist mit den üblichen DSPs einfach nicht mehr viel zu reissen. Da kann man dann den Kompromiss eingehen, die "stupide" Vektorenrechnung (parallelisiert) ins FPGA auszulagern, um die Daten vorzuverarbeiten, sobald aber eine Echtzeit-Interaktion zwischen FPGA und uC-Core gefragt ist, wird das Interfacing u.U. aufwendig. Dann kann man versuchen, den Algorithmus auf eine State-Machine/Sequencer herunterzubrechen bzw. einen kleinen dummen Softcore mit DSP-Operationen aufzubohren, aber dann stellt sich natürlich die Frage des Aufwands oder der Kosten, teure Tools für C -> HDL einzusetzen. Ersteres hat bisher recht gut funktioniert, aber ist vom Aufwand her nicht ohne, da man den Chip und den Assembler/die Opcodes selbermachen muss. Insofern würde mich mal interessieren, ob jemand schon z.B. die ZPU mit eigenen Opcodes erweitert hat und wie gut sich die Architektur (vom Pipelining her) dazu eignet. Fazit ist (für mich zumindest), dass die Zukunft in auf einem Chip kombinierten Hard und Softcores steckt. Wenn die Technologie dann auch noch bezahlbar wird, ist es zumindest für den Custom-Markt (kleine Stückzahlen...) eine immer heisser werdende Geschichte... Grüsse, - Strubi
Thomas Reinemann schrieb: > Du hast den Sinn eines FPGAs nicht verstanden. Och, ich denke eigentlich, das habe ich schon :-) > Einen Prozessor Softcore verwendet man in einem FPGA > nur für Funktionen die keine Rechenleistung erfordern naja, dann wären DPS-softcores aber nicht sonderlich sinnig, oder? Martin S. schrieb: >eine immer heisser werdende Geschichte So dachte ich das auch, aber meine eigenen Recherchen ergeben zumindest für den Jetztzeitpunkt, ich mit einer handvoll DSPs für die Mehrheit der Anwendungen besser fähre. >einen kleinen dummen Softcore mit DSP-Operationen aufzubohren Hättest Du ein Beispiel dafür, bzw hast Du das schon gemacht, einen DSP aufzurüsten? Juergen Schuhmacher schrieb: > leistungsschwachen DSPs kurzerhand in FPGAs gestopft werden und > der DSP unter Beibehalt des Codes absobiert wird. Interessant, allerdings stellt sich dann noch die Frage nach der Software. Wenn der DSP abgekündigt wird, ist mitunter auch die Designsoftware obsolet. Wie will man das dann pflegen?
>Was kann denn da der NIOS? Ich habe mir die Doku angesehen und finde >z.B. keine Float-Unterstützung, mathematische Funktionen (TriGo) etc. >Gibt es da so etwas wie einen CoPro den man instanziieren könnte, oder >alternativ: Was ich nicht verstehe: hier wird wild drauflos "diskutiert", anstatt mal zu fragen was denn konkret gerechnet werden soll: MP3 , Video, matrizen, fft etc pp
Martin schrieb: > Was ich nicht verstehe: hier wird wild drauflos "diskutiert", anstatt > mal zu fragen was denn konkret gerechnet werden soll: MP3 , Video, > matrizen, fft etc pp Weil das alles Aufgaben sind, die man einem NIOS oder Microblaze nicht antut. Die einzig sinnvolle Aufgabe eines NIOS oder Microblaze sind komplexe aber nicht rechenintensive Probleme. Deine oben genannten Probleme sind typische Aufgaben für die direkte Abbildung auf einen FPGA. Tom
Gerald Hellinghaus schrieb: >> Einen Prozessor Softcore verwendet man in einem FPGA >> nur für Funktionen die keine Rechenleistung erfordern > naja, dann wären DPS-softcores aber nicht sonderlich sinnig, oder? Wer stellt so was her? Moderne FPGAs haben DSP-Hardcores (bei Xilinx DSP-Slice), da braucht man keinen DSP-Softcore mehr. Tom
Also konkret handelt es sich um Statistik auf eingehende Daten. Mittelwerte, Standardabweichung, Kontingenz, sowie verschiedene Filterungen. Die Mathematik ist nicht so trivial, dass man es einfach in FPGA-statemachines abbilden könnte, gleichzeitig aber nicht so kritisch, dass alles im Gigaherztempo erledigt werden müsste. Einfache Stabw, Mittel und Exponentialfilter kann man im FPGA natürlich hinschreiben, braucht aber für jeden Kanal einen eigenen Speicher für die Werte. Deshalb soll das Rechenwerk nur einmal rein und die Kanäle (256+) "multitaskten". Die mir bekannten Softcores haben aber, wie das FPGA in dem sie sitzen, meist kein floating point Format, was aber nötig wäre.
Gerald Hellinghaus schrieb: > Also konkret handelt es sich um Statistik auf eingehende Daten. > Mittelwerte, Standardabweichung, Kontingenz, sowie verschiedene > Filterungen. Die Mathematik ist nicht so trivial, dass man es einfach in > FPGA-statemachines abbilden könnte, gleichzeitig aber nicht so kritisch, > dass alles im Gigaherztempo erledigt werden müsste. > > Einfache Stabw, Mittel und Exponentialfilter kann man im FPGA natürlich > hinschreiben, braucht aber für jeden Kanal einen eigenen Speicher für > die Werte. Deshalb soll das Rechenwerk nur einmal rein und die Kanäle > (256+) "multitaskten". > > Die mir bekannten Softcores haben aber, wie das FPGA in dem sie sitzen, > meist kein floating point Format, was aber nötig wäre. Also dafür würde ich nun auch nicht zum FPGA greifen, das klingt nicht so, als ob massive Parallelisierung nötig wäre (aber ich weiss ja nicht, welce 'fps' du brauchst). Was ist mit einem OMAP L1? Der hat eine FPU. Allerdings würde ich eher versuchen, das ganze in einer vernünftigen Fixkomma-Breite zu rechnen, und zu konvertieren. Wenns aber unbedingt im FPGA sein soll: Was ist mit Simulink, oder Celoxica? Letzere tools kosten allerdings so viel wie'n Auto, soweit ich mich erinnere. Wäre ev. "mit Kanone auf Spatz", wenn's nur Filter und Statistik ist. Zur CPU: Gerald Hellinghaus schrieb: > Hättest Du ein Beispiel dafür, bzw hast Du das schon gemacht, einen DSP > aufzurüsten? Also, ich meinte, einen simplen Core (nicht DSP) mit DSP-Vektoroperationen zu 'enhancen' (Fixkomma). Ich hab verschiedene Ansätze probiert: - 8051 core aufbohren (weitere SFR-Register zu 'Coprozessor', hat aber zuviel Zeit für die Synthese gebraucht und das FPGA fast zum Platzen gebracht) - Einige Funktionen eines etablierten DSPs zu klonen (Übung abgebrochen, wurde zu komplex) - Simplen Sequencer 'from scratch', also eigene Opcodes und zwei Hardware-Loop-Units. Hat schlussendlich am wenigsten Resourcen gekostet, aber die Tools (faktisch den GPU-Assembler) musste ich selber hacken. Hält sich aber dank Parser-Generator in Grenzen. Was die Sache immer langsam macht, ist irgend eine if/else-Bedingung, weil man da im allgemeinen die Pipeline flushen muss, um die Resultate vorliegen zu haben. Deswegen muss man sich gut überlegen, was man in Hardware giesst, oder wie man den Code so programmiert, dass die Pipeline möglichst immer voll bleibt. Läuft also auf Assembler raus, also, dass man einzelne Rechen-Funktionen, die vorher C waren, als Aufrufe der GPU mit entsprechendem Microcode umsetzt. Eigentlich genau das, was nvidia mit seinen Grafikkarten-Shader-Units (in CUDA) macht. Mein Tip sonst: Einfach mal die Kern-GPU prototypen/simulieren, auf coregen-IP-Basis kriegt man schon einige Arithmetik in 1-2 Tagen hin, ohne dass man sich gigantisch mit float-Arithmetik beschäftigen muss. Wenn Du dann weisst, wie dein "Coprozessor" prinzipiell aussehen muss, kannst du ihn z.B. per Register-Interface an einen uC (oder off the shelf softcore) ranbacken, und dann in einem späteren Schritt anfangen, Opcodes zu definieren. Sonst bin ich auch der Meinung einiger Diskussionsteilnehmer, dass es schwer ist, eine vernünftige Aussage zu machen, ohne das eigentliche Programm (die Berechnungen) zu kennen.
Thomas Reinemann schrieb: > Moderne FPGAs haben DSP-Hardcores (bei Xilinx DSP-Slice), > da braucht man keinen DSP-Softcore mehr Was die Firma Xilinx hochtrabend als "DSP-slices" anpreist, sind kleine, mickrige Ecken auf dem Silizium, auf denen ein bischen multipliziert und aufaddiert werden kann. Bei Altera heissen die etwas realistischer "embedded multiplier" (auch wenn das nicht ganz vergleichbar ist). Unter einem DSP-SoftCore verstehe (ich zumindest) eine komplette ALU, die Abläufe verarbeiten kann, Register beinhaltet, Grundrechenarten beherrscht und möglichst noch skalierbar und konfigurierbar ist, also eher sowas, wie TheMason mit seinem AudioCore macht. Den DSP-Softcore sehe ich auf einer anderen Abstraktionsebene, als grundlegende FPGA-Funktionen - im übrigen auch gegenüber MCU-SoftCores! Ein solcher Core muss Vorteile gegenüber der FPGA-Lösung haben und die sehe ich aus technischer Sicht in genau solchen Punkten wie Skalierbarkeit, wenn man z.B. die gegebene Genauigkeitsgrenze an Bit in einem realen DSP überwinden möchte oder im Fall einer speziellen Adaption auf einen Anwendungsfall. Wenn man weitere Vorteile gegenüber einer direkten FPGA-Implementierung herausstellen will, dann kann (muss) das über die Argumentation der Entwicklungszeiten laufen (siehe meinen ersten Beitrag) oder gfs. auch über das Thema "Test": Ein homogenes System, dass nur aus VHDL besteht, kann ich gfs. leichter verifizieren und validieren, als eine heterogene Struktur, die aus einem SoftCore und VHDL-Logik besteht. Es kann allerdings auch genau umgekehrt sein, da muss man den Einzelfall sehen. Das gilt dann auch für die Betrachtung "externer DSP" <-> DSP-Core. Eine Lösung, die komplett im FPGA sitzt, lässt sich z.B. besser gegen Kopieren schützen, weil man die Abläufe und Strukturen um den SoftCore herum samt dessen SW manipulieren und individualieren kann, während ein C-Programm für einen käuflichen DSP mit bekannten Strukturen leicht ausspähbar ist. Eine reine VHDL-Lösung ohne Softcore wiederum kriegt man leichter in einem ASIC hinein, wenn es das mal braucht. > Xilinx hat ja das angekündigt, was wir schon alle immer haben wollten > ARM-Kern(e) mit frei konfigurierbarer Peripherie. Ich wusste gar nicht, dass ich sowas schon immer haben wollte :-) Konkret den ARM sehe ich nicht unbedingt als DSP-Ersatz, siehe meine Überlegung oben zum Thema Genauigkeit. Aber Du hast schon Recht: Mit einem solchen System wird wieder eine Lücke geschlossen und Anwendungen gibt es dafür in Hülle und Fülle. Ich denke aber, dass bei dieser ARM-Lösung mein Argument von oben (Codewiederverwertung) noch mehr wirkt, als beim Thema Power-PC in den Virtexen: Ein ganz entscheidender Punkt bei der Entscheidung fuer einen Prozessor bei bestimmten Teilfunktionen ist nach meiner Beobachtung der, dass es massenweise Programmierer gibt. Das wird nicht immer objektiv technisch entschieden. So sieht das sicher auch Xilinx. Es gibt viele ARM-Applikationen, die mit einem FPGA zusammenspielen - ich habe selber schon einige realisiert und nicht wenige davon eignen sich aus verschiedenen Gründen gut zur Integration in einem FPGA. > dass die Zukunft in auf einem Chip kombinierten Hard und Softcores steckt Grundsätzlich d'accord, aber bei rechenintensiver DSP-Funktionalität sehe ich die SoftCore-Lösung auf sehr enge Gebiete begrenzt, denke ich. Ich glaube, dass der finale Schritt hin zur Voll-FPGA-Lösung sogar immer kleiner werden wird, da es ja heute oft schon effektiver ist, die C-DSP-Software schon zur Compilezeit in VHDL zu übersetzen, zumal die aufwändigen Anwendungen immer mehr mit Tools wie MATLAB gemacht werden und man daraus jederzeit einen VHDL-Ablauf bekommt, der ähnlich effektiv ist, wie ein C-Ablauf, für den man später im FPGA wieder einen Interpreter bräuchte. Markttechnisch gesprochen, wird der DSP-SoftCore von den immer besser werdenden VHDL-Softcores mitsamt den DSP-Entwurfswerkzeugen einerseits- und den komplexer werdenden MCU-Softcores in die Zange genommen.
Juergen Schuhmacher schrieb: > Was die Firma Xilinx hochtrabend als "DSP-slices" anpreist, sind kleine, > mickrige Ecken auf dem Silizium, auf denen ein bischen multipliziert und > aufaddiert werden kann. Bei Altera heissen die etwas realistischer > "embedded multiplier" (auch wenn das nicht ganz vergleichbar ist). Unter > einem DSP-SoftCore verstehe (ich zumindest) eine komplette ALU, die > Abläufe verarbeiten kann, Register beinhaltet, Grundrechenarten > beherrscht und möglichst noch skalierbar und konfigurierbar ist, also > eher sowas, wie TheMason mit seinem AudioCore macht. > Moment, ich bin mir nicht sicher, ob wir genau das gleiche meinen. Bei mir ist: - Softcore: Ein in Logik-Elementen synthetisierter Core (mit Constraints, Wegstrecke, usw.) - Hardcore: Ein fest in Silizium 'gegossener', platzoptimierter Core. Die DSP-Slices sind IMHO schon etwas mehr als nur Multiplikatoren, sie sind immerhin so clever designt, dass man sie leicht zu n-bit/float/double DSP units kaskadieren kann. Ergo, als DSP-Atome zu betrachten, aus dem man sich sein gewünschtes ALU-Molekül selberbaut. Soll ja primär flexibel sein. Und bei den neueren FPGAs sind's keine mickrigen Ecken mehr, die sind gehörig übers Silicon verteilt :-) > > Wenn man weitere Vorteile gegenüber einer direkten FPGA-Implementierung > herausstellen will, dann kann (muss) das über die Argumentation der > Entwicklungszeiten laufen (siehe meinen ersten Beitrag) oder gfs. auch > über das Thema "Test": Ein homogenes System, dass nur aus VHDL besteht, > kann ich gfs. leichter verifizieren und validieren, als eine heterogene > Struktur, die aus einem SoftCore und VHDL-Logik besteht. Es kann > allerdings auch genau umgekehrt sein, da muss man den Einzelfall sehen. > Das gilt dann auch für die Betrachtung "externer DSP" <-> DSP-Core. Eine > Lösung, die komplett im FPGA sitzt, lässt sich z.B. besser gegen > Kopieren schützen, weil man die Abläufe und Strukturen um den SoftCore > herum samt dessen SW manipulieren und individualieren kann, während ein > C-Programm für einen käuflichen DSP mit bekannten Strukturen leicht > ausspähbar ist. Eine reine VHDL-Lösung ohne Softcore wiederum kriegt man > leichter in einem ASIC hinein, wenn es das mal braucht. Tja, eine Frage der Entwicklungs-Strategie und der in-house-tools. Für mich ist ein CPU-Softcore kein riesiger Stress, da ich auf eine gute JTAG-Debugging-Library aufbauen kann. Der CPU-Softcore (sagen wir mal Sequencer) hilft mir auch, die HW durchzuverifizieren, on-chip Testvektoren durchzunudeln, etc. Aber dazu musste ich schon mal in den Dreck packen und mir meine Debug-Schnittstelle selber implementieren. Hat sich aber schnell amortisiert :-) > >> Xilinx hat ja das angekündigt, was wir schon alle immer haben wollten >> ARM-Kern(e) mit frei konfigurierbarer Peripherie. > Ich wusste gar nicht, dass ich sowas schon immer haben wollte :-) > > Konkret den ARM sehe ich nicht unbedingt als DSP-Ersatz, siehe meine > Überlegung oben zum Thema Genauigkeit. Aber Du hast schon Recht: Mit > einem solchen System wird wieder eine Lücke geschlossen und Anwendungen > gibt es dafür in Hülle und Fülle. Ich denke aber, dass bei dieser > ARM-Lösung mein Argument von oben (Codewiederverwertung) noch mehr > wirkt, als beim Thema Power-PC in den Virtexen: Ein ganz entscheidender > Punkt bei der Entscheidung fuer einen Prozessor bei bestimmten > Teilfunktionen ist nach meiner Beobachtung der, dass es massenweise > Programmierer gibt. Das wird nicht immer objektiv technisch > entschieden. So sieht das sicher auch Xilinx. Es gibt viele > ARM-Applikationen, die mit einem FPGA zusammenspielen - ich habe selber > schon einige realisiert und nicht wenige davon eignen sich aus > verschiedenen Gründen gut zur Integration in einem FPGA. > Naja, also mit den NEON-Extensions rücken die Cortexe gefährlich nahe an manche DSPs ran. Weiss nicht, ob Du Hybriden wie den Blackfin kennst - aber an ihm kann man sehen, wohin der Trend geht: der Unterschied zwischen MCU und DSP verwässert stetig. In einem Zynq könntest Du dann - in den bisher noch feuchten Träumen eines embedded developers - einen Core als DSP und den andern als Linux-Frontend nutzen. Plus noch mal eben den Video-Codec in HW realisieren. TI macht das in seinen Davinci-Chips ja mit Erfolg, ADI mit dem etwas homogeneren BF561. Thema Code-Wiederverwertung ist ein Knackpunkt, aber bei vielen kein Thema mehr, die mit GCC entwickeln und ihren Code von vornherein cross-platform designen. Insofern ist die Wahl des Prozessors und der Toolchain kein grosses Thema mehr bei mir. Die Frage ist nur, ob man auch den kompletten DSP-Code in C entwickeln will. Wenn man Speed braucht, kommt man leider an Assembler-Optimierung nie vorbei, und dann muss man sich den Chip natürlich genau aussuchen. >> dass die Zukunft in auf einem Chip kombinierten Hard und Softcores steckt > Grundsätzlich d'accord, aber bei rechenintensiver DSP-Funktionalität > sehe ich die SoftCore-Lösung auf sehr enge Gebiete begrenzt, denke ich. > Ich glaube, dass der finale Schritt hin zur Voll-FPGA-Lösung sogar immer > kleiner werden wird, da es ja heute oft schon effektiver ist, die > C-DSP-Software schon zur Compilezeit in VHDL zu übersetzen, zumal die > aufwändigen Anwendungen immer mehr mit Tools wie MATLAB gemacht werden > und man daraus jederzeit einen VHDL-Ablauf bekommt, der ähnlich effektiv > ist, wie ein C-Ablauf, für den man später im FPGA wieder einen > Interpreter bräuchte. > Also, bisher konnte mich keines dieser (zumindest < 10000 € kostenden) Tools so recht überzeugen. Modellieren, ja, implementieren: nein. Der Teufel liegt immer wieder im Detail, so dass ich im Endeffekt doch wieder im VHDL-Code das Gesamtsystem feintunen muss. Da kann man sich manche Elemente auch gleich selber schreiben. Eher wünsche ich mir eine gut verbreitete Meta-Sprache (Python?), um VHDL-Elemente leichter verbinden und komplexe Systeme gut debuggen zu können. Grüsse, - Strubi
soll Dein System echtzeitfähig sein oder was motiviert Dich überhaupt ein FPGA in Betracht zu ziehen? Mittelwert, Standardabweichung, das klingt ja alles etwas nach "high speed trading" . Du bisst aber kein Scheiss Broker, oder arbeitest für einen? Habe mal auf Linkedin eine Stellenanzeige gesehen da suchten sie FPGA Designer für high speed trading .
Danke für all eure Einschätzungen. Martin schrieb: > soll Dein System echtzeitfähig sein alle Systeme müssen doch echtzeitfähig sein :-) > ein FPGA in Betracht zu ziehen? Er ist da und wird benutzt. Die Frage ist, ob man Funktionalität, die auf DSPs sitzt, auch ins FPGA reinbringen soll oder nicht und wenn ja, wie. Und es geht darum, ob man bei C bleibt / bleiben kann. > Mittelwert, Standardabweichung, das klingt ja alles etwas nach > "high speed trading" > FPGA Designer für high speed trading Nein ich bin kein Broker:-) Es geht um Signalqualität. Juergen Schuhmacher schrieb: > Markttechnisch gesprochen, wird der DSP-SoftCore von den immer > besser werdenden VHDL-Softcores mitsamt den DSP-Entwurfswerkzeugen > einerseits- und den komplexer werdenden MCU-Softcores in die > Zange genommen. Also ich lese daraus, dass es durchaus sinnvoll ist, für komplexe Rechnungen bei C zu bleiben, auch wenn se künftige keine Soft-DSPs geben wird(, weil sie in FPGAs als HW existieren werden (?)
Martin S. schrieb: Hardcore: Ein fest in Silizium 'gegossener', platzoptimierter Core. > > Die DSP-Slices sind IMHO schon etwas mehr als nur Multiplikatoren, sie > sind immerhin so clever designt, dass man sie leicht zu > n-bit/float/double DSP units kaskadieren kann. Ergo, als DSP-Atome zu > betrachten, aus dem man sich sein gewünschtes ALU-Molekül selberbaut. > Soll ja primär flexibel sein. Hast du da einen guten Einstiegspunkt? Ich überlege einen Coprocessor mit Floating Point an meinen Softcore zu hängen. Vorher sind noch ein paar andere Dinge zu lösen. Doch ich brauche etwas Vorlauf. > > Tja, eine Frage der Entwicklungs-Strategie und der in-house-tools. Für > mich ist ein CPU-Softcore kein riesiger Stress, da ich auf eine gute > JTAG-Debugging-Library aufbauen kann. > Der CPU-Softcore (sagen wir mal Sequencer) hilft mir auch, die HW > durchzuverifizieren, on-chip Testvektoren durchzunudeln, etc. > Aber dazu musste ich schon mal in den Dreck packen und mir meine > Debug-Schnittstelle selber implementieren. Hat sich aber schnell > amortisiert :-) Das ist der nächste Punkt. Wie hast du das gelöst oder nutzt du fertige Tools? Ich habe eine Softcore im Simulator und weiss noch nicht wie ich ideal im FPGA handhabe. An einen JTAG habe ich ich auch gedacht. > Thema Code-Wiederverwertung ist ein Knackpunkt, aber bei vielen kein > Thema mehr, die mit GCC entwickeln und ihren Code von vornherein > cross-platform designen. Insofern ist die Wahl des Prozessors und der > Toolchain kein grosses Thema mehr bei mir. Die Frage ist nur, ob man > auch den kompletten DSP-Code in C entwickeln will. Wenn man Speed > braucht, kommt man leider an Assembler-Optimierung nie vorbei, und > dann muss man sich den Chip natürlich genau aussuchen. Wenn es ein Mikrocontroller schafft, wird es aus wirtschaftlichen Gründen ein Mikrocontroller werden. Die FPGA Lösung ist immer teurer. > Eher wünsche ich mir eine gut verbreitete Meta-Sprache (Python?), um > VHDL-Elemente leichter verbinden und komplexe Systeme gut debuggen zu > können. An so etwas habe ich auch gedacht an Precompiler, der einen Bus durch alle Module legt und alles verbindet und gleichzeitig das korrekte Linkerscript für den C-Compiler erzeugt.
Moin, > > Hast du da einen guten Einstiegspunkt? > > Ich überlege einen Coprocessor mit Floating Point an meinen Softcore zu > hängen. Vorher sind noch ein paar andere Dinge zu lösen. Doch ich > brauche etwas Vorlauf. > Ich habe gerade mich gerade mal letztens getraut, Xilinx LogiCore anzuschmeissen (nicht mehr benutzt seit ISE 9.x) und ne parallel-FPU durchzusimulieren. Klappt erstaunlich gut. Ist halt Blackbox, aber man kann der Simulation wohl trauen. Bisher hab' ich aber float immer vermieden und die Slices von Hand vernetzt. So nen richtigen Einstiegspunkt hat's da nicht gebraucht, die Logicore-Datasheets fand ich eigentlich ausreichend. > > Das ist der nächste Punkt. Wie hast du das gelöst oder nutzt du fertige > Tools? > Ich habe eine Softcore im Simulator und weiss noch nicht wie ich ideal > im FPGA handhabe. An einen JTAG habe ich ich auch gedacht. > Gab damals nix fertiges was zu brauchen war. Ansich hatte ich die JTAG-Debugger-Toolchain für den Blackfin geschrieben und hatte zum Reverse-Engineering den JTAG-TAP-Controller auf dem FPGA nachgebaut. Den TAP kann man aber ohne grossen Aufwand an beliebige Register-Logik anbacken. Auf PC-Seite wird das dann per Python via einen FT2232 angesteuert. Wenn man allerdings richtig C-Code debuggen will, muss man sich mit dem DWARF-Format rumschlagen, das hab ich nicht mehr gemacht, dazu nutzt man dann besser den gdb und einen JTAG-Proxy-Server (gdbproxy) auf den man sich per remote-debugging-Protokoll verbindet. Da findet man einiges an offenem Source zu. > > Wenn es ein Mikrocontroller schafft, wird es aus wirtschaftlichen > Gründen ein Mikrocontroller werden. Die FPGA Lösung ist immer teurer. > Sehe ich im allg. auch so. Aber wenn mit der Zeit eine brauchbare VHDL-Lib anwächst und man seine Toolbox so im Griff hat, dass man "mal eben" eine neue Implementation aus dem Ärmel schüttelt, amortisiert sich der Totalaufwand u.U., da man kein (PCB-)Neudesign mehr mit dem passenden Controller anschmeissen muss. Das aber nur, solange man keine komplexen OS (Linux, ...) laufen lassen will/muss. Bisher würde ich für die diversen Softcores unter uClinux noch keine Hand ins Feuer legen (der Teufel steckt zu sehr im Detail). Wenn ich mir überlege, wieviel Ärger ich schon mit buggy CPUs hatte, wo der Hersteller erst nach einem halben Jahr wirklich zugibt, dass es der Chip und nicht die Software war... > > An so etwas habe ich auch gedacht an Precompiler, der einen Bus durch > alle Module legt und alles verbindet und gleichzeitig das korrekte > Linkerscript für den C-Compiler erzeugt. Also, da gibt es ja zig Ansätze (handel-C, System C, und wie sie alle heissen), aber irgendwie ist das alles nur derselbe Schlonz mit anderem Geschmack, und leider oft sehr akademisch, am Schluss ist das Debuggen eben doch wieder eine Tortur, wenns nich klappen will. Bin aber forschungs-technisch nicht so ganz up to date... Grüsse, - Strubi
Für NIOS gibt z:b einen "C To Hardware Converter"; einfach gesagt kovertiert dieser C Code in VHDL oder verilog. Weiterhin gibt es für MATLAB Tools die das design vhdl oder verilog konvertier. Im Allgemeinen hatte ich NIOS immer als Management CPU (mit oder ohne uClinux) genutzt,
> Für NIOS gibt z:b einen "C To Hardware Converter"; einfach gesagt > kovertiert dieser C Code in VHDL oder verilog. Wie effektiv ist das?
@Marian Was verstehst Du unter effektiv?. Man darf keine Wunder erwarten. Man muss seinen code so schreiben dass der c2h kompiler diesen gut umsetzen kann (loop unrolling, arbeitsschritte parallelisieren usw.). Irgendwas zwischen Faktor 1 und 10.
Marian Kopecky schrieb: > Faktor 1 und 10 bezogen worauf, bitte? Im Schnitt wird der Algorithmus 3,7327463027490230 schneller. Bezogen auf deine pauschale Frage bekommst du eine pauschale Antwort :-). Ich kann dir nicht sagen, wie viel schneller ein bestimmter Algorithmus durch den C2H Compiler. Wie denn auch?
Im Allgemeinen gilt; je parallelisierbarer dein Algorithmus ist,desto bester. Schau einfach mal auf der Altera Webseite. Dort gibt es Beispiele, in denen der Algorithmus von 40x bis 100x beschleunigt wird. Man hat sich natürlich die besten Beispiele herausgesucht.
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.