Hallo, weil ich mich etwas weiterbilden möchte, möchte ich mal was mit schnellem RAM und auch schnellen ADCs anfangen. Derzeit verwende ich das Blockram im FPGA wenn es um schnelle Dinge geht, aber es gibt ja auch ZBT SRAM und DDR2/3. Da ich Anfänger bin ein paar Fragen hierzu: 1. Kann ich ZBT SRAM wie Blockram verwenden? Oder ist das deutlich komplizierter? 2. Wie kompliziert ist die Verwendung von DDR2/3? Klar würde ich den MiG verwenden, aber ich will keinen Microblaze nutzen und den RAM also selbst ansprechen, muss ich da die komplette Signalform aus dem Datenblatt des Baustein nachbasteln für einen Schreib- und Lesezugriff oder brauche ich nur eine kleine FSM die den generierten Speichercontroller füttert? Dann habe ich derzeit einen Flash ADC den ich mit 100MHz betreibe, der hat 8 Bits Auflösung und es ist eben nur einer. Jetzt gibt es da ja auch bezahlbare Platinen für z.B. FMC oder HSMC die 2x 500MSpS bei 12Bits können. Das würde mir sehr gefallen. Ich kann aber überhaupt nicht abschätzen wie schwer ist ist die Daten dann in das FPGA zu bekommen. Also muss ich den dann auch mit der Samplerate takten (was für einen Spartan eher schwer werden könnte) oder geschieht das anders? Hat das schonmal Jemand hier gemacht und kann mich beruhigen? Der grobe Plan ist: Signale abtasten mit z.B. 2x 500MSps und auf einem Monitor darstellen. Dazu etwas RAM für einige Kilo- bis Megapunkte Speicher und vor allem will ich dieses "Digital Phosphor" nachbauen. Das scheint mir nicht soooo schwer. Ich brauche also Bildspeicher, 1024 x 512Pixel x 8Bit Farbtiefe = 512kBytes. Das hat z.B. der Artix 7 XC7A200T schon drinnen, der hat sogar 1,425MBytes BRAM. Aber wenn DDR3 "einfach" ist, dann wäre das wohl die bessere Option. Mir geht es hier also darum sowas abzuschätzen. Ja ich will ein Oszi basteln mit >= 500MSpS, 2 Kanälen und gerne auch Logic Analyzer. Wenn Jemand schon sowas plant oder auch bauen will würde mich das auch sehr interessieren. Eine Platine die genau dafür zugeschnitten ist, also genau die passende Ausstattung besitzt wäre auch sehr fein. Vielen Dank!
:
Bearbeitet durch User
Also DDR2/3 RAM am MIG des Spartan6 anzusteuern ist relativ einfach, im Datenblatt des MIG gibt es die Timingdiagramme, um das "externe" Timing zum DDR-Baustein kuemmert er sich dann komplett selbst, incl Refreshzyklen. mann muss halt eine kleine FSM aufsetzen, um immer nach 64 Datenwoertern einen Schreibbefehl zu senden und die Adresse zu erhöhen. Er arbeitet intern mit einem 64word tiefen Fifo, um den DDR-RAM im Burst ansprechen zu koennen und so moeglichst hohen Durchsartz zu ereichen. Zum Takt des DAC: das kommt auf den DAC an, aber 500MHz an den IOs schafft ein Spartan 6 locker (max ~1GHz), intern arbeitet man dann mit groesseren Datenbreiten. Abarbeitung von mehreren Samples gleichzeitig, dafuer niedrigerer Takt. Am besten waere es, wenn du Stueck fuer Stueck arbeitest, also erst einmal die Bildschirmausgabe, mit Mustern oder fertigen Bildern aus dem externen RAM, diese kannst du z.B. von einem Microblaze dort hin kopieren lassen. Dieser wird spaeter bestimmt auch anderweitig Verwendung finden. (der Microblaze MCS ist kostenlos im WebPack enthalten, ist eine etwas abgespeckte Variante).
Hallo, vielen Dank! Also Bildschirmausgabe habe ich schon, also aufgenommene Daten aus dem BlockRAM anzeigen, mit scrollen und allem. Mir geht es wirklich darum jetzt schneller zu werden, also schneller abzutasten und auch mehr zu speichern, gerade für "Digital Phosphor". Testen kann ich das jetzt leider noch nicht, weil dieser Thread dazu gedacht ist, dass ich mich danach besser entscheiden kann welche Hardware ich kaufen sollte, also lieber dickeren FPGA mit mehr BRAM oder lieber schnelles externes RAM und wenn ja welches? Mein aktueller Spartan 3 kann leider noch kein Bild mit "Farbtiefe" speichern weil der zu klein ist. Für 32kSamples reicht es jedoch.
500MS/s ist schon eine Marke. Spartan 6 kann intern so etwa 100...125MHz abarbeiten, ohne dass man viel frickeln und optimieren muss. An den ISERDES gehen bis zu 1080MBit/s aber das wird dann halt deserialisiert. Muss man halt sehen wie man das wegbekommt. 500MHz direkt geht eigentlich nur mit der Virtex Klasse, dein Spartan 3 macht da keinesfalls mit. Es gibt auch ADCs, die interne Sample-FIFOs haben. Die kannst du dann ganz bequem auslesen. Oder 4 ADCs mit 90° verschobenen Takten ansteuern, aber das ist auch eine haarige Sache.
ich wuerde einen mit externem RAM nehmen, denn Speicher kann man nie genug haben. Der interne wird zum schnellen Zwischenspeichern und als Puffer fuer den externen verwendet.
Hallo Christian, hast Du da irgendwelche Empfehlungen an ADCs? >= 10Bit, >= 500MHz, 2 Kanäle und preislich unter 400€ wäre fein. Und natürlich irgendwie so dass man die an "übliche" FPGA Boards anbekommt. Klar den Spartan 3 werde ich dafür nicht verwenden, ein Artix 7 oder Spartan 6 wäre ne Option oder eben was von Altera. Alles zusammen, also FPGA Board + ADC Karte sollten halt unter so 800€ liegen. Lieber noch weiter drunter. Weil es ein Oszi werden soll muss auch Bildausgabe und Bedienelemente irgendwie entweder vorhanden sein oder angeschlossen werden können.
Üblicherweise sind auf den Spartan6 Boards, die man so kaufen kann Chips mit Speedgrade 2 verbaut und die gehen an den LVDS Eingängen nur bis 950 Mb/s. Dickes internes Ram wird teuer und du landest sehr schnell bei Chips, die nicht mehr vom kostenlosen Webpack unterstützt werden. Von daher sind externe DDR Rams billiger. Sagen wir mal ... Für 4 A/D Kanäle mit je 8 Bit und parallel dazu 32 Kanäle Logic Analyzer würde sich theoretisch ein Spartan6 LX75 mit 4 x 16 Bit breiten DDR3 Rams anbieten. Aber so ein Board habe ich bisher noch nicht gesehen. Ich würde mir aber die Fummelei mit dem Microblaze sparen und dann eher an den Zynq denken. Da hast du zusätzlich zur FPGA 2 Arm9 Cores und Standard Schnittstellen ohne Ende. z.B: High Speed USB OTG zum Abspeichern auf Sticks bei Standalone Betrieb oder zur Schnellen Datenübertragung auf einen PC. Ethernet geht auch. Und auch die ganzen Schalter, Drehencoder, LED, Relais, LCD-Display usw. lassen sich von der Arm-Cores viel besser bedienen.
Hallo, also eigentlich will ich das nur auf den Monitor bringen, Netzwerk und so habe ich eigentlich nicht vor. Also 2 Kanäle und schneller RAM wären mir wichtig. Wie sieht es mit ZBT SRAM aus? Ist der einfach zu benutzen? Oder so Dual-Port RAMs, habt ihr sowas schonmal gemacht? Man will ja gleichzeitig Daten aufnehmen und anzeigen. Also das soll sich möglichst wenig in die Quere kommen.
Hm, in dem Preisrahmen wirds schwierig, alleine der "kleine" Artix 7-100T kostet schon über 100€. FMC Zusatzkarten gibts da wohl, die sind aber alle nicht unbedingt darauf ausgelegt, mit solchen Tricks wie den ISERDES angesprochen zu werden. Geht aber eventuell doch. Problem beim Spartan 6 ist, dass das Clocking für die ISERDES sehr beschränkt ist (halbe IO Bank), und die FMC Pins meist ziemlich wild über mehrere Bänke verteilt sind. Dann passt der ADC nicht an den FPGA. DDR-RAM ist ja meist drauf, das SP605 hat DVI Ausgang und kostet ca. 500 Dollar. Hat einen LX45T drauf mit Speedgrade 3. Aber für 800€ incl. ADC wirds sicher schwer. Dual port RAM ist doch völlig unnötig, zwischen den Aktualisierungen des Bilschirms hat du doch alle Zeit der Welt, deinen Schnappschuss vom ADC abzuholen. Im Vergleich zu den 60 Hz sind doch die paar µs die du mit so einem schnellen ADC bei voller Geschwindigkeit speichern kannst extrem gering. Aber ZBT RAM wird heute kaum noch auf den Boards verbaut, da kenn ich nur die ollen Virtex 4 Boards. Da war interner BRAM halt teuer. Aber der DDR RAM ist nicht breit genug...verzwickt. Warum wohl kostet der extra Sample-Speicher bei schnellen DSOs nur solche Unmengen? Genau deswegen...
:
Bearbeitet durch User
Hm ja. Naja also wenn ich mit 500MSpS aufnehme bei sagen wir 8 Bits (weil es einfacher ist) dann bekomme ich 500MBytes/s rein. Wenn ich jetzt aber dieses "Digital Phosphor" oder "Intensity-grading" machen will, dann muss ich viele Aufnahmen überlagern. Selbst wenn ich da einen Bildspeicher von nur 0.5MBytes verwende, also 1024x512 Pixel (ok das sind 9Bits Auflösung) mal 8 Bit "Farbtiefe" Dann kann ich bei der "Farbtiefe" maximal 255 unterschiedliche helle Signalverläufe überlagern. Um die aber aufzunehmen braucht es auch Zeit, also 255*Samplezahl/Samplerate. Hier für ein Bild mit 1024 Pixeln in x-Richtung wären das schon 255*1024/500M = 0.5 Sekunden. Und ich will doch mehr wie 2 Frames je Sekunde anzeigen können. Also entweder ich nehme immer auf und schreibe aber nur dort ins VideoRAM wo gerade nicht gelesen wird oder ich schreibe immer und lese nur dort wo gerade nicht geschrieben wird oder ich verwende 2 VideoRAMs. also 2x512KBytes. Dann kann ich in eines kontinuierlich schreiben und das dann im Videoblank ins andere kopieren und zwar so, dass immer nur da kopiert wird wo gerade nicht geschrieben wird. Dazu brauche ich also schon 1MByte echt schnelles RAM. Für eine Aufnahme mit mehreren MPunkten zum Scrollen und so könnte man noch zusätzliches schnelles RAM verwenden, da muss man ja nicht gleichzeitig lesen und schreiben. Auch interessant wird der x-y-Modus mit "Intensity-grading". Da könnte man ein Bild nehmen mit 512x512 Pixeln und wieder 8Bit Tiefe und als Schreibadresse eben beide ADC Werte nehmen. Aber wenn man das live will mit hoher Framerate wird man kaum um entweder extrem schnelles oder mehrere RAMs herumkommen. Der Artix 7 200T hat das, der hat mehr als 1MByte drinnen und das Board bei ZTEX http://shop.ztex.de/product_info.php?products_id=76 ist bezahlbar. Leider habe ich keinen Plan ob ich das mit diesen "schlichten" Anschlussleisten mit schnellen ADCs verheiraten kann oder ob ich doch was teureres brauche.
Falls du nicht unbedingt auf Xilinx fixiert bist: von TI gibt's zu fast allen ADCs auch passende Testboards, leider mit TI-spezifischem Connector. Aber dafür hat TI einen Adapter auf HSMC im Angebot (HSMC: Standard-Connector auf Altera-Boards). Damit sind dann 1-4 Kanal-Systeme mit 500MHz möglich.
Altera ist schon auch ok, aber da bräuchte ich auch ein FPGA mit viel BRAM oder schnellem externen RAM. Ich hab da leider keinen Überblick über die Boards, das neue Terasic Cyclone GX http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830&PartNo=2 hat ja etwas BRAM und HSMC. Aber leider kein halbes MByte und schon gar nicht das Doppelte wie der Artix. Gibt es was vergleichbares zum Artix zu ähnlichen Preisen? Bei eBay.com gibt es günstige Stratix Boards mit HSMC. Die haben auch schnelles RAM aber ist wohl nur mit dem teuren Quartus zu verwenden.
Das mit FPGA und Megabytes internem RAM solltest du lieber vergessen: Um das interne RAM komplett(!) und schnell genug anzusteuern müsstest du FPGA-intern viel Aufwand betreiben. Die internen RAMs sind nur für lokale Geschichten gut. Von Altera bzw. von Xilinx kriegst du DDR-SDRAM-Controller, die sind dann schnell genug, und dass bei etlichen MegBytes. Stratix: es werden nur wenige Stratixe (I bis III, idR nur kleinere) in den alten+freien Quartus-Versionen unterstützt. 500MHz IO sind auch bei aktuellen Cyclons möglich.
Ich scheue etwas den DDR RAM weil ich vermute, dass das doch nicht sooo einfach ist wie BRAM. Also z.B. wenn ich da ein Vollbild speichern will, dann will ich da relativ zufällig an einzelne Punkte etwas schreiben, also nicht mehrere zusammenhängende Bytes am Stück an aufeinanderfolgende Stellen sondern eben irgendwo. Mit BRAM geht sowas ganz einfach, wie ist das bei DDR3? Wie groß ist der Aufwand den ich da treiben müsste? Ich will ja von einer zufälligen Stelle im Bild den Farbwert lesen, was dazuaddieren und dann wieder dorthin schreiben, und das an 500M Stellen je Sekunde. Am Besten auch das noch doppelt mit 2 ADCs. Klar kann man das langsamer machen, also z.B. immer ein paar Kilopunkte aufnehmen, im BRAM puffern und die dann ins Bild einbauen. Aber dann bekommt man eben Totzeit, also Zeit in der das Signal nicht abgetastet wird oder zwar abgetastet wird, das aber nicht im Bild landet am Ende. Mit BRAM könnte man das relativ einfach umgehen.
Hans-Georg Lehnard schrieb: > Ich würde mir aber die Fummelei mit dem Microblaze sparen und dann eher > an den Zynq denken. Insb. das microzedboard ist hier sehr interssant: http://www.microzed.org/product/microzed Das hat 1GB DDR3-Ram mit drauf. nur hängt dieser recht direkt am ARM und nur über den Amba-bus am FPGA. Weiß da wer, wie hohe Datenraten man über diesen Bus erreichen kann?
Christian R. schrieb: > Warum wohl kostet > der extra Sample-Speicher bei schnellen DSOs nur solche Unmengen? Genau > deswegen... So teuer kann es nicht sein. Als wir letztens ein Speicherupgrade gemacht haben, wurde uns nur ein Lizenzschlüssel zugeschickt. Der zusätzliche Samplespeicher ist also beim Kauf schon dabei... Duke
beim Spartan6 hast du bis zu vier Hardcore-memorycontroller on board, schau mal in die UG388 ( http://www.xilinx.com/support/documentation/user_guides/ug388.pdf ) was die so eine transferrate erreichen. dabei Checken ob die Webpack-ISE auch die S6-varianten mit mit (mehreren) mem-controller unterstützt. Flüchtig geschaut finde ich was von DDR3 mit 400MHz, es könnten also 800 MS möglich sein. Andere FPGA#s haben diese hardcore-memcontroller leider nicht, da muss man sich mit MIG und viel Erfahrungen einen schnellen memorycontroller selbst generieren. Das wird schnell schwieriger als es klingt, deshalb schätze ich die S6-memorycontroller sehr. Falls der mem zu langsam ist kann man mit parallen datenbussen reserven erschließen. Also bspw kommen 8 bit mit 200 MS/s rein dann sorttiert man diese entweder auf 4 SRAMs a 8 bit @50 MHZ, oder auf einen SRAM mit 32 bit. MfG
Also nur um das klarzuszellen, ich will kein eigenes Board bauen. Wenn das Jemand kann und machen will gerne, wenn es in meinem Preisrahmen liegt kaufe ich vielleicht eines. Microblaze oder ARM brauche ich auch nicht. Klar wäre vielleicht ganz fein für die GUI am Ende aber sonst? Ich will kein USB oder Ethernet oder so sondern wirklich nur einen Monitor anschließen. Derzeit sieht für mich eine Lösung mit BRAM am besten aus. Also zumindest für den Bildspeicher. DDR3 als Samplespeicher zusätzlich wäre auch fein aber es muss für mich nicht viel sein. Wenige Kilosamples je Kanal würden mir reichen. Also so 128k Speicher je Kanal. Das würde gut noch ein den Artix passen, vielleicht sogar mehr. Glaubt ihr man kann das ZTEX Artix 200T Board irgendwie mit schnellen ADCs verbinden, also funktionsfähig?
Gustl Buheitel schrieb: > Glaubt ihr man kann das ZTEX Artix 200T Board irgendwie mit schnellen > ADCs verbinden, also funktionsfähig? Schnelle ADC's heistt meist LVDS, auf die schnelle sehe ich bei ZTEX nur die pfostenleiste und bin da skeptisch. Für das Atlys habe ich ein ähnliches Projekt (AD-Wandler an FPGA-Board anschliessen) gefunden: http://xellers.wordpress.com/2013/12/14/6-111-or-how-i-learned-to-stop-worrying-and-love-the-fpga/ Die AD-Wandler Platine ist allerdings selbst gemacht. MfG,
Fpga Kuechle schrieb: > Schnelle ADC's heistt meist LVDS, auf die schnelle sehe ich bei ZTEX nur > die pfostenleiste und bin da skeptisch. siehe auch: www.mikrocontroller.net/topic/323654
Ja gut ich brauche ja keine MGTs. Kann man nicht auch normale IOs also je zwei zu einem LVDS Pärchen verbinden also als solches nutzen? Wenn ich da irgendwie parallel die Daten mit 500MHz je Pin oder je Pin Pärchen reinbekomme würde mir das genügen. @Fpga Kuechle: Das Atlys ADC Projekt habe ich schon gesehen, Ich habe an einem Nexys2 einen ADC dran der auch fein mit 100MHz abtastet, ganz ohne LVDS und tolles Layout. Ich habe hier auch ein Celoxica RC10 mit 2x75MHz ADCs die sogar je 10 Bits haben. Leider ist da aber ausser dem BRAM im Spartan3 nix an zusätzlichem RAM verbaut. Ich würde gerne etwas basteln, vor allem in VHDL und eben gerne irgendwie "Intensity Grading" und einen X-Y-Modus einbauen. Dazu brauche ich in beiden Fällen RAM um ein komplettes Bild zu speichern. BRAM würde mir genügen. Natürlich könnte ich weiterhin einen oder dann zwei 100MHz 8Bit ADCs verwenden, aber wieso nicht was schnelleres? 200MHz und 8Bits sind auch günstig und ohne LVDS zu haben, aber 8 Bit sind mir etwas wenig, vor allem weil ich eine Auflösung von 1024x768 Pixeln verwenden möchte. Also es müssen ja keine 12 oder 14 Bits sein, aber 10 will ich schon, da kann man das kleinste weglassen und bekommt schöne 512 Pixel in der Vertikalen. Hier das also dieser Thread dient für mich dazu, mich zu entscheiden was ich am geeignetsten kaufe, also lieber einen dicken FPGA mit viel BRAM weil das einfach ist, oder lieber was mit DDR3, da kann ich leider nicht abschätzen wie einfach oder schwer das ist wenn man zufällige Zugriffe hat. Vielleicht kennt Jemand auch ein Board mit schnellem DualPort SRAM oder so, da gibt es ja einiges exotisches wie auch ZBT SRAM. Und wenn ich bei meiner aktuellen Lieblingslösung mit dem BRAM bleibe, dann bräuchte ich ein preiswertes Board mit einem solchen FPGA und ein passendes Board mit ADC. Zur Not wird es dann vielleicht dieses ZTEX Board (das leider weder HSMC noch FMC hat) und 2x 200MHz 10Bit Flash ADC. Die werden da schon irgendwie anschließbar sein. So 500MHz wären halt schöner ...
Gustl Buheitel schrieb: > Ich will ja von einer zufälligen Stelle im Bild den Farbwert lesen, was > dazuaddieren und dann wieder dorthin schreiben, und das an 500M Stellen > je Sekunde. Es ist schon so wie du vermutest, für zufällige Zugriffe ist ein einfaches SRAM (wie z. B. ein internes BRAM) gut geeignet und schnell. Es gibt auch externe SRAM Chips die sich für solche Projekte eignen. Ein DDR-RAM kann man auch benutzen um nur einzelne Speicherzellen zu lesen/schreiben. Schnell ist das aber überhauptnicht. Mein derzeigitges rudimentäres Verständnis von Intensity Grading lässt mich aber darauf schliessen, dass deine Speicherzugriffe alles andere als Zufällig sind, sondern stark sequentiell. (Du bearbeitest ja deinen Signalspeicher immer von links nach rechts, so wie der Kathodenstrahl früher auch). XY-Modus mit Grading ist dann wohl komplexer. Vielleicht würde es mit XY so klappen: Du brauchst 5 Speicher - Video Speicher - 2 Sample Speicher für ADC Werte (als SRAM/BRAM für zufälligen Zugriff) - 2 Speicher für das Grading (DDR-RAM) Der Video- und Grading Speicher ist gleich strukturiert, entspricht also dem Bildschirminhalt. Die zwei Grading Speicher wechseln jeweils ab, einer ist Quelle (alt) und der andere ist die Senke (neu). Der ADC liest konstant Werte ein in den neuen Sample Speicher, immer wenn er den Speicher ein mal vollgeschrieben hat wechselt er den Sample Speicher und startet einen neuen Zyklus (Damit ein Sample Speicher frei gelesen werden kann): Der alte Grading Speicher wird sequentiell ausgelesen, die alten Werte werden zur Ausgabe in den Videospeicher geschrieben, die alten Werte werden zusammen mit dem Sample Speicher verrechnet (Den Sample Speicher kann man ja schnell zufällig Adressieren) und die Ergebnisse werden sequentiell im neuen Grading Speicher gespeichert. Das ganze läuft synchron zum ADC (also von der Datenmenge her), das Grading ist fertig, wenn der ADC wieder einen Sample Speicher gefüllt hat, dann beginnt der Zyklus von vorne. So wie ich mich kenne habe ich wahrscheinlich habe ich etwas wichtiges Vergessen und es funktioniert so nicht :-) Was ich damit sagen möchte: Du musst dein Problem so zurechtbiegen, damit es sich mit DDR-RAM gut lösen lässt.
Naja also ich weiß nicht ob der Speicher so squentiell gelesen/geschrieben werden kann. Also das ist ja quasi "3D" also in x-Richtung habe ich die Zeit, in x-Richtung den Wert und in z-Richtung den Inhalt, also die "Farbe". Wie ich mir das so vorstelle ist, dass da jetzt ein Sample reinkommt, dann wird in dem Speicher an die x-y-Stelle gegangen, da der Farbwert gelesen, verändert und dort wieder hingeschrieben. Das einzige was da sequenziell ist sind die x-Werte. Wenn ich den Speicher also so aufbaue, die Adresse die x-y-Position ist, und der Inhalt dort die Farbe dann sähe das in etwa so aus: 18 ... 9 8 ... 0 sind die Bits der Adresse, die oberen 10 sind die x-Richtung, die ändern sich schön nacheinander, aber dahinter ist es dann schon vorbei. Weil die y-Richtung ist ja beliebig durch das Signal vorgegeben, das kann sich langsam kontinuierlich ändern, kann aber auch große Sprünge machen. Für mich sieht da DDR3 einigermaßen ungeeignet aus, ausser man macht da viele Tricks die ich nicht kenne oder nutzt viele RAMs parallel oder so, aber eine günstige Lösung mit einem DDR3 Stein wird das aus meiner Sicht erstmal nicht leisten können. Also Deine Idee mit den 2 Speichern ist schon nicht schlecht, ich versuche das Problem nochmal zu beschreiben: Von den 1024x512 Pixeln im Bild müssen ja bei einem "Durchlauf" von 1024 Samples nicht alle 0,5MPixel gelesen und geschrieben werden, sondern eben nur 1024 Pixel - dafür diese aber zufällig, weil die eben gerade auf dem Signalverlauf liegen. Man könnte aber auch immer alle lesen, vielleicht muss man das ja auch weil man die die nicht auf dem Signalverlauf liegen etwas abdunkeln möchte. Das macht es aber eher komplizierter, also in der Zeit in der 1 neues Sample reinkommt hat man ja einen x-Wert. Den y-Wert entscheidet das Sample. Diese x-y-Stelle muss man lesen, verändern und speichern. UND vor allem muss man alle anderen Stellen die auf dieser y-Spalte liegen, (also das ist die Bildpixelspalte mit dem gleichen x-Wert) auch lesen, verändern (abdunkeln) und schreiben. Wenn jetzt das Sample kommt muss man also nicht nur 1Byte lesen und schreiben, sondern sogar 512, das sind bei 500MSpS dann 500M*0.5kBytes = 256GBytes/s (!). Na das ist schon ne andere Hausnummer :-D Aber das hybsche daran: Es ist machbar! Man könnte jede Bildzeile also eigenes BRAM schreiben, dann hat man da also 512 BRAMs aus denen man parallel lesen kann, also wirklich bei 500MHz jeweils 1Byte/Takt. Aber das will man ja auch wieder schreiben. Gleichzeitig lesen und schreiben ginge mit Dualport, die Stellen wären für den Lese- und den Schreibzugriff auch unterschiedlich, denn es wird gelesen, verändert, geschrieben, also 2 Takte später wird dort geschrieben wo zuerst gelesen wurde. DDR3 wäre damit dann raus und irgendwie sehe ich jetzt auch wieso Oszis so verdamt teuer sind. Habe ich was übersehen/falsch verstanden? Edit: Die 256GBytes/s sind nur lesend, das muss auch noch geschrieben werden :-D
:
Bearbeitet durch User
Gustl Buheitel schrieb: > 18 ... 9 8 ... 0 sind die Bits der Adresse, die oberen 10 sind die > x-Richtung, die ändern sich schön nacheinander, aber dahinter ist es > dann schon vorbei. Genau darum habe ich ja vorgeschlagen, das ganze umzudrehen. Gustl Buheitel schrieb: > DDR3 wäre damit dann raus und irgendwie sehe ich jetzt auch wieso Oszis > so verdamt teuer sind. Habe ich was übersehen/falsch verstanden? Irgendwas muss da noch falsch sein, mein TDS3012B Baujahr 2002 kann auch Digital-Phosphor und das Ding hat sicher keinen Supercomputer Speicher drin :-) (Tek hat das zusammen mit National damals als ASIC gebaut).
Ein "Nachleuchten" kann man auch einfacher haben, klar. Also ich kann auch dauerhaft in viele kleine Speicher aufnehmen, also: Man nehmen sagen wir 64KBytes BRAM eingeteilt in 64 einzelne 1KByte BRAMs. Jetzt kommt der erste Trigger, der erste BRAM wird gefüllt, dann der nächste Trigger, der zweite wird gefüllt ... jeder einzelne mit 1024 ADC Werten. Und dann Speichert man eben kein komplettes Bild, sondern fragt parallel alle hier 64 Speicher ab wenn man bei einem Pixel ist ob da ein Bit gesetzt ist oder nicht. Bei dem "neuesten" also dem als letztes gefüllten RAM wird das wenn da ein Bit in dem Pixel gesetzt ist dieses also volle Heligkeit ausgegeben, bei weiter in der Vergangenheit gelegenen RAMs dann etwas dunkler. Man geht also wie der normale VGA Monitor sein RAM zeilenweise ab, ich mache das auch so, aber eben nur mit einem RAM. Die RAM Adresse ist die x-Position in der Zeile und dann wird eben verglichen ob der Inhalt des RAMs an dieser Stelle der Zeilennummer, also y-Position entspricht, wenn ja, wird das Pixel hell, wenn nicht bleibt es dunkel. Das könnte man auch mit mehreren kleinen RAMs hintereinander (kann man sich so vorstellen als lägen diese Signal-Datenreihen hintereinander/übereinander) parallel machen und die ältesten werden eben abgedunkelt ausgegeben. Ja, könnte ich auch machen, braucht vor allem weniger Speicher weil man nur da Speichert wo auch Information ist und nicht den ganzen leeren Bereich im Bild. Mir ist noch nicht klar wie das da mit schreiben und lesen geht, also während ich lese ändert sich ja die Reihenfolge der RAMs, weil alte wieder neu geschrieben werden und dann "neu" sind. Man sollte da vielleicht auch unterscheiden, also dieses "Nachleuchten" beachtet ob Werte alt oder neu sind, "Intensity Grading" ist aber vermutlich eher, dass Orte (x-y-Punkte auf dem Monitor) an denen die Signalkurve oft vorbeikommt heller werden und andere nicht. Bei den hintereinander/übereinander gelegten RAMs wie oben wäre das dann so, dass alle gleich bewertet werden und die Pixelhelligkeit dann die Summe ist. Wenn ein Pixel nur in einem RAM vorkommt, ist es dunkler wie wenn es in vielen RAMs vorkommt. Man ist das schwer sich da für was zu entscheiden^^ vielleicht reicht ja doch der olle Spartan3.
So, also ja vielleicht sollte man da wirklich unterscheiden zwischen Nachleuchten und einem "Intensity grading" oder "Heatmap". Das Nachleuchten kann man ja auch komplett nur für die Ausgabe machen, also für den Monitor. Sagen wir ich betreibe den mit 60Hz und will eine Sekunde nachleuchten. Dann Baue ich einen FIFO mit 60 Signaldatenreihen wie oben, also einen Stapel aus 60 Signalverläufen und nehme mit jedem Monitorframe das unterste weg und lege ein neues oben drauf. Das oberste ist am hellsten, das unterste am dunkelsten. Da bekäme man dann z.B. 60 Signalverläufe. Und wie ist das, also mich interessiert die Totzeit, ich möchte, dass möchlichst die ganze Zeit abgetastet wird und auch jedes Sample auf den Monitor kommt. Das wäre mit diesem Nachleuchten nicht der Fall, ausser ich schaffe es in jedem der 60 Bilder die ja maximal 1/60s Samplezeit abdecken auch die kompletten Daten dieser Zeit darzustellen, also bei 500MSpS wären das dann 500M*1/60 = 8,33MPunkte. Das ist schon ziemlich viel für ein Display das nur 1024 Punkte in x-Richtung darstellen kann. Klar man kann Punkte zusammenfassen oder den Sampletakt ändern, ... Mit der "Heatmap" oder "Intensity Grading" verliert man die Zeit glaube ich nicht, man verliert nur die Zeit zwischen einem Durchlauf und dem nächsten Trigger (gut das ist auch viel aber vermutlich weniger). Man kann da immer aufnehmen, der Trigger feuert, die Signalform wird ins Bild geschrieben, nach den 1024 Werten wird kurz auf den nächsten Trigger gewartet und es geht wieder los. Jedes Bild am Monitor enthält dann nicht nur einen Schnappschuss der einmal alle 1/60s gemacht wurde, sondern fast alle Daten die während der 1/60s aufgenommen wurde. Und bei 1/60s kann bei 500MSpS und 1024 Werten in x-Richtung maximal 500M/1024 = 488.000 Mal das Bild beschrieben werden (gut da fehlt jetzt die Totzeit wenn auf den Trigger gewartet wird, selbst wenn das 50% der Zeit sind sind das immernoch massig Signalverläufe). Es kann also ein ziemlich fein abgestuftes Bild aus sehr vielen Signalverläufen entstehen und wenn nur ganz selten ein andersartiger Verlauf dabei ist, ist die Wahrscheinlichkeit deutlich höher, dass auch dieser abgebildet wird. Das ist jetzt halt "Nachleuchten" das auch mit wenig RAM oder DDR3 RAM geht vs. "Intensity grading" mit extrem hoher Datenrate und vermutlich zwingend viel BRAM.
Noch ne Frage zu BRAM und Bandbreite/Datenrate. Der XC7A200T hat 365 36kb BRAMs. Jedes davon kann man ja mit 72Bit Breite ansprechen (maximal). Da ist dann noch Parity dabei vermutlich also sagen wir mal 64Bit Breite je BRAM. Das sind dann zusammen 64*365 = 23.360Bits. Und wenn man das jetzt mit 500MHz taktet bekommt man 23.360*500M = 11.680.000MBits/s = 1.460.000MBytes/s = 1,46TBytes/s Kann man das wirklich nutzen? Das ist schon extrem viel an Datenrate aber halt auch richtig super wenn das geht. Oder wo ist der Fehler? Klar das ist dann nichtmehr DualPort bei den 72Bits, aber trotzdem sehr fein.
Das Problem ist wohl wie Du ALLE BRAMs gleichzeitig (und sinnvoll) so schnell mit Daten befüllen willst. Die sind ja über den ganzen Chip verteilt und nicht ein gemeinsamer Speicherblock...
Klar, das ist ja auch gut so. Also angenommen ich mache für jede Bildzeile einen RAM. Also mit 8Bit Farbtiefe und 1024 Pixeln in x-Richtung wären das 1kByte/RAM. (Ja ich weiß, die kleinen RAMs haben 2KBytes aber erstmal egal.) Da kommt dann also das abgetastete Signal Sample für Sample. Jetzt hat das Sample für die x-Position X und das hat gerade den Wert Y. Dann lese ich aus allen (!) RAMs den aktuellen Wert für das Pixel X (jedes RAM ist ja eine Zeile). Und dann entscheide ich: Wenn der RAM die Zeile Y darstellt, also die Zeile mit dem aktuellen Sample-Wert, dann wird der Inhalt erhöht (also irgendwas addiert um das Pixel heller zu machen), und bei allen anderen RAMs, die also nicht der Zeile mit dem aktuellen Sample-Wert entsprechen, wird der Inhalt erniedrigt (subtrahiert oder sowas um das Pixel abzudunkeln). Es wird also bei jedem Sample immer von allen RAMs gelesen, dann entweder heller oder dunkler gemacht und dann wieder geschrieben.
Hallo, kann man bei Xilinx in diese 18kb BRAMs auch wirklich 18kb speichern, also 9 Bit Breite und 2048 Tiefe speichern? Oder ist der Parity Bereich wirklich nur für Parity da?
:
Bearbeitet durch User
Nee, der ist frei verfügbar. Ich nutze den auch immer mal für Zusatz-Infos, die ich durch die FIFOs durchschieben muss. Man kriegt nur beim Bitgen dann eine Info, dass man die Parity Bits nicht als Parity benutzt.
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.