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...
:
Bearbeitet durch Moderator
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_VHDL https://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA https://www.mikrocontroller.net/articles/Xilinx_Microblaze_MCS_Workflow MfG,
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.