Liebes Forum,
ich möchte gerne ein dsp Projekt, das bisher mit einem Microcontroller
realisiert wurde auf FPGA umstellen um eine höhere Geschwindigkeit zu
erreichen. Bei der Auswahl des FPGAs tue ich mir schwer, weil es ja
keine fixe Clock-Rate wie bei Microcontrolern gibt und ich noch nicht
viel FPGA Erfahrung habe.
Die Ansprüche an den FPGA sind bescheiden: schneller (mit geringer
Latenz) Zugriff auf ca 24gpio lines, Verwertung durch simplen
algorithmus, schnelle Ausgabe auf ca 32gpio lines.
Daher meine Frage: was sind die Kenngrößen die mir zeigen wie schnell
der gpio Zugriff vonstatten geht und mit welcher clock(relativ) ich
einen simplen arithmetischen algorithmus ausführen kann? Mit relativ
meine ich, dass die clock natürlich vom Algorithmus abhängt, aber es
vielleicht eine Kenngröße gibt die mir zeigt wie schnell der selbe
algorithmus auf unterschiedlichen FGPAs laufen kann.
Hättet ihr einen Vorschlag für einen konkreten FPGA/Devboard?
viele Grüße,
Manuel
Hallo, das geht leider nicht so pauschal. Es gibt aber mehrere
Herangehensweisen:
1. Du beschreibst die Schaltung und lässt die Werkzeuge der FPGA
Hersteller den maximalen Takt berechnen.
2. Du beschreibst die Schaltung und guckst was maximal zwischen zwei
aufeinanderfolgenden Taktflanken getan werden muss. Das kannst Du uns
dann mitteilen oder den Herstellerwerkzeugen und die spucken dann den
maximalen Takt aus.
>ich möchte gerne ein dsp Projekt, das bisher mit einem Microcontroller>realisiert wurde auf FPGA umstellen um eine höhere Geschwindigkeit zu>erreichen.
Das könnte man vermutlich auch mit einem schelleren fertigen uC oder DSP
-Chip erreichen, wäre viel günstiger.
Manuel schrieb:> wie schnell der selbe algorithmus auf unterschiedlichen FGPAs laufen> kann.
Man muss den Algorithmus erst mal auf 1 FPGA bringen. Und wenn er dann
mal läuft lässt sich leicht abschätzen, was mit anderen FPGA
herauskommen wird...
Es gibt aber meist mehrere Möglichkeiten einen Algo ins FPGA zu setzen.
Und daran bemisst sich das clock rate und die Latenz.
Schlauer wäre es, der TE würde beschreiben, was er braucht und wie
"schnell" er arbeiten möchte, bzw was er unter Schnell versteht.
Softwarewerker haben das vereinzelt etwas schräge Vorstellungen.
Eine dieser Vorstellungen ist, man nimmt einen FPGA mit hardcore,
portiert das Ganze als C in den Core und ist fertig und schneller.
Eine weitere ist, dass das mit Softcores geht.
Wieder eine solche (und die wohl abenteurlichste) ist, dass man das C in
Catapult oder andere C2VHDL-Parser reinwirft und dann einen FPGA
bekommt, der schnell rechnet.
Das Beste, was es gibt, um DSPs schnell zu machen, ist, einen
schnelleren DSP zu nehmen. Dann entfällt die umständliche Planung,
Portierung, Verfikation und Softwarezulassung, die im Umfeld des FPGAs
nicht nur aufwändiger, sondern auch umfangreicher und schwieriger ist.
Ich könnte einen Kunden benennen, der mit allem drum und dran 15MM
investiert hat, um einen FPGA ins Spiel zu bekommen und übersehen hat,
dass von der Baugruppe nur 2000 p.a. laufen. 3 statt einem DSP hätten
die Arbeit gemacht, ins Geräte gepasst und weniger Strom gebraucht, als
das fette FPGA, das jetzt drauf sitzt und gerade 40 Euro pro Einheit
spart.
Demnächst werden die FPGAs zwar nochmal 15% billiger, aber der
Spareffekt wird noch kleiner sein, weil der DPS-Hersteller einen Chip
angekündigt hat, von denen 2 ausreichen würden und man hätte einen bei
der Bestückung weglassen können.
FPGA bitte nur, wenn man ein dafür nötiges Design hat.
Und jemanden, der es effektiv bauen kann, also nicht aus der SW-Ecke
kommt.
Manuel schrieb:> schneller (mit geringer Latenz) Zugriff auf ca 24gpio lines, Verwertung> durch simplen algorithmus, schnelle Ausgabe auf ca 32gpio lines.
Ich wrde vorschlagen, du sagst einfach mal, was da "schnell" in Zahlen
bedeutet (Bytes/Worte pro Sekunde). Und du sagst, woher die Daten kommen
und wohin sie gehen. Interessant ist hier auch, ob die Daten
taktsynchron und stetig kommen, oder ob es da Bursts gibt. Weiter
interessant ist die maximale Latency für den "Durchlauf" eines Wertes
und ob man den Ablauf/Algorithmus pipelinen kann/darf. Dann kann dir
vermutlich recht schnell jemand sagen, ob der Ansatz so für ein FPGA
geeignet ist.
Es ist übrigens durchaus auch so, dass man auch auf einem DSP einen
Algorithmus umständlich und langsam umsetzen kann. Aber ich hoffe und
denke, die Effizienz dieser Umsetzung wurde schon hinterfragt. Und es
gibt zudem keinen schnelleren DSP, der die Arbeit noch packen würde...
Manuel schrieb:> Liebes Forum,>> ich möchte gerne ein dsp Projekt, das bisher mit einem Microcontroller> realisiert wurde auf FPGA umstellen um eine höhere Geschwindigkeit zu> erreichen. Bei der Auswahl des FPGAs tue ich mir schwer, weil es ja> keine fixe Clock-Rate wie bei Microcontrolern gibt und ich noch nicht> viel FPGA Erfahrung habe.> Die Ansprüche an den FPGA sind bescheiden: schneller (mit geringer> Latenz) Zugriff auf ca 24gpio lines, Verwertung durch simplen> algorithmus, schnelle Ausgabe auf ca 32gpio lines.> Daher meine Frage: was sind die Kenngrößen die mir zeigen wie schnell> der gpio Zugriff vonstatten geht und mit welcher clock(relativ) ich> einen simplen arithmetischen algorithmus ausführen kann?
welcher Mikrocontroller soll ersetzt werden?
mit welchen Takt läuft dieser?
Welcher Signalstandard an den GPIO: 3V3 5V LVDS TTL CMOS ?
Zum Vergleich könnte man einen VGA-controller heranziehen, sowas gibt es
zuhauf, da schafft ein FPGA locker 100 MHz. auch die kleinen. die
gefragten Kennwerte finden sich im Datenblatt unter IO characteristics
o.ä.. Schau mal nach max frequency, toggle rate, propagation delay oder
rechne es dir anhand setup und hold aus. Vorsichtshalber sollte man 100%
reserve einrechnen.
Beispiel dort:
http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf
ab seite 6 - Ja das ist eine Monster tabelle da man die IO's auf x^y
Parameter konfigurieren kann.
IMHO macht man sich die Konvertierung eines uc-designs leichter wenn man
einen FPGA mit gut unterstützer Soft-CPU fehlt. Da spricht leider gegen
Xilinx spartan6, ausser dir reicht der microblace MCS. Deshalb könnte
man hier eher nach altera mit deren NIOS-Softcore schielen.
https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDLhttps://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGAhttps://www.mikrocontroller.net/articles/Xilinx_Microblaze_MCS_Workflow
MfG,
