Hallo ich möchte einen Langzeitdatenspeicher bauen, mit dem ich Controll-Daten aus dem FPGA holen und festhalten kann. Dazu möchte ich eine IDE- Festplatte, USB-Platte oder SATA-Festplatte möglichst direkt an das FPGA dranhängen. Die Frage ist, wie man das am Besten macht! Gibt es dafür gfs IDE-Interfaces zum kaufen oder eine andere Hardware, die man einfach programmieren kann? Ich brauche natürlich auch den Core, der das Protokoll macht. Am Einfachsten wäre ein binärerer Datenstrom oder auch ASCI, den ich rausstreamen kann (so schnell, wie halt machbar) und den ich dann mit einem C Programm wieder einlesen und umwandeln kann. Die Bandbreite würde man sicher mit genügend Fifos und parallelen Platten hinbekommen. Ich brauche so ungefähr 20MByte/s im Endstadium und insgesamt eine Kapazität von 20 GB, weshalb es weder mit JTAG und ChipsScope noch Ethernet oder Flashdrives geht. Was würdet ihr mir empfehlen?
Oli schrieb: > Die Bandbreite würde man sicher mit genügend Fifos und parallelen > Platten hinbekommen. Ich brauche so ungefähr 20MByte/s im Endstadium und > insgesamt eine Kapazität von 20 GB, weshalb es weder mit JTAG und > ChipsScope noch Ethernet oder Flashdrives geht. wir haben doch das Jahr 2011 oder? 20Mbyte/s konnten festplatten schon vor 5Jahren ohne Probleme. 20GB Platten sollte auch nicht das Problem darstellen. Ethernet mit Gigabit ist auch nicht wirklich neu und schafft das auch locker. mit USB2.0 sollten auch 30Mbyte/s mit jeden bessere Stick machbar sein. > Am Einfachsten wäre ein binärerer Datenstrom > oder auch ASCI, den ich rausstreamen kann wo ist da für dich der Unterschied? Vermutlich lassen sich die Daten sogar Komprimieren, damit könntest du auch 100Mbit Ethernet verwenden.
>> Am Einfachsten wäre ein binärerer Datenstrom >> oder auch ASCI, den ich rausstreamen kann >wo ist da für dich der Unterschied? ASCI sind explizite Daten und damit direkt lesbar. Macht ca 3-4mal an Bedarf, was ich so abgeschätzt habe. >mit USB2.0 sollten auch 30Mbyte/s mit jeden bessere Stick machbar sein. Wäre nicht schlecht. Mit dem Durchsatz komme ich auf 820 MB/min für alle Kanäle, brauche aber leider bis zu 200 GB für eine Aufzeichnung. Das ist als Flash etwas teuer und auch unnötig. Was natürlich gut wäre: Eine USB Platte ausreichender Grösse. Aber wie kriege ich die am schnellsten ans FPGA? Es darf auch ruhig etwas kosten, wenn es im Rahmen bleibt.
Kommt auf das FPGA drauf an ob SATA oder NAS geht. am einfachsten wäre SD Karte, aber warscheinlich zu teuer. IDE Platte würde ich sagen falls dein FPGA kein SERDES kann.
Bin gerade am suchen, was an an boards gibt, die IDE oder SATA haben. Das Problem ist, dass ich eben auch einen COre brauche. Mal schauen, was OC hat.
Oli schrieb: > ich möchte einen Langzeitdatenspeicher bauen, mit dem ich Controll-Daten > aus dem FPGA holen und festhalten kann. Dazu möchte ich eine IDE- > Festplatte, USB-Platte oder SATA-Festplatte möglichst direkt an das FPGA > dranhängen. > > Die Frage ist, wie man das am Besten macht! Ein wesentlicher Faktor ist, ob du ein standardisiertes Filesystem (FAT, Ext2/3/4 oder NTFS) auf der HD haben willst. Eine HD raw zu beschreiben ist aus einem FPGA kein Problem. Ein standardisiertes Filesystem in Logik zu vergraben ist schon aufwendig. Tom
Ja, das denke ich mir auch. Bin gerade auf der Suche, ob es da nicht EVAL-Boards zu gibt, die das gfs mit Microblaze machen. Das müsste dann in C einigermassen erträglich sein / bereits existieren.(?)
Auf den Xilinx Boards gibts öfters mal SATA, oder für die neuen Boards mit dem FMC Anschluss auch als Zusatzkarte erhältlich. Prinzipiell können alle Xilinx FPGAs, die einen RocketIO Transceiver haben, SATA, zumindest SATA-I. Im CoreGenerator für den GTP/GTX kann man SATA einstellen. Aber einen IP Core brauchst du dann natürlich noch, ich weiß nicht, ob beim EDK einer dabei ist eventuell. Ansonsten selber machen. Wenn nicht noch ein File-System drauf muss, ist das ja nicht ausufernd schwer. Ansonsten einen MicroBlaze benutzen und darauf die FAT Sachen machen. USB 2.0 Host Controller wäre da schon wesentlich aufwendiger als ein SATA Host.
Mein Vorschlag wäre ein PC als Gegenüber mit einer dedizierten GBit-Ethernetverbindung. Die Daten würde ich als UDP-Pakete senden. Da dabei alle Pakete den gleichen Aufbau haben, kannst Du den fest kodieren (auch IP- und MAC-Adressen) und nur die Daten, Zähler und CRCs an der richtigen Stelle einfügen. Das kriegt man auch ohne gekaufte IP ganz gut hin. Die Daten würde ich binär übertragen, eine Umwandlung in ASCII kann später der PC offline machen. Wenn der PC während der Datennahme nichts anderes tut, sollte er die Daten auch locker wegschreiben können. Nimm Linux, dann kannst Du besser beeinflussen, was sonst noch auf dem Rechner läuft. Deine Datenpakete solltest Du so gestalten, dass Du Ausfälle erkennen kannst. Bei 20 GB Datenvolumen kannst Du notfalls auch so viel RAM in den PC stecken. Bei 200 GB ist das natürlich keine Option mehr. Ein NAT ist keine gute Idee, da das ein viel zu kompliziertes Protokoll (z. B. SMB) spricht. Das willst Du in einem FPGA nicht wirklich nachprogrammieren. Die PC-Lösung hat auch den Vorteil, dass die Daten gleich in einem zur einfachen Weiterverarbeitung geeigneten Format weggeschrieben werden. Wenn die Platte direkt am FPGA hängt, kannst Du nur einfach einen Block nach dem anderen vollschreiben. Bei der anschließenden Auswertung muss der PC dann direkt diese Blöcke am Betriebssystem vorbei lesen. Das ist je nach System nur mit speziellen Treibern möglich.
dnalorac schrieb: > Nimm Linux, dann kannst Du besser > beeinflussen, was sonst noch auf dem Rechner läuft. naja dafür Recht auch ein windows - hier kann linux nichts was windows auch kann. > Ein NAT ist keine gute Idee, da das ein viel zu kompliziertes Protokoll > (z. B. SMB) spricht. Das willst Du in einem FPGA nicht wirklich > nachprogrammieren. NAT? meinst du eine NAS also Netwerkfestplatte? > Bei der anschließenden Auswertung muss > der PC dann direkt diese Blöcke am Betriebssystem vorbei lesen. Das ist > je nach System nur mit speziellen Treibern möglich. welchens System braucht da speziellen Treibern? Bei windows und Linux geht es mit den Passenden Rechte und ohne speziellen Treiber.
Peter II schrieb: > dnalorac schrieb: >> Nimm Linux, dann kannst Du besser >> beeinflussen, was sonst noch auf dem Rechner läuft. > naja dafür Recht auch ein windows - hier kann linux nichts was windows > auch kann. Klar geht alles auch irgendwie mit Windows, aber zumindest aus meiner Sicht viel komplizierter. Ist aber eine Geschmacksfrage. > >> Ein NAT ist keine gute Idee, da das ein viel zu kompliziertes Protokoll >> (z. B. SMB) spricht. Das willst Du in einem FPGA nicht wirklich >> nachprogrammieren. > NAT? meinst du eine NAS also Netwerkfestplatte? Ja, natürlich. Tippfehler. > >> Bei der anschließenden Auswertung muss >> der PC dann direkt diese Blöcke am Betriebssystem vorbei lesen. Das ist >> je nach System nur mit speziellen Treibern möglich. > welchens System braucht da speziellen Treibern? Bei windows und Linux > geht es mit den Passenden Rechte und ohne speziellen Treiber. Bei Windows war ich mir da nicht so sicher. Wie bekommt man denn da die Rechte?
Dann würde ja auch USB 2.0 reichen, die 20MB/s schafft man mit ordentlicher Pufferung locker. Notfalls PCIe nehmen (fertigen Chip). Es klang aber eher nach einem Stand-alone System...
dnalorac schrieb: > Bei Windows war ich mir da nicht so sicher. Wie bekommt man denn da die > Rechte? Anwendung als Admin starten? Eventuell ist es möglich auch anderen nutzer das Recht inzurichten aber da müsste ich auch erst suchen ob das geht.
Eine IDE Festplatte ans FPGA zu "pflanschen" ist "peace of cake". Bei Altera gibt es da sogar freie Cores, bei Xilinx (Stichwort XESS) gibt's die auch. Zu der Geschwindigkeit kann ich ncihts sagen, aber wird schon schnell genug sein, wenn man es nicht ganz verkehrt macht. An SATA würde ich mich nur mit SATA-to-Local Bus ASICs rantrauen, alles andere ist sehr komplex. Kest
>Eine IDE Festplatte ans FPGA zu "pflanschen" ist "peace of cake". Aber einen PHY brauche ich dafür schon, denke ich, oder? Ich denke nicht, dass ich da ohne Pegelwandlung direkt aus einem Expansionboard raus kann. UDP wäre natürlich auch eine Möglichkeit. Ich habe inzwischen das hier gefunden: http://opencores.org/project,pc_fpga_com "PC-FPGA Communication Platform" Andererseits haben sie auch einen UBS2.0 Core. Ein filesystem wäre schon gut, habe ich aber noch nie gemacht.
Und nochmal eine andere Idee: >USB 2.0 Host Controller wäre da schon wesentlich aufwendiger als >ein SATA Host. Wäre mir natürlich sehr symühatisch. Ich habe gerade bei Reichelt die SS-Drives gesehen: OCZSSD2-2VTXE120, 120 GB, 275 MB/sec Schreiben. 177,- Das wäre ok. Ich brauche also einen SATA-core und ein Protokoll zum Anlegen von Dateien im Windowsformat. Wäre hätte da auch Bedarf und würde sich an einem Projekt beteiligen?
Oli schrieb: > Ich brauche also einen SATA-core und ein Protokoll zum Anlegen von > Dateien im Windowsformat. Dann wirds in reiner Logik schon schwierig. Da brauchst du am besten einen MicroBlaze Prozessor samt passendem RAM usw. dann kannst du beliebige FAT Implementierungen implementieren. Die Daten dann zu SATA ist auch nicht so schwer, da gibts sicher auch Beispiele, denn das ML505 Board beispielsweise hat SATA dran.
Oli schrieb: > OCZSSD2-2VTXE120, 120 GB, 275 MB/sec Schreiben. 177,- Das wäre ok. Vorsicht bei den angegebenen Schreibraten! Das sind Maximalwerte. Ich habe bisher noch keinen Hersteller gefunden, der eine garantierte minimale Schreibrate in seinem Datenblatt aufgeführt hat... Duke
Für eine IDE Festplatte brauchst Du keinen Phy. Ich würde schätzen, dass sogar wenn Du einen SATA Core hättest, alles zum Laufen zu bringen 3 Mannmonate dauert. Es ist also nicht so trivial, wie IDE. Kest
Hm, eigentlich brauche ich Lösung mit 3 Manntagen :-( Es muss doch irgendwelche passenden Sachen am Markt geben, denke ich ...
Das mit 3 Manntagen kriegst Du nicht mehr hin ;-) Dann müsstest Du ja am Mo fertig werden :-) Wenn Du bereit bist, viel Geld zu bezahlen, dann wirst Du sicherlich was finden. Statt IDE Festplatte könnte man CF-Karte nehmen, auf die 20 MB/s kommst Du sicherlich, wenn Du 2-4 davon parallel nimmst. Die CF Karte kannst Du direkt ans FPGA anschließen. Grüße, Kest
Haha, 3 Manntage. Die brauchst du schon für das Aufsetzen des EDK/XPS Projektes für dein Board (wenn überhaupt vorhanden) und bis zum ersten "Hello World" über die Konsole. Klar, für PATA brauchst du keinen PHY, aber einen Pegelwandler, PATA läuft meines Wissens mit 5V, sowas hat kaum ein aktuelles FPGA noch. Ist aber wenigs zukunftsfähig, die PATA Platten werden immer weniger und teurer.
Also ich würde das wie folgt machen: Nehme den FTDI-Chip FT2232H das gibt es sehr kleine Boards überall für sehr wenig Geld (29€) zu kaufen http://de.farnell.com/ftdi/ft2232hq-mini-module/modul-usb-2-port-ft2232h-basiert/dp/1697465 Mit diesem Chip kann man Daten in Richtung PC mit bis zu 40MByte pro Sekunde übertragen. Ich benutze immer Labview um dann ein kleines Empfangsprogramm zu schreiben. Demnach kommen die Daten von Deinem Messsystem über USB 2.0 und in Richtung PC. Dort schreibt Dein Programm die Daten dann auf die Festplatte oder einen USB-Stick. Der FTDI-Chip übernimmt das ganze USB-Protokoll. Du must Die Daten beim FTDI-Chip wie in einen FIFO schreiben und ein Flag setzen wenn ein Byte übertragen wurde. Den Rest macht dann der FTDI-Chip. Dadurch muss man sich nicht mit einem IP-Core rumägern und verbringt keine Zeit mit dem Suchen. Der Chip funktioniert inzwischen sehr gut. Ich habe Ihn selber auf eingien Boards verbaut.
PS. Ich würde es auch in weniger als 3 Manntage lösen können :-) Jedoch habe ich in diesen Bereich auch schon einige Jahre Erfahrungen
Hm, ich hatte mich jetzt schon mit einer non-PC_Lösung angefreundet. Naja, ich werde mal am WE darüber grübeln, was ich mache.
Mit Host-PC zerfällt die Aufgabe natürlich in wenige Zeilen VHDL, den FT2(2)32H anzusprechen ist ein Kinderspiel. Den Cypress FX2 kann man genauso nehmen, etwas aufwendiger in der Programmierung der Firmware, aber dafür universeller.
Die Frage ist, wie bequem man es beim Auslesen haben will. Entweder man steckt den C Code auf einen Core im FPGA oder macht es mit einem Konverter im PC offline. Letzteres scheint mir einfacher.
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.