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
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
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....
@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
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.
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.
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
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.
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?
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
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.
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-DK4-UNI-G.htm 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
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
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.
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.
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
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.
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.
Ethernet ist kein Problem wenn man RAW Kommunkation betreibt, das gibt maximalen Durchsatz ohne Protokoll Overhead. Und das LocalLink Interface ist nicht schwierig.
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
Also keine Echtzeit? Wozu dann so hohe Anforderungen an die Datenrate? Nimm USB, das ist bei weitem das einfachste.
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?
@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.
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
Angehängte Dateien:
-
GTP_DUAL.PNG
90 KB
@ 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.
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.