Hallo erstmal, ich habe mal bezüglich Erfahrungen mal ne Frage zu meinem Design. Ganz kurz gefasst habe ich folgendes Problem: Bin zur Zeit in der Entwicklungs- und Testphase meines Design, baue daher ab und zu Änderungen im Code ein. Dementsprechend implementiere ich mein Design von neu und lade es mit impact auf mein FPGA. Nun stelle ich manchmal fest, dass das Design manchmal nicht richtig läuft, dass Funktionen die vorher alle liefen, jetzt teilweise nicht mehr laufen, obwohl die Änderung im Code, mit diesen Funktionsteilen nicht mal zusammenhängen (mit Funktionen bzw. Funktionsteilen meine ich sowas wie Kommunikation[Uart], FFT, Fifos). Habe folgende Sachen im Design als Sicherheit eingebaut: Aktuell habe ich 2 Clockdomains in meinem Design, die ich mittels eines externen 100MHz taktes über eine DCM mir erzeuge. Im Design werden dann 100MHz(Systemtakt) und 59,...MHz (für Kommunikationseinheit) benutzt. Das LOCKED Signal der DCM verwende ich für die Clocks als Enable, quasi zwei BUFGCE habe ich dafür verwendet. Dadurch habe ich sichergestellt, dass die beiden Clock mit der pos. Flanke zum gleichen Zeitpunkt starten (habe es am Oszilloskopen mir auch dargestellt und verifiziert). Der Startup_Wait der DCM ist auch auf TRUE und die einstellungen unter Impact(Startup Options) habe ich eingestellt wie folgt: Done_cycle = 4, GTS_cycle = 1, GWE_cycle = 1 und LCK_cycle = 2. Weiterhin habe ich alle internen Signale auch initialisiert. Alle externen Signale (sind wenige) werden auch mit mind. 2 FFs einsynchronisiert. Bei den Taktdomains 100MHz und 59,...MHz erfolgt der Datenaustausch ausschließlich über Fifos. Auch evtl. Flags in diesen Taktdomains werden einsynchronisiert und dann verwendet. Als Timing-Constraints habe ich nur die 100MHz angegeben. Ich wollte erstmal vermeiden Programmteile aus meinem Code zu posten, da es mir erstmal um das allgemeine Design geht, quasi um Techniken wie synchronisationen usw. Falls gewünscht kann ich evtl. Programmteile posten. Was ich jetzt nicht verstehe ist, dass mein Design ab und zu, aber auch öfters nach einer Neuimplimentierung (natürlich mit Änderung im Code) nicht mehr richtig läuft. Wenn es mal richtig läuft, quasi alle Funktionen wie erwartet laufen, dann gibt es auch keine Probleme wenn ich z.B. die Bit-File neu rauflade. Worauf ich mich beziehen will ist, dass ich versucht habe mein Design immer stets synchron zu entwickeln und auch Sachen wie Startup verhalten habe ich schon berücksichtigt. Doch warum funktioniert es ab und zu nach einer Neuimplimentierung nicht? Woran kann so was denn liegen? Bräuchte hier mal Erfahrungen von euch, ob ihr auch schon mal mit solchen Problemen rumhantieren müsstest. Vielleicht noch Erwähnenswert, dass Design ist zur Zeit aktuell ca. 25% Slice Luts und 22% Slice Registern belegt. Freu mich schon auf Anregungen. Danke Gruß Cihan
Cihan Kalayci schrieb: > Nun stelle ich manchmal fest, dass das Design nicht richtig läuft, dass > Funktionen die vorher alle liefen, jetzt teilweise nicht mehr laufen, > obwohl die Änderung im Code, mit diesen Funktionsteilen nicht mal > zusammenhängen (mit Funktionen bzw. Funktionsteilen meine ich sowas wie > Kommunikation[Uart], FFT, Fifos). Wie schnell stellst du das fest? Wie oft passieren Fehler? Wie ässern sich solche Fehler? > Als Timing-Constraints habe ich nur die 100MHz angegeben. Mehr brauchst du auch nicht, denn die 60MHz sind ja daraus abgeleitet...
Lothar Miller schrieb: > Cihan Kalayci schrieb: >> Nun stelle ich manchmal fest, dass das Design nicht richtig läuft, dass >> Funktionen die vorher alle liefen, jetzt teilweise nicht mehr laufen, >> obwohl die Änderung im Code, mit diesen Funktionsteilen nicht mal >> zusammenhängen (mit Funktionen bzw. Funktionsteilen meine ich sowas wie >> Kommunikation[Uart], FFT, Fifos). > Wie schnell stellst du das fest? Wie oft passieren Fehler? Wie ässern > sich solche Fehler? Anhand meiner Daten, die ich zum FPGA per UART schicke sehe ich sehr schnell, ob es Kommunkationsprobleme gibt(sehr selten gewesen), ob ebend die Daten auch an den richigen Stellen im Design in die dazugehörigen Fifos und Brams hineingelangen, ob Bspw. die FFT richtig gelaufen ist usw. Da ich mir immer meine Daten vor der FFT, nach der FFT und nach der Verabeitung der FFT-Output Werte sofort sehe (sende die Daten per Uart-Schnittstellen raus und empfange sie über Hterm), kann ich sie anhand von Referenzdaten die ich mir per Software am PC erstellt habe vergleichen. Dann sehe ich sofort ob mein Design grad richtig läuft oder nicht. Cihan
Manchmal habe ich allerdings auch den Fall, dass jetzt nicht die Daten Fehlerhaft sind, sondern beispielsweise läuft die FFT(übrigens mit dem Xilinx Core Generator erstellt) aus irgendeinem Grund nicht oder die FFT läuft, aber die Ausgangsdaten werden nicht verarbeitet. Der Fehler liegt also nicht immer in den Daten. Cihan
Ich hatte mal ein ähnliches Problem, als ich Gigabit-Ethernet
implementiert hab.
Die Ursache war, daß ich keine Timing-Constraints für Signale zum PHY
definiert hatte. Den Takt zwar sehr wohl, aber eben nicht die
Setup/Hold-Zeiten der einzelnen Datensignale.
Das hat dann ein sehr willkürliches "mal gehts, mal nicht"-Verhalten
erzeugt.
Seit ich die Timing Constraints drinn hatte, geht's immer.
Auch interessant: Alternativ hätte laut Aussage eines Kollegen auch
geholfen, die I/O-Register in die IOBs zu erzwingen ("Pack I/O
Registers/Latches into IOBs").
Bronco schrieb: > Auch interessant: Alternativ hätte laut Aussage eines Kollegen auch > geholfen, die I/O-Register in die IOBs zu erzwingen ("Pack I/O > Registers/Latches into IOBs"). Das Attribute war bei mir auf Auto, habe es mal jetzt auf Yes gesetzt. Werde es mir mal anschauen. Bronco schrieb: > Die Ursache war, daß ich keine Timing-Constraints für Signale zum PHY > definiert hatte. Den Takt zwar sehr wohl, aber eben nicht die > Setup/Hold-Zeiten der einzelnen Datensignale. > Das hat dann ein sehr willkürliches "mal gehts, mal nicht"-Verhalten > erzeugt. > > Seit ich die Timing Constraints drinn hatte, geht's immer. An Timing-Constraints habe ich auch gedacht, aber wie war für mich immer die Frage. Ich lese ja die Daten über eine UART Schnittstelle ein und aus, quasi habe ich mehrere Tx und Rx. Das komische ist ja manchmal, dass die Daten auch richtig ankommen ins FPGA, aber intern kommst es zu Fehlern, die ich mir nicht erklären kann. Hast du auch interne Signale mit Constraints versehen? Cihan
Angehängte Dateien:
-
Struktur.png
29 KB
Hier mal eine grobe Struktur, wie ich die Daten ein- und auslese. Habe ich gerade gemacht, natürlich ohne Details, also nur ganz grob, damit man sich vorstellen kann wie das Design grob aufgebaut ist. Cihan
Cihan Kalayci schrieb: > Bronco schrieb: >> Auch interessant: Alternativ hätte laut Aussage eines Kollegen auch >> geholfen, die I/O-Register in die IOBs zu erzwingen ("Pack I/O >> Registers/Latches into IOBs"). > > Das Attribute war bei mir auf Auto, habe es mal jetzt auf Yes gesetzt. > Werde es mir mal anschauen. Ich hatte aktuell grad im Design Probleme. Dann habe ich einfach mal das Erzwingen des IOBs auf Yes gesetzt. Das Ergebnis bis jetzt ist erstmal positiv. Werde es natürlich weiter untersuchen, aber es hat schon was gebracht, Danke hier an Bronco. Die andere Seite ist aber, dass ich jetzt viele Warnungen bekommen habe, zurecht denke ich auch, hier mal einer von vielen: WARNING:Pack:2780 - The register "u_RS_422_SH/u_RXFLAG/i_serial_in_FDE" has the property IOB=TRUE, but it did not join an IO component because it is not connected to any IO element. Auf welche Signale sollten denn die IOBs erzwungen werden? Meines Wissens nach nur an Eingängen? :-S kann mich auch gewaltig irren. Kann da jemand eine klare Aussage machen? Wenn es wirklich an den IOBs lag, dass das Design manchmal lief und manchmal nicht, dann hat doch das Attribute unter den Synthese Optionen IOB = AUTO versagt. Kann man das daraus schliessen. Müsste ich evtl. durch Attribute im Design selber für die IOBs sorgen? Ich dachte immer, dass bspsw. die Eingangspins die mit 2 FFs synchronisiert werden, immer automatisch IOBs erzwingen werden. hmmm Cihan
Cihan Kalayci schrieb: > Ich hatte aktuell grad im Design Probleme. Dann habe ich einfach mal das > Erzwingen des IOBs auf Yes gesetzt. Das Ergebnis bis jetzt ist erstmal > positiv. Werde es natürlich weiter untersuchen, aber es hat schon was > gebracht, Danke hier an Bronco. Zu früh gefreut, habe doch noch Fehler drin. Seltsam.
Ich hatte mal ein nicht nachvollziehbares Verhalten von Synthese zu Synthese. Ähnlich, wie bei dir. Am Ende lag es an einer unvollständigen Sensitivity-Liste. Skurrilerweise war in dem Prozess ein Counter in der Sensitivity-Liste, der mit jedem Takt inkrementiert wurde und somit eigentlich auch den Prozess mit jedem Takt angestoßen hat und trotzdem führte ein Eingang, der nicht in der Liste war, zu diesem Verhalten. Ist mir bis heute schleierhaft, wieso. Aber Liste vervollständigt und Problem war weg.
Schlumpf schrieb: > Aber Liste vervollständigt und > Problem war weg. Das war wohl zufall, dass das Problem gleichzeitig verschwand.
Klaus schrieb: > Das war wohl zufall, dass das Problem gleichzeitig verschwand. Keine Ahnung, ob es das war oder nicht.. jedenfalls war davor trotz diverser Änderungen im Design das Problem immer da. Also die Synthese hatte genug "Chancen", es auch mal anders zu machen. Und nach vervollständigen der Sensitivity-List kam das Problem nie wieder.. auch nach vielen weiteren Änderungen am Design. Ich find´s selber eigenartig....
Schlumpf schrieb: > Keine Ahnung, ob es das war oder nicht.. jedenfalls war davor trotz > diverser Änderungen im Design das Problem immer da. Also die Synthese > hatte genug "Chancen", es auch mal anders zu machen. Und nach > vervollständigen der Sensitivity-List kam das Problem nie wieder.. auch > nach vielen weiteren Änderungen am Design. > > Ich find´s selber eigenartig.... Welche Systhesetootl hast du denn verwendet (Version, Hersteller)? Wäre echt ne Kuriosität, wenn das tatsächlich die Ursache war :)
Klaus schrieb: > Welche Systhesetootl hast du denn verwendet (Version, Hersteller)? Wäre > echt ne Kuriosität, wenn das tatsächlich die Ursache war :) Boahh jetzt fragst mich was.. ist schon ein paar Jährchen her. Es war synplify, aber frag mich bitte nicht, welche Version.. Na ja, dem TO wird das vermutlich auch nicht weiterhelfen ;-) Beim ihm hört sich das eher nach sowas wie "unconstrained path" oder Problem an den Domaingrenzen durch inkonsistente Daten an.
Hat sich ja übers Wochende hier einiges getan :-) Danke erstmal für die vielen Antworten. Schlumpf schrieb: > Am Ende lag es an einer unvollständigen Sensitivity-Liste. Immer wieder lese ich, dass die Sensitivity-List mehr für die Simulation seinen Zweck hat, als für die Implementierung des Designs. Aber abgesehen davon gestalte ich meine Prozesse ausschließlich immer so:
1 | PROCESS(CLK) |
2 | BEGIN
|
3 | -- hier mach ich generell überhaupt nix, sonst müsste es ja in die Sensitivity-List
|
4 | IF CLK = '1' AND CLK'EVENT THEN |
5 | ... -- hier werden alle logischen Zuweisungen und logische Funktionen beschrieben |
6 | i_SIG <= R_SIG; |
7 | END IF; |
8 | -- hier mach ich generell überhaupt nix, sonst müsste es ja in die Sensitivity-List
|
9 | END PROCESS; |
10 | |
11 | SIG <= i_SIG; -- Signal Entity List |
Das was ich generell mache ist, dass ich mit Signalen innerhalb eines Prozesses arbeite und dann wenn ich das Signal nun zu einem anderen Prozess außerhalb meiner .vhd file übertragen will, weise ich es an das Signal der Entity List zu. Und wenn es am anderen Ende wieder in einem Prozess mit gleichem Takt gebraucht wird, benutze ich es einfach zur Abfrage oder Zuweisung. Also wenn ich es kurz zusammenfassen darf, sind alle meine Prozesse mit CLK in der Sensitivity-List gefüllt und sollten auch vollständig sein, da alle Funktionen und Zuweisungen innerhalb von
1 | IF CLK = '1' AND CLK'EVENT THEN |
2 | ...
|
3 | END IF; |
passieren. Was ich noch zu Prozessen mal fragen will. Ist es besser viele Funktionen und Zuweisungen innerhalb eines Prozesses zu beschreiben oder sollte man viele kleinere Funktionen innerhalb mehrerer Prozesse beschreiben. Eignetlich sollte das doch auch keinen Unterschied machen? oder? Schlumpf schrieb: > Beim ihm hört sich das eher nach sowas wie > "unconstrained path" oder Problem an den Domaingrenzen durch > inkonsistente Daten an. Das hört sich für mich logisch an, könnte sein das es sowas auch ist. Denn es kommt mir manchmal vor, dass Daten falsch oder Parameter die ich einstellen kann falsch aufgenommen werden oder garnicht erst zum Ziel gelangen! Wie kann ich unconstrained path prüfen? Warum kommt es überhaupt zu so etwas? Danke nochmals Cihan
Habe neue Erkenntnisse mit dem "unconstrained path". Erstens kann man sich die anzeigen lassen, wenn man sie mit der option -u limitiert unter Implement Design -> Properties -> Post-Place & Route Static Timing Report Properties. Hatte z.B. 10000 rein geschrieben. Im Anschluss daran sah ich im nächsten Durchlauf, das automatisch OFFSET IN / OUT constraints gesetzt wurden, die vermutlich nicht passten. Habe ich im Report-File twr gesehen. Die Lösung war dann, sie selber in der ucf zu setzen. Habe folgendes eingefügt: OFFSET = IN 10 ns VALID 9.5 ns BEFORE "CLKIN" RISING; OFFSET = OUT 9 ns AFTER "CLKIN"; Nun läuft das Design ohne Fehler, habs mehrmals getestet, bis jetzt ist mir nichts aufgefallen. Werde natürlich noch ein Dauertest und einen Test in einer Thermalkammer machen, um das System auch unter "schweren" Bedingungen zu testen. Jetzt tretet für mich die Frage auf, was ich mit den Constraints OFFSET bewirkt habe, was das Tool von Xilinx selber nicht geschafft hat? Welche Erkenntnis kann man hier als Abschluss geben. Weiterhin würde die Antwort auf folgende Frage mich auch noch interressieren: Cihan Kalayci schrieb: > Was ich noch zu Prozessen mal fragen will. Ist es besser viele > Funktionen und Zuweisungen innerhalb eines Prozesses zu beschreiben oder > sollte man viele kleinere Funktionen innerhalb mehrerer Prozesse > beschreiben. Eignetlich sollte das doch auch keinen Unterschied machen? > oder? Danke Cihan
Cihan Kalayci schrieb: > Immer wieder lese ich, dass die Sensitivity-List mehr für die Simulation > seinen Zweck hat, als für die Implementierung des Designs. Ersetze "mehr" duch "ausschließlich". Dann passts. Die Synthese erweitert die Sensitivliste selber und weißt dich dann mit eine Info darauf hin, dass die Simulation nicht zur Hardware passen wird... > Was ich noch zu Prozessen mal fragen will. Ist es besser viele > Funktionen und Zuweisungen innerhalb eines Prozesses zu beschreiben oder > sollte man viele kleinere Funktionen innerhalb mehrerer Prozesse > beschreiben. Eignetlich sollte das doch auch keinen Unterschied machen? Der Synthesizer muss deine Idee aus dem VHDL-Code heruaslesen und interpretieren können. Das kann schon bei kleinen Änderungen signifikante Auswirkungen haben. Dort fügt der Synthesizer wegen einer anderen Reihenfolge im Quelltext zwei zusätzliche Inverter ein: http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html (lies unten: "Als kleiner Gimmick"). Ich selber schreibe gern recht viel in 1 getakteten Prozess, und die Kombinatorik soweit möglich als Concurrent Statements.
Cihan Kalayci schrieb: > Jetzt tretet für mich die Frage auf, was ich mit den Constraints OFFSET > bewirkt habe, was das Tool von Xilinx selber nicht geschafft hat? Welche > Erkenntnis kann man hier als Abschluss geben. Die Synthese kann bei Angabe der Taktfrequenz der Register nur die Pfade automatisch mit einem sinnvollen Constraint versehen, dessen Quelle und Ziel mit diesem Takt (oder einem daraus abgeleiteten und für die Synthese bekannten Takt) betrieben sind. Sprich: Die Synthese muss die Phasenbeziehung der Takte von Quell und Zielregister eines Pfades kennen. Das funktioniert tadellos, solange du dich innerhalb einer Clock-Domain befindest. An den Grenzen zu einer anderen Domain (und die Schaltung rund ums FPGA sind eine andere Domain), kennt die Synthese den Phasenbezug nicht mehr und hat daher keine Chance, automatisch was Sinnvolles zu machen. Daher musst du den Phasenbezug bekannt geben, oder Setup- und Holdzeiten. Das gleiche kann innerhalb des FPGAs an Domaingrenzen vorkommen. Allerdings schafft es da die Synthese in der Regel doch selber, da die Takte aus der PLL kommen, welche im FPGA sitzt und die Synthese somit de Phasenbezug zwischen den beiden Domains kennt. Zu deiner Frage ob einer oder mehrere Prozesse: Ich beschreibe mit 2 Prozessen: im ersten Prozess beschreibe ich ausschließlich die Register. im zweiten Prozess beschreibe ich dann die gesamte Kombinatorik. Hab ich mir so angewöhnt, da es sehr übersichtlich ist.
Super Erklärung. Danke dir für die hilfreiche und informative Antwort. Und vielen dank auch an alle anderen Beteiligten. Mein Problem sieht erstmal behoben aus. Hoffe es bleibt auch so. Gruß Cihan
Cihan Kalayci schrieb: > Super Erklärung. Danke dir für die hilfreiche und informative Antwort. Sehr gerne geschehen :-) Cihan Kalayci schrieb: > Mein Problem sieht > erstmal behoben aus. Hoffe es bleibt auch so. Hoffen wir´s.. denn solche Fehler sind einfach nur lästig :-)
Cihan Kalayci schrieb: > Jetzt tretet für mich die Frage auf, was ich mit den Constraints OFFSET > bewirkt habe, was das Tool von Xilinx selber nicht geschafft hat? Welche > Erkenntnis kann man hier als Abschluss geben. Diese Constraints beziehen sich auf IO-Pins des FPGAs, oder ? Das wäre genau das, was ich gemeint habe: über die OFFSET-Constraints sagst Du der Toolchain, was die an den FPGA angeschlossene Hardware für die Setup/Hold-Zeiten hat bzw. erwartet. Dann kann die Toolchain versuchen, diese einzuhalten bzw. warnen, wenn sie nicht eingehalten werden.
Ich meine dann zu sagen, dass man neben dem CLK-Constraint dem Tool auch immer die OFFSET IN / OUT Constraints mitteilen sollte. Ich glaube ich hatte sogar etwas ähnliches hier im Forum gelesen. Kann mich aber auch irren. Cihan
Cihan Kalayci schrieb: > Ich meine dann zu sagen, dass man neben dem CLK-Constraint dem Tool auch > immer die OFFSET IN / OUT Constraints mitteilen sollte. Muss man nicht unbedingt. Solange die Signale an den Ports in sich nicht konsistenz sein müssen (also z.B. keine Datenbusse sind, sondern nur irgendwelche Steuersignale), kann man das auch weglassen. Wichtig ist dabei halt, dass du dir im Klaren darüber bist, ob dein Design damit klar kommt, wenn das eine Steuersignal schon mit dem einen Takt, das andere aber erst mit dem nächsten Takt erfasst wird. Wenn der Phasenbezug deiner extrenen Quelle zum internen Takt bekannt ist, dann kannst dir sogar das einsynchronisieren sparen. Denn dann ist mit richtigem Constraining sichergestellt, dass zum Zeitpunkt der Flanke des PFGA-Registers, deine Ports "stabil" sind.
Schlumpf schrieb: > Cihan Kalayci schrieb: >> Ich meine dann zu sagen, dass man neben dem CLK-Constraint dem Tool auch >> immer die OFFSET IN / OUT Constraints mitteilen sollte. > Muss man nicht unbedingt. Man kann es überhaupt nur sinnvoll bei solchen Signalen, die synchron zum Takt sind. Denn nur dann kann man sagen, wie lange vor oder nach einer Taktflanke das Signal stabil ist. Bei jedem asynchronen Signal ist diese Angabe nutzlos.
Lothar Miller schrieb: > Man kann es überhaupt nur sinnvoll bei solchen Signalen Na ja, in den allermeisten Fällen ist das so, aber es kann auch fälle geben, in denen es Sinnvoll sein kann, sowas anzugeben, obwohl das Signal asynchron ist. z.B. wenn ich den anynchronen Eingang auf mehreren Taktdomänen sample. Dann kann es hilfreich sein, mit dieser Methode die Synthese ein wenig zu "zwingen", den Skew zwischen Port und den einzelnen Sampleregistern der Taktomänen gering zu halten. Aber ich gebe dir recht. Das ist sicher eher eine Ausnahme und nicht die Regel.
Schlumpf schrieb: > z.B. wenn ich den anynchronen Eingang auf mehreren Taktdomänen sample. Unabhängige Taktdomänen (z.B. 47MHz/17MHz)? Oder "phasenstarre" Taktdomänen (z.B. 25MHz/50MHz)? > Dann kann es hilfreich sein, mit dieser Methode die Synthese ein wenig > zu "zwingen", den Skew zwischen Port und den einzelnen Sampleregistern > der Taktomänen gering zu halten. Wenn die Takte unabhängig sind, dann hilft eine begrenzte maximale Lauzeit zwischen Pad und FF auch nichts. Gesampelt wird dann sowieso jedesmal zu einem anderen Zeitpunkt... Und auch bei starrem Phasenbezug hilft eine Limitierung der maximalen Laufzeit nur mental, denn wenn ich sage: vom Pad zum FF maximal 10ns, dann kann trotzdem die eine Domäne mit 4ns angebunden werden und die andere mit 10ns... > die Synthese ein wenig zu "zwingen" Naja, der Synthese ist es erst mal egal. Der Placer und der Router können da schon eher was ausrichten... ;-)
Lothar Miller schrieb: > vom Pad zum FF maximal 10ns, > dann kann trotzdem die eine Domäne mit 4ns angebunden werden und die > andere mit 10ns... richtig.. aber genau darauf wollte ich hinaus.. wenn ich damit die maximale Laufzeit begrenze, dann kann ich wenigstens davon ausgehen, dass die Signale intern dann um maximal einen Takt verschoben sind und nicht um mehrere. Weil ich den Skew dann so einstellen kann dass er eben irgendwo zwischen 0 und n ist und nicht vollkommen unbekannt. Vielleicht habe ich mich etwas schlecht ausgedrückt. Lothar Miller schrieb: > Naja, der Synthese ist es erst mal egal. Der Placer und der Router > können da schon eher was ausrichten... ;-) richtig.. und man kann ein Haar auch 0..n mal der Länge nach Spalten, wenn das Messer nur scharf genug ist :-)
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.