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