Hallo Zusammen, folgendes Problem: Ich bin auf der Suche nach einem Speicherbaustein der mir für folgenden Aufbau dienlich sein muss: Zunächst nur ein ADC08200 liefert 200MSPS zu je 8 Bit, ein Cyclone II holt die Daten ab und muss sie mir auf einen Speicherbaustein schreiben. Das Problem - soweit ich richtig gerechnet habe: 200 MSPS zu je 8 Bit verursachen 200 MB Datenaufkommen pro Sekunde. Wo speichere ich solch eine Datenflut hin? Ziel wäre zunächst mal 2-3 Sekunden FIFO zu sampeln und dann 'langsam' via USB rauszugeben. SD-Karten und Konsorten kommen meiner Meinung nach bei 200 MB/s nicht mehr mit. SSD ist nicht - da fällt mir nur noch S/D-Ram ein... bessere Ideen ?
Aua. Üblicher Speicher für PCs hat eine max. Datenrate von 133MHz. Die Irrsinns-Frequenzen von 1066MHz und inzwischen noch schneller kommen nur zustande, weil der Speicher Wartezyklen (CL u.a.) hat - je schneller getaktet, desto mehr. Ich würde auf eine Busverbreiterung setzen, also ein CPLD o.ä., das vier oder acht 8-Bit-Werte auf einmal in eine Speicherbank schreibt. Gruß - Wolfgang
Wolfgang schrieb: > Aua. Üblicher Speicher für PCs hat eine max. Datenrate von 133MHz. Die > Irrsinns-Frequenzen von 1066MHz und inzwischen noch schneller kommen nur > zustande, weil der Speicher Wartezyklen (CL u.a.) hat - je schneller > getaktet, desto mehr. Ich würde auf eine Busverbreiterung setzen, also > ein CPLD o.ä., das vier oder acht 8-Bit-Werte auf einmal in eine > Speicherbank schreibt. > > Gruß - Wolfgang Weißt du was Wolfgang - vielleicht hast du recht. Ich müsste einen RAM finden der ein ein paralleles 8 Bit Interface hat. Mit entsprechenden Pegelwandlern könnte ich ADC08200 und RAM direkt auf dem parallelen Interface kommunizieren lassen. Danach kann ich in aller Ruhe den RAM auslesen ... Jetzt brauche ich nur noch einen RAM den man auch als Normalsterblicher mit endlichem Zeitaufwand ansteuern kann. Kennt da jemand was? Links, Ideen ?
Da sehe ich schwarz. Leicht anzusteuern (wie auch immer das auszulegen ist), ist z.B. ein Dual-Port-RAM. Die Dinger haben wenig Speichertiefe, sind meist langsam, extrem schwer zu beschaffen und teuer. SDRAM, DDR? Njet, Ansteuerung ist abenteuerlich. EDO, Fast-Page-DRAM? Abenteuerlich, inzwischen schwer erhältlich. Fast-SRAM? Extrem schwer erhältlich, teuer. Viel Spaß bei der weiteren Suche! Gruß - Wolfgang
Normalerweise schreibt man das in die internen BlockRAMs von FPGAs oder externe FIFO-Speicher. Aber 2...3 Sekunden wird schwierig (bzw. teuer). Da brauchst du wirklich (DDR-)SDRAM mit einem schnellen Memory Controller und viel Puffer dran. Schließlich will der immer wieder seinen Refresh und alle möglichen Adress- Bank- und sonstigen Umschaltungen.... Also ADC -> FPGA -> BlockRAM FIFO (8Bit -> 32 Bit) -> SDRAM Controller -> SDRAM.
K7R643684M, s. http://www.samsung.com/global/business/semiconductor/productList.do?fmly_id=176&xFmly_id=173 Ist aber schwer erhältlich, teuer, extrem schwer zu verarbeiten (FBGA165), erfordert viel Hirnschmalz in der Ansteuerung. Soll ich weitererzählen?
wie wärs mit NoBL ? http://www.cypress.com/?id=105&addcols=¶metric=html&filter_189=73728&pagenum=all#parametric einfacher in dr Ansteuerung und TQFP
Mann O Mann, hier sind mal wieder ein paar Experten unterwegs . . . 8-0 Für 200 MB/s und 3s Speicherzeit = 600MB braucht man sauber RAM, nämlich SD-RAM oder heute eher DDR bzw. DDR2 RAM. Siehe Speicher. Und um dessen Ansteuerung kommt man nicht herum. Und mit 8 Bit Datenbus macht bei sowas keiner rum, 16, 32 oder gar 64 Bit sind da angesagt. Kauf dir einen DDR-RAM Speicherriegel mit 1Gb für den PC, kostet heute praktisch nix, hat aber 64 Bit Busbreite. Viel Spass damit ;-) Merke: Das ist nix für Möchtegernbastler. MFG Falk
Ich habe zwar von FPGA kein Ahnung, aber wenn die Daten eh auf einen PC sollen, dann kann man sie doch auch gleich live dort hin schicken. Eine einfache Gigabit Netwerkkarte schaft doch auch schon 100Mbyte/s. Eventuell kommt ja auch Fibrechannel in Frage. Die Karte gibt es zur zeit für 4Gbit/s was ja schon mal mehr als notwendig ist. Man man also dem FPGA ein FC interace verpassen könnte, dann sollte der rest mit normaler PC-hardware möglich sein. Dann einfach ein paar GB ram rein dan braucht man auch keine schnelles Festplattensystem.
Es gibt FPGA kits mit pciE interface. da gehn solche Datenraten. suche dir eine solche, fuer die es gute Treiber gibt, dh solche, welche ein einfaches interface (via dll) bieten. dann kannst du dein pc ram vollschreiben.
Ich habe so was ähnliches mit FIFOs von IDT gemacht. Aber eine andere Frage, was willst du mit 400-600Mio. Samples tun. Bist du sicher dass du weissst was du willst...
Neue Generation von CF-Karten: 'max. 200 MB/s lesen, max. 200 MB/s schreiben' http://www.alternate.de/prod?id=147182 (Im Text steht etwas von 90MB/s - stimmt allerdings nicht mit 1333x überein) Gruß Jobst
Falk Brunner schrieb: > Kauf dir > einen DDR-RAM Speicherriegel mit 1Gb für den PC, kostet heute praktisch > nix, hat aber 64 Bit Busbreite. Viel Spass damit ;-) > > Merke: Das ist nix für Möchtegernbastler. Auf DDR-Ram wird's rauslaufen ... keine Angst das Projekt hat schon einen gewissen Grundgedanken für Ernsthaftigkeit und soll summa summarum eher in einer Bachelorarbeit ausarten ... Nur keine Angst ich bin keiner von den nicht praxistauglichen Ingenieuren. Ich darf immerhin auf 8 Jahre Mikrocontrollererfahrung zurückblicken + einige Jahre FPGA. Peter schrieb: > Ich habe zwar von FPGA kein Ahnung, aber wenn die Daten eh auf einen PC > sollen, dann kann man sie doch auch gleich live dort hin schicken. ! Peter schrieb: > Eine > einfache Gigabit Netwerkkarte schaft doch auch schon 100Mbyte/s. theoretisch vielleicht ja - praktisch wohl eher nicht. Das scheitert schon alleine daran, dass die Schreibgeschwindigkeiten auf der Festplatte eines Computers (außer SSD) meist schon unter dem Datenaufkommen angesiedelt sind. Das bringt niemand hin - ich hab in meinem Netzwerk noch nie gesehen, dass ein 700 MB Film in 7 Sekunden übertragen wäre ... Peter schrieb: > Eventuell kommt ja auch Fibrechannel in Frage. Gleiche Problematik - bezahlbar nur mit Media Converter - nix gut Peter schrieb: > Man man also > dem FPGA ein FC interace verpassen könnte, dann sollte der rest mit > normaler PC-hardware möglich sein. Dann einfach ein paar GB ram rein dan > braucht man auch keine schnelles Festplattensystem. Am FPGA liegt das Problem nicht - eher am Computer ... Daniel Müller schrieb: > Aber eine andere Frage, was willst du mit 400-600Mio. Samples tun. Bist > du sicher dass du weissst was du willst... Um es genau zu sagen möchte ich ein 'vernünftiges' und bezahlbares open source DSO bauen. Es sollte bis ca. 100 MHz verwendbar sein (gemäß dem WKS-Abtasttheorem also Faktor 2 (eigentlich 2,2 aber das wollen wir heir vernachlässigen) 200 MSPS). 8 Bit Speichertiefe. Kostenpunkt max. 150€, High Speed USB, in der Zukunft vermutlich weiterer FPGA mit VGA Schnittstelle. Warum 3 Sekunden? Ganz einfach weil ich gerade eine Anwendung in Planung habe in der ich 3 Sekunden lang durchgehend Frequenzen bis ca. 80 MHz aufzeichen sollte. Das open source DSO ist ein netter Nebeneffekt den ich nach Abschluss zu Verfügung stellen möchte.
Lehrmann Michael schrieb: > Das scheitert > schon alleine daran, dass die Schreibgeschwindigkeiten auf der > Festplatte eines Computers (außer SSD) meist schon unter dem > Datenaufkommen angesiedelt sind. du darfst halt nicht von MediaMarkt technik ausgehen, die aktuellen Raidcontroller schaffen bequem die 200Mbyte/s auf normale Festplatten. Die Frage ist ja in welcher Preislage das Projekt stattfindet. Und warum sollte man dafür auch keine SSD einsetzen das schafft man es sogar ohne Raid. Wenn du nur ein paar Sekunden speichern willst, dann muss es doch überhaupt nicht auf eine Festplatte - 8GB ram bekommst du heute schon in ein Notebook. Bei 200Mbyte/s sind das mehr als 30 sekunden. Zum speicher kann man es sogar packen, ich gehe mal davon aus das es kein gleichmäßiges Rausschen ist und sich damit recht gut packen läst (eventuell das schon im FPGA machen?). Oder gleich hier drauf http://www.alternate.de/html/product/Festplatte/OCZ/RevoDrive_X2_PCIe_SSD_100_GB/671186/?tn=HARDWARE&l1=Festplatten&l2=Solid+State+Drives&l3=PCI+Express
Lehrmann Michael schrieb: > Das bringt niemand hin - ich hab in > meinem Netzwerk noch nie gesehen, dass ein 700 MB Film in 7 Sekunden > übertragen wäre ... $ dd if=ein_film.avi of=/dev/null bs=1024 714774+0 Datensätze ein 714774+0 Datensätze aus 731928576 Bytes (732 MB) kopiert, 7,02249 s, 104 MB/s geht ... Gruß Jobst
Peter schrieb: > du darfst halt nicht von MediaMarkt technik ausgehen, die aktuellen > Raidcontroller schaffen bequem die 200Mbyte/s auf normale Festplatten. Beim normalen Anwender kann ich leider nur von Mediamarkt Technik ausgehen. Peter schrieb: > Die Frage ist ja in welcher Preislage das Projekt stattfindet. Diese Frage hatte ich bereits hinreichend beantwortet: < 150€ Peter schrieb: > Und warum > sollte man dafür auch keine SSD einsetzen das schafft man es sogar ohne > Raid. Ja einen Hardware Raid Controller kann man sich sowieso eher nicht leisten - was auf den Mainboards verbaut ist ehe ein Witz und hat mit Hardware Raid (auch wenn ein toller 'Raidcontroller' verbaut ist) rel. wenig zu tun. Geht alles auf CPU-Kosten. Peter schrieb: > Wenn du nur ein paar Sekunden speichern willst, dann muss es doch > überhaupt nicht auf eine Festplatte - 8GB ram bekommst du heute schon in > ein Notebook. Bei 200Mbyte/s sind das mehr als 30 sekunden. Auch hier das Problem - wer hat in seinem 'Labor' ein Notebook mit 8 GB Ram stehen - wobei ja Windows 32bit nicht mehr als 4 GB nutzen kann und bei Windows 64bit kommen auch nur 5 GB raus wenn du 8 GB reinsteckst. Peter schrieb: > Zum speicher kann man es sogar packen, ich gehe mal davon aus das es > kein gleichmäßiges Rausschen ist und sich damit recht gut packen läst > (eventuell das schon im FPGA machen?). 200 MB/s (!) - man könnte das sicherlich packen - wäre nur die Frage nach der Effizienz - wohl eher nicht. Was will ich denn bei 8 Bitwörtern packen? Das ist ja nicht ein Dateiformat oder so ... es sind einfach nur 8 Bitwörter, Regelmäßigkeiten sind nicht zu erwarten. Jobst M. schrieb: > Lehrmann Michael schrieb: >> Das bringt niemand hin - ich hab in >> meinem Netzwerk noch nie gesehen, dass ein 700 MB Film in 7 Sekunden >> übertragen wäre ... > > $ dd if=ein_film.avi of=/dev/null bs=1024 > 714774+0 Datensätze ein > 714774+0 Datensätze aus > 731928576 Bytes (732 MB) kopiert, 7,02249 s, 104 MB/s Respekt. Ich hab zwar keine Ahnung ob du es jetzt einem anderen Computer gesendet hast aber ich glaub dir das jetzt einfach mal =) So Zusammenfassend: Schnittstelle ist nicht - die LAN Standartschnittstelle von 100 MBit/s ist zu langsam. ACHTUNG : LAN-Schnittstelle 100 MBit / s = 1 MegaBIT pro Sekunde = 1.000.000 Bit / Sekunde 100 MByte / s = 1 MegaBYTE pro Sekunde = 8.000.000 Bit / Sekunde !!!!!!!!!!!!!!!!! Ich hoffe der Unterschied ist ersichtlich - ich bräuchte eine Schnittstelle die 200 MB/s = 1600 MBit/s überträgt! Das gibt es wohl eher nicht für den Konsumenten ... Damit hat sich das erledigt. Hat jemand Ideen / Links zu Anwendung mit DDR-Speicherriegeln? Vielen Dank
Schau mal opencores, die haben einen DDR Speicher Controller. Ansonsten den MIG von Xilinx benutzen, vielleicht wäre da ein Spartan 6 mit integriertem Memory Controller sinnvoll. 200MB/s Streaming an den PC geht schon, und zwar mit USB 3.0 oder Cabled PCI Express. Für PCIe gibts beispielsweise den PLX PEX8311 dafür oder den Gennun GN4121 zum Anschluss an einen FPGA. Oder halt internen PCIe Endpoint benutzen, aber da fehlt immer noch die DMA Engine. Wir setzen den PLX ein, der macht etwa 170MB/s zum PC dauerhaft. Aber wenn du speicherst, reicht ja auch USB 2.0 mit dem Cypress FX2 oder den neuen H-Devices von FTDI.
Christian R. schrieb: > 200MB/s Streaming an den PC > geht schon, und zwar mit USB 3.0 oder Cabled PCI Express. Für PCIe gibts > beispielsweise den PLX PEX8311 dafür oder den Gennun GN4121 zum > Anschluss an einen FPGA. Oder halt internen PCIe Endpoint benutzen, aber > da fehlt immer noch die DMA Engine. Wir setzen den PLX ein, der macht > etwa 170MB/s zum PC dauerhaft. Vielen Dank. Wie bereits öfters erwähnt kommt PCIe nicht in frage, da kein normales Notebook bzw. 'Bastelcomputer' im heimischen Labor das unterstüzt. Neben der Plug n' Play Fähigkeit kann ich höchstens USB2.0 als Standart annehmen. Des weiteren sollte auch eine Verarbeitung ohne PC-Anschluss möglich sein (VGA Schnittstelle an FPGA) - von daher suche ich jetzt definitiv nach einem Speicherbaustein. Christian R. schrieb: > Aber wenn du speicherst, reicht ja auch > USB 2.0 mit dem Cypress FX2 oder den neuen H-Devices von FTDI. Genau - an sowas hatte ich auch gedacht.
Jo, das PCIe war auch nur so ein Einwurf. Direktes Streaming geht wegen unvorhersehbarer Latenzen mit Windows/Linux ja eh nicht. USB 2.0 sollte dann völlig ausreichen. Aber ein gescheites FPGA, ein 200MS/s ADC, DDR2-SDRAM, die 8-Lagen-Platine, das ganze Analogteil und das Hühnerfutter für USB und VGA bekommst du niemals für unter 150 Euro hin. Ich bin selbst in der Hardware-Entwicklung für solche Messgeräte, daher denke ich kann ich das etwa abschätzen.
Hier mal was ich noch gefunden habe: http://www.xilinx.com/prs_rls/silicon_vir/0362ddrsdram.htm Offensichtilich gibt es von Xilinx da einiges: http://www.xilinx.com/products/design_resources/mem_corner/index.htm
Lehrmann Michael schrieb: > 200 MB/s (!) - man könnte das sicherlich packen - wäre nur die Frage > nach der Effizienz - wohl eher nicht. Was will ich denn bei 8 > Bitwörtern packen? Das ist ja nicht ein Dateiformat oder so ... es sind > einfach nur 8 Bitwörter, Regelmäßigkeiten sind nicht zu erwarten. klar sind da regelmäßigkeiten vorhanden, man könnte auch nur die differenz zum lesten wert übertragen und da kommt man eventuell schon mit 4bit aus. Teste doch mal ob es etwas bring, eventuell wird die Datenrate schon so klein das man es mit USB 2.0 übertragen kann. (Den TEst kann man ja erstmal auf einem PC machen wo man ein paar tausend messerte in eine Datei schreibt) > wobei ja Windows 32bit nicht mehr als 4 GB nutzen kann und > bei Windows 64bit kommen auch nur 5 GB raus wenn du 8 GB reinsteckst warum soll das so sein?
Peter schrieb: > Lehrmann Michael schrieb: >> 200 MB/s (!) - man könnte das sicherlich packen - wäre nur die Frage >> nach der Effizienz - wohl eher nicht. Was will ich denn bei 8 >> Bitwörtern packen? Das ist ja nicht ein Dateiformat oder so ... es sind >> einfach nur 8 Bitwörter, Regelmäßigkeiten sind nicht zu erwarten. > > klar sind da regelmäßigkeiten vorhanden, man könnte auch nur die > differenz zum lesten wert übertragen und da kommt man eventuell schon > mit 4bit aus. Teste doch mal ob es etwas bring, eventuell wird die > Datenrate schon so klein das man es mit USB 2.0 übertragen kann. (Den > TEst kann man ja erstmal auf einem PC machen wo man ein paar tausend > messerte in eine Datei schreibt) Ja das stimmt aber wenn man das weiterdenkt muss ich mich fragen, wie ich dem Empfänger mitteilen soll, dass der aktuell übertragene Frame nun beispielsweise statt 8 nur 4 Bit lang ist. Ich finde die Idee insofern gut, dass es in der Tat warscheinlich ist, dass der Wert in der Tat nicht zu heftig springt, sondern eher eine zusammenhängende Wertereihe ergibt. Und im worst-case-Bereich sind es noch immer 8 Bit Differenz. Ich komme nie und nimmer unter 8 Bit pro Messwert - oder hast du eine vernünftige Idee? Könntest du mir zeigen, wie du dir die variable Bitanzahl-Übertragung vorstellst und wie du erkennst, dass ein neuer Frame begonnen hat? Peter schrieb: >> wobei ja Windows 32bit nicht mehr als 4 GB nutzen kann und >> bei Windows 64bit kommen auch nur 5 GB raus wenn du 8 GB reinsteckst > warum soll das so sein? Probier's aus, dann wirst du's merken. Win64 braucht dann massig des Speicherplatz zur RAM-Verwaltung.
Lehrmann Michael schrieb: > Ich komme nie und nimmer unter 8 Bit pro Messwert - oder hast du eine > vernünftige Idee? Könntest du mir zeigen, wie du dir die variable > Bitanzahl-Übertragung vorstellst und wie du erkennst, dass ein neuer > Frame begonnen hat? Du muss dir ein kleines Protokoll überlegen. Du sammelst z.b. 100 Messerte stellt fest das sich bei diesen nur immer 4bit ändern. Jetzt kannst du die 100 werte in einem Packet versenden wo du einen kleinen header mitschickt wo drinsteht das jezt 100 differenzen mit je 4bit kommen. Dafür müssten mit reserve 4byte reichen. also überträgt du 50+4byte statt 100. > Peter schrieb: >>> wobei ja Windows 32bit nicht mehr als 4 GB nutzen kann und >>> bei Windows 64bit kommen auch nur 5 GB raus wenn du 8 GB reinsteckst >> warum soll das so sein? > Probier's aus, dann wirst du's merken. Win64 braucht dann massig des > Speicherplatz zur RAM-Verwaltung. ich kann leider nur von 6GB reden und da ist es kein Problem, du darst natülich nicht einfach in den Taskmanager schauen, weil windows alle möglichen dll einfach mal so in den Speicher lädt fals sie mal gebraucht werden. Das stört aber nicht weil sobalt eine Anwendung speicher bracht wird das zeug rausgeschmissen. Nach dem Motto laden dauert länger als wegmeißen. Du kannst also bei 8GB ohne Probleme 6-7GB für deine Anwendung bekommen.
In einem 150 Euro Preisrahmen wird es wohl nichts geben. Schnelle Interfaces, die 200 MB/s und die FPGA und PC verbinden, gibt es einige: S-ATA, PCI-e, 10 GBit/s Ethernet, USB3.0, IEEE 1394-2008 (Keines davon kann ein Cylone II) Alternativ könnte man DDR2 oder DDR3 Speicher verbauen (nur DDR2 ist mit dem Cyclone II möglich).
Lehrmann Michael schrieb: >> 731928576 Bytes (732 MB) kopiert, 7,02249 s, 104 MB/s > > Respekt. > Ich hab zwar keine Ahnung ob du es jetzt einem anderen Computer gesendet > hast aber ich glaub dir das jetzt einfach mal =) Lokal schaffe ich auf dem Raid ~350MB/s. (6 SATA-HDs, SW-Raid auf Core2duo) Aber stimmt schon, 100MB/s sind für 200MB/s einfach zu wenig. ;-) Und ein Packverfahren, das garantierte 50% Kompression liefert, kannst Du vergessen. Man könnte sich ein iAtom-Board (ab ca 60€) + RAM (20€) hernehmen und den Wandler als PCI-Karte ausführen. (Man kann natürlich auch jeden anderen Rechner nehmen, der schnell genug ist) Dann schnappst Du Dir den sourcecode von diesem http://www.memtest86.com/ und modifizierst ihn so, daß keine Bitmuster ins RAM geschrieben werden, sondern die Daten vom Wandler. Ist mal wieder nur eine Idee. Ob das wirklich so machbar ist, weiß ich nicht. Gruß Jobst
Wenn du im CPLD/FPGA je 4 Samples in ein 32 Bit Wort umwandelst sind das ja "nur" noch 50 Mwords/s, bei 64 Bit noch 25 MWords/s. Das sollte sich eigentlich ganz gut hinbekommen lassen. Einen FIFO-Puffer kannst du dir ggf mit einem NoBL/Streaming SRAM im bereich 256-512kx36 machen, der reicht bei der Geschwindigkeit für ein so paar ms. Und 25*10^6 Writes pro sekunde sollte in SDRAM auch noch beherrschbar sein. nen 133er Speedgrade SRAM könnte eigentlich grad so hinhaun, um @50MHz FIFO spielen zu können. BTW: Ein normales DSO hat was mie 1Mx8 pro kanal Buffer. Sicher, dass du wirklich soooo viel Buffer brauchst? Und ein normales DSO hat auch nach der Ackquisition eine kurze totzeit in der es die daten aus dem buffer rüberkopiert. Langer Rede kurzer Sinn, ein 256kx36 reicht für 1M Buffer aus. und kann fix als 32Bit-Worte ausgelesen werden @100MHz read. Die standard SRAMs für sowas gehen bis so 100/133MHz, damit ist dann theoretisch auch noch 400MSPS drin. Gruß Andreas
Peter schrieb: > Lehrmann Michael schrieb: >> Ich komme nie und nimmer unter 8 Bit pro Messwert - oder hast du eine >> vernünftige Idee? Könntest du mir zeigen, wie du dir die variable >> Bitanzahl-Übertragung vorstellst und wie du erkennst, dass ein neuer >> Frame begonnen hat? > Du muss dir ein kleines Protokoll überlegen. Du sammelst z.b. 100 > Messerte stellt fest das sich bei diesen nur immer 4bit ändern. Jetzt > kannst du die 100 werte in einem Packet versenden wo du einen kleinen > header mitschickt wo drinsteht das jezt 100 differenzen mit je 4bit > kommen. Dafür müssten mit reserve 4byte reichen. also überträgt du > 50+4byte statt 100. Okay noch besser =) Ich arbeite gerade an einer kleinen Simulation (noch in Quickbasic) - wenn's nicht reicht kommt Fortran dran. Sym schrieb: > In einem 150 Euro Preisrahmen wird es wohl nichts geben. > > Schnelle Interfaces, die 200 MB/s und die FPGA und PC verbinden, gibt es > einige: S-ATA, PCI-e, 10 GBit/s Ethernet, USB3.0, IEEE 1394-2008 (Keines > davon kann ein Cylone II) Vergesst doch mal die Computeranbindung - um DDR2 komm ich nicht rum. Eine Liveanbindung kann man später machen. Wie gesagt kommen alle diese Schnittstellen nicht in Frage weil das keine Standartvoraussetzungen für den 0-8-15 Laborcomputer sind. Maximal USB2.0 - das wird dann mit Live wohl eher nichts - außer ich reduzier die Abtastrate, etc... das wird sich später zeigen. Sym schrieb: > Alternativ könnte man DDR2 oder DDR3 Speicher verbauen (nur DDR2 ist mit > dem Cyclone II möglich). DDR2 sollte eigentlich ausreichend sein - muss schauen was der Cyclone II dadrauf schafft. Ansonsten muss ich auf einen Spartan 3A, Virtex 4-6 oder Spartan 6 ausweichen. Angeblich schafft der Spartan 3A bis zu 400 Mb/s (http://www.xilinx.com/support/documentation/application_notes/xapp458.pdf) Jobst M. schrieb: > Man könnte sich ein iAtom-Board (ab ca 60€) + RAM (20€) hernehmen und > den Wandler als PCI-Karte ausführen. (Man kann natürlich auch jeden > anderen Rechner nehmen, der schnell genug ist) > Dann schnappst Du Dir den sourcecode von diesem > http://www.memtest86.com/ und modifizierst ihn so, daß keine Bitmuster > ins RAM geschrieben werden, sondern die Daten vom Wandler. > > Ist mal wieder nur eine Idee. Ob das wirklich so machbar ist, weiß ich > nicht. puuuh vielleicht Rettunsanker - nicht das was ich mir so vorgestellt habe. Andreas Lang schrieb: > Wenn du im CPLD/FPGA je 4 Samples in ein 32 Bit Wort umwandelst sind das > ja "nur" noch 50 Mwords/s, bei 64 Bit noch 25 MWords/s. Das sollte sich > eigentlich ganz gut hinbekommen lassen. Einen FIFO-Puffer kannst du dir > ggf mit einem NoBL/Streaming SRAM im bereich 256-512kx36 machen, der > reicht bei der Geschwindigkeit für ein so paar ms. > Und 25*10^6 Writes pro sekunde sollte in SDRAM auch noch beherrschbar > sein. Auch ein gute Ansatz - werde ich mal durchrechnen und überlegen was ich damit anfangen kann. Ein fettes Dankeschön für diesen Hinweis. Andreas Lang schrieb: > BTW: Ein normales DSO hat was mie 1Mx8 pro kanal Buffer. Sicher, dass du > wirklich soooo viel Buffer brauchst? > Und ein normales DSO hat auch nach der Ackquisition eine kurze totzeit > in der es die daten aus dem buffer rüberkopiert. Jaa leider brauche ich das - so sind die Vorgaben die ich zu erfüllen habe. Selbige Argument habe ich auch vorgebracht - wurde nur leider nicht akzeptiert. Totzeit nicht akzeptabel.
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.