NIOS und SoftCores allgemein als DSP-Ersatz

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

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

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

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