Forum: FPGA, VHDL & Co. vergleich verschiedener fpga chips: mögliche clock rates


von Manuel (Gast)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Weltbester FPGA Pongo (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von Fpgakuechle K. (Gast)


Lesenswert?

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,

Bitte 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
Noch kein Account? Hier anmelden.