Hallo zusammen, mein Name ist Moritz, ich arbeite aktuell an meiner Masterarbeit im Bereich der Quantenoptik und stehe vor einer Herausforderung bei der Umsetzung eines Feedforward-Experiments, für das ich voraussichtlich einen FPGA einsetzen muss – allerdings habe ich bisher keine praktische Erfahrung damit. Kurz zum Experiment: Ich arbeite mit einem gepulsten Laser (80 MHz), also mit Lichtpulsen im Abstand von 12,5 ns. In einem besonderen Prozess entstehen mit einer gewissen Wahrscheinlichkeit aus diesen Pulsen Einzelphotonen. Mein Ziel ist es, mit einem Einzel-Photonen-Detektor über ein festes Zeitfenster (z. B. 100 Pulse = 1250 ns) zu messen, wann ein Photon detektiert wird. Dieses Muster soll direkt im Anschluss ausgewertet werden, um ein entsprechendes Spannungssignal für einen elektro-optischen Modulator (EOM) zu erzeugen. (Alle Geräte werden üblicherweise über SMA Kabel angesteuert) Das System soll synchron zur Laserfrequenz laufen, also dient diese als Master Clock. Eventuell muss ich sie intern im FPGA hochskalieren (falls das möglich ist), um die passende zeitliche Auflösung für den Modulator zu erreichen. Zusammengefasst: Clock als Input, Detektor als Input, Output für Modulator Meine konkreten Fragen: 1. Welche Anforderungen ergeben sich daraus für den FPGA? 2. Eignet sich ein Board wie das Opal Kelly XEM7310MT dafür? Es scheint in der Forschung gängig zu sein (viele High Performance Geräte in unserem Labor basieren auf Opal Kelly FPGAs) und bietet scheinbar eine gute Dokumentation. 3. Wir haben noch einen alten Spartan-6 (XC6SLX45T) auf einem Board von whizzsystems im Labor rumliegen mit dem in der Vergangenheit ein ähnliches Experiment gemacht wurde, reicht dieser theoretisch aus? Ich habe nämlich gesehen, dass die Software dafür auch nicht mehr aktuell ist und wollte deshalb fragen ob man lieber einen neuen besorgen soll um mit aktueller Hard- und Software zu arbeiten. 4. Welche Software und Programmiersprache eignet sich für den Einstieg in die FPGA-Programmierung in diesem Kontext? Ich bin dankbar für jede Einschätzung – gerne auch Erfahrungswerte aus ähnlichen Projekten. Viele Grüße Moritz
Moritz schrieb: > für das ich voraussichtlich einen FPGA einsetzen muss – > allerdings habe ich bisher keine praktische Erfahrung damit. Das klingt nach guten Voraussetzungen für ein gelungenes System. Man sollte eventuell mal so vorgehen, dass man Anforderungen erfasst und dann festlegt, womit man arbeitet. Hat sich bewährt ;-) Moritz schrieb: > Das System soll synchron zur Laserfrequenz laufen, also dient diese als > Master Clock. Das erfordert eine aktive Synchronisation mit Kompensation der Delays des Ausgangs des Lasertaktgebers, der Kabel, der FPGA-Eingänge. > Eventuell muss ich sie intern im FPGA hochskalieren > das möglich ist), um die passende zeitliche Auflösung für den Modulator > zu erreichen. Erst muss mal die Auflösung her: Um Einzelphotonen zu erfassen, muss eine Analyse über deren Lebensdauer und Wirkung im Detektor her, um zu wissen wie genau und wie lang man messen muss. Daraus ergibt sich ein S/N. Daraus eine Betrachtung, was die Wandler können müssen und wie man die abtastet und auswertet. Das ist meistens eine Mischung aus Integratin und Differentiation. Moritz schrieb: > 1. Welche Anforderungen ergeben sich daraus für den FPGA? Das musst du formulieren. Was ich schon sagen kann, ist dass die PLLs im FPGA nicht die Besten sind, wenn man hochgenaue Pulse braucht. Also einfach was Hochskalieren ist nicht. Moritz schrieb: > Eignet sich ein Board wie das Opal Kelly XEM7310MT dafür? Auch das ist Ergebnis der Analyse der Anforderungen. > Es scheint in der Forschung gängig zu sein > (viele High Performance Geräte in unserem Labor basieren auf Opal Kelly FPGAs) Ich wüsste nicht, wie gängig die in der Forschung wären, aber OK baut nur boards, keine FPGAs und das sind alles EVal-Kits. Solche gibt es von vielen Anbietern, darunter den Haus-und-Hoflieferanten von Xilinx und Altera nämlich Digilent und Terasic. Moritz schrieb: > Wir haben noch einen alten Spartan-6 (XC6SLX45T) No comment. Ist seit 15 Jahren abgekündigt. Wird auch von aktueller SW nicht unterstützt. Moritz schrieb: > Welche Software und Programmiersprache eignet sich für den Einstieg > in die FPGA-Programmierung in diesem Kontext? VHDL und sehr viel Zeit. Das Ganze ist nicht trivial und birgt, gerade was die letztliche Präzision angeht, einige Fallstricke. Einen ADC auslesen und einen Messwert holen, sind 50 Zeilen VHDL und 1 Tag Arbeit eines Studenten. Das System hinzuzeichnen, so wie ihr es aber wahrscheinlich braucht, erfordert eher 10 Jahre Erfahrung mit Signalverarbeitung und der Technik drum herum. Um moderne Wandler, die im Bereich hoher MHz oder GHz arbeiten, auszulesen, muss man oft Transceiver nutzen, samt der Clocking-Struktur im FPGA und der Taktversorgung drum herum - von dem PCB-Design geanz zu schweigen. Das ist nichts für Anfänger. Das gleiche gilt für die Signalauswertung, um aus den schönen ADC-Daten das richtige rauszufischen. Und ohne ein physikalisches Modell der Anordnung samt Beschreibung mit vor allem belastbaren Zahlen, auf deren Basis man o.g. Überlegungen anstellen könnte, ist das jetzt schon ein perfekter Kandidat, um in die Wiese entwickelt zu werden, wo am Ende nix Nutzbares rauskommt. (Wäre im Bereich Quantencomputing nicht das erste Projekt dieser Art. BTDT)
:
Bearbeitet durch User
Angehängte Dateien:
-
S6-45T.png
25 KB
> 3. Wir haben noch einen alten Spartan-6 (XC6SLX45T) auf einem Board von > whizzsystems im Labor rumliegen mit dem in der Vergangenheit ein > ähnliches Experiment gemacht wurde, reicht dieser theoretisch aus? Ich > habe nämlich gesehen, dass die Software dafür auch nicht mehr aktuell > ist und wollte deshalb fragen ob man lieber einen neuen besorgen soll um > mit aktueller Hard- und Software zu arbeiten. > 4. Welche Software und Programmiersprache eignet sich für den Einstieg > in die FPGA-Programmierung in diesem Kontext? Der Spartan-6 sollte für Datenverarbeitung einer Zeitreihe, die mit 80 MHz gesampelt wird völlig ausreichen, die 58 DSP-Slices (multiplicatoren) sind ausreichend auch für ineffizient programmierte Filter. Allerdings braucht es für den Spartan-6 als Entwicklungssoftware die ISE, die seit Jahrzehnten nicht wehr weiterentwickelt wird. Wenn man 0-Ahnung und nur arg begrenzte Zeit zur Einarbeitung hat, sollte man eher auf die Nachfolger-FPGA's wie Spartan-7 und Artix-7 setzen weil die mit der heute verbreiteten Software "Vivado" programmiert werden. https://docs.amd.com/r/en-US/ug973-vivado-release-notes-install-license/Supported-Devices https://www.fpgadeveloper.com/list-of-fpga-dev-boards-dont-require-license/ Das CERN veranstaltet im Sommer FPGA-User Treffen, vielleicht mal dort vorbeischauen, Quantenoptik ist da auch ein Thema (leider ist das Diesjährige grad vorbei: https://indico.cern.ch/event/1467417/ )
:
Bearbeitet durch User
Soll das ein digitaler Lock-In fuer eine Laser-Regelung werden? Dafuer ist der Spartan6 in der Tat geeignet und ausreichend. Man kriegt auch Delay-Taps hin, die im Bereich von 5-20 ps aufloesen, Stichwort TDC. Damit werden gerne auch mal Szintillator-Koinzidenzen genauer gemessen. Aber schlussendlich musst du die Timings anschauen, die PLLs sind in der Tat nicht so trivial zu ziehen, wenn es langzeitstabil sein soll. Dann muss ein externer VCO und allenfalls PLL-Logik her, oder man verbraet viel Zeit mit manueller Plazierung von Logik. Gerade weil der Spartan6 nicht totzukriegen ist, und die Bugs bei ISE 14.7 unter Linux (Windows vermeidet man hier besser) deutlich ueberschaubarer sind als bei Vivado, wuerde ich den auch in dem Fall hernehmen, im Sinne von: Auf alten Toepfen lernt man kochen und fuer den SP6 gibt es einige OpenHW projekte v.a. vom CERN. Wenn du dann an die Grenzen mit dem Prozess kommst, portierst du es notfalls auf eine neuere Architektur. Sonst faellt mir noch m-labs ein, die fuer QM-Messungen Technik bauen. Vielleicht da mal umschauen, bevor's zu komplex wird?
Evtl. ginge auch ein Red Pitaya, da sind 2 flotte AD und DA-Wandler schon drauf + Xilinx. Es gibt auch genügend open-source-Projekte bei denen man das Interface zur Hardware abschreiben kann. < https://redpitaya.com/?srsltid=AfmBOoqbmjrUjXHf5t0cQmVf3-KD4g5FI1TKJjGUeX_8BGyfdHWlsmto > Gruß, Gerhard
Martin S. schrieb: > Dafuer ist der Spartan6 in der Tat geeignet und ausreichend. Man kriegt > auch Delay-Taps hin, die im Bereich von 5-20 ps aufloesen, Stichwort > TDC. Da muss ich etwas widersprechen: Auch mit höchsten Taktfreqenzen bekommt man qualitativ nicht die 20ps hin, weil die S6-Delays einfach nicht koheränt genug sind. Zudem sind sie stark temperaturabhängig und müssen nachgeregelt werden. Genauer als faktisch 50ps+ wird man damit nicht. Allerdings reicht das natürlich, um einen mittelschnellen DAC zu interface, nur muss man das eben auch richtig tun. Je nach Takt-Verdrahtung und Banknutzung gibt es zwischen den Laufzeiten dann durchaus 200ps zwischen zwei IO-Pins, wenn man parallel anschließt. Die gehen dann direkt vom budget ab. Wenn man damit Video machen will (BTDT) kommt man schon bei 148MHz in Bedrängnis und muss den Betriebsbereich der Temperaturen einschränken. Der TE möchte/muss überdies in einer noch undefinierten Weise sampeln und will über die 80MHz hinaus überabtasten. Da ist beim Spartan schnell Ende. Ich sehe per se keinen Grund, auf einen derart alten und nicht zeigemäßen Chip zu gehen. Wenn kostenbewusst, dann einen S7, empfehlen möchte ich da aber in aller Regel einen Artix 7. Mit dem gibt es auch massenweise PCBs auf denen - wenn man Glück hat - auch schon passend hochaufgelöste Wandler mit dabei sind. Oder man nimmt ein PCB, das über Erweiterungsmöglichkeiten verfügt. Opal-Kelly arbeitet hier i.D.r. mit SYZYGY. Die Auswahl an kompatiblen Karten ist da aber beschränkt. Solange aber der TE nicht mit technischen Anforderungen, vor allem über Auflösungen und Genauigkeiten herausrückt, ist das alles ein Stochern im Trüben und dann bleibt nur das, was alle machen, ein riesiges dickes und überdimensioniertes EVAL-PCB mit Anschlüssen zu kaufen, dass man weitere Karten einstecken kann und die Entscheidung sozusagen vertagt. Diese Strategie ist dann mit ein Grund, warum in Forschungsabteilungen immer solche Boards rumhängen: Der Nutzer hat keinen Plan, was er braucht und auch keine Ahnung, wie er zu Informationen kommt, die ihm helfen, zu wissen, was er braucht. Also kauft er dick und fett ein und nutzt nachher 10% der Peripherie, läuft dann aber in das Problem, bei dem vielen Kram, der ungenutzt drauf ist, nicht genug IOs zu haben, um dann wirklich eine gute und für ihn passende Karte dranzuklemmen. Ich finde es schade, dass man Studenten nicht konsequent beibringt, die für ihre Aufgabe nötigen Infos zusammenzutragen, aufzuarbeiten und in ein technisches Anforderungsprofil umszusetzen. Würde man das tun, wäre es eine Aufgabe von 1-2 Stunden, sich die boards anzusehen und zu entscheiden, ob da was da ist, was passt, oder es eine Kombi tut und wenn ja, welche. Was machen eigentlich die Betreuer solcher Arbeiten?
J. S. schrieb: > Da muss ich etwas widersprechen: Auch mit höchsten Taktfreqenzen bekommt > man qualitativ nicht die 20ps hin, weil die S6-Delays einfach nicht > koheränt genug sind. Zudem sind sie stark temperaturabhängig und müssen > nachgeregelt werden. Genauer als faktisch 50ps+ wird man damit nicht. Es ist nicht ganz trivial, wie gesagt. und man macht seinen eigenen Floorplan, aber ich sag mal so: es funktioniert. Mit etwas extra Hirnschmalz kommt man auf seine 3-6ps single shot precision. Ja, Temperatur und Versorgungsspannung macht arg was aus, die Chipcharge ebenso und man sollte nach Moeglichkeit keine Binaerzaehler in der Nachbarschaft verwenden . (Preisfrage...warum). Wie gesagt, besagte m-labs haben das vor Jahren vorgemacht, da sollte auch noch einiges OpenSource rumliegen, die man fuer seinen Zweck optimiert kriegt. Ich persoenlich wuerde das heute mit einem ECP5 machen, aber die OpenSource-Baustelle ist eben eine weitere Baustelle und die Lattice-Tools wuerde ich jetzt nicht empfehlen. Ich verstehe allerdings nicht, warum man den Masterstudenten immer wieder weismachen will: "Du kannst das nicht". Es gibt immer mal wieder Kaepsele, die die Materie intuitiv verstehen und das auch hinkriegen. Das ist bei den Physikern auffallend oft so, schlicht weil sie meist die VLSI-Grundlagen kapiert haben und HDL nur noch Mittel zum Zweck wird. Einige wenige ueberschaetzen sich mal, aber danach klingt's hier nun wirklich nicht. Moritz hat ja erwaehnt, dass es bereits ein Referenzprojekt gibt. Sic..
Hallo zusammen, vielen Dank zunächst für den zahlreichen Input, das hat mir bereits sehr weitergeholfen. Da ich ehrlicherweise nicht mit so vielen Rückmeldungen gerechnet hatte, war meine ursprüngliche Beschreibung recht knapp. Daher habe ich meine Anforderungen nochmals überdacht und im Folgenden präziser zusammengefasst. Ich verwende Detektoren mit einer Totzeit von unter 10 ns. Bei einem Detektionsevent erzeugen diese einen Spannungspuls. Soweit ich informiert bin, kann dieser Puls vom FPGA nicht direkt sinnvoll verarbeitet werden. Daher plane ich, den Ausgang zunächst über einen PRL-350TTL-Komparator zu führen, der bereits zur Verfügung steht. Dieser vergleicht das Eingangssignal mit einer einstellbaren Referenzspannung und gibt bei Überschreiten ein TTL-Signal aus, das sich wiederum zuverlässig vom FPGA verarbeiten lässt. Sollte diese Annahme nicht korrekt sein, freue ich mich über Hinweise oder Korrekturen. Ich möchte ein Zeitfenster von 100 Pulsen (entsprechend 1250 ns) analysieren. Dabei betrachte ich 100 diskrete Zeitpunkte im Abstand von jeweils 12,5 ns, an denen potenziell ein Detektionsevent auftreten kann. Ziel ist es, festzustellen, zu welchen Zeitpunkten eine Detektion erfolgt ist und zu welchen nicht. Das daraus resultierende Muster soll anschließend mit vordefinierten Mustern verglichen werden. Abhängig davon, welchem Muster das aktuelle entspricht, soll ein entsprechendes Ausgangssignal an den elektro-optischen Modulator gesendet werden. Soweit ich es verstanden habe, müsste ich dieses Ausgangssignal in Form eines TTL-Signals ausgeben und anschließend über einen externen Verstärker auf die für den Modulator erforderliche Spannung bringen. Zum Thema Clock: Mein Laser arbeitet mit einer Repetitionsrate von 80 MHz. Der elektro-optische Modulator kann zwischen den Zuständen An und Aus umschalten. Da bestimmte Photonen im An-Zustand und andere im Aus-Zustand durchgelassen bzw. blockiert werden sollen, muss der Zustandswechsel immer zwischen den Pulsen erfolgen. Um dies sicherzustellen, ist mindestens die doppelte Repetitionsrate des Lasers erforderlich – also 160 MHz –, sodass alle 6,25 ns ein Umschalten möglich ist (zwischen den Pulsen im 12,5-ns-Abstand). Idealerweise steht eine noch höhere Clock-Frequenz zur Verfügung, um größere Flexibilität beim Timing der Modulator-Steuerung zu gewinnen, also nicht nur exakt auf oder zwischen den Pulsen schalten zu können. Bezüglich der Anschlüsse gehe ich davon aus, dass ich folgende Konfiguration benötige: – Einen differenziellen Clock-Eingang über zwei SMA-Verbinder (CLK P und CLK N) – Einen differenziellen Detektor-Eingang, ebenfalls über zwei SMA-Verbinder (DET P und DET N) – Einen differenziellen Ausgang für den Modulator über zwei SMA-Verbinder (MOD P und MOD N) In der bisherigen Diskussion wurde bereits deutlich, dass die Verwendung eines modernen FPGA sinnvoll ist – insbesondere aufgrund der aktuellen Softwareunterstützung. Habt ihr konkrete Empfehlungen, welches FPGA-Board sich für mein Vorhaben eignet? Wichtig ist, dass sich die benötigten SMA-Anschlüsse integrieren lassen und das Board die erforderliche Verarbeitungsgeschwindigkeit für mein Experiment bietet. Zudem wäre ich dankbar, wenn ihr noch einmal auf das Thema Clockerzeugung eingehen könntet: Ist es möglich, die höhere Taktfrequenz direkt auf dem FPGA zu generieren, oder sollte dafür besser ein externes Gerät verwendet werden? Falls letzteres der Fall ist, interessiert mich insbesondere, welche technischen Gründe dafür sprechen. Vielen Dank im Voraus für jedes Feedback – ich bin natürlich auch für alle Hinweise dankbar, die auf mögliche Schwachstellen oder Probleme in meinem Vorhaben hinweisen.
Moin, Hm, vielleicht habbichs ja ueberlesen - ueber welchen Zeitrahmen schwaetzen wir denn hier eigentlich? So Abschlussarbeiten kann man ja schon mal anfangen, aber dann irgendwann wird man sie auch anmelden muessen und dann laeuft die Uhr rueckwaerts... Fuer jemanden, der noch nie was mit FPGAs gemacht hat, finde ich das leicht "ambitioniert", um nicht zu sagen: bekloppt. Mir will nicht in den Kopp, warum man als Abschlussarbeit immer unbedingt irgendwas ganz neues machen muss, mit dem man vorher noch nie zu tun gehabt hatte. Anstatt irgendwas, wo man schon mal so was aehnliches gemacht hat und sich leichter tut, irgendwelche Zeiten, Aufwaende, etc. abzuschaetzen. Gruss WK
Die Bearbeitungszeit für die Masterarbeit beträgt insgesamt zwölf Monate. Da ich Anfang April begonnen habe, endet die Frist Ende März 2026. Da das beschriebene Setup nur einen Teil meines Gesamtprojekts darstellt und auch Zeit für das Verfassen der Thesis eingeplant werden muss, ist es mein Ziel, diesen Experimentteil bis September funktionsfähig umzusetzen. Parallel dazu arbeite ich an weiteren Aspekten meines Projekts.
Moin, OK, also so ca. 3..4 Monate Zeit zum einarbeiten in FPGA-Entwicklung und entwickeln/testen eines Designs. Ich waere bei sowas in der Abschlussarbeit komplett an Zeitmangel gescheitert. Aber ich bin auch kein Einstein :-) Gruss WK
J. S. schrieb: >> Wir haben noch einen alten Spartan-6 (XC6SLX45T) > No comment. Ist seit 15 Jahren abgekündigt. Zeigt mir mal bitte das Abkündigungsdokument! Der Chip wird immer noch beworben: https://www.amd.com/de/products/adaptive-socs-and-fpgas/fpga/spartan-6.html ... und verkauft: https://eu.mouser.com/c/semiconductors/programmable-logic-ics/fpga-field-programmable-gate-array/?q=XC6SLX45T Die Design-Software gehört eh in eine VM oder ähnliches.
Gerhard H. schrieb: > Evtl. ginge auch ein Red Pitaya, da sind 2 flotte AD und DA-Wandler > schon drauf + Xilinx Ja, aber der ist nicht wirklich für externes Clocking geeignet: https://downloads.redpitaya.com/doc/Red_Pitaya_Schematics_v1.0.1.pdf Der ADC wird mit 125 MHz oder extern oder aus dem FPGA getaktet (umlöten). Das FPGA hat auf diesem Board keinen dedizierten Takteingang. Moritz schrieb: > Das System soll synchron zur Laserfrequenz laufen, Damit lässt sich diese Forderung nicht erfüllen.
J. S. schrieb: > Solange aber der TE nicht mit technischen Anforderungen, vor allem über > Auflösungen und Genauigkeiten herausrückt Du hast noch nicht viel mit Wissenschaftlern - respektive Physikern - zu tun gehabt, oder? Bei mir läuft gerade ein Projekt, wo sich die Anforderungen nahezu wöchentlich ändern. Jackpot :(
Moritz schrieb: > Ziel ist es, festzustellen, zu welchen Zeitpunkten eine Detektion > erfolgt ist und zu welchen nicht. Also ein TDC. Im Prinzip baut man sich da ein langes Schieberegister (hier mit 100 Taps) und schaut da drin nach, welche Bits gesetzt sind. Oder man nimmt einen schnellen Zähler und schreibt bei einem Flankenwechsel den Zeitstempel weg (FIFO). BTDT
Moritz schrieb: > Ich verwende Detektoren mit einer Totzeit von unter 10 ns. Bei einem > Detektionsevent erzeugen diese einen Spannungspuls. Soweit ich > informiert bin, kann dieser Puls vom FPGA nicht direkt sinnvoll > verarbeitet werden. Daher plane ich, den Ausgang zunächst über einen > PRL-350TTL-Komparator zu führen, der bereits zur Verfügung steht. Dieser > vergleicht das Eingangssignal mit einer einstellbaren Referenzspannung > und gibt bei Überschreiten ein TTL-Signal aus, das sich wiederum > zuverlässig vom FPGA verarbeiten lässt. Sollte diese Annahme nicht > korrekt sein, freue ich mich über Hinweise oder Korrekturen. Randnotiz: Ein LVDS-Eingang ist u.U. ein prima Komparator. Aber vielleicht willst du auch eine weitere Baustelle eher vermeiden, oder du findest das richtige Referenzprojekt. Bei TTL-Out ist Vorsicht geboten, absolute Ratings checken. 5V vertragen die I/Os des FPGA nicht und mit Spannungsteilern musst du wieder die Impedanz beachten. > Zudem wäre ich dankbar, wenn ihr noch einmal auf das Thema > Clockerzeugung eingehen könntet: Ist es möglich, die höhere Taktfrequenz > direkt auf dem FPGA zu generieren, oder sollte dafür besser ein externes > Gerät verwendet werden? Falls letzteres der Fall ist, interessiert mich > insbesondere, welche technischen Gründe dafür sprechen. State of the Art FPGA hat typischweise eine PLL oder DLL. Da musst du dich als erstes reinlesen und gegen deine Anforderungen an Jitter checken. So wie ich es lese, hast du keine komplexen Regelschleifen im System, somit auch nicht allzuviele Stolperfallen. Ich wuerde mal ein FPGA und die Tools, die ihr im Haus habt, einfach hernehmen und die ersten Schritte machen, also PLL unter die Lupe nehmen. 160 MHz kriegt die Logik hin. Wenn du dann merkst, das der Kram zuviel jittert oder driftet, gehst du in die Optimierung, dann brauchst du die besagten TDC-Glieder und musst dich mit diversen Tricks im FPGA beschäftigen, wie Selbstkalibration, Temperaturdrift, usw. Wenn du dann die subtoptimalen Messwerte praesentieren kannst, hast du das Ganze relativ schnell auf Kintex, oder allenfalls MachXO2/3 oder ECP5 am Laufen. Ein Aspekt noch: Bei einer Masterarbeit ist schliesslich auch von Nutzen, "gut zu scheitern". Wenn einer mit einem 1.0-Endresultat vor einem rumwedelt, ist meistens irgendwas faul :-)
Moin, Martin S. schrieb: > Ein Aspekt noch: Bei einer Masterarbeit ist schliesslich auch von > Nutzen, "gut zu scheitern". Wenn einer mit einem 1.0-Endresultat vor > einem rumwedelt, ist meistens irgendwas faul :-) Ein Scheissaspekt. Wenn in der Masterarbeit ein 4.0-Endresultat steht (oder eine dem gleichkommende bessere, aber nicht gute Bewertung fuers scheitern), kommt man mit hoher Wahrscheinlichkeit nicht mal an den HR-Leuten vorbei, um sich dann von einem technisch versierten Mitarbeiter erklaeren zu koennen. Sollte man also geflissentlich vermeiden. Schon bei der Wahl des Themas. Gruss WK
>>> Wir haben noch einen alten Spartan-6 (XC6SLX45T) >> No comment. Ist seit 15 Jahren abgekündigt. > Zeigt mir mal bitte das Abkündigungsdokument! > > Der Chip wird immer noch beworben: Eben, ersten vor kurzem erzählte mir ein FAE das der Spartan-6 5-fach überbestellt ist. also es sind fünfmal soviele FPGA's bestellt wurden als die Produktionskapazitäten dafür vorhanden sind. * https://china.xilinx.com/content/dam/xilinx/publications/webinars/spartan-6-migration-webinar-faq.pdf Die Entwicklungs-Software dafür wird seit Jahren nicht mehr weiter weiter gereift, ist ja IMHO auch nicht nötig. > Evtl. ginge auch ein Red Pitaya, da sind 2 flotte AD und DA-Wandler > schon drauf + Xilinx. Beim Red Pitaya gibt es verschiedene Varianten mit unterschiedlicher Anzahl von Ein- und Ausgangskanälen, Bitbreiten und clocking Möglichkeiten: https://content.redpitaya.com/blog/stemlab-125-14-variants https://redpitaya.readthedocs.io/en/latest/developerGuide/hardware/GEN1/compares/vs.html Insgesamt ist aber der RedPitaye als Zynq-SoC-FPGA unter Linux etliche Lern-Kurven, ach was, Lern-Hochgebirgs-Aufstiege oberhalb eines reinen FPGA's. Ohne intensive Betreuung an der Grenze zur Teamarbeit statt Eigenverantwortliches Rumbasteln ist da für einen Newbie kein Blumentopp gewinnbar. Mal das Zynq-book lesen, der FPGA-Aspekt (PL) macht darin nur einen Bruchteil aus: https://is.muni.cz/el/1433/jaro2015/PV191/um/The_Zynq_Book_ebook.pdf
:
Bearbeitet durch User
>> Solange aber der TE nicht mit technischen Anforderungen, vor allem über >> Auflösungen und Genauigkeiten herausrückt > Du hast noch nicht viel mit Wissenschaftlern - respektive Physikern - zu > tun gehabt, oder? > Bei mir läuft gerade ein Projekt, wo sich die Anforderungen nahezu > wöchentlich ändern. Jackpot :( Jaja die Unschärferelation nach Heisenberg haben die Physiker von der Quantenphysik auch auf die Elektronik-Entwicklung übertragen: * weiss man was es kosten darf, weiss man nicht welche Funktionen man überhaupt realisieren bekommt * weiss man was es machen soll, will man die Kosten garnicht wissen um nicht den Verstand zu verlieren ... Oder so ähnlich: http://www.urantiansojourn.com/wp-content/uploads/2012/07/Dilbert_uncertainty_principle.gif
Dergute W. schrieb: > Ein Scheissaspekt. > Wenn in der Masterarbeit ein 4.0-Endresultat steht (oder eine dem > gleichkommende bessere, aber nicht gute Bewertung fuers scheitern), > kommt man mit hoher Wahrscheinlichkeit nicht mal an den HR-Leuten > vorbei, um sich dann von einem technisch versierten Mitarbeiter > erklaeren zu koennen. > Sollte man also geflissentlich vermeiden. Schon bei der Wahl des Themas. Das Thema ist hier in meiner Umgebung sehr gefragt, da spielt die Note weniger ein Rolle als das gitlab-Repo. Ansonsten gehe ich davon aus, dass die meisten Dozenten ein "gut dokumentiertes Scheitern" durchaus mit einer 1.5 auf dem Papier bewerten. Da hat mal ein 1.0-er Kandidat auch schon richtig Augen gemacht, als er weniger Punkte bekam als der "Gescheiterte". Bei Firmen mit derart gestalteten HR, die auf die Blender typischerweise reinfallen, will man als kreatives Talent sowieso nicht arbeiten, da sich die HR meist aus genau solchen Leuten zusammensetzt: Grundlagen nicht kapiert, nie im Dreck gewuehlt, schlagende Verbindung, oder ein McKinsey-Faehnchen aus der Hose haengen. Aber wir schweifen ab.. Thema RedPitaya: ZynQ und das ganze Vivado-Geraffel hat mir sogar als "Senior" nicht zugesagt. xsim ist eine Katastrophe mit VHDL. Wenn das nicht zwingend eine Linux-Loesung sein muss, faehrt man mit bare metal besser und ueberschaubarer, da sich das ganze System inkl Software mit Opensource-Tools co-simulieren laesst.
Angehängte Dateien:
-
Auswahl_176.png
120 KB -
rp_stecker.png
48 KB
Rick D. schrieb: > Gerhard H. schrieb: >> Evtl. ginge auch ein Red Pitaya, da sind 2 flotte AD und DA-Wandler >> schon drauf + Xilinx > Ja, aber der ist nicht wirklich für externes Clocking geeignet: > https://downloads.redpitaya.com/doc/Red_Pitaya_Schematics_v1.0.1.pdf > > Der ADC wird mit 125 MHz oder extern oder aus dem FPGA getaktet > (umlöten). Das FPGA hat auf diesem Board keinen dedizierten Takteingang. > > Moritz schrieb: >> Das System soll synchron zur Laserfrequenz laufen, > Damit lässt sich diese Forderung nicht erfüllen. Hä? Man verschiebt 2 SMD-Widerstände auf den Platz nebenan und speist seinen Wunschtakt mit LVDS-Pegel in den Flachkabel- Verbinder ein und der ADC reicht seinen Takt ans FPGA weiter. > Thema RedPitaya: > ZynQ und das ganze Vivado-Geraffel hat mir sogar als "Senior" nicht > zugesagt. xsim ist eine Katastrophe mit VHDL. Wenn das nicht zwingend > eine Linux-Loesung sein muss, faehrt man mit bare metal besser und > ueberschaubarer, da sich das ganze System inkl Software mit > Opensource-Tools co-simulieren laesst. Das erklärt dann wohl, warum der RedPitaya in fast allen Software Defined Radios von Funkamateuren ist. Gruß, Gerhard
:
Bearbeitet durch User
> Das erklärt dann wohl, warum der RedPitaya in fast allen > Software Defined Radios von Funkamateuren ist. Sorry, aber diese Aussage über die Nutzung des RedPidPitaya im Amateurfunk ist so missverständlich/nicht nachvollziehbar. Bei den wenigsten Funkamateuren dürfte SDR mit einem FPGA realisiert sein, insbesonders bei den beliebten SDR-Sticks. Und falls ein Funkamateur sich mit FPGA-Technik konstruktiv beschäftigt hat er eine große Auswahl an Eval-Boards. Will man in den Bereich oberhalb der KW-Bänder rutscht das Angebot zusammen, aber ist meines Wissens weitaus größer als "fast alle RedPitaya". Da wären bspw. das AdalmPluto von Analog Devices. In dem gerade mal einen Jahr alten thread werden noch ein paar mehr genannt: Beitrag "Warum gibt es eigentlich so gut wie keine SDR mit FPGA?" Entwickeln mit FPGA ist ziemlich komplex, komplexer als µC ans Laufen bringen und übersteigt somit die Fähigkeiten im Bereich HW - Entwicklung der allermeisten Funkamateure. (Sorry, ist aber so). Der Vorteil des RedPitaya als Board mag sein, das man es gleich als Oszilloskop und Signal-Generator ansetzen kann. Also dank Mehrfachfunktion Geld für Extra-Equipment gespart. Und "Sparen" findet man auch im Amateurfunk toll, da spart man sich schon bei der Modulation an Bandbreite (SSB statt A3E) ;-)
:
Bearbeitet durch User
Der Software-Support fuer RP ist unterirdisch, mit Verlaub. Auch wenn man mit gnuradio als Funki allenfalls damit anfangen kann Bei Echtzeit ist dann schnell mal schluss, fuer tiefergehende Entwicklung erfordert der gesamte SoC eine Menge an Fachwissen und Framework, womit man sich grandios verzetteln kann. Das liegt mithin auch an dem overengineerten ZynQ-Oekosystem. Alles andere steht schon oben Merke: 1) Der TE braucht das nicht. Er macht kein SDR. 2) Er sollte sich auf das eigentliche Thema fokussieren koennen, nicht auf Kerneltreiberprogrammierung 3) Man nimmt das beste existierende Werkzeug, wo ein Referenzprojekt vorliegt und einer vor Ort Grips und Tips hat. 4) Fanboys helfen nicht weiter
Hallo Moritz, also ich kann auch den Red Pitaya empfehlen. Als Software-Basis würde ich das Projekt von Pavel Demin nehmen: https://pavel-demin.github.io/red-pitaya-notes/ An Hand vorhandener Projekte kann man sehr schnell lernen, wie man z.B. Parameter von Linux (C oder Python) an den FPGA übergeben oder Messdaten vom FPGA per Netzwerk streamen kann. Diese Fähigkeiten sind schon sehr nützlich. Die vorhandenen Bausteine kann man dann durch eigenen Verilog oder VHDL Code erweitern. Aus den Bausteinen wird mit einem Skript (TCL) ein Blockdiagramm erzeugt. Es ist eleganter, minimalistischer Code, der einige der etwas aufgeblähten, komplizierten Struktur des Xilinx Systems vermeidet. Man braucht dann auch keine Linux Treiber entwickeln, wenn man nicht möchte. Mittlerweile gibt es auch eine ganze Menge an Online-Kursen zum Thema, um zu starten. Und zu Verilog/VHDL Simulation gibt es gut funktionierende Open Source Lösungen (Verilog/Cocotb/GTKWave). Bei Syntax-Problemen mit Verilog oder TCL oder sonstigen Problemen hilft auch ChatGPT. Die 80 MHz Clock könnte man auch über das neue MIKROE-5942 Click-Shield einspeisen. Viele Grüße, Moritz
Ich hab mal etwas aehnliches gebaut. Der Laser, dh die 80MHz sind der Clock fuer das FPGA. Die Anwendung war ein regenerativer Verstaerker. Als erstes lief ein Zaehler, wie lange der Puls in der Cavity drin war. Dann zwei kuerzere Zaehler, und schliesslich Delays. Damit wurden schliesslich optische Schalter angesteuert um den Puls rein und raus zu lassen. Das FPGA war ein ACEX, der konnte einen 32bit synchron zaehler mit 160MHz laufen lassen. Die Anbindung and das PC System machte ein AVR Probleme traten auf, wenn mal einer der 80MHz pulse fehlten ... das muss man bedenken. Ich wuerde den Laser erst in einem PLL geben, um die Frequenz und Phase zu duplizieren. Sodass kein Puls zum Zaehlen fehlt.
:
Bearbeitet durch User
Martin S. schrieb: > Mit etwas extra > Hirnschmalz kommt man auf seine 3-6ps single shot precision. Ne, wirklich nicht. Ich habe schon solche Systeme gebaut und der Jitter ist bei besten externen Takten eine Größenordnung höher und da reden wir jeweils von gegateten Signalen aus den FPGAs mit GaAs-FET hinten dran. Ist auch patentiert. Sobald da FPGA-Ausgänge direkt in das Timing eingreifen wird es noch schlechter, selbst bei eindem dedizierten Design das immer gleich schaltet, weil entkoppelt. Mit einem Spartan der oben reingeworfen wird, geht da schon mal gar nichts. Da geht es z.B. um die Unterdrückung des Ausgangsswings in Abh. von der Eingangspannung. Da braucht es eine alleinige Bank mit deterministischem Design und einer hochstabilen Versorgung und 1A-Blocking. Die FPGA-Ausgänge dämpfen zwar V-ripple um 40-60dB prim weg, aber bei solchen Anwendungen ist das oft noch zu schlecht.
Richtig, die SP6-Eingaenge sind teils besch... und die Streuuung ist immens. Vermutlich hast du eine der "schlechten" Chargen oder Packages verbaut, oder es fehlen halt die noetigen Tricks in der Selbstkalibration/Korrelation. Ohne die liegst du bei 25-50 ps. Teufel wie immer im Detail, mehr verrate ich auch hier nicht, falls der TO diese Genauigkeit ueberhaupt benoetigt (was ich eher bezweifle), bekommt er mit Sicherheit in den akademischen Kreisen genug Hilfestellung oder soll sich direkt melden. Eine genug exakte Zeitreferenz (GO 10e-18s) zur Verifizierung duerfte er haben. Wie gesagt, heute wuerde ich das mit einem ECP5 machen, da hat man ueber die Tools auch viel bessere Moeglichkeiten, die Logic prozedural zu instanzieren und zu plazieren, so dass die Resultate auch reproduzierbar werden. Mit dem Spartan6 ist das ein teures Lottospiel, da hatten wir einfach auch Glueck.
Ich habe dem Beitrag jetzt erst gelesen. Exakt so etwas habe ich letztes Jahr auch gemacht. Die Steuerung in einem FPGA, ein Elektroniker hat mir noch eine DAC-Platine erstellt. Ich habe vorher schon gemeint: es wird nie funktionieren. Ich habe dann also 6 Monate an einem FPGA entwickelt. VHDL und Spartan kannte ich schon. Aber dann mußte ich auch noch Floating-Point Bibliotheken benutzen. Und das ganze Timing passte nicht mehr. Letztendlich hat es nicht funktioniert, ist nie zum Debugging gekommen, und war eine große Zeitverschwendung. Meine Empfehlung: mach etwas anderes. Wenn du noch nie etwas mit VHDL/Verilog gemacht hast, rechne noch mal 4 Monate Zeit dazu.
> Ich habe vorher schon gemeint: es wird nie funktionieren. ^^^^^^ Das ist das Problem, negative Grundeinstellung und der Hang zu selbsterfüllenden Prophezeiungen. > Wie gesagt, heute wuerde ich das mit einem ECP5 machen, da hat man ueber > die Tools auch viel bessere Moeglichkeiten, die Logic prozedural zu > instanzieren und zu plazieren, so dass die Resultate auch reproduzierbar > werden. Mit dem Spartan6 ist das ein teures Lottospiel, da hatten wir > einfach auch Glueck. Beim Spartan 6 resp. mit dem FPGA-Editor der ISE-Toolchain hat man auch die Möglichkeit LOCation-Constraints zu vergeben und mit "dedicated routing" Teile des Routings "einzufrieren". Das ist z.T. für die DDR-Mems nötig. Nix Lotto, zeigen lassen wie es geht.
:
Bearbeitet durch User
Bradward B. schrieb: > Beim Spartan 6 resp. mit dem FPGA-Editor der ISE-Toolchain hat man auch > die Möglichkeit LOCation-Constraints zu vergeben und mit "dedicated > routing" Teile des Routings "einzufrieren". Das ist z.T. für die > DDR-Mems nötig. > > Nix Lotto, zeigen lassen wie es geht. "Manuelle Plazierung" schrieb ich ja weiter oben schon. Das ist ja genau der Gag an der Reproduzierbarkeit einer TDC und die Voraussetzung als solches. Muehsam wird es dann, wenn man per HDL und den Vendor-Tools auch noch stoerende Logik zwingend von Hand in einem andern Quadranten routen muss, via nextpnr geht das viel effizienter, aber ist genauso weit vom eigentlichen Fokus weg. Das Lotto kommt aus den Varianzen im Samsung-Prozess und Packaging. Touchy subject...fuer Forschung eine gute Uebung des "optimalen Scheiterns", fuer ein Produkt: Njet.
> Das Lotto kommt aus den Varianzen im Samsung-Prozess und Packaging.
Samsung macht die Xilinx-Chips? Ich dachte, das wäre TSMC und Co.. und
jetzt vielleicht AMD resp. Global Foundries.
Prinzipiell natürlich korrekt, anderes Package, neuer Spass. Dann muss
man schauen, ob man das mit Regelschleifen hinbekommt, Trainingsphasen
für die IO-delays an den Spartan6 Pads bspw..
Bei der ganzen Diskussion wird erst mal des Laengeren ueber den unbedingt benoetigten Hammer diskutiert, bevor man sich die Schraube genauer anschaut. Timing ? Welches Timing ? Das Timing wird vom Laser vorgegeben. Nein, ein externer Generator passt nicht, der Laser gibt das Timing vor, ausser er waere auf einen Generator gelockt. Es koennen uebrigens auch zwei Pulse pro Umlauf vorkommen, oder hin und wieder einer fehlen. Deswegen ... mit dem Laser auf einen PLL zB AD4001, resp incl. VCO und dieselbe Frequenz nochmals erzeugen. Die ist dann immer Synchron zum Laser. Das zu detektierene Ereignls, das Photon ist nicht irgendwann, sondern streng synchron zum Puls. Falls eine Reaktionszeit bestimmt werden soll, zB bei Fluoreszenz, misst man statistisch mit Zeitfenstern, als Histogram. Wenn die Reaktionszeit Null ist, zB bei einem Verdoppler, genuegt ein gegateter Zahler. Ich hab mal einen Histogrammzaehler gebaut. Da wurde ein schneller Zaehler vom Laserpuls genullt, und alle Zeitscheibe in eine neue Speicherstelle addiert. Der schnelle Zaehler wurde vom Photomultiplier angesteuert. Die Zeitscheiben waren einstellbar 10, 20, 50, 100, 200, 500ns und Mikrosekunden. Nach N (10k, 100k, 1M) Schuss wurde dann ausgelesen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.