FPGA Feedforward-System in Quantenoptik-Experiment

[Moritz (moritz2001)]

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

[J. S. (engineer)]

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)

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> 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/ )

[Martin S. (strubi)]

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?

[Gerhard H. (ghf)]

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

[J. S. (engineer)]

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?

[Martin S. (strubi)]

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..