Hallo zusammen. Als Einarbeitung in die FPGA Welt wollte ich mir einen kleinen Logicanalyzer bauen (Standalone mit Bildschirm), Nach und nach, sodass ich dabei Vieles lernen kann (somit gehts Primär ums lernen, Sekundär ums Ergebnis). Ich hab mir da ein FPGA (Cyclone4, Testboard ist vorhanden), einen PIC24 (fürs Display und andere Dinge, z.B. Bedienung) und einen SDRAM ausgeguckt: AS4C4M16S-6TCN (http://www.mouser.com/ds/2/12/64M-AS4C4M16S-7450.pdf) Meine grobe Idee: Ich will 16bit aufnehmen. Hierzu lese ich die 16 Eingänge ins FPGA ein, packe sie zu einem Wort und speicher sie ins RAM. Das passiert durch einen Zähler durchgehend und wenn es ans Ende vom RAM kommt, fängt es wieder von vorne an. Gleichzeitig prüft das FPGA auf die Triggerbedingung (z.B. D0-D15 = 0). Sollte diese Bedingung erkannt werden, so wird, je nach dem, wo der Triggerzeitpunkt sein soll, der Zählerendwert berechnet. Also soll der Triggerzeitpunkt am Anfang sein, so ist der Zählerendwert=Adresse_Trigger - 1. Soll er in der Mitte sein, so ist der Zählerendwert=Adresse_Trigger - (N/2) - 1. Dieser wird gespeichert. Wenn der Zähler an diese Adresse kommt, schreibt er das Wort in den RAM und bricht dann ab. Zudem gibt er an den PIC (durch eine Leitung) das Signal, dass die Daten gelesen werden können. Das Quittiert der PIC, indem er ein Rücksignal (auch eine Leitung), z.B. "Go", auf Low setzt. Nun kann der PIC auf den Speicher zugreifen, wie er will. Die Adresse, die der PIC sendet, wird um den Zählerendwert erhöht und zum RAM gegeben. Somit braucht der PIC nicht zu wissen, wo der Triggerzeitpunkt im RAM liegt, er fängt einfach bei 0 an. Er weiß, dass der Trigger z.B. am Anfang oder in der Mitte ist. Ist die Anzeige der Bits 1000 Pixel breit, so kann der PIC 1000 gleichverteilte Werte lesen. Bei einem Zoom von 2x, kann der PIC 1000 Werte aus z.B. der ersten Hälfte des RAMs lesen. Wenn eine neue Messung gestartet werden soll, setzt der PIC das "Go" Bit wieder auf High und das FPGA wartet wieder auf die Triggerbedingung. Dazu hätte ich noch ein paar Fragen. 1. Ist für das Vorhaben ein SDRAM überhaupt die beste Wahl? Ich hab mal nach "normalen" SRAMs gesucht und die sind bei langsameren Zeiten und kleineren Speichergrößen deutlich teurer. Ich hab auch mal bei FlashSpeichern geguckt, aber die sind ja alle auch nur 10k bis 100k fach beschreibbar, was bei meiner Idee bestimmt nicht so viel ist, wie es klingt. Bei SDRAMs ist es aber nicht so, dass es eine maximale Schreib-/Leseanzahl gibt, oder? 2. Ist der Zugriff auf SDRAMs auch langsam möglich? Angegeben ist er ja bis 166MHz, aber was ist, wenn ich z.B. nur mit 100kHz schreiben will? Sollte doch eigentlich kein Problem sein!? Im Datenblatt steht auch "Auto Refresh and Self Refresh", was für mich bedeutet, ich muss mich nicht um das Aktualisieren der Daten kümmern. 3. Wie lege ich die Adresse an? Ich hatte gedacht, ich kann an A0-A11+B0 und B1 (was ja ansich auch als A12 und A13 gesehen werden kann) die Adresse anlegen, lege die zu schreibenen Daten an DQn, lege WR# auf Low und gebe dann den clock aus. Ist das zu simpel gedacht? Ich habe noch nie was mit SDRAMs gemacht, habe immer gehört, dass die Ansteuerung nicht ganz trivial sein soll (was gegen meinen Gedanken spricht). Außerdem verunsichert mich die Tabelle 4 auf Seite 5. In der Zeile zum Schreiben: Wieso wird da von A0-A9+A11 nur A0-A7 und A10 garnicht für die Adresse verwendet? Ich will doch aber;) 4. Ist es ein Problem, wenn ich den Datenbus zwischen FPGA und RAM "anzapfe" und zum PIC führe? So kann ich dann die Adresse vom PIC zum FPGA schicken, er rechnet den Offset drauf und gibt die Adresse weiter zum RAM. Die Daten aus dem RAM kann ich dann somit direkt vom RAM lesen und müssen nicht noch durch das FPGA geschickt werden. Kann es Probleme geben, wenn der PIC viel langsamer läuft, als die Daten vom FPGA zum RAM geschickt werden? Ich werte sie da ja nicht aus, aber nicht, dass das den PIC durcheinander bringt. Außerdem habe ich gedacht, da die Eingänge vom PIC ja hochohmig sind, liegen die Leitungen ja quasi frei und sind doch somit gute Antennen. Zudem, sollte es irgendwann in die Geschwindigkeit gehen, dass die Leiterbahnen gleich lang sein müssen, macht es da für den hochfrequenten Teil Probleme? Danke schonmal für alle (netten;) )Antworten
Du stellst dir die Sache tatsächlich zu einfach vor: die Ansteuerung von
DRAM ist aufwändiger als die Ansteuerung von SRAM. Um z.B. auf eine
bestimmte Speicherstelle zu schreiben, musst du erst die "x-Adresse" mit
einem Activate-Kommando übergeben ("die Wordline aktivieren"). Einige
Takte danach kannst du dann mit einem Write-Befehl die den y-Teil der
Adresse übergeben und auf dem Datenbus einen vollen Burst von Daten
liefern (oder das Data-Mask Signal richtig ansteuern). Wieder einige
Takte später kannst du dann die x-Adresse wieder prechargen, so dass das
DRAM wieder für einen Befehl auf einer anderen Adresse bereit ist.
Google mal nach Tutorials zur DRAM-Ansteuerung oder schau bei Micron
nach Einführungen zu dem Thema.
Die gute Nachricht ist: normalerweise musst du dich darum nicht kümmern,
sondern du setzt einen Memory-Controller im FPGA ein. Der weiß, wie er
das DRAM zu Beginn initialisieren muss, der kümmert sich um die
Aufteilung der linearen Adresse in x-Adresse und y-Adresse (und
Bank-adresse), der hält die notwendigen Timings fürs DRAM ein und der
kümmert sich auch um den Refresh.
Solche Sachen wie ein paralleler Zugriff von µC und FPGA aufs
DRAM-Interface klappen nicht. Brauchst du aber auch nicht: der µC greift
über das FPGA aufs DRAM zu und sorgt dafür, dass das DRAM richtig
betrieben wird.
Das Layout der Platine ist für moderne DRAM tatsächlich anspruchsvoll,
aber bei 100MHz SDRAM ist es noch einigermaßen harmlos: wenn die
Leitungen über einer Versorgungslage geroutet sind, nicht unnötig lang
sind, nur von einem Pin zum anderen Pin gehen (keine Verzweigungen) und
keine zu wilden Kopplungen untereinander haben, dann sollte das klappen.
Wäre ja auch zu schön gewesen. Würdest du mir dann ein SRAM empfehlen oder eher DRAM mit der Steuerung via FPGA? Ich weiß ja nicht, was ich bei einem 166MHz DRAM dann als Speicherrate übrig habe, wenn man immer so umständlich drauf zugreifen muss. Achim S. schrieb: > Solche Sachen wie ein paralleler Zugriff von µC und FPGA aufs > DRAM-Interface klappen nicht. Brauchst du aber auch nicht: der µC greift > über das FPGA aufs DRAM zu und sorgt dafür, dass das DRAM richtig > betrieben wird. Hab ich zuerst auch gedacht, nur war mein 2ter Gedanke, dass ich 16 Pins vom FPGA sparen kann (würde gerne ein gut lötbares Gehäuse, sprich xPFQ haben). Aber dann ist es eben nicht so.
Michael Skropski schrieb: > Würdest du mir dann ein SRAM empfehlen > oder eher DRAM mit der Steuerung via FPGA? Ich weiß ja nicht, was ich > bei einem 166MHz DRAM dann als Speicherrate übrig habe, wenn man immer > so umständlich drauf zugreifen muss. Die Komplexität sollte dir der Memory-Controller im FPGA abnehmen. Als Bandbreite für kontinuierliches Schreiben oder kontinuierliches Lesen bekommst du mit einem halbwegs vernünftigen Memory-Controller annähernd die 166MHz*2Byte=333MByte/s (in der Realität vielleicht ca. 280MByte/s). Und bei einer Logic-Analyzer Anwendung würde ich solche kontinuierliche Schreibzugriffe auf aufeinanderfolgende Adressen erwarten. Die Bandbreite geht dann gehörig in den Keller, wenn du Schreib- und Lesezugriffe mischst und immer nur einzelne Bytes auf nicht aufeinanderfolgenden Adressen transferierst. Dann kann der Memory-Controller keine Bursts nutzen und muss für jeden Zugriff Prechargen und neu Aktivieren, und im schlimmsten Fall geht die Speicherbandbreite vielleicht auf 1Byte/120ns=8MByte/s herunter. Ich würde dir raten erst mal zu schauen, welcher Memory-Controller für dein FPGA angeboten wird und wie du mit dessen Nutzung und seinen Application Notes klarkommst. Wenn das halbwegs läuft spricht kaum etwas gegen die Nutzung von SDRAM. SRAM hätte als Vorteil kürzere Latenzen, aber für deine Logic-Analyzer Anwendung sollten die Latenzen keine Rolle spielen. Anstelle von single data rate SDRAM könntest du auch etwas modernere DRAMs einsetzen (double data rate 1 oder double data rate 2 oder ....). Wenn der Memory-Controller das ebenfalls unterstützt hast du aktuelle Speicherchips (single data rate wird seit Jahren nicht mehr für einen Massenmarkt produziert), eine höhere Bandbreite und Speicherdichte. Mit der zunehmenden Datenrate auf dem Bus wird lediglich das Layout der Platine wieder kritischer.
Moin, auch wenn's etwas mehr kostet: Ich würde auch mal erst SRAM nehmen und klein anfangen. Mit SDRAM oder gar DDRAM hat man - auch mit hart eingebauten Controllern wie auf dem Spartan6 - beliebig viel 'Spass', mal vom Layouten abgesehen. Du könntest natürlich gleich ein fertiges FPGA-Core-Modul nehmen. Anderer Ansatz: Gleich ein DMA-fähiges uC-Board nehmen, FPGA huckepack aufpropfen, eine sinnvolle Datenkompression implementieren und die Daten per DMA ins Memory des uC-Systems streamen. Nach und nach kann man dann alles ins FPGA verschieben. Damit hat man eher Spass, weil man vom uC aus immer eine einigermassen gut funktionierende Referenz hat, gegen die man vergleichen kann. Apropos: die günstig hackbaren Rigol-Oszis mit LA machen das im Prinzip auch so. Grüsse, - Strubi
Michael Skropski schrieb: > Hallo zusammen. Als Einarbeitung in die FPGA Welt wollte ich mir einen > kleinen Logicanalyzer bauen (Standalone mit Bildschirm), Nach und nach, > sodass ich dabei Vieles lernen kann (somit gehts Primär ums lernen, > Sekundär ums Ergebnis). Ich hab mir da ein FPGA (Cyclone4, Testboard ist > vorhanden), Machs für erste ohne externen RAM, nur mit dem FPGA-internen. Das hat zwar nicht die Speichertiefe ist aber ein guter Einstieg in die FPGA-Problematik. Siehe bspw. hier: http://www.mikrocontroller.net/articles/Durchblicker Anderes Projekt, ist der bithound http://www.bastli.ethz.ch/index.php?page=BitHoundEn dafür wird aber ein extraboard an ein "Standard FPGA-kit geklemmt und externe RAM als Sample-speicher benutzt. MfG,
Von unseren chinesischen Freunden gibt es recht preisguenstige Boards mit einem Cyclone4 EP4CE6 oder EP4CE10 und 16 oder 32 MB SDRAM onboard. Dazu gibt es passende Module in Quartus2 die das auch recht einfach zugreifbar machen. Das Auslesen der Daten per Altera-JTAG ist da schon komplizierter. Viel Spass dabei.
Achim S. schrieb: > Anstelle von single data rate SDRAM könntest du auch etwas modernere > DRAMs einsetzen (double data rate 1 oder double data rate 2 oder ....). > Wenn der Memory-Controller das ebenfalls unterstützt hast du aktuelle > Speicherchips (single data rate wird seit Jahren nicht mehr für einen > Massenmarkt produziert), eine höhere Bandbreite und Speicherdichte. Mit > der zunehmenden Datenrate auf dem Bus wird lediglich das Layout der > Platine wieder kritischer. Ich habe das hier gefunden : http://www.altera.com/products/ip/iup/memory/m-alt-ddr2_sdram.html Zudem noch ein 16Mx16bit SDRAM DDR mit 200MHz. Sollte als Kompromiss in Technikstand (nicht so alt wie single data rate, aber nicht so neu wie DDR3) und Designaufwand (kritischer als bei 166MHz, aber nicht so kritisch wie 1000MHz+ bei DDR3). Strubi schrieb: > Anderer Ansatz: Gleich ein DMA-fähiges uC-Board nehmen, FPGA huckepack > aufpropfen, eine sinnvolle Datenkompression implementieren und die Daten > per DMA ins Memory des uC-Systems streamen. Klingt auch nicht schlecht, muss ich mich mal informieren. ... schrieb: > Von unseren chinesischen Freunden gibt es recht preisguenstige > Boards > mit einem Cyclone4 EP4CE6 oder EP4CE10 und 16 oder 32 MB SDRAM onboard. > > Dazu gibt es passende Module in Quartus2 die das auch recht einfach > zugreifbar machen. Habe ich sogar: Beitrag "Re: was haltet ihr von diesem Board?" Ich werde damit rumspielen und gucken, ob ich soeinen RAM-Controller implementieren kann. Damit werde ich manches testen können, bevor es an ein eigenes Board geht. Ist zwar "nur" single data rate, aber zum testen und üben sollte es reichen.
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.