www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Verbindung Virtex5 <-> PC, PCIe oder S-ATA


Autor: Valko Zapalko (hydravliska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

Ich muss bald mit meinem Masterarbeit anfangen und zurzeit bin ich im 
Gedanken wie das ganze überhaupt aussehen soll.

Also die Aufgabe ist ein "schneller" AD Umsetzer (~80 MHz) anzusprechen, 
Daten im FPGA zu verarbeiten und dann die in Richtung PC zu schicken. Am 
PC sollten die Daten anhand andere Software, z.B. Matlab oder ähnliches, 
weiterverarbeitet werden.

Zurzeit bin ich am überlegen wie soll die Verbindung zum PC aufgebauut 
werden. Zu Verfügung wären USB 2.0, PCIe und S-ATA.

USB 2.0 wurde schon ausgeschlossen da man auf die Datenraten gar nicht 
kommt,

40 MHz * 16 Bit = 640 Mbit/s

Also bleiben PCIe und S-ATA.

Ich habe mich an der Suche nach Info gemacht und irgendwie scheint es 
mir, dass es deutlich mehr Information und Beispiele über PCIe gibt in 
Vergleich zu S-ATA.

Über S-ATA habe ich leider nur ein Application Note von Xilinx gefunden 
und da ich nicht der Experte bin würde ich mich schon freuen wenn ich 
irgendwo einiges nachlesen könnte.

Da meine grösste Sorgen genau mit dieser Schnittstelle sind (die HW soll 
implementiert werden, es muss ein Windows Treiber entwickeln werden und 
und und...), würde ich euch gern die Fragen stellen welche Interface 
würden Sie auswählen. Ich habe schon bemerkt dass hier sich einige Leute 
gut mit PCIe auskennen und würde um ein Einstiegsratschlag bitten.

Vielen Dank im voraus und ein schönen Abend wünsch ich euch.


MfG
Valentin

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm,
vielleicht auch eine Alternative: Das ganze als 'IDE Festplatte' tarnen. 
Ist weniger Logik als SATA und geht ja auch bis UDMA133 oder sogar 
UDMA150 (MB/sec). Die Daten koennten dann ja auf 512Byte Sektoren mit 
wrap-around gemappt werden. Und als Treiber koennte man sich ja mal den 
Linux IDE-Treiber ansehen als Referenz. Das sind auch nur 16Bit 
parallel, sollte mit einem Virtex kein Problem sein. Und die 
Taktfrequenzen sind Peanuts.

Wenns dann unbedingt SATA sein muss, koennte man an den FPGA ja einen 
IDE-SATA Wandler anschliessen. Das wuerde aber an der prinzipiellen 
Funktion nichts aendern.

Frueher gab's zu ATA/SATA alles wissenswerte bei www.t13.org

Gruss,
- berndl

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, da selbst ein schneller aktueller PC solche Datenraten sowieso 
nicht in Echtzeit verarbeiten kann, geschweige denn mit MatLab, der 
lahmen Java-Schleuder....macht sich die Frage nach einem ultra-schnellen 
Interface schon überflüssig. USB 2.0 mit knapp 40MByte/s sollte 
ausreichen, um auch einen i7 mit x64 so zuzuballern, dass alle Kerne bei 
100% hängen, wenn er die Daten nicht nur in den RAM schreiben soll. 
Echtzeit bekommst du mit Linux oder Windows so ohne weiteres eh nicht 
hin. Also S-ATA ist ja auch für Speicher-Medien gedacht, das macht in 
dem Fall wenig Sinn. Zumal man mehr Rechte als ein normaler User 
braucht, um auf Block-Ebene auf (emulierte) Speicher-Geräte zuzugreifen. 
Das ist Frickelei am OS vorbei. Bleibt PCIe. Kann man machen, der Virtex 
5 hat ja je nach Typ schon PCIe Hard-IP drin, Treiber gibts auch schon 
einiges bei Xilinx und es ist mittlerweile eine Stanrad-Schnittstelle. 
Allerdings ist der Aufwand im Vergleich zu USB 2.0 enorm. Bei USB 2.0 
kann man den Cypress FX2 Controller nehmen incl. fertigem Treiber, 
fertig. Bei PCIe muss man in FPGA-Design ziemlich fit sein und außerdem 
noch jemanden haben, der sich mit Kernel-Treibern auskennt. Auf jeden 
Fall wäre bei PCIe ein fertiges Demo-Board, wie etwa das ML505 
empfehlenswert....

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Valentin Stanev (Firma: Garz & Fricke) (hydravliska)

>Also die Aufgabe ist ein "schneller" AD Umsetzer (~80 MHz) anzusprechen,

Naja, das geht mal noch.

>Daten im FPGA zu verarbeiten und dann die in Richtung PC zu schicken.

Was heisst verarbeiten? Wieviele Daten? Echtzeit? Dauerbetrieb?

>USB 2.0 wurde schon ausgeschlossen da man auf die Datenraten gar nicht
>kommt,

>40 MHz * 16 Bit = 640 Mbit/s

Woher kommen diese Zahlen? Oben war es nocht ein 80 MHz ADC.

>Also bleiben PCIe und S-ATA.

Nöö, siehe Christian. Wenn es nur um kuze Datenpakete ohne Echtzeit 
geht, kann man sogar RS232 nehmen ;-)

>Da meine grösste Sorgen genau mit dieser Schnittstelle sind (die HW soll
>implementiert werden, es muss ein Windows Treiber entwickeln werden und
>und und...),

Und das alles in einer Masterarbeit? IMO viel zu viel!
Allein das PCIe/SATA Design dürfte da schon mehr als anspruchsvoll sein, 
TROTZ vorhandener ICS etc.

> würde ich euch gern die Fragen stellen welche Interface
>würden Sie auswählen.

PCIe ist nur als Steckkarte verfügbar. SATA hängt am Kabel, kann man 
auch neben den PC stellen wenn nötig.

Sata hat "nur" 1,5-3 Gbit/s, PCIe hat n x 2,5Gbit/s, brutto.

Die Antwort kann man ohne Kenntnis der anderen Anforderungen nicht 
geben.

MFG
Falk

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Also, da selbst ein schneller aktueller PC solche Datenraten sowieso
> nicht in Echtzeit verarbeiten kann

Na sicher kann er das, wieso denn nicht? Wozu hat man CPUs mit zig 
GFLOP/s und GPUs mit TFLOP/s wenn man damit keine 40 MS/s verarbeiten 
kann? Kommt natürlich darauf an was man damit machen will, aber 
grundsätzlich sind das Datenraten mit denen aktuelle PCs problemlos 
umgehen können.

Valentin Stanev schrieb:
> Also bleiben PCIe und S-ATA.

Wie wär's mit GBit-Ethernet?

Falk Brunner schrieb:
> Und das alles in einer Masterarbeit? IMO viel zu viel!

Darüber würde ich mir auch mal Gedanken machen.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Christian R. schrieb:
>> Also, da selbst ein schneller aktueller PC solche Datenraten sowieso
>> nicht in Echtzeit verarbeiten kann
>
> Na sicher kann er das, wieso denn nicht? Wozu hat man CPUs mit zig
> GFLOP/s und GPUs mit TFLOP/s wenn man damit keine 40 MS/s verarbeiten
> kann? Kommt natürlich darauf an was man damit machen will, aber
> grundsätzlich sind das Datenraten mit denen aktuelle PCs problemlos
> umgehen können.

Kommt drauf an. Wenn man nix berechnet und die Daten einfach auf eine 
schnelle Platte meißelt vielleicht. Pausen durch den Scheduler mal 
ausgenommen.
Wenn man aber was sinnvoles mit den Daten berechnet, siehts ganz anders 
aus. Wir setzen USB 2.0 ein und wenn wir Ultraschall-Bildgebung machen, 
fast alles auf der Grafikkarte rechne lassen, aber eben Daten abholen, 
aufbereiten, GPU programmieren usw. kann man morderne Dual-Cores mit 
4870 Grafikkarte problemlos schon bei wenigen MB/s auslasten. Vor allem 
kritisch bei externen Triggern, die man nicht verlieren darf.

Prinzipiell geb ich dir aber recht, es kommt auf die Anwendung drauf an. 
Da er aber was von Matlab schrieb, kann man die ganze High-Speed 
Geschichte eh erst mal entspannt sehen.

Und auch von mir: Für eine Master-Arbeit viel zu viel. Wenn du eine PCIe 
Hardware samt der ADC-Ansteuerung, Pufferung, Vorberechnung...halbwegs 
zum Laufen bekommst, jemand anderes den Treiber bemuttelt und du zum 
Ende der 4...5 Monate erste ADC-Daten in einer Matlab Figure anzeigen 
kannst, bist du schon fix gewesen.

Autor: Valko Zapalko (hydravliska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also vielen Dank an alle, in so kurze Zeit haben sich so viele Leute 
gemeldet :)

Das ganze werde ich mir nochmal überlegen, morgen habe ich auch noch ein 
Gespräch und werde auch nachfragen.

Also das Projekt könnte länger als 5 Monate dauern, aber ich glaube das 
bringt mir auch nicht viel.

Nebenbei muss noch ein Digital Down COnverter im FPGA implementiert 
werden was auch einges an Zeit kosten würde. Ich muss mir schon Gedanken 
über die Zeit machen, sonst werde ich nie fertig...

Nochmals vielen Dank und ein schönen Abend.


MfG
Valentin

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also PCIe würde ich auf jedenfall ausschließen, dies treibt selbst 
erfahrenen Usern den Schweiß auf die Stirn. Mal abgesehn vom Treiber. 
eSATA würde ich auch ausschließen.

Am besten ist ein Evaluation Board zu nehmen der einen AD-Wandler in der 
ausreichenden Geschwindigkeit enthält. Zudem sollte Dein Board dann 
einen Steckverbinder besitzen, mit dem Du einige Signale vom FPGA direkt 
an ein eigenes kleines Board weitergeben kannst. Auf diesem Board würde 
ich dann einen FTDI-USB Chip setzen. Hier braucht man sich nicht um die 
Treiber und das USB Protokoll kümmern, sonern es geht einfach. Somit 
kann man schon mal ein Programm schreiben das Daten in dem FPGA 
zwischenspeichert und dann per USB überträgt. Danach kann man die 
Schnittstelle gegen etwas schnelleres austauschen. Hier bietet sich der 
Camera Link Standard an. Hierzu gibt es Framegrabberkarten. Diese 
entahlten gleich die passenden Treiber. Mit einer Framegrabberkarte sind 
bis zu 600MByte\s machbar.

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Möglicherweise ist es ja möglich die Daten im FPGA vorzuverarbeiten um 
die Datenrate zu verringern. Was soll den überhaupt gemacht werden?

Du könntest die Daten einer Fourier-Transformation unterziehen um die 
Informationen zu extrahieren, die du wirklich brauchst. Die Datenrate 
würde sich dramatisch verringern und du könntest wirklich mit RS232 
arbeiten ;-)  oder vielleicht doch besser mit USB.

Ich habe vor kurzem ein Projekt fertiggestellt, in dem in einem FPGA auf 
Daten von 20 AD-wandlern eine single-bin-fourier-transformation 
angewendet wurde (eine einzelne frequenz). Die daten werden über 
ethernet (UDP) in den rechner übertragen.

Interesse an mehr infos?

Autor: Valko Zapalko (hydravliska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Sebastian: Danke für den Vorschlag, klingt sehr "straight forward" und 
ich würde mir gut überlegen ob ich es nicht wirklich einsetzte.

@Daniel: Also das mit dem Fourier Transform habe ich mir gar nicht 
gedacht. USB wäre ein schöne Sache, da man das Board nicht auf dem 
Motherboard stecken muss sondern bleibt man ein bisschen flexibel. Info 
wäre auf jeden Fall hilfreich :)

Das ganze soll später in Richtung Software Defined Radio 
weiterentwickelt werden. Ich muss mich um das ADC Interface, 
SChnittstelle zum PC sowie ein Digital Down Converter kümmern.

Am liebsten wäre mir ein vorhandene Treiber rauszusuchen so dass ich nur 
den Schnittstelle Interface implementieren muss.

Danke nochmal an alle :)


Gruß
Valentin

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schlage da immer noch den Cypress FX2 als USB Controller vor. Muss 
man zwar Firmware schreiben, ist aber für FPGA Systeme ideal, da Slave 
FIFO Ansteuerung. Und man kommt dank der Beispielcodes in einem Tag zum 
lauffähigen System. Die Geschwindigkeit mit 40MB/s durchschnittlich 
reicht bestimmt aus, klär das mal mit deinem Betreuer.

Autor: Gordo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Valentin,

was ist in etwa das Thema der Masterarbeit? Die Hardware (FPGA-Board, 
AD-Wandler) aufbauen, oder ein System z.B. Demoboard mit VHDL Code 
füttern bzw. mit dem PC verbinden?
Das ganze ist nämlich nicht ganz trivial. Ein gutes Demoboard für SW 
Defined Radio ist z.B. das XtremeDSP Kit von Xilinx. (Anbindung über PCI 
oder USB)
http://www.xilinx.com/products/devkits/DO-DI-DSP-D...
Ist leider schon ein bisschen in die Jahre gekommen, aber die AD und DA 
Wandler auf dem Board sind recht gut und funktionieren bis ca. 110MHz 
bei 14 Bit. (und sind  DC gekoppelt). Es gibt ausserdem zu dem Board 
eine Matlab-Library die sich System Generator nennt mit der man recht 
schnell zu Ergebnissen kommt.
Wenn mehr Geld seitens der Uni vorhanden ist frag mal bei Nallatech nach 
(www.nallatech.com). Dort sind Boards mit recht schnellen AD-DA Wandlern 
und grossen FPGAS (Virtex5 155) verfügbar. Preis liegt leider sehr hoch 
ca. ~ > 15k€ für ein Baord + BenOne PCIe. Dafür ist gleich die ganze 
Umgebung vorhanden samt Beispielcode.
Preiswerte Boards kann man auch bei Avnet finden, eine gute Kombination 
ist z.B. das "Xilinx® Virtex®-5 LXT/SXT PCI Express Development Kit" 
(AES-XLX-V5LXT-PCIE155-G) mit PCIe Schnittstelle und Virtex5-155 drauf. 
(kommt so auf 4k€) Als AD Board bietet sich das "EXP High-Speed 
Analog-to-Digital Converter Module" an, hat 500MS/sec bei 12 Bit...
Diese Boards samt LVDS Interface an den PC anzubinden und rudimentär 
funktionsfähig zu machen, müsste dann schon fast genug Arbeit für eine 
Masterarbeit sein.

Gruss
Michael

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte auch noch über Ethernet nachdenken (in der 1Gbit-Variante), 
reicht von der Bandbreite her locker, und jeder Popel-PC hat heute ein 
entsprechendes Interface. Auf PC-Seite muss man nicht im Kernel 
rumfummeln, sondern kann das im User Space erledigen. Der Kernel macht 
sogar Buffering für einen, wenn der Rechner mal für einen kurzen Moment 
nicht hinterherkommt ;-)

Wenn der Link dediziert ist, kann das Protokoll auf das allereinfachste 
reduziert werden (ggf. sogar Ethernet pur, ohne den neumodischen Kram 
wie IP oder gar TCP). Die wirklich "ekligen" Dinge an Netzwerken (allen 
voran Packet Reordering) betreffen einen in diesem Fall alle nicht. Ein 
bisschen RAM für einen Sendepuffer, Pakete ACKen lassen, und gut ist.

Wie es in punkto Schaltungsdesign dafür aussehen würde kann ich 
allerdings nicht helfen, da müssten die Experten ran.

Andreas

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Man könnte auch noch über Ethernet nachdenken (in der 1Gbit-Variante),
> reicht von der Bandbreite her locker, und jeder Popel-PC hat heute ein
> entsprechendes Interface. Auf PC-Seite muss man nicht im Kernel
> rumfummeln, sondern kann das im User Space erledigen. Der Kernel macht
> sogar Buffering für einen, wenn der Rechner mal für einen kurzen Moment
> nicht hinterherkommt ;-)

Auch wenn jeder PC einen GB ethernet port hat, auslasten können ihn die 
wenigsten. Und locker schafft der Port das auch nicht sondern ist schon 
fast am Limit.

Was der PC an Signalverarbeitung machen kann, kann ein FPGA oder DSP 
besser und schneller und billiger und sparsamer. Nur es ist halt nicht 
so flexibel. Lagere alle Algorithmen die die Daten reduzieren und die 
man nicht bequem am PC ändern muss auf dedizierte Hardware. Vor allem 
wenn harte Echtzeitanforderungen dazu kommen, wird es für den PC 
schwierig.

Wenn Du mit Ethernet arbeitest, was keine elegante Lösung m.E. 
darstellt, wirst du wahrscheinlich viel Entwicklungsaufwand haben, weil 
du nicht die standart Treiber und (Kernel-)Module nehmen kannst nehmen 
kannst. Überhaupt handelst du dir mit jeder Extrawurst viel Ärger ein! 
Daher lieber alles so benutzen wie es vorgesehen ist.

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Valentin Stanev schrieb:
> @Daniel: Also das mit dem Fourier Transform habe ich mir gar nicht
> gedacht. USB wäre ein schöne Sache, da man das Board nicht auf dem
> Motherboard stecken muss sondern bleibt man ein bisschen flexibel. Info
> wäre auf jeden Fall hilfreich :)

Eine elegante Lösung wäre sicherlich eine dedizierte Hardware auf der 
die FT Parameter verändert werden können, so weit das überhaupt mit 
euren Anforderungen hinkommt. Für so eine Hardware habe ich eine 
Schnittstelle entwickelt, die eine komfortable Schnittstelle zum 
Konfigurieren und Betreiben darstellt und die Daten über Ethernet/IP/UDP 
an den (Echtzeit-)Rechner schickt. Soll aber nicht heißen, dass das eine 
elegante Lösung ist! Ethernet haben wir genommen, weil es jeder PC und 
jedes bessere MCU board schon mitbringt.

Baust Du nur einen Prototypen? Dann ist es vielleicht egal, ob die 
Datenübertragung zum PC elegant ist oder nicht. Am schönsten ist eine 
Steckkarte aber das das viel Aufwand bedeutet, haben wir ja schon gehört 
:-).

Kläre erstmal...
1. mit welchen Algorithmen die Daten verarbeitet werden.
2. in wie weit die parameter/Algorithmen verändert werden müssen.
3. In wie weit sich die Algorithmen auf externe Hardware auslagern 
lassen.
4. Welche Echtzeitanforderungen es gibt.
5. Ob Datenverlust toleriert werden kann, oder in wie weit
6. Ob es off-the-shelf hardware gibt die den anforderungen genügt.

Wenn es hardware fertig gibt, und du USB nutzt, was schon auf dem board 
ist, hast du wohl einen überschaubaren und abschätzbaren Aufwand.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel G. schrieb:
>
> Auch wenn jeder PC einen GB ethernet port hat, auslasten können ihn die
> wenigsten.

Das ist Quatsch. Jeder halbwegs aktuelle Rechner schafft rein vom 
Durchsatz her 1Gbps ohne Probleme, und langweilt sich noch dabei. Selbst 
mehrere parallel (z.B. via Bonding) sind kein Problem, die begrenzenden 
Faktoren sind eher, wieviele Karten noch ins Gehäuse passen, oder wie 
schnell die Festplatten sind (bei Fileservern z.B.).

> Und locker schafft der Port das auch nicht sondern ist schon
> fast am Limit.

Realistisch machbar sind mit TCP/IP in der Praxis ca. 800Mbps NUTZDATEN, 
den IP-Overhead kann man noch weglassen. Sehe nicht, dass das mit 
640Mbps schon am Limit wäre, da ist noch Luft nach oben.

> Was der PC an Signalverarbeitung machen kann, kann ein FPGA oder DSP
> besser und schneller und billiger und sparsamer. Nur es ist halt nicht
> so flexibel. Lagere alle Algorithmen die die Daten reduzieren und die
> man nicht bequem am PC ändern muss auf dedizierte Hardware.

Der entscheidende Punkt ist aber nicht, was den höchsten Durchsatz 
bringt, sondern was überhaupt gebraucht wird. Dazu gibt es bis jetzt 
keine Infos.

Wenn es nur ums Speichern geht, dann kann ein Rechner mit ein paar 
schnellen Platten (RAID) mehrere von den genannten Datenströmen parallel 
verkraften. Selbst verschlüsselt (nur als Beispiel) wäre das noch kein 
Problem, der Rechner an dem ich hier gerade sitze (AMD Phenom II mit 
2,8GHz) macht mit AES128 auf einem einzelnen Prozessorkern 150 MByte/s, 
also > 1Gbps.

Bei FFT kommt es stark darauf an, über wieviele Punkte die FFT gehen 
soll. Je nach Parametern sollte bei vernünftiger Programmierung 
(natürlich nicht mit Matlab) ein PC mit entsprechend vielen Kernen die 
geforderten Datenraten locker schaffen, insbesondere wenn die 
Grafikkarte auch mitrechnet.

Von daher ist es Quatsch, pauschal zu sagen, ein PC könnte das nicht 
schaffen.

> Vor allem
> wenn harte Echtzeitanforderungen dazu kommen, wird es für den PC
> schwierig.

Das ist in der Tat schwierig, davon war aber nicht die Rede. Wenn es nur 
darum geht, dass keine Daten verloren gehen, ist das auch nicht nötig, 
man braucht nur geeignet dimensionierte Buffer auf Senderseite.

> Wenn Du mit Ethernet arbeitest, was keine elegante Lösung m.E.
> darstellt, wirst du wahrscheinlich viel Entwicklungsaufwand haben, weil
> du nicht die standart Treiber und (Kernel-)Module nehmen kannst nehmen
> kannst.

Wieso das denn nicht? Die Netzwerkkarte auf PC-Seite soll er doch nicht 
selbst bauen, und man muss schon eine sehr schlechte nehmen, wenn die 
normalen Treiber da die Leitung nicht auslasten können.

Im Gegenteil, bei PCIe müsstest du dir die Treiber komplett selbst 
schreiben, aber nicht bei Ethernet.

> Überhaupt handelst du dir mit jeder Extrawurst viel Ärger ein!
> Daher lieber alles so benutzen wie es vorgesehen ist.

Zumindest was die PC-Seite angeht würde ich PCIe oder SATA eher als 
"Extrawurst" bezeichnen als Ethernet.

Andreas

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ganz ehrlich Ihr ratet zum GB ethernet in der kurzen Zeit. Der Junge 
ist nach 2 Wochen so gefrustet und dann noch ein Board für 15k Euro zu 
empfehlen. Da kann man das Geld gleich verbraten. Ich habe ein Board für 
1700€ mit einem Virtex 5 SX50 gekauft, dieser hat bereits für die ersten 
Test mehr als genug DSP Einheiten.

Allein das Protokoll für TCP oder UDP ist schon eine Sache für sich. 
Einen Empfänger muß man auch noch schreiben. Und dann noch die 
Geschwindigkeit halte ich für den Anfang mehr als unrealistisch. Man muß 
auch mal auf dem Boden der Tatsachen bleiben.

Nimm blos den FTDI 2.0 basic Chip mit 15MBit. Es reicht für den Anfang 
aus. Du speicherst erst mal alle Daten in den RAM wenn ausreichend 
vorhanden sind, dann verarbeitet man diese und anschließend überträgt 
man die und überprüft ob alles richtig ist.

Zudem würde ich auch die Rohdaten an den PC übertragen dort die gleichen 
Operationen durchführen und die Ergebnisse miteinander vergleichen.

Wenn dies erfolgreich war kann man die Übertragung der Daten 
beschleunigen.

Wir haben hier einige Datenerfassungskarten (100MHz 400MHz 2GS) jedoch 
habe alle ein PCI Interface und schaffen gerade mal 150MB/s 
Datenübertragung. Es gibt so gut wie keine Datenerfassungskarten auf 
PCIe Basis. Dies kommt jetzt erst langsam und dies hat auch seinen Grund 
weil dies sehr schwer ist.

Autor: Denis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss Johann recht geben, geht mal von euren Anfangszeiten mit FPGA's 
aus die Lösungen sind für uns vielleicht kein Problem aber ein Neuling 
wird sich daran die Zähne ausbeißen vor allem in der Zeit.

Ich hätte auch noch eine Lösung die vielleicht nicht all zu teuer ist 
und vom Zeitaufwand sich in Grenzen hält.

Wenn es um den Datendurchsatz geht nimm ein ML507 Board mit einem Fiber 
Optic Converter + eine PCIe Karte mit einer Grabbersoftware(ich empfehle 
hierfür diese Karte http://www.adnaco.com/products/h1)

Da musst du dich nur um das Senden der Daten kümmern.Da kannst du auf 
ein Xaui IP von Xilinx nehmen und genügend Beispiele gibts auch.

Das Empfangen übernimmt die Grabberkarte. Die hat einen Datendruchsatz 
von 2,5Gbps hat.

Ist vom Aufwand her überschaubar würde jetzt bei einem Anfänger mal von 
3 Montaten ausgehen für die komplette Umsetzung der Datenübertragung.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ethernet ist kein Problem wenn man RAW Kommunkation betreibt, das gibt 
maximalen Durchsatz ohne Protokoll Overhead. Und das LocalLink Interface 
ist nicht schwierig.

Autor: Valko Zapalko (hydravliska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank an alle, echt nett das es hier so viel geschrieben wird :)

Also nochmal das Projekt:

Es wird ein ML507 verwendet. Dazu kommt ein externe AD Umsetzer LTC2206.

Ziel das Projekt ist der ADU anzusprechen, Daten abholen und irgendwo 
erstmal auf dem FPGA speichern(DDR2 SDRAM interface -> 256 MB externe 
Speicher). Um das ganze zu überprüfen wäre ein Schnittstelle zum PC 
benötigt. Am Anfang wurde über S-ATA, PCIe und USB 2.0 gesprochen. Mein 
erste Aufgabe wäre die drei zu evaluieren und so zu sagen mit einander 
zu vergleichen. Wichtig dabei wäre dass es ein fertiges Windows Treiber 
schon vorhanden ist. Sobald die Daten auf PC sind, soll z.B. durch 
Matlab überprüft werden ob alles stimmt. Deswegen finde ich der 
Vorschlag von Johann schon sehr gut, ich habe mir das auch ähnlich 
gedacht.

Am Ende ist es schon klar dass die komplette Datenverarbeitung auf FPGA 
Ebene passieren sollte. Der PC wird nur zum Überprüfung benötigt.

Meine Aufgabe ist die Verbingdung zwischen ADC und FPGA sowie FPGA und 
PC herzustellen. Dann werden Algorithmen wie Digital Down Conversion in 
der FPGA implementiert und die Ergebnisse dann, wie Johann meinte, mit 
eine Matlab Berechnung verglichen werden.

Gruß
Valentin

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also keine Echtzeit? Wozu dann so hohe Anforderungen an die Datenrate? 
Nimm USB, das ist bei weitem das einfachste.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denis schrieb:
> Wenn es um den Datendurchsatz geht nimm ein ML507 Board mit einem Fiber
> Optic Converter + eine PCIe Karte mit einer Grabbersoftware(ich empfehle
> hierfür diese Karte http://www.adnaco.com/products/h1)

Ist ja interessant. Sehe ich das richtig, dass ich völlig transparent 
ein PCIe Device über 250m Glasfaser anschließe? Was bräuchte man dann 
zwischen dem SFP-Modul und einem FPGA mit integriertem PCIe, wie dem 
Spartan 6 da noch? Irgendwie muss man ja wieder auf die TX/RX/CLK Paare 
kommen...oder muss man das Backplane-System von denen dann nehmen?

Autor: Denis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

ich weiß nicht ob ich deine Frage richtig verstanden habe,aber ich 
versuchs mal ;-)

also du bindest das SFP Modul an dein GTX Modul des Spartan 6. Diese 
sind bereits hardwareseitig von Xilinx integriert. Dazu benötigst du 
noch einen high precision Oszillator für den low Speed Takt und das 
wars.

Dann setzt du den PCIe IP Core ein und kannst damit die Daten bzw 
Befehle über eine Glasfaßer an das PCIe Board übertragen und auf dem PC 
brauchst du dann noch eine Grabber Software, die die Daten ausliest. Wir 
benutzen ein System das bei 4.25Gbps arbeitet aber auch nach dem selben 
Prinzip

Damit kannst du Daten super einfach auf einen PC übertragen.

Hoffe ich konnte dir damit weiterhelfen.

Autor: Gordo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Valentin,

jetzt wirds ein bisschen klarer, wenn es das ML507 Board wird. Wenn ich 
richtig verstehe ist das Ziel der Schnittstelle in erster Instanz die 
Ueberpruefung der AD-Wandler Anbindung, welche du gestalten sollst und 
den SDRAM Controller. Musst du das AD-Konverterboard layouten und 
aufbauen?

Aus meiner Praxis noch folgende Tipps:
- Noch einen DA Wandler zwecks Datenausgabe hinzubauen. (da kann man 
recht schnell ueber eine Loop Verbindung sehen ob alles funktioniert) Am 
besten sind da 2 Stueck.

- Die Daten seitens des AD Konverters koennen recht einfach ohne externe 
Schnittstelle ueber das ChipScope ausgelesen und analog dargestellt 
werden. (ChipScope wird ueber das Programmierkabel bzw. JTAG 
Schnittstelle angeschlossen und ist in die ISE integriert). 
Speichertiefe ist zwar gering und vom FPGA abhaenig aber um den AD 
Konverter HW maessig zu testen ok.

- Normale serielle Schnittstelle. Wenn Geschwindigkeit keine Rolle 
spielt, ist sie einfach zu implementieren und zum debuggen recht 
nuetzlich. (z.B. habe ich mir im FPGA einen Picoblaze samt 
Terminalprogramm gebastelt mit dem man Register und Speicher auslesen 
kann.)

- Sich vor dem Layout Gedanken ueber die Clockstrukturen machen. 
(Anbindung an DCMs etc)

- SDRAM Controller: fertigen Core nehmen oder Finger davon lassen. Falls 
du keine grosse Speichertiefe brauchst nehm erst einmal die internen 
RAMs im FPGA zum testen. So ein SDRAM Core samt den Einstellungen ist 
recht komplex. Schon alleine bis die Simulation laeuft dauert es recht 
lange und es ist ueberaus frustrierend. Gleiches gilt ueberigens für 
alle komplexen Cores: PCIe, GTP, Microblaze etc.

- Fertiges zu dem Eval Board passendes AD-DA Board kaufen, wenn es sowas 
gibt. Ich suche mir meine Eval Platinen so aus, dass ich im ersten 
Schuss ein passendes Analogboard dazu kaufen kann. (meist eine 
Zeitfrage, da es recht lange dauert bis man was anstaendiges gebaut 
hat).  Selber bauen + in die ganze FPGA Thematik einzusteigen ist sonst 
echt muehsam, es lauern  genug Stolperfallen ...


Gruss
Michael

Autor: Johann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@ Denis

Ich genau so etwas wollte ich in Zukunft auch machen. Somit sind zwei 
Geräte gleich galvanisch getrennt. Ich habe auch schon mal die GTX 
IP-Cores vom Virtex 5 angeschaut. Ich dachte immer ich muß den IP-Core 
auf die Oberfläche ziehen (Schaltplan) einen Clock dranhängen und dann 
die Daten übergeben und vielleicht ein Flag setzten. Als ich jedoch den 
IP-Core auf den Schaltplan gezogen habe, muste ich feststellen das dort 
150 Anschlüsse vorhanden sind und ich erst mal erschlagen war und mir 
dachte mach erst mal etwas anders ^^

Aber ich werde mich damit noch mal ein wenig mehr beschäftigen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.