Hallo, ich muss für meine Masterarbeit mithilfe eines FPGA basierten Boards eine Signaldatenreihe aufnehmen und diese dann für weitere Zwischenschritte abspeichern. Die Datenreihe sollte möglichst mit 200Msps und 12-16Bit Auflösung aufgenommen werden. Da man für solch schnellen ADCs einen FPGA mit Gigabit Transceiver (GTP/GTX) benötigt habe ich meine Auswahl auf Evaluation-Boards von Xilinx beschränkt die eben diese bieten. Als ADC Lösung bietet sich am besten eine passende FMC ADC-Karte an. Folgende Artikel favorisiere ich: FPGA Eva-Board: http://www.xilinx.com/products/boards-and-kits/ek-s6-sp605-g.html FMC ADC-Karte: http://www.xilinx.com/products/boards-and-kits/1-2rqm0s.html Meine Erfahrung in Sachen VHDL beziehen sich auf einfache Zustandsautomaten für serielle Datenübertragung oder Daten-Speichern/Lesen von SRAM Memorys. Aber mit Gigabit Transceivern habe ich bisher keine Erfahrung. Die GTP auf dem XC6SLX45T kann bis zu 3,2Gbps seriell übertragen (1) und ein ADC mit 16bit Auflösung und einer Übertragungsrate von 200Msps sollte nur 1,6Gbps benötigen (2). Das SP605 Evaluation-Board ist zwar nicht unter den "Base Board Support" für die AD9467 FMC Card aufgelistet, aber ~1000€ billiger als die dort aufgelisteten Boards (3). Ist die Konfiguration dieser beiden Komponenten sinnvoll oder habe ich eine wichtige Sache übersehen? Falls ja, wie einfach ist die Implementierung des ADC im VHDL Code mit den geeigneten IP-COREs? Ich würde mich auch über Empfehlungen für andere mögliche Systemkonfigurationen freuen die eventuell etwas kostengünstiger sind. (1) http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/lxt.html#32gbps-gtp-transceivers (2) http://www.xilinx.com/support/documentation/application_notes/xapp876.pdf (3) http://www.xilinx.com/products/boards-and-kits/fmc-cards.html
Christian Kantner schrieb: > Da man für solch > schnellen ADCs einen FPGA mit Gigabit Transceiver (GTP/GTX) benötigt > habe ich meine Auswahl auf Evaluation-Boards von Xilinx beschränkt die > eben diese bieten. Wie kommst du denn auf den Trichter? Der von dir genannte AD9467 hat ein paralleles LVDS Interface das die Daten DDR ausgibt. Da ist nix GTP, nichtmal seriell für die ISERDES. Das schafft der Spartan 6 locker.
Moin, Die GTPs werden hoechstens interessant, wenn du die Daten wieder aus dem SP605 rauskotzen musst - aber da ist dann die grosse Preisfrage: Wie (Welches Protokoll, welche Schnittstelle) und wer horcht am anderen Ende? Die ueblichen Standards, wie zB. GBit-Ethernet oder PCIe, die das Board unterstuetzt, sind ein bisschen langsam fuer 3.2 GBit/sec. Da muss man schon arg Obacht geben, dass man 800MBit/sec, also ein Viertel, drueberbringt. Abgesehen davon ist auch eine PCIe Anbindung incl. dem ganzen SW-Gedoense oder erzeugen von Ethernet/IP/UDP-Paketen mit ein paar Samples drinnen ein bisschen heftig fuer eine Masterarbeit, wenn man noch nicht vorher gross was in der Richtung gemacht hat. Gruss WK
Naja, es soll ja offenbar immer nur eine gewisse Anzahl Samples genommen werden die dann weiter verarbeitet werden. Trotzdem muss man vom Board ja wieder runter, blöderweise hat es nur einen FMC und sonst nur PCIe und GBit LAN. Beides in einer Masterarbeit kaum zu schaffen.
Also sollte es völlig ausreichen die 16 Datenpinpaare über den FMC direkt an den FPGA anzuschließen? Gibt es für das Datenübertragungsprotokoll vom ADC einen entsprechenden IP-Core? Sieht so aus als ob er nur über 8 parallele LVDS Paare alle 16Bit immer in 2er Blöcken ausgibt, also das erste LVDS Paar macht D1 & D0, das Zweite D3 & D2, ... und das Achte D15 & D14. Da müsste ich ja auf steigende und fallende Flanken triggern für die DDR. Ich hatte bereits einmal das Problem mit der Signalintergrität wenn der FPGA mit zu vielen Flanken belastet wurde. Dann sollten die aufgenommenen Datensätze im vorhandenen 128MB DDR3 Speicher abgelegt werden. Dafür sollte es ja den MIG Core geben und der sollte auch locker mit seine 16-bit data path die einzelnen Datensätze ablegen können. Die Datenübertragung zum PC kann ich zur Not über UART machen, da der Prozess nicht mehr wirklich zeitkritisch ist. Entscheidend ist eher die Qualität und Bandbreite der aufgenommenen Signalfolge.
:
Bearbeitet durch User
Moin, Wirf mal einen Blick in die xapp1064 - vielleicht hilft dir die weiter, um den ADC ans FPGA zu flanschen. Klappt das ueberhaupt hardwaremaessig? Bei den Geschwindigkeiten und Datenbusbreiten ist Drahtigelloeten eher nicht so angesagt. Klaro, danach die Daten ins SDRAM schreiben wird auch irgendwie klappen - aber biste dir z.b. sicher, dass der 64-Wort-FIFO in der MIG Komponente immer auf jeden Fall reicht oder brauchste evtl. noch einen extra Fifo...usw. Wie lange haste denn Zeit fuer deine Masterarbeit? Ich wuerde fuer das, was du vorhast, fuer dich mal locker von 1 Jahr ausgehen - wenn alles glattlaeuft. Sonst gerne auch noch laenger.... Gruss WK
Dafür braucht man nichts weiter als an jedem Eingangspaar einen IBUFDS, dann ein IDDR Register, fertig ist der Lack. Da ist keinerlei Protokoll oder was serialisiertes, was man mit der XAPP1064 machen müsste. Das steckt so ein Spartan 6 loecker weg. DDR3 ist dann natürlich wieder eine ganz andere Ecke....dafür brauchste natürlich den MIG, aber der nimmt dir ja einiges an Arbeit ab. Musst aber vor dem MIG noch ordentlich in einen FIFO puffern, denn der DDR-RAM macht ja auch immer mal Refresh.
Angehängte Dateien:
-
serialization.JPG
52 KB
Eine Lösung für die ADC Auslesung mithilfe von Serialsieren der I/O scheint auch der "SelectIO Interface Wizard" zu bieten. Hier kann man die Busbreite und die Größe der Serialisierung angeben. Natürlich kann hier auch die ganze Pin-Config definiert werden (differential LVDS33 usw.). -> siehe Anhang IDDR schaue ich mir auch noch an. Im UG381 stehen ein paar Worte dazu drin und ISE Project Navigator bietet ein Template für IDDR2
1 | IDDR2_inst : IDDR2 |
2 | generic map( |
3 | DDR_ALIGNMENT => "NONE", -- Sets output alignment to "NONE", "C0", "C1" |
4 | INIT_Q0 => '0', -- Sets initial state of the Q0 output to '0' or '1' |
5 | INIT_Q1 => '0', -- Sets initial state of the Q1 output to '0' or '1' |
6 | SRTYPE => "SYNC") -- Specifies "SYNC" or "ASYNC" set/reset |
7 | port map ( |
8 | Q0 => Q0, -- 1-bit output captured with C0 clock |
9 | Q1 => Q1, -- 1-bit output captured with C1 clock |
10 | C0 => C0, -- 1-bit clock input |
11 | C1 => C1, -- 1-bit clock input |
12 | CE => CE, -- 1-bit clock enable input |
13 | D => D, -- 1-bit data input |
14 | R => R, -- 1-bit reset input |
15 | S => S -- 1-bit set input |
16 | );
|
Inwiefern kann ich hier C0 und C1 verstehen? Handelt es sich hierbei um die steigende und fallende Flanke einer Clock und lege ich dann eine dieser Flanken dann als CE fest?
:
Bearbeitet durch User
Christian K. schrieb: > Inwiefern kann ich hier C0 und C1 verstehen? Handelt es sich hierbei um > die steigende und fallende Flanke einer Clock und lege ich dann eine > dieser Flanken dann als CE fest? Richtig. An C0 und C1 muss der Takt, um jeweil 180° verschoben. Idealerweise aus einer PLL. Das hat z.B. auch den Vorteil, daß man dort die Phase noch etwas schieben kann, um den Abtastzeitpunkt der Daten zu optimieren. CE legt man permanent auf '1'. Es sein denn, man will gelegentlich keine ADC-Daten empfangen. Duke
Christian K. schrieb: > Eine Lösung für die ADC Auslesung mithilfe von Serialsieren der I/O > scheint auch der "SelectIO Interface Wizard" zu bieten. Hier kann man > die Busbreite und die Größe der Serialisierung angeben. Natürlich kann > hier auch die ganze Pin-Config definiert werden (differential LVDS33 > usw.). -> siehe Anhang Ja, schön und gut, das hat aber überhaupt gar nichts mit deinem ADC zu tun, der hat parallele Ausgänge. Christian K. schrieb: > IDDR schaue ich mir auch noch an Das passt schon viel besser :)
Der Deiner Applikation solltest Du Dich vor allem um einen präzisen Takt kümmern. Daran wird es am Ende hängen. Zu der Frage, ob man bei einer Masterarbeit IP-Cores einsetzen sollte, oder eher doch etwas machen sollte, was man komplett selber realisiert, nehme ich jetzt mal nicht Stellung.
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.