Hallo, Ich versuche gerade ein Testprojekt zum funktionieren zu bringen wo ich 2 unterschiedliche Takte habe. Bisher habe ich der Einfachheit halber immer nur mit einem Takt gearbeitet oder von einer schnellen auf eine langsame clock domain zugegriffen (Signale über flipflops einsynchronisiert). Jetzt versuche ich aber genau den umgedrehten Fall, von langsam auf schnell und da klappts natürlich mit dem timing überhaupt nicht mehr. Quartus meckert zu Recht an das timing kann nicht eingehalten werden (setup negative slack, ~ -4ns). Versuche an irgendwelchen constrains rumzubasteln und es damit hinzubekommen sind an nicht-wissen kläglich gescheitert von daher hab ich es erstmal anders probiert, leider ohne Erfolg. Also das ganze ist ein USB keyboard -> PS2 converter und PS2 frame decoder: Haupttakt top level entity = 50 MHz ulpiToPS2 Komponente und PS2decoder Komponente Takt = 60 MHz -30° verschoben zu einem externen 60 MHz Takt vom USB phy, generiert durch eine PLL, die Verschiebung muss wohl beim deca board so sein sonst gibt es Probleme mit dem TUSB1210. Der PS2decoder hat 3 outputs: - FrameReceived (1 bit) (wird gesetzt wenn ein PS2 frame empfangen wurde und gelöscht wenn FrameAck gesetzt ist) - FrameError (1 bit) (wird gesetzt wenn ein Fehler im empfangenen PS2 frame erkannt wurde (parity, stop bit) oder FrameReceive noch gesetzt ist(overflow) ansonsten gelöscht) - FrameData (8 bits) und 1 input: - FrameAck (1 bit) auf diese soll das toplevel entity zugreifen. Also mein Versuch einfach die Signale jeweils über 2 flipflops zu schicken (FrameAck 2 ffs getaktet mit 60 MHz, FrameReceived 2 ffs getaktet mit 50 MHz usw.) hat an der Situation nichts geändert, was mich auch nicht wirklich überrascht hat. Mein nächster und auch letzter Versuch, von dem ich mir eigentlich mehr erhofft hatte, war zusätzlich die output Signale zu "verlängern" also deren Zustand über n Takte zu halten. Wahrscheinlich habe ich das total falsch gemacht (Prozess mit nem counter und alle x (habe Werte von 4 bis 100 probiert) 60 MHz Takte werden die outputs vom ps2Decoder übernommen) denn das hat absolut nichts geändert, egal wieviele Takte "gehalten" wurde. Hatte versucht mehr oder weniger das umzusetzen was in Cummings "Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog" Dokument steht aber anscheinend nicht verstanden. Hat evtl. jemand nen link zu einem einfachen funktionierenden Beispiel design (wenn möglich bitte VHDL) wo sowas gemacht wird? Oder eine einfache Erklärung was hier die richtige Vorgehensweise ist? MfG Christian G. P.S. evtuelle Fragen kann ich leider erst nach dem WE beantworten
Takte verschieben wird man i.d.R nur, um Eingangssignale zu sampeln, die um die Clock-Flanke herum wechseln. Zwischen zwei internen Domänen kann man dann vereinfacht arbeiten, wenn die Takte tatsächlich ganzzahlig zueinander sind, oder in Sonderfällen, wenn für alle Flankenkonstellationen ausreichende Reserven bestehen. Dann kann man mit der Periode des schnelleren Takte ein Multi-Cycle aufsetzen und das Timing so entspannen. Im Normalfall muss man sampeln und synchronisieren, d.h. man muss mit einen ausreichen schnellen Takt abtasten, auf Stabilität prüfen oder (Normalfall) diese annehmen (z.B. mit einem strobe) und dabei gfs. Nyqist beachten. Dies kann man bei Taktkonstellationen von besser als 1:2 in gewohnter Weise. Bei kleiner als 1:2, z.B. bei 2:3 geht es durch parallele Strukturen mit jeweils einem Multicycle auf den langsameren Takt, um die Eingangsfrequenz zu "halbieren" und sicherzustellen, dass der Zieltakt beide Flanken sieht. Idealfall: Wenn in der Zieldomain etwas Dynamik an Verarbeitung zugelassen werden kann, was ausreichende Bandbreite erfordert, sind asynchrone FIFOs die beste Wahl. Im Einzelfall ist das ein Triple-Buffer oder bei günstigen Konstellationen ein Wechselbuffer, der wiederum zu ähnlich funktioniert, wie die Vorgehensweise "parallele Struktur + MultiCon".
Die Probleme an taktdomainübergängen löst man nicht mit timing-constraints sondern per Schaltungstechnik: DualPort-RAM, FIFO, kette aus synchronidierungs-FF. Aus dem TO-posting geht jetzt nicht hervor, woran der TO "Das Scheitern" seiner Lösungsansätze erkannt haben will. Simulation? Oder kotzt dem die Toolchain irgendwas Unappetitliches vor die Füße? Der Code ist im Falle von Synchronisierungs-FF so simple das es sich nicht lohnt diesen als Beispiel hier anzugeben. Pulsverlängerung über mehrere Takte kann da schon trickreicher sein. Seite 16 des PDF;s zeigt blockbilder verschiedene synchronizer. Einfach das mit den einschlägigen VHDL-Mittel zur FF-Beschreibung umsetzen. http://ebook.pldworld.com/_eBook/FPGA%EF%BC%8FHDL/-Examples-/clock%20synchronization.pdf
DSGV-Violator schrieb: > kette aus synchronidierungs-FF. Und trotzdem braucht es zusätzlich noch ein Constraint damit die Toolchain auch weiß was man da macht und dann auch keine Timingverletzung meldet. Also false path zwischen den Signalen oder Clocks.
:
Bearbeitet durch User
> Und trotzdem braucht es zusätzlich noch ein Constraint damit die > Toolchain auch weiß was man da macht und dann auch keine > Timingverletzung meldet. Ich geh davon aus, das es kein constraint gibt wenn kein constraint explizit definiert wurde und sich daher das einzusynchronisierende Signal in den der Klasse der unconstrained pathes findet und somit nicht in die STA eingeht. Aus den normalerweise definierten period constraint für eine einzelne clock domain (Baseline constraints), bastelt IMHO die STA nicht automatisch eins für domainwechselnde signale. Also erwarte ich nicht, das da irgendwas zu false path umdeklariert werden muß. Aber natürlich schadet es sicher nicht, sich mal alle Pfade anzeigen zu lassen, die die STA für domain crosser hält: https://docs.xilinx.com/r/en-US/ug949-vivado-design-methodology/Constraining-Clock-Domain-Crossings Und wenn man mal an Taktübergangen ein constraint setzt, dann kann das auch bewusst ein kleines sein: Da die FF eher kurz im metastabilen Zustand verweilen, verringert eine kurze Signallaufstrecke die Wahrscheinlichtkeit, das der Metastabile Zustand in das nachgeschaltetet FF propagiert. Interessanterweise ist das bei altera/intel anders formuliert ("is essential*") https://www.intel.com/content/www/us/en/support/programmable/articles/000080400.html Wobei es doch scheint, das intel hier von taktdomainen spricht, die tatsächlich einen fixen bezug zueinander haben (phasenstarr). Die Einsynchronisation zwischen complett unäbhängigen Taktdomainen zählt da wohl eher nicht darunter. Früher (ISE) hiess es, es nicht mit der Anzahl der definierten constraints, auch der false path constraints "nicht zu übertreiben". weil das die STA signifikant verlangsamt. Nur constrainen was nötig, und asnychrone Pfade zähl(t?)en nicht darunter.
DSGV-Violator schrieb: > und sich daher das einzusynchronisierende Signal in den der Klasse der > unconstrained pathes findet und somit nicht in die STA eingeht. Wenn das Signal von Extern kommt ja, aber wenn da Clock Constraint DSGV-Violator schrieb: > Aus den normalerweise definierten period constraint für eine einzelne > clock domain gesetzt ist, dann glaubt die STA dass alle Signale die mit einer dieser Clocks getaktet sind zu dieser Clockdomain gehören. Will man also von einem getakteten Signale einer Clock zu einem getakteten Signal einer anderen Clock, so muss man einen False Path oder die Clocks/Signale asynchron setzen.
DSGV-Violator schrieb: > Interessanterweise ist das bei altera/intel anders formuliert ("is > essential*") > https://www.intel.com/content/www/us/en/support/programmable/articles/000080400.html Das ist für die "Timing Driven Synthesis" u.U. wichtig. Ein einfaches set_false_path sagt der nur "interessiert mich nicht". Wenn's dann ums Optimieren geht, fasst der Fitter den CDC-Timingpfad gar nicht an und legt ihn im dümmsten Fall einmal quer durchs ganze Design. Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über Clock Groups und definiert einen Max-Delay über die CDC-Logik. Damit "sieht" der Fitter, dass uns der Pfad eben doch interessiert. Ich denke, das wird bei Vivado (das auch Timing-Driven Synthese beherrscht?) auch nicht anders gehandhabt werden.
Markus F. schrieb: > Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über > Clock Groups und definiert einen max_delay über die CDC-Logik. Damit > "sieht" der Fitter, dass uns der Pfad eben doch interessiert. Das klingt für mich nach einem Widerspruch zur Aussage von Gustl: > Und trotzdem braucht es zusätzlich noch ein Constraint damit die > Toolchain auch weiß was man da macht und dann auch keine > Timingverletzung meldet. > Also false path zwischen den Signalen oder Clocks. Also bei Signalen zwischen (internen,nicht phasen starren) clockdomains haben wir jetzt drei Möglichkeiten: * [NO_CON] kein explizites constraint * [FALSE_PATH] set_false_path constraint ? * [MAX_DEL] set_max_delay constraint ? Und es wurde angedeutet das man für STA und timing_driven_synthesis dies Unterschiedlich handhaben könnte. Vielleich kann man es so reglementieren, das bei der STA als Verificationsschritt der requiremets alle constraints gesetzt werden müßen, während man bei der (zeitinsensiven) timing-driven synthesis sich auf die für die Synthese erforderlichen beschränkt und diese ergänzt, falls die STA Verletzungen meldet die sich nicht durch HDL-Code Optimierungen beheben lassen? Daher tendiere ich persönlich zu Variante [NO_CON] und falls die STA meckert auf [MAX_DEL]. Das der Pfad exterm lang wird (> 10 ns) , ist mir bei Xilinx mit ihren vielen fein granularen routing ressourcen noch nicht passiert, da seh ich die Gefahr eher bei altera mit den Long und short lines zum routing.
DSGV-Violator schrieb: > drei Möglichkeiten: > > * [NO_CON] kein explizites constraint > * [FALSE_PATH] set_false_path constraint ? > * [MAX_DEL] set_max_delay constraint ? NO_CON ist bei Intel keine Option (es sei denn, man stört sich nicht an knallroten Timing Reports). Die Quartus STA betrachtet immer alle Pfade, die nicht explizit (entweder über clock groups oder set_false_path) isoliert/ausgeschlossen werden. Deswegen ist die richtige Option, schlicht das zu machen, was in dem von dir verlinkten Artikel steht.
Markus F. schrieb: > Deswegen ist die richtige Option, schlicht das zu machen, was in dem > von dir verlinkten Artikel steht. Ich finde auch false_path OK. Wenn einem egal ist ob das Signal vielleicht erst mehrere Takte später da ist, dann ist das ein schneller Weg um Timingfehlermeldungen zu vermeiden. Mache ich gerne und das funktioniert gut wenn man seinen Code kennt. Wichtig ist auch die Realität korrekt mit Constraints anzugeben. Takte die nicht phasenstarr sind sollte man auch so über asynchrone Clocks definieren.
Christian schrieb: > Der PS2decoder hat 3 outputs: > - FrameReceived (1 bit) (wird gesetzt wenn ein PS2 frame empfangen wurde > und gelöscht wenn FrameAck gesetzt ist) > - FrameError (1 bit) (wird gesetzt wenn ein Fehler im empfangenen PS2 > frame erkannt wurde (parity, stop bit) oder FrameReceive noch gesetzt > ist(overflow) ansonsten gelöscht) > - FrameData (8 bits) Wenn Du hier nur - so habe ich dich jedenfalls verstanden - die Received und Error Bits synchronisierst, müssen die Daten (FrameData) längst nicht mehr aktuell sein, wenn die synchronisierten Bits auf der anderen Seite des CDC ankommen. Der sicherste Weg dürfte hier sein, bei FrameReceived alle Signale aneinander zu kleben, durch einen dual clock FIFO zu schicken und auf der anderen Seite wieder auseinander zu nehmen.
:
Bearbeitet durch User
Angehängte Dateien:
-
ps2kb.png
28 KB
Christian schrieb: > Der PS2decoder hat 3 outputs: Blockbild über die beiden(?) domains PS2 und USB sollte stark den Überblick erleichtern. PS2-Tastatur ist eigentlich schnarch langsam da Zappelt doe signale im zweistelligen µs Bereich (siehe Anhang aus: https://www.networktechinc.com/ps2-prots.html) > die Verschiebung muss wohl beim deca board so sein sonst gibt > es Probleme mit dem TUSB1210. wo sitzt dieser Chip konkret? Sowie es ausschaut, musst du lediglich ein funktionierendes ULPI-IF verwenden. https://www.ti.com/lit/ds/symlink/tusb1210.pdf?ts=1682244132263&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252Fde-de%252FTUSB1210 der ULPI-chip scheint den clock zu seinen signalen mitzuliefern also scheint es nicht weiter kompliziert zu sein: https://ww1.microchip.com/downloads/en/AppNotes/en562704.pdf
DSGV-Violator schrieb: > PS2-Tastatur ist eigentlich schnarch langsam Und weil das so ist, braucht man keine zweite Taktdomäne sondern kann alles mit einem schnellen Takt machen. Mit dem tastet man die sehr viel langsameren Eingänge ab. Man kann sie entprellen, Flankenerkennung machen, ...
Hallo, vielen lieben Dank für die ganze Hinweise und links, alles absolut wertvoll für mich! Ja, ein wenig peinlich, das "Problem" ließ sich innerhalb 1 min. lösen. Also ihr habt natürlich absolut Recht, die PS2 Signale sind total langsam im Vergleich zum Rest des designs. Deshalb hatte ich auch schon synchronisation und Flankenerkennung etc. in den PS2decoder eingebaut. Was am Ende gefehlt hat waren wirklich nur zwei Zeilen die einen false path setzen zwischen den PS2 signalen von der ulpi Komponente zum PS2decoder und halt den PS2decoder mit der main 50MHz clock laufen lassen. ... einen schönen Sonntag noch!
DSGV-Violator schrieb: > sich daher das einzusynchronisierende > Signal in den der Klasse der unconstrained pathes findet und somit nicht > in die STA eingeht. Das stimmt aber so nicht. Das tool wird vielmehr versuchen, das timing zu treffen, was ihm gfs nicht möglich ist. Unconstrained ist der Path nicht. DSGV-Violator schrieb: > Da die FF eher kurz im metastabilen > Zustand verweilen, verringert eine kurze Signallaufstrecke die > Wahrscheinlichtkeit, Warum sollte das so sein? Wenn das FF verspätet kippt, ist ein entfernter plaziertes FFs dagegen resistenter, weil in dem Fall eines glitches, das Zucken nur in der Nähe zu einer ausreichenden Amplitude führt, weiter weg aber einen geringen Hub hat und damit weniger wahrscheinlich als falsch erkannt wird. Gustl B. schrieb: > Also false path zwischen den Signalen oder Clocks. False path darf man laut unseren design Vorgaben gar nicht verwenden. Es muss ein verlängertes Timing Constraint aufgesetzt werden und zwar nur auf dieses Signal und nicht auf den gesamten Takt. Markus F. schrieb: > Die im Link genannte Vorgehensweise "isoliert" die Clock-Domänen über > Clock Groups und definiert einen Max-Delay über die CDC-Logik. Damit > "sieht" der Fitter, dass uns der Pfad eben doch interessiert. Ja und nein. Der Placer "sieht" dass er entspannter arbeiten darf und die Timing Analyse hat eine weniger enge Vorgabe, welche dann bei Prüfung durchgeht. Interessieren tut uns das Signal in beiden Fällen: Ist nichts angegeben, welchen die weitergetretenen Vorgaben von dem jeweiligen Takt in Verbindung mit der jeweils annehmenden Taktflanke.
Georg B. schrieb: > False path darf man laut unseren design Vorgaben gar nicht verwenden. Zum Glück arbeite ich wo anders. Ich finde es nicht gut wenn Dinge pauschal verboten werden. Gerade im Beispiel oben mit einer sehr langsamen Clock und einer schnellen Clock machen doch Georg B. schrieb: > ein verlängertes Timing Constraint nicht wirklich Sinn. Eigentlich macht auch der langsame Takt keinen Sinn sondern man nimmt den schnellen Takt und erzeugt sich enable Signale. Ich finde false_path macht auch zwischen Clocks Sinn wenn man weiß was man macht. Wenn man da überall schön dual Clock FIFOs drinnen hat oder eintaktet oder das mit Handshake übergibt, dann reicht es mir das mit false path zu constrainen.
> DSGV-Violator schrieb: >> Da die FF eher kurz im metastabilen >> Zustand verweilen, verringert eine kurze Signallaufstrecke die >> Wahrscheinlichtkeit, > Warum sollte das so sein? Wenn das FF verspätet kippt, ist ein > entfernter plaziertes FFs dagegen resistenter, weil in dem Fall eines > glitches, das Zucken nur in der Nähe zu einer ausreichenden Amplitude > führt, weiter weg aber einen geringen Hub hat und damit weniger > wahrscheinlich als falsch erkannt wird. Nope, da hat man Zusammenhang zwischen propagation delay: t_prop und recovery time: t_rec nicht verstanden. Wenn beim ersten FF eine timing Verletzung auftritt, erscheint für die dauer von t_rec ein metastabiler Zustand am Q-Ausgang, der t_prop später am D-Eingang des/der folgenden FF auftritt. Nimmt man beispielhaft an, die Takt-periode sei 10 ns, t_rec sei 5 ns und für den t_prop zwischen FF1 und FF2 rechnet man zwei Varianten durch: * t_prop_near (nah platziertes FF) = 4ns und * t_prop_far (fern platziertes FF) = 9ns. Daraus ergibt sich folgender zeitlicher Verlauf: * FF1 fällt von t=0 bis t=t_rec = 5ns in einen metastabilen Zustand, * FF2_near 'sieht' diesen metastabilen Zustand T_prop_near später, also von t= 4 bis 9 ns * FF2_far 'sieht' diesen metastabilen Zustand T_prop_far später, also von t = 9 bis 14 ns. Da aller 10 ns der Takt kommt, wird das fern platzierte FF getaktet, wenn an dessem Eingang der metastabile Zustand anliegt; der metastabile Zustand propagiert also tiefer in das Design. Dagegen das nah platzierte FF wird getaktet, zu einem zeitpunkt zu dem der metastabile Zustand an seinem Eingang schon wieder abgeklungen ist. ++++ >> sich daher das einzusynchronisierende >> Signal in den der Klasse der unconstrained pathes findet und somit nicht >> in die STA eingeht. > Das stimmt aber so nicht. Das tool wird vielmehr versuchen, das timing > zu treffen, was ihm gfs nicht möglich ist. Unconstrained ist der Path > nicht. Nicht jedes tool ist gleich und wo kein constraint gesetzt ist, gibt es auch kein timing das einzuhalten ist. Das sieht man insbesonders an den tools die kein SDC-Format für timing spezifikation kennen, wie die ISE. Das period-constraint der ISE trifft nur FF in der selben Taktdomain: "If the clocks are not related, the cross clock domain paths are not analyzed." Xilinx UG612 V13.2 p.120 https://redirect.cs.umbc.edu/~tinoosh/cmpe691/tutorials/timing-constraint-guide.pdf Will man den Pfad durch das tool analysiert haben, muß man explizit ein FROM TO constraint setzen.
Gustl B. schrieb: > false_path macht auch zwischen Clocks Sinn wenn man weiß was > man macht. dann nimmst du dir aber die Möglichkeit, dass das Werkzeug das Timing prüft.
Zur Ergänzung: Bei Vivado gibt es das constraint ASYNC_REG, um Vivado anzuweisen, solche Einsynchroniserungs-FlipFlops möglichst nah beeinander zu halten. Das plus false_path verwende ich bei meinen CDC-FFs. https://docs.xilinx.com/r/en-US/ug912-vivado-properties/ASYNC_REG
Gustl B. schrieb: > Ich finde auch false_path OK. Wenn einem egal ist ob das Signal > vielleicht erst mehrere Takte später da ist, dann ist das ein schneller > Weg um Timingfehlermeldungen zu vermeiden. Das ist aber kein sauberer Weg. Dafür haben wir ja das MultiCycleContraint. Man sollte das schon so "einpferchen" wie es real benötigt wird. DSGV-Violator schrieb: > Die Probleme an taktdomainübergängen löst man nicht mit > timing-constraints Indirekt schon, wenn man dort, wo man entspannen kann, auch entspannt, weil durch die timing-gesteuerte Platzierung sich auch das routing ändert, womit sich dann das reale timing der Schaltung ändert und somit die timing-checks an anderen Stellen wieder gut ausgehen können.
J. S. schrieb: > weil durch die timing-gesteuerte Platzierung sich auch das routing > ändert Das liest man oft, aber kann man das irgendwie mal mit Zahlen oder Berichten untermauern? Klar, ich glaube schon dass das stimmt, habe ich auch selber schon gesehen. Aber wie weit geht diese Optimierung? Werden da wirklich "Umwege" geroutet damit ein Signal gegenüber eines anderen Signals verzögert wird? Werden automatisch Idelays eingebaut (habe ich noch nicht gesehen aber vielleicht auch nicht die passenden Constraints verwendet)? J. S. schrieb: > Gustl B. schrieb: >> Ich finde auch false_path OK. Wenn einem egal ist ob das Signal >> vielleicht erst mehrere Takte später da ist, dann ist das ein schneller >> Weg um Timingfehlermeldungen zu vermeiden. > > Das ist aber kein sauberer Weg. Dafür haben wir ja das > MultiCycleContraint. Ja und nein. So wie ich das verstehe sagt man mit dem MultiCycle Contraint eben, nach wie vielen Takten man das Signal stabil (!) haben will. Aber was soll ich da hinschreiben wenn mir das egal ist und ich das in der anderen Taktdomäne selber eintakte in mehrere FFs? false_path ist aus meiner Sicht die Anweisung "bemühe dich gar nicht", also genau das was ich an dem Punkt will.
Gustl B. schrieb: > J. S. schrieb: >> weil durch die timing-gesteuerte Platzierung sich auch das routing >> ändert > > Das liest man oft, aber kann man das irgendwie mal mit Zahlen oder > Berichten untermauern? Das lässt sich ja leicht ausprobieren, wenn man die post routing Analyse bemüht. Außerdem merkt man es ja daran, dass sich das timing der Problempfade verbessert (es sei denn, er verrennt sich, was ja auch passieren kann). Gustl B. schrieb: > Werden da wirklich "Umwege" geroutet damit ein Signal gegenüber eines > anderen Signals verzögert wird? Das wohl nicht, jedenfalls nicht ausdrücklich. Wozu auch? Der Werdegang ist der, dass das entspannte Signal weiter hinten in die Liste wandert und später angefasst wird. Damit werden die zeitkritischen Signale früher behandelt, haben bessere Optionen und indirekt wird das entspannte Signal "umständlicher" geroutet. So richtig zutage tritt das bei gut gefüllten FPGAs, bzw SLRs. Gustl B. schrieb: > Aber was soll ich da hinschreiben wenn mir das egal ist Das kann einem streng genommen nicht egal sein, weil es aus funktioneller Sicht immer eine Anforderung für die maximale Zeit gibt, die vergehen darf, bevor ein Design auf eine Signaländerung reagiert - auch wenn es Millisekunden sind und damit Tausende Zyklen. In solchen Fällen ist ja auch immer ein funktioneller oder formeller Nachweis zu führen, dass das klappt. Dabei muss u.U. die Latenz des designs berücksichtigt werden. Das ist regelmäßig bei Schaltungen der Fall, die irgendwelche Alert-Signale von Chips verarbeiten sollen, aber noch Filter und Signaldekodierung im Pfad haben. In dem Fall, wo das nicht definiert ist, kann man natürlich tatsächlich ein Ignore auf den Pfad setzen.
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.