Hallo, bisher habe ich mit ADCs gespielt deren Sampletakt geringer als der maximal erreichbare Takt im FPGA war. Ich konnte im FPGA also schön bequem z. B. gleitende Mittelwerte oder Peakerkennung machen. Jetzt möchte ich aber sehr kurze Impulse erkennen, so grob 20 ns lang, und daher schneller abtasten. Ich dachte an 500 MSps oder mehr. Die Auflösung ist relativ egal, daher werde ich 8 Bits verwenden. Ich dachte an den AD9484BCPZ-500 (500 MSps, 500 MHz LVDS SDR) oder den HMCAD1511 (1 GSps, 500 MHz DDR LVDS). Ich bekomme also 500 MByte/s oder mehr ins FPGA, kann die Logik aber vermutlich nicht mit 500 MHz takten. Möchte aber weiterhin Peakerkennung und gleitenden Mittelwert oder so rechnen. Ich könnte natürlich mal ein schnelleres FPGA kaufen und verlöten. Aber ob das FPGA die Rechnerei schafft sehe ich ja erst wenn ich den Code habe. Den habe ich noch nicht und weiß auch noch gar nicht wie der final seien wird, das kann sich also auch verändern. Ich bin also auf der Suche nach so üblichen Herangehensweisen für die parallele Verarbeitung von vielen Daten.
:
Bearbeitet durch User
Du musst deinen Datenstrom eifnach auch parallelisieren. Z.B. mit zwei Ringbuffern und immer die t_2n Samples werden in einen und die t_2n+1 Samples in den anderen Buffer geschrieben. Da kann ich nur den Einsatz von Ringbuffern empfehlen. Dann kommt es darauf an was du mit den Daten machen moechtest. In der Regel brauchst du dann eine Trigger Bedingung welche das weitere Processing anstoesst, z.B. im einfachsten Fall einfach einen gewissen Schwellwert deiner Pulse. Dein Processing hat dann prinzipiell alle Zeit der Welt, erhoeht halt die Totzeit zwischen zwei eintreffenden Pulsen. Das Prinzip wird in den ganzen Teilchendetektoren angewandt, wie sie z.B. am CERN zu finden sind. Riesige FPGA Arrays schaufeln die ADC Daten an eine zentrale Trigger Einheit, welche versucht in Echtzeit eine Filterung der Daten vorzunehmen. Interessant Ereignisse werden herausgeschrieben und evtl. noch vorprozessiert. Falls da Interesse besteht kann ich gerne mal ein paar Arbeiten zusammen suchen, von einem CERN Experiment an dem ich zu Uni Zeiten selbst mitgewirkt habe.
Klar, die Option mit dem Abspeichern habe ich immer. Das sind je Impuls nur wenige Samples. Ich kann das also entweder abspeichern und im FPGA verrechnen oder sogar zum PC schicken und dort rechnen. Aber das will ich eigentlich nicht. Ich möchte ohne Totzeit z. B. einen kurzen FIR rechnen und dann auf dessen Ergebnis eine Peakerkennung machen. Oder sagen wir ich möchte nur einen Trigger machen im FPGA. Dann muss der ja auch mehrere Samples vergleichen die parallel reinkommen. Als Beispiel bei 250 MHz Frameclock bekomme ich dann jeweils 4 Sample gleichzeitig. n,n+1,n+2,n+3 n+4,n+5,n+6,n+7 ... Und da will ich triggern wenn n < Schwelle und n+1 >= Schwelle. Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen. Ich dachte da gibt es vielleicht elegante Standardherangehensweisen.
Tobias B. schrieb: > Du musst deinen Datenstrom einfnach auch parallelisieren. Das ist mal die Grundlage von allem, dass du die Datenbusbreite erhöhst. Also anstatt mit 8 bit breite rechnest du dann mit 16, 32, 64,... bit breite. Es ist natürlich selten trivial, deine eigentliche Berechnung zu parallelisieren bzw. sie in einzelne kleine Rechenschritte zu zerlegen und aus diesen kleinen schritten eine Pipeline zu bauen. Kommt dann auch sehr auf die FPGA Architektur / Datenrate an, ob die BlockRAMs noch den Sample Takt mitmachen oder ob die auch schon zu langsam sind. (Daten an passender Stelle in der Pipeline aus dem FIFO/Ringpuffer auslesen vs. Daten mit durch die Pipeline schaufeln).
-gb- schrieb: > Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen. Das generate Statement hilf beim parallelisieren ungemein :-)
-gb- schrieb: > Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen. Ich > dachte da gibt es vielleicht elegante Standardherangehensweisen. Ich habe bisher noch keinen eleganten Weg gefunden, mit mehrere Samples pro Takt gleichzeitig umzugehen, zumal wenn die Berechnungen voneinander abhängig sind. Bei gepulsten Signalen, wie in Deinem Fall, würde ich sehen, ob ich mit den schnellen Daten einen FIFO füllen kann, um diesen dann langsam Takt für Takt abzuarbeiten. Die Triggerei muß natrürlich mit allen Samples parallel geschehen und darf daher nicht zu aufwendig werden. Duke
Christoph Z. schrieb: > dass du die Datenbusbreite erhöhst. > Also anstatt mit 8 bit breite rechnest du dann mit 16, 32, 64,... bit > breite. Ja genau. Ich habe beim HMCAD1511 dann 8 LVDS Lanes die mir die Daten mit jeweils 1 GBit/s anliefern. Mit der Frameclock, 1/8 der Samplerate, also 125 MHz bekomme ich dann 64 Bit gleichzeitig, also einen 8 Bit Samplewert je LVDS Lane. Christoph Z. schrieb: > Kommt dann auch sehr auf die FPGA Architektur / Datenrate an, ob die > BlockRAMs noch den Sample Takt mitmachen oder ob die auch schon zu > langsam sind. Egal ob ich 500 MHz oder 1 GHz Sampletakt nehme, weder im Spartan7 noch im Artix7 kann der BlockRAM dann den vollen Sampletakt. Ich werde also z. B. den Takt der Frameclock verwenden. Aber eigentlich möchte ich ja komplett ohne BRAM auskommen. Die Werte kommen rein, werden FIR gefiltert und dann wird auf den Ausgang des FIRs eine Peakerkennung/Trigger gemacht. Warum mache ich das überhaupt? Wir messen hier Radioaktivität und zwar sehr schwache Proben. Da macht die Umgebungsstrahlung den Großteil der gemessenen Impulse aus. Klar haben wir das in einer Burg aus Bleiziegeln, aber das hilft auch nur bedingt. Besser wäre die Messung tief unter der Erde zu machen aber ... dann müsste man sich in einem Tunnel einmieten und hätte andere Probleme wie Radon das aus dem Gestein rauskommt. Aber das Schöne ist, dass einige Zerfälle schön charakteristisch sind. Ein Isotop zerfällt zuerst in eine sehr kurzlebige Tochter und die dann eben nach kurzer Zeit wieder weiter in eine langlebigere Tochter. Das kann man ausnutzen, aber weil das verschiedene Zerfälle sind muss man gleichzeitig an der Probe alle Zerfallsarten messen. Wir messen also gleichzeitig mit einem Germaniumdetektor, der liefert eine sehr gute Energieauflösung. Und wir verwenden einen Anzeigen Photomultiplier. Aber da ist die Energieauflösung recht schlecht, was egal ist wenn man den nur für das Timing verwendet. Die Idee ist also das Signal des PMT nur für das Timing zu verwenden und um zwischen Alpha und Beta zu unterscheiden. Letzteres geht recht einfach auch wenn man die Impulse mit nur mit wenigen Bits Auflösung hat. Klar, man könnte nach der Impulsform gehen, aber die unterscheiden sich auch so schon recht deutlich. Das Problem ist hier das Timing. Und zwar haben PMTs typischerweise einen TIA der aus dem kleinen Stron eine Spannung erzeugt. Und da ist die Bandbreite typischerweise sehr gering. Und zwar so gering, dass zwei Zerfälle die kurz hintereinander in der Probe passieren dann als Signal hinter dem TIA wie ein Impuls aussehen. Wenn man aber das Signal an der Anode direkt anguckt, z. B. mit dem Oszi, dann kann man das unterscheiden, dann sind das sehr kurze einzelne Impulse denen ich dann einzelne Zeitstempel geben kann. Aber die Impulse sind eben kurz, ich muss also schnell abtasten und zwar so genau, dass ich zumindest die Zerfallsarten unterscheiden kann. So 6 rauschfreie Bits reichen da aber. Duke Scarring schrieb: > Ich habe bisher noch keinen eleganten Weg gefunden, mit mehrere Samples > pro Takt gleichzeitig umzugehen, zumal wenn die Berechnungen voneinander > abhängig sind. Da hatte ich gehofft, dass es schon so standard Vorgehensweisen gibt. Duke Scarring schrieb: > Die Triggerei muß natrürlich mit allen Samples parallel geschehen und > darf daher nicht zu aufwendig werden. Richtig, gut, ich schreibe auch gerne viel HDL, das ist nicht das Problem, ich möchte nur nicht später sehen, dass man das üblicherweise irgendwie viel eleganter machen kann.
Hi, koennte evtl. ein Flancter hilfreich fuer dich sein? https://www.doulos.com/knowhow/fpga/fastcounter/
Gustl B. schrieb: > Wir messen hier Radioaktivität und zwar sehr schwache Proben. Da macht > die Umgebungsstrahlung den Großteil der gemessenen Impulse aus. Klar > haben wir das in einer Burg aus Bleiziegeln, aber das hilft auch nur > bedingt. Besser wäre die Messung tief unter der Erde zu machen aber ... > dann müsste man sich in einem Tunnel einmieten und hätte andere Probleme > wie Radon das aus dem Gestein rauskommt. Und warum musst du dann unbedingt ohne Totzeit detektieren? Entweder du hast genug Zerfaelle pro Sekunde, dann ist es egal wenn du einzelne Ereignisse verlierst oder du hast so wenige, dass du eh genug Zeit zwischen den Ereignissen hast. Deine Anwendung ist ein ganz klassische Fall fuer mein beschriebenes Vorgehen, wird seit Jahrzehnten in der Teilchenphysik so gehandhabt. Wenn du allerdings auf biegen und brechen das in Realtime willst, dann musst du deine Algorithmen so clever aufbauen, dass nunmal ein Satz an Datensamples parallel verarbeitet wird. Ein Pauschalrezept wie das auszusehen hat gibt es dafuer nicht.
Gustl B. schrieb: > Ja genau. Ich habe beim HMCAD1511 dann 8 LVDS Lanes die mir die Daten > mit jeweils 1 GBit/s anliefern. Mit der Frameclock, 1/8 der Samplerate, > also 125 MHz bekomme ich dann 64 Bit gleichzeitig, also einen 8 Bit > Samplewert je LVDS Lane. OK, ja das ist so gedacht, dass du dann deine Verarbeitung mit 125 MHz und 8*8 bit parallel machst. Mit 125 MHz kannst du dann wieder Register oder BlockRAM nehmen, wenn du Berechnungen hast, die mehr als 8 Werte überstreichen oder Daten aus dem vorherigen Frame benötigen. Wenn das immer noch zu schnell ist, dann kannst du das auch auf 16*8 bit aufblasen und mit 62.5 MHz rechnen.
Tobias B. schrieb: > Und warum musst du dann unbedingt ohne Totzeit detektieren? Weil es um das Erkennen von kurz aufeinanderfolgenden Impulsen geht. Ich könnte höchstens immer Impulspaare abwarten und dann verarbeiten, aber dann müsste ich irgendwie ohne Totzeit erkennen, dass das Paare sind. Und es sind natürlich nicht immer Paare, sondern auch einzelne. Es geht darum aus den ganzen Zerfällen die paar wenigen herauszufiltern die tatsächlich aus der Probe stammen. Das sind im Vergleich zu der natürlichen Radioaktivität und Höhenstrahlung sehr wenige, aber die haben charakteristische Eigenschaften wodurch man sie erkennen kann. Ich bin aber gerade nur dabei mir das zu überlegen. Wir haben schon Messmethoden mit denen das auch mit langsamen ADC funktioniert, allerdings haben die Nachteile. Man kann dann nur anhand der Energieen Impulse unterscheiden und keine kurz aufeinander folgenden Doppelimpulse erkennen. Das mit der gemütlichen Verarbeitung nach Speicherung werde ich mir jedenfalls mal merken ... Christoph Z. schrieb: > Mit 125 MHz kannst du dann wieder Register > oder BlockRAM nehmen, Exakt. Christoph Z. schrieb: > wenn du Berechnungen hast, die mehr als 8 Werte > überstreichen oder Daten aus dem vorherigen Frame benötigen. Und darum geht es mir, ob es für typische Berechnungen wie FIR und Trigger Herangehensweisen gibt wenn immer mehrere Samples parallel ankommen. Mal gucken ob ich das wirklich baue. Wäre zwar schön auch um zu lernen, aber ich müsste auch das Thema Takterzeugung und Verteilung anfassen. berndl schrieb: > Hi, koennte evtl. ein Flancter hilfreich fuer dich sein? Ob ich das hier brauche weiß ich noch nicht, aber das sieht trotzdem interessant aus, vielen Dank!
:
Bearbeitet durch User
Noch eine Nachfrage zur Takterzeugung: Ich möchte ja den Jitter gering halten, aber auch keinen Oszillator fester Frequenz an den ADC anschließen, weil ich den Takt auch reduzieren können möchte wenn das mit dem SerDes nicht so funktioniert wie ich will. Was macht da mehr Sinn: 1. Externe PLL wie die https://www.analog.com/en/products/ltc6951.html mit 100 MHz Referenz. 2. Einen programmierbaren Oszillator wie den https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf und dann damit entwider direkt in den ADC oder zuerst in einen Taktverteiler wie den https://www.analog.com/media/en/technical-documentation/data-sheets/AD9508.pdf . Wobei ich den Sampletakt ja sowieso nicht im FPGA brauchen kann, das FPGA bekommt dann vom ADC den FrameClock (1/8 Fsample) und den halben Sampletakt für den SerDes. Das mit dem AD9508 wäre trotzdem nett weil ich dann auch gleich meinen FPGA Systemtakt damit erzeugen könnte und weitere Takte die ich brauche.
:
Bearbeitet durch User
Gustl B. schrieb: > Weil es um das Erkennen von kurz aufeinanderfolgenden Impulsen geht. Ich > könnte höchstens immer Impulspaare abwarten und dann verarbeiten, aber > dann müsste ich irgendwie ohne Totzeit erkennen, dass das Paare sind. > Und es sind natürlich nicht immer Paare, sondern auch einzelne. Es geht > darum aus den ganzen Zerfällen die paar wenigen herauszufiltern die > tatsächlich aus der Probe stammen. Das sind im Vergleich zu der > natürlichen Radioaktivität und Höhenstrahlung sehr wenige, aber die > haben charakteristische Eigenschaften wodurch man sie erkennen kann. Das schliesst das Vorhaben immer noch nicht aus. Die stellst einen Trigger ein, wenn der ausloest wird dein Buffer vollgeschrieben und die Daten kannst du dann in Ruhe nach den Doppelpulsen untersuchen. Es gibt hier immer noch keinen Grund fuer eine Totzeit freie Messung.
Ja das stimmt schon, ich finde das nur eleganter wenn ich das ohne Zwischenspeicherei machen könnte so wie jetzt. Derzeit habe ich mehrere langsame ADCs, die Sample laufen durch einen FIR und dahinter wird der Peak erkannt. Bei der Zwischenspeicherei ist das Problem, oder das vermute ich zumindest, dass das recht aufwendig wird. Die Impulse sind zwar so nah zusammen, dass der TIA am PMT die zu einem Impuls macht, aber sie sind trotzdem bei 1 GSample/s viele Samples getrennt. Ist ja Statistik, aber das können schon mal mehrere wenige us sein, das müssten also viele Samples im Speicher sein. Wenn ich die dann nachträglich verarbeitet kann das zu viel Totzeit führen. Oder man macht das mit mehreren Zwischenspeichern so round robin mäßig. Das wäre dann allerdings wieder schick. Eine andere Möglichkeit wäre das mit den doppelten Impulsen zu ignorieren und einfach jeden Impuls mit Zeitstempel und Energiewert auszugeben. Dann kann man später am PC in Software schön filtern und dann auch Zeitfenster setzen. Vorteil wäre, dass man bei einzelnen Impulsen nur sehr wenig zwischenspeichern müsste. Die sind so maximal 20 ns lang, das sind also nur wenige Samples.
:
Bearbeitet durch User
Ne garnicht. Einfacher und flexibler bist du wenn du die Daten erst bufferst und dann ebarbeitest. Idealerweise dann via Microblaze oder noch besser nenn Zynq. Dann hast du da auch ordentlich Rechenpower und Alogirthmen auf deine Daten sind viel schneller und einfacher implementiert. Je nachdem wie dein Detektor aufgebaut ist und was du dir aus der Messung erhoffst, koennen da zum Teil fuer einen FPGA die Algorithmen (z.B. eine Deconvolution) recht schnell komplex werden, auch das Testing ist nich zu vernachlaessigen. Bei der geringen Datenmenge bist da mit einem Prozessor als Auswerteeinheit deutlich effektiver unterwegs.
Da hast du vermutlich Recht. Ich habe bisher kaum was mit CPUs gemacht und fühle mich bei HDL eher wohl. Aber vielleicht sollte ich mich mal an einen Zynq herantrauen. Da kann man ja auch ohne Linux und DDR RAM auskommen wenn ich das richtig sehe.
Gustl B. schrieb: > Da kann man ja auch ohne Linux und DDR RAM auskommen wenn ich das > richtig sehe. Ohne Linux kommst du richtig weit, fuer deine Anwendung brauchst du nichtmal ein RTOS. Aber ganz ohne RAM ist dann doch etwas unschoen, gerade bei den grossen Datenmengen. Der Zynq hat aber seinen eigenen Speichercontroller im Prozessor System, das macht die Sache super easy zum einsteigen.
Hm, welchen Zynq würdest du empfehlen? Bisher habe ich den Spartan7 mit 1 mm Bällchenabstand verlötet. Da ist auch die Spannungsversorgung recht einfach machbar. DDR RAM habe ich noch nie gelayoutet.
Gustl B. schrieb: > Hm, welchen Zynq würdest du empfehlen? Bisher habe ich den > Spartan7 mit > 1 mm Bällchenabstand verlötet. Da ist auch die Spannungsversorgung recht > einfach machbar. DDR RAM habe ich noch nie gelayoutet. Fuer diese Aufgabe? Den erst besten der mit unter die Naegel kommt. Die ARM Cores sind innerhalb der Familien alle gleich. Idealerweise ein Evalboard nehmen, bei den Stueckzahlen wuerde ich mir nicht die Muehe machen. Theoretisch tuts auch ein Microblaze, daher wird auch schon ein Artix 7 ausreichen.
:
Bearbeitet durch User
Tobias B. schrieb: > Idealerweise dann via Microblaze oder > noch besser nenn Zynq. Dann hast du da auch ordentlich Rechenpower und > Alogirthmen auf deine Daten sind viel schneller und einfacher > implementiert. Zynq und einfach? Hast Du damit schon gearbeitet oder bisher nur die Marketing-Slides angeschaut? Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht... Duke
Tobias B. schrieb: > Den erst besten der mit unter die Naegel kommt. Die > ARM Cores sind innerhalb der Familien alle gleich. Ich frage vor allem weil ich das Marketing von Xilinx nicht so wirklich verstehe. Ist Ultrascale der Nachfolger von der 7 Serie und man sollte also Ultrascale verbauen weil irgendwann eine Software den Support hinten abschneidet? Oder laufen die Produkte parallel und 7 Series ist quasi lowend? Tobias B. schrieb: > bei den Stueckzahlen wuerde ich mir nicht die Muehe > machen. Klar, wirtschaftlich macht das alles keinen Sinn, da könnte ich das komplett bleiben lassen. Mir geht es drum eine Messmethode auszuprobieren und auch Elektronik zu lernen. Das ist für mich alles erstmal Hobby und macht ja auch Spaß. Tobias B. schrieb: > Theoretisch tuts auch ein Microblaze, daher wird auch schon ein Artix 7 > ausreichen. Das wäre auch eine Überlegung. Dann könnte ich aber auch beim Spartan7 bleiben. Denn wenn sowieso die CPU die Rechnerei erledigt brauche ich nicht viele DSP Slices oder so und für die paar Sample reicht der BRAM locker. Die LVDS Eingänge sind bei Artix leider auch nicht schneller als beim Spartan, ist aber egal, denn das ist schnell genug. Duke Scarring schrieb: > Zynq und einfach? Ich kenne mich damit gar nicht aus, weiß aber, dass zusätzlich zum HDL dann noch Software dazu kommt die man bauen muss. Dann ist für mich unklar wie das mit dem JTAG läuft, also ob die ARM Kerne und das FPGA sich einen JTAG teilen oder ob ich dann zwei Adapter brauche und auch das Debugging stelle ich mir schwieriger vor. Oder kann man sich das einfach wie bei einem reinen FPGA simulieren lassen nur, dass beim Zynq auch der ARM mit der Software mitsimuliert wird? Ich denke das wird fast einfacher, wenn ich die Rechnerei zum PC hin auslagere. Ein kleines FPGA sammelt die Daten ein, schickt die zum Rechner, dort wird dann die Peakhöhe bestimmt und in eine Aufnahme ausgegeben/geschrieben.
Duke Scarring schrieb: > Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht... Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und dann noch einen FPGA dazu. Das Technical Refrence Manual ist gut, erschlägt einem aber im ersten Moment nur schon durch die Seitenzahl. Gustl B. schrieb: > Klar, wirtschaftlich macht das alles keinen Sinn, da könnte ich das > komplett bleiben lassen. Mir geht es drum eine Messmethode > auszuprobieren und auch Elektronik zu lernen. Das ist für mich alles > erstmal Hobby und macht ja auch Spaß. Wir verwenden hier recht gerne das MicroZed Board von Avnet. Ziemlich günstig und eben kein Evalboard sondern gedacht um damit eine Anwendung in kleinen Stückzahlen zu bauen. Gustl B. schrieb: > Ich kenne mich damit gar nicht aus, weiß aber, dass zusätzlich zum HDL > dann noch Software dazu kommt die man bauen muss. Dann ist für mich > unklar wie das mit dem JTAG läuft, also ob die ARM Kerne und das FPGA > sich einen JTAG teilen oder ob ich dann zwei Adapter brauche und auch > das Debugging stelle ich mir schwieriger vor. Das läuft gleich wie mit dem Microblaze, da kommt auch Software dazu und in Vivado ist es gleich aufgebaut, egal ob dein Target ein Microblaze enthält oder einen ARM. Du hast einen einzelnen JTAG Anschluss zum Konfigurieren und Debuggen. Brakepoints und ILA (Chipscope) Triggern kann man auch zusammenknüpfen. > Oder kann man sich das > einfach wie bei einem reinen FPGA simulieren lassen nur, dass beim Zynq > auch der ARM mit der Software mitsimuliert wird? Schön wärs, ja. Wir bauen die FPGA Teile wie gewohnt in HDL und mit Testbench bis sie laufen, dann schreiben wir Embedded Software dazu und Debuggen die per JTAG. Es gibt Ansätze das auch zusammen zu simulieren, leider ist da Xilinx selber nicht so weit wie sie sein müssten. Es gibt so "Demos" mit Qemu und Icarus (SystemVerilog), Renode oder CocoTb. Strubi hier im Forum ist ja hier super Fit (gefühlte 10 Jahre voraus zu allen anderen die ich kenne oder zusammenarbeite).
Christoph Z. schrieb: > Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und > dann noch einen FPGA dazu. Hm ... Christoph Z. schrieb: > Wir verwenden hier recht gerne das MicroZed Board von Avnet. Sieht interessant aus. Christoph Z. schrieb: > Das läuft gleich wie mit dem Microblaze, da kommt auch Software dazu und > in Vivado ist es gleich aufgebaut, egal ob dein Target ein Microblaze > enthält oder einen ARM. Das ist doch schonmal schön. Christoph Z. schrieb: > Strubi hier im Forum ist > ja hier super Fit (gefühlte 10 Jahre voraus zu allen anderen die ich > kenne oder zusammenarbeite). Das stimmt allerdings. Nun gut, mir erscheint es da tatsächlich einfacher wenn ich in einem kleinen FPGA einen einfachen Trigger in HDL einbaue und dann jeweils die Sampledaten des Impulses an den PC schicke. Das mit dem Zynq schaue ich mir dann mal getrennt an. Das möchte ich ja auch mal gemacht haben weil das jetzt modern ist.
Christoph Z. schrieb: > Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und > dann noch einen FPGA dazu. Das Technical Refrence Manual ist gut, > erschlägt einem aber im ersten Moment nur schon durch die Seitenzahl. Die Prozessorleistungsklasse ist doch unerheblich ob die Implementierung schnell oder nicht ist. Im Vergleich zu das ganze zu 100% im FPGA machen, ist das aber definitiv schneller. Wenn er den HDL Code eh shcon aht fuer die ADCs, dan muss er nur noch einen AXI Wrapper schreiben und die Daten in einem Speicher ablegen. Wenn er genug BRAM hat kann er auch laessig einen dedizierten BRAM fuer die ADC Daten als Ringbuffer nehmen. Seinen Trigger den er in HDL schreibt erzeugt nenn Interrupt und wenn dieser ausloest kann er die Daten vom Prozessor aus aus dem BRAM holen und verarbeiten wie er moechte. Eine Schleife ueber eine Speicher Offsetadresse bekommt doch wohl jeder von uns hin ohn das gleich als Aufwand zu bezeichnen? Duke Scarring schrieb: > Zynq und einfach? Hast Du damit schon gearbeitet oder bisher nur die > Marketing-Slides angeschaut? > > Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht... Klar, mehr als nur einmal. Dein Prblem ist nunmal das du nicht die Erfahrung hast, sondern dir die Erfahrung fehlt. Deshalb ist erscheint auch dieses Miniprojekt bei dir auch wie ein Mords Akt. Daher kann ich nur empfehlen: ueben, ueben, ueben. ;-)
Überlege doch mal, ob Du Dein Interface nicht auf eine M.2 Typ M Karte oder eine normale PCIe x8 Karte bekommst und das dann mit einem NVidia Xavier (entweder dem großen AGX oder dem kleinen NX) koppelst. Da hast Du dann nämlich eine GPU, die Tausende von CUDA Kernen hat, die alle parallel arbeiten. Xavier hat Unified Memory, d.h. Du hast nicht wie beim PC separaten GPU-Speicher, sondern die 32GB auf dem AGX sind voll von der GPU nutzbar. Die Arms sind dann nur fürs Management da, und um die DMAs passend anzuwerfen. fchk
Tobias B. schrieb: > Im Vergleich zu das ganze zu 100% im FPGA machen, ist das aber definitiv > schneller. Das weiß ich nicht. Ich müsste mich erst in dieses ganze Zynq Ökosystem einarbeiten (was ich sowieso mal machen sollte). Schneller/einfacher wäre es das am PC zu rechnen. Also wie du beschrieben hast, kleiner Speicher im FPGA, Trigger im FPGA und dann wird der Speicher nach jedem Trigger zum PC geschickt. Die Datenraten sind auch eher sehr gemütlich. Sagen wir maximal 1k Impule/s (ist wahrscheinlich deutlich zu hoch gegriffen, aber über 100 gibt es schon manchmal). Dann ist jeder Impuls so 20 ns lang, macht bei 1 GSample/s also 20 Samples, da würde ich vorher und nachher noch was dazu nehmen, also so 64 Samples insgesammt. Und dann noch ein Zeitstempel. Also < 100 Bytes/Impuls und < 100 kByte/s. Das kann man locker sogar über UART an den PC schicken. Frank K. schrieb: > Überlege doch mal, ob Du Dein Interface nicht auf eine M.2 Typ M Karte > oder eine normale PCIe x8 Karte bekommst und das dann mit einem NVidia > Xavier (entweder dem großen AGX oder dem kleinen NX) koppelst. Äh ... nun, man warf mir schon overengeneering vor, das möchte ich ungerne wiederholen. Ein anderes Problem habe ich noch und frage das hier einfach auch noch: Und zwar geht es ja drum von den Impulsen die Höhe zu messen. Jetzt bekomme ich aber von jedem Impuls nur wenige Abtastpunkte und es ist unwahrscheinlich, dass da immer einer der Abtastpunkte das Maximum getroffen hat. Wie bekommt man denn die Höhe die der Impuls hatte wenn man nur so wenige Stützpunkte hat? Das Signal würde ich natürlich in der Bandbreite begrenzen, man kann also aus den Abtastpunkten das tatsächliche Signal rekonstruieren. Mir geht es um eine einfache Methode wie man das macht. Danz primitiv würde ich virtuell die Samplerate deutlich erhöhen und dann mit einer schönen Tiefpass filtern. Dann hätte ich eine glatte Kurve mit vielen Stützstellen und könnte davon dann die höchste nehmen.
Also wenn du ein PC zur Verfuegung hast, dann wuerde ich die Auswertung acuh am PC machen. ROOT ist da das absolute Mittel der Wahl: https://de.wikipedia.org/wiki/ROOT Aber selbst fuer diese Aufgabe wuerde ich noch einen Prozessor nehmen. In diesem Fall einen Microblaze (ohne DDR Speicher). UART Protokolle sind in Software einfach schneller entwickelt als in Hardware. Gerade fuer UART verwende ich gern eine Eigenentwicklung welches ein Handshake Verfahren verwendet, angelehnt an TCP. ICh wuerde diesen Schritt wirklich mal wagen, der Einstieg ist bei Weitem nicht so schwierig, wie hier im Forum suggeriert wird. Am besten mit einem Hello World UART Beispiel anfangen und dann Schrittweise BRAM und Interrupts hinzufuegen (das letzte ist als Neuling wahrscheinlich das schwierigste, aber auch nix weltbewegendes - ausserdem ist die Menge an Leuten die Helfen koennen noch groesser, weils nicht mehr FPGA sondern Mikrocontroller ist ;-)).
Tobias B. schrieb: > Die Prozessorleistungsklasse ist doch unerheblich ob die Implementierung > schnell oder nicht ist. Die Anzahl Seiten an Dokumentation steigt halt mit der Leistungsklasse und entsprechend auch die Einarbeitungszeit. Merkt man nur schon wenn man vom AVR zum STM32 wechselt, weil sie ja gleich wenig kosten aber nun kommt z. B. noch eine DMA Einheit mit etc. Tobias B. schrieb: > Seinen Trigger den er in > HDL schreibt erzeugt nenn Interrupt und wenn dieser ausloest kann er die > Daten vom Prozessor aus aus dem BRAM holen und verarbeiten wie er > moechte. > > Eine Schleife ueber eine Speicher Offsetadresse bekommt doch wohl jeder > von uns hin ohn das gleich als Aufwand zu bezeichnen? Nee, ein Aufwand ist diese Aufgabe nicht, nach dem man sich x Tage in Vivado & Vivado SDK eingearbeitet hat, endlich weiss, wo welche Häckchen zu setzen sind, damit da auch eine Interrupt Leitung ist und nach weiteren Tagen hat man es geschafft, das die Triggereinheit ein Xilinx IP core ist, bei dem die Offset Adresse automatisch in der Header Datei landet und der Softwaretreiber automatisch ins SDK Projekt kopiert wird. Die Tutorials vom MicroZed waren für mich ziemlich hilfreich: http://zedboard.org/support/design/1519/10 Beim zweiten Mal gehts dann ganz fix. Tobias B. schrieb: > Daher kann ich > nur empfehlen: ueben, ueben, ueben. ;-) Definitiv. Diese FPGA-SoCs machen generell schon Spass, weil mit denen kaum etwas unmöglich ist und wenn die Prozessor Peripherie nicht passt, dann hat man viel FPGA Platz um da alles rein zu bauen in einer Kombination die man so sicher nie kaufen könnte.
Tobias B. schrieb: > Aber selbst fuer diese Aufgabe wuerde ich noch einen Prozessor nehmen. > In diesem Fall einen Microblaze (ohne DDR Speicher). UART Protokolle > sind in Software einfach schneller entwickelt als in Hardware. Ja, das kann gut sein. Bisher habe ich das alles in HDL gemacht. Und was Protokolle angehet, das muss ja nicht irre komplex werden. Da definiert man ein Paket mit fester Länge und schon kann man da Daten an den PC schicken. Geht mit FT2232H/FT600 auch schnell. Aber ja, man ist in Software natürlich deutlich flexibler, das wäre ein Vorteil. Tobias B. schrieb: > ICh wuerde diesen Schritt wirklich mal wagen, der Einstieg ist bei > Weitem nicht so schwierig, wie hier im Forum suggeriert wird. Am besten > mit einem Hello World UART Beispiel anfangen [...] Das hatte iich schon mal gemacht, aber den Vorteil nicht gesehen. Ich hatte damals versucht die Daten von Blockram zum FT2232H durch den Microblaze zu schieben. Also im BRAM lagen die ADC Samples, der Mikroblaze sollte daraus dann Pakete bauen (jeweils n Samples aufsummieren) und ausgeben. Aber das war schnarchlangsam. In reinem HDL konnte ich USB2 fast voll auslasten. Christoph Z. schrieb: > nach dem man sich x Tage in > Vivado & Vivado SDK eingearbeitet hat, endlich weiss, wo welche Häckchen > zu setzen sind, damit da auch eine Interrupt Leitung ist und nach > weiteren Tagen hat man es geschafft, das die Triggereinheit ein Xilinx > IP core ist, bei dem die Offset Adresse automatisch in der Header Datei > landet und der Softwaretreiber automatisch ins SDK Projekt kopiert wird. Und das will ich mir gerne erstmal sparen. Wenn Zynq, dann würde ich auch gleich Ethernet verwenden wollen, aber dann muss ich auf der PC Seite meine Software deutlich umschreiben. Da müsste ich mich wirklich erstmal einarbeiten. Aber das ist ja nicht schlimm. Werde ich machen, aber nicht bei diesem Projekt wobei ich mir jetzt noch etwas über Zynq einlesen werde. Vielleicht kann man den Artix ja einfach durch einen Zynq ersetzen und muss nicht alles neu machen. Man könnte ja auch zuerst den Zynq nur wie einen FPGA verwenden. Nachtrag: Ist der Zynq Ultrascale der Nachfolger vom der 7k Serie oder existieren die nebeneinander? Und dann haben die alle deutlich mehr BGA Bällchen als so ein kleiner Spartan. Da würde eine Platine mit vielen Lagen teuer werden. Aber ich kann doch weiterhin nur wenige IOs routen (auf wenigen Lagen) und die restlichen Bällchen unverbunden lassen? Die Zynq sehen schick aus weil die schon ziemlich viel BRAM und DSPs drinnen haben. Vielleicht könnte ich da den Datenstrom sogar in Echtzeit filtern.
:
Bearbeitet durch User
Christoph Z. schrieb: > Die Anzahl Seiten an Dokumentation steigt halt mit der Leistungsklasse > und entsprechend auch die Einarbeitungszeit. Merkt man nur schon wenn > man vom AVR zum STM32 wechselt, weil sie ja gleich wenig kosten aber nun > kommt z. B. noch eine DMA Einheit mit etc. Die Doku steigt aber nicht mit der Leistungsklasse sondern mit den Features die auf dem Chip sind. Und wenn ich 98% der Features nicht brauche, dann brauch ich auch 98% der Doku nicht lesen. Gustl B. schrieb: > Das hatte iich schon mal gemacht, aber den Vorteil nicht gesehen. Ich > hatte damals versucht die Daten von Blockram zum FT2232H durch den > Microblaze zu schieben. Also im BRAM lagen die ADC Samples, der > Mikroblaze sollte daraus dann Pakete bauen (jeweils n Samples > aufsummieren) und ausgeben. Aber das war schnarchlangsam. In reinem HDL > konnte ich USB2 fast voll auslasten. Das ist auch nochmal ein anderer Anwendungsfall und da muss man auch schauen wie man die Anbindung an den FT2232 ordentlich macht. Da geht es dann Richtung DMA damit man auch die volle Performance ausschoepfen kann. Eben wie bei einem Mikrocontroller auch. Nur weil man die Technologie nicht richtig beherscht, sollte man sie nicht gleich verteufeln. Vielleicht einfach ordentlicher einarbeiten. ;-) Gustl B. schrieb: > Nachtrag: > Ist der Zynq Ultrascale der Nachfolger vom der 7k Serie oder existieren > die nebeneinander? Die Ultrascale(+) sind die Nachfolger, beide Familien existieren aber parallel. Genauso wie die anderen Familien eben auch. Und wie schon gesagt, wenn du das Processing am PC machst reicht fuer diese Anwendung auch ein Microblaze ohne DDR RAM auf einem Spartan 7.
:
Bearbeitet durch User
Tobias B. schrieb: > Nur weil man die Technologie nicht richtig beherscht, sollte man sie > nicht gleich verteufeln. Vielleicht einfach ordentlicher einarbeiten. > ;-) Vollkommen richtig, ich verteufel hier aber auch nix. Ich habe mit HDL bisher recht gut das erreicht was ich erreichen wollte und sehe auch jetzt oft keinen Grund einen Prozessor zu verbauen. Tobias B. schrieb: > Die Ultrascale(+) sind die Nachfolger, beide Familien existieren aber > parallel. Genauso wie die anderen Familien eben auch. OK, danke. Ich finde das doch irgendwie seltsam von Xilinx und weiß dann nicht was ich machen soll. Es droht eben immer die Gefahr, dass man dann wie beim Spartan6 abgehängt ist und nicht mit der neuen Software arbeiten kann. Tobias B. schrieb: > Und wie schon gesagt, wenn du das Processing am PC machst reicht fuer > diese Anwendung auch ein Microblaze ohne DDR RAM auf einem Spartan 7. Dann bleibe ich dabei. Denn da habe ich schon Versorgung und alles wunderbar im Griff.
Gustl B. schrieb: > OK, danke. Ich finde das doch irgendwie seltsam von Xilinx und weiß dann > nicht was ich machen soll. Es droht eben immer die Gefahr, dass man dann > wie beim Spartan6 abgehängt ist und nicht mit der neuen Software > arbeiten kann. Du produzierst hier doch Einzelstuecke? Die Softwrae ist verfuegbar und die Chips auch noch viele Jahre. Da wuerde ich nicht eine Sekunden fuer verschwenden, ist doch alles nicht-kommerziell? Und die Spartan6 bekommst du heute auch noch, die werden sogar noch produziert und auch die Tools sind noch verfuegbar.
Stimmt auch wieder. Wie macht man das eigentlich bei der Versorgung von so FPGAs, welchen Wert nimmt man da für den Strom? Ja, ich kenne dieses XPE Teil, da fallen auch Werte raus je nach Verwendung im FPGA, aber wie geht man da typischerweise heran und wie viel mehr Strom sollte die Versorgung können? Als Beispiel sagt mir das XPE jetzt mal 2,5 A auf 1.0 V. Reicht dann ein DCDC der 3 A liefern kann oder würde man als Profi mehr Sicherheit drauflegen? Bisher verwende ich den https://www.ti.com/lit/ds/symlink/tps65266.pdf und bin sehr zufrieden. Der hab jetzt bei mehreren verschiedenen Layouts nie Probleme gemacht und hat auch immer genug Strom geliefert. Aber jetzt kommt eben ein schneller ADC, ein langsamerer ADC, USB ICs und Analogschaltung vor den ADCs dazu. Vieler der Bausteine speziell für FPGAs sehen irre kompliziert aus und wollen programmiert werden. Wenn dann dachte ich an den ADP5054 oder so.
Gustl B. schrieb: > Wie macht man das eigentlich bei der Versorgung von so FPGAs, welchen > Wert nimmt man da für den Strom? Ja, ich kenne dieses XPE Teil, da > fallen auch Werte raus je nach Verwendung im FPGA, aber wie geht man da > typischerweise heran und wie viel mehr Strom sollte die Versorgung > können? Du schaust auf entsprechendem Evalboard nach wie da die Stromverorgung aufgebaut ist. Am einfachsten ist es spezielle Regler zu verwenden die fuer den FPGA Typ entwickelt wurden, da ist dann auch die Ein- und Abschaltsequenz geregelt. Das ist aber wirklich ein Thema fuer sich, vll ist es besser dafuer ein extra Thread aufzumachen?
:
Bearbeitet durch User
Ja stimmt, werde ich machen. Zu der Eingangsbeschaltung von schnellen ADCs habe ich auch noch Fragen. Aber ich mache ja gerne Threads auf^^. Jedenfalls vielen Dank!
So, ich habe mich jetzt für einen Artix entschieden. Aber ich brauche bei weitem nicht alle IOs. Kann ich ungenutze IOs unverbunden lassen? Ich würde sagen Ja. Und wie sieht es bei einer Bank aus die ich nicht verwende, muss da trotzdem VCCO angeschlossen sein? Und dann brauchen LVDS Eingänge scheinbar nur minimal Strom über VCCO, da sollte also ein kleiner LDO für die 2,5 V genügen. BRAM und DSP brauchen auch erstaunlich wenig Strom.
Gustl B. schrieb: > Aber ich brauche bei weitem nicht alle IOs. Kann ich ungenutze IOs > unverbunden lassen? Ich würde sagen Ja. jep. man könnte sogar noch im bitfile "unused pulldown" oder "unused pullup" einstellen. Das ist natürlich erst nach dem Programmieren gültig. In der Regel muss man nichts machen. Gustl B. schrieb: > Und wie sieht es bei einer Bank aus die ich nicht verwende, muss da > trotzdem VCCO angeschlossen sein? Diesen Fall hatte ich noch nicht überlegt, da meist immer irgendwas dranhängt. Eigentlich könnte man die ungenutze Bank auslassen, aber wehe da ist etwas angeschlossen (reverse biasing of bank). Ansonsten einfach die Spannung von der Nachbarbank anschließen. Die statische Leistung ist in der 7er Generation ganz angenehm gering.
Wunderbar, Danke! Hach wenn man nur wenige IOs verwendet lässt sich sogar ein BGA stressfrei auf wenigen Lagen routen (-:
Fuer solche Falle wuerde ich immer in den entsprechenden PCB Design Guide schauen. Den bietet so ziemlich jeder FPGA Hersteller zu seinem FPGA an. Die sind meistens unter 100 Seiten und laessig an einem Nachmittag durchgearbeitet. Beim Artix 7 ist das UG483 und da gibt es ein kompletten Abschnitt zu dem Thema: https://www.xilinx.com/support/documentation/user_guides/ug483_7Series_PCB.pdf Seite 36.
Vielen Dank! Das Dokument kannte ich schon weil da auch drinnen steht wie viele und welche Kondensatoren an welche Versorgung sollen, aber diesen Teil kannte ich noch nicht. Ich werde einfach das VCCO anschließen und unbenutzte Pins dann im Bitstream auf Pullup/Pulldown legen.
Hallo Gustl, ich hatte mal so eine ähnlichen Fall für einen Laser. Das Projekt nannte sich Multistop. Da gab es noch keinen High-speed ADC. Die Lösung war ein schneller free running Zähler. Am Eingang war ein Komperator und immer wenn ein Übergang von Low zu High kam, wurde der Zählerwert in einen Fifo abgelegt. Auf der Ausgangsseite war an dem Fifo ein geringerer Takt. Jetzt der Bringer. Intern war ein zweiter Takt der 180° Phasen verschoben war. Mit diesen zweiten Takt wurde das Gleiche auf gebaut. So hatte man die doppelte Taktrate genutzt.
Das stimmt, mit verschobenen Takten und mehrfacher Logik kann man höhere Datenraten erreichen.
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.