www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA: Verständnisproblem, asynch. Reset


Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe Frage zum Artikel
http://www.mikrocontroller.net/articles/Reset_f%C3...
process(clk, reset)
begin
  if reset = '1' then
    -- Initialisierung der Register
  elsif rising_edge(clk) then
    -- Kombinatorik
  end if;
end process;
Beim Chipdesign ist er i.d.R. unverzichtbar, bei FPGAs wird er nicht 
unbedingt benötigt. Er kann sogar zu Problemen führen, wenn die fallenden 
Flanke des Resetsignals zu einem ungünstigen Zeitpunkt kommt (Siehe 
Witepaper 272 bei Xilinx). Je nach Logikdesign und der dadurch bedingten 
Auswirkung der Resetrücknahme, ist damit u.U. eine Verlängerung des 
Resetsignales so durchzuführen, daß das Löschen des Signals in jedem Falle 
ausserhalb des Bereiches möglicher Flankenwechsel des Systemtaktes 
erfolgen. Generell ist darauf zu achten, daß das asynchrone Resetsignal 
eine genügend lange Periode besitzt, um erfasst zu werden.

Könnte jemand näher darauf eingehen?

Kann er zum Problemen führen, wenn reset ein synchrones Signal ist
und obiges vhdl template benutzt wird? Sollte eigentlich 
unproblematisch
sein, denn dann steht im if Zweig komb. Logik, die Register für nächste
Flanke initialisiert. Was wäre so ein ungünstiger Zeitpunkt?

ps. Das Paper habe ich nicht leider gefunden.

Danke im Voraus

Autor: Vollprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Reset genau dann verlischt, wenn der FPGA schaltet, dann beseht 
aufgrund der geometrischen Struktur und der Laufzeiten das Problem, dass 
einige FFs den vorher sehen, während ihn andere hinterher sehen. Damit 
liegen z.B. Zählerstartzustände in verschiedenen Modulen nicht auf 
demselben clock.

Schlimm ist es, wenn die FF eines einzelnen Zählers auseinanderlaufen, 
dann rennt der komplett falsch los. Dasselbe gilt für FFs in state 
machines. Daher

1)  alle einzelnen externen Signale einmal eintakten, wenn sie an 
mehreren Stellen gebraucht werden

2) asynchrone Resets und verbundene Signale (=Busse) zweimal eintakten, 
da diese voll kohärent sein müssen.

3) in Schaltungen, in denen metastabile Zustände zu Problemen füren 
können, weil das aynchrone Signal nicht verspätet oder zweimal 
interpretiert werden darf, überabtasten und filtern oder das Problem mit 
wieteren FFs + gfs oder-Kette quantitativ erschlagen

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch noch die Quelle gefunden.
http://www.xilinx.com/support/documentation/white_...

Trotzdem Danke für die ausführliche Erklärung.
Bis zum Punkt 1 kann ich gut folgen.

unter Punkt 1) meinst du mit externen Signalen, externe synchrone oder
auch asynchrone Signale?

Asynch. Reset Signal ist nur in der Hinsicht ein spezielles Signal,
weil es einen höhren Fan Out hat. Ansonsten droht die verspätete
Wertübernahe bei allen asynch. Signalen. Deswegen verstehe ich nicht
ganz den Unterschied zwischen Punkt 1) und 2).

Zu Punkt 3), ist glaube ich eine gute Strategie so vorzugehen, dass
man Signal mit einem FF abtastet, dann einfach 16 Zyklen wartet,
nochmal abtastet. Bleibt Wert der Neue Wert bestehen, wird es 
übernommen.

Autor: Vollprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
asyn)
Gemeint sind die asynchronen. Synchron würde ja bedeutet, sie passen 
bereits zu FPGA-Takt. Aynchron bezieht sich auf "irgendwann in Relation 
zum FPGA-Clock"

Zu 1) Wenn Du nur auf eine Flanke eines Signals wartest und nur ein FF 
darauf reagiert, dann reicht einmal eintakten, weil dann genau an diesem 
einen Punkt das Signal einmal übernommen wird, egal ob im stabilen oder 
im instabilen Fall. Von dort aus kann man dann fein verzeigen.

Täte man das nicht, (FF weglassen) liegt da Signal je nach 
Syntheseergebnis wieder an verschiedenen Stellen über Kombinatorik an 
und richtet denselben Unfug an, wie der asyn-Reset.

Zu)
Bei Bussen ist doppelt deshalb nötig, weil man zusättzlich die Daten auf 
einer Zeitebene erwischen muss. Sonst hat man unsinnige Werte. Ergo 
eintakten und entscheiden, ob gültig, dann das Eingetaktete übernehmen. 
Das geht nicht über Kombinatorik wie es machbar zu sein scheint, weil in 
dem Moment, in dem die Kombinatorik entscheidet, dass der Bus zu 
verwenden ist (zweimal dasselbe gekommen, oder strobe ist gekommen) sich 
im Moment der Übernahme nach hinten gerade wieder was ändern kann. Da 
aber auch eim Eintakten selber eine meta-Zustand herrschen kann und FFs 
falsch kippen, wäre im Fall eines zu langen meta-Zustandes das 
Sampleschaltwerk noch nicht stabil, bis es ausgewertet wird.

Ergo zweimal!

Wenn man im FPGA deutlich schneller ist, als die doppelte 
Bus-Geschwindigkeit, sollte man einfach oversmaplen. Die 
Entscheiderschaltung läuft auf dasselbe hinaus, ist aber kleiner und dei 
Daten schneller valid.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lies mal den Beitrag "Hardware mit VHDL "richtig" beschreiben."

Interessant ist bei einem asynchronen Reset nicht der Eintritt in den 
Reset-Zustand, sondern das Herauskommen vom Reset-Zustand in den 
Normalbetrieb.

Zu dem bereits oben beschriebenen Effekt mit dem Zähler bzw. der 
State-Machine kommt bei einem komplett asynchronen Reset noch ein ganz 
lustiger Effekt dazu:
Wenn auf der Reset-Leitung ein kurzer (sagen wir mal 5 ns) 
ESD-Störimpuls ist, dann werden verteilt über das FPGA ein paar FFs 
zurückgesetzt, und andere nicht.
Und du hast jedesmal ein anderes Fehlerbild. Das macht Spass  :-/


> Beim Chipdesign ist er i.d.R. unverzichtbar,
Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.
> bei FPGAs wird er nicht unbedingt benötigt.
Weil beim Laden des FPGAs alle FFs definierte Zustände einnehmen.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Zu)
>Bei Bussen ist doppelt deshalb nötig, weil man zusättzlich die Daten auf
>einer Zeitebene erwischen muss. Sonst hat man unsinnige Werte. Ergo
>eintakten und entscheiden, ob gültig, dann das Eingetaktete übernehmen.
>Das geht nicht über Kombinatorik wie es machbar zu sein scheint, weil in
>dem Moment, in dem die Kombinatorik entscheidet, dass der Bus zu
>verwenden ist (zweimal dasselbe gekommen, oder strobe ist gekommen) sich
>im Moment der Übernahme nach hinten gerade wieder was ändern kann. Da
>aber auch eim Eintakten selber eine meta-Zustand herrschen kann und FFs
>falsch kippen, wäre im Fall eines zu langen meta-Zustandes das
>Sampleschaltwerk noch nicht stabil, bis es ausgewertet wird.

Mit den Bussen habe ich bisher nichts gemacht. Vielleicht kommt es 
daher,
dass ich es nur waage verstehe. Mein Wissen begrenzt sich in dem Bereich
auf 2,3 von mit verfolgte Threads wo es um fehlende Tristate Buffer in
modernen FPGAs ging, und wie man sonst Busse beschreibt.

Grob gesagt, geht es darum, dass in dem Moment der Entscheidung, 
Businhalt
sich nicht verändert hat. Also wird später nur geschaut, dass die 
Inhalte
gleich geblieben sind.

>Interessant ist bei einem asynchronen Reset nicht der Eintritt in den
>Reset-Zustand, sondern das Herauskommen vom Reset-Zustand in den
>Normalbetrieb.

Genau, nach dem Lesen des white papers ist einiges klar geworden.


>> Beim Chipdesign ist er i.d.R. unverzichtbar,
>Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.

und wie entgeht man beim ASIC den Problemen beim Wegname des asynchr.
Resetsignals?
Im Grunde besteht ja das Problem immernoch.

>> bei FPGAs wird er nicht unbedingt benötigt.
>Weil beim Laden des FPGAs alle FFs definierte Zustände einnehmen.

Das ist cool. Gilt das für alle FPGAs?
SRAM basierte FPGA sind damit nach Konfiguration bereits im
richtigen Ausgangszustand.
Was ist mit Flashbasierten? Ich denke hier auch.
Und was Fuse/Antifuse FPGAs?

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist cool. Gilt das für alle FPGAs?

Trifft für Xilinx wohl zu, für Lattice nicht.

Gruß,
SuperWilly

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Das ist cool. Gilt das für alle FPGAs?
> SRAM basierte FPGA sind damit nach Konfiguration bereits im
> richtigen Ausgangszustand.
Die Erfahrung sagt, dass dies beim Spartan3 nur bei der ersten 
Konfiguration  nach dem Einschalten der Fall ist. Wenn man im Zuge der 
Entwicklung im Betrieb ein neues Design lädt, müssen die 
Initialisierungen nicht stimmen.

> Was ist mit Flashbasierten? Ich denke hier auch.
> Und was Fuse/Antifuse FPGAs?

Bei Actel FPGAs braucht man ein Reset, am besten ein synchrones. Gut 
eignet sich das Lock der PLL.


    reset <= sres_cnt (sres_cnt'high); -- H aktives synchrones Reset

    pres : process (lock_pll, clk) is
    begin  -- process pres
        if lock_pll = '0' then          -- rising clock edge
            sres_cnt <= (others => '1');
        elsif rising_edge(clk) then     -- rising clock edge
            if sres_cnt (sres_cnt'high) then
                sres_cnt <= sres_cnt - 1;
            end if;
        end if;
    end process pres;

Damit hat man nur einen Prozess, der ein asynchronen Reset verarbeiten 
muss.

Tom

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Zu dem bereits oben beschriebenen Effekt mit dem Zähler bzw. der
> State-Machine kommt bei einem komplett asynchronen Reset noch ein ganz
> lustiger Effekt dazu:
> Wenn auf der Reset-Leitung ein kurzer (sagen wir mal 5 ns)
> ESD-Störimpuls ist, dann werden verteilt über das FPGA ein paar FFs
> zurückgesetzt, und andere nicht.
> Und du hast jedesmal ein anderes Fehlerbild. Das macht Spass  :-/

Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem 
anderen Signal, dass sich so verhält.

Tom

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
>>> Beim Chipdesign ist er i.d.R. unverzichtbar,
>>Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.
>
> und wie entgeht man beim ASIC den Problemen beim Wegname des asynchr.
> Resetsignals?
> Im Grunde besteht ja das Problem immernoch.

Asynchronous assert, synchronous deassert.

Das Zurücknehmen des Reset erfolgt synchron. Etwa so:
logic reset_int, reset_sync;

always @(posedge clk, negedge reset_ext)
begin
    if (!reset_ext) begin
        reset_sync <= 0;
        reset_int  <= 0;
    else begin
        reset_sync <= 1;
        reset_int  <= reset_sync;
    end
end

Gruß
Marcus
http://www.doulos.com/

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem
> anderen Signal, dass sich so verhält.
Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal 
an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den 
selben Zustand haben, wird der Reset verwendet. Sicher ist sicher  ;-)

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem
>> anderen Signal, dass sich so verhält.
> Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal
> an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den
> selben Zustand haben, wird der Reset verwendet. Sicher ist sicher  ;-)

Ist es sinnvoll wenn man ein Reset an mehreren Modulen im Design braucht 
ein Reset Modul zu implementieren, dass einen Reset einsynchronisiert 
und an die Module weiterleitet? Oder sollte man in jedem Modul die 
Resets einsynchronisieren?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> dass einen Reset einsynchronisiert und an die Module weiterleitet?
Ja, damit du nur einen (in Zahlen 1) definierten Reset hast.

> Oder sollte man in jedem Modul die Resets einsynchronisieren?
Nein, denn dann ist zwar der Reset synchron, aber aufgrund von 
Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt 
versetzt ist.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> dass einen Reset einsynchronisiert und an die Module weiterleitet?
> Ja, damit du nur einen (in Zahlen 1) Reset hast.
>
>> Oder sollte man in jedem Modul die Resets einsynchronisieren?
> Nein, denn dann ist zwar der Reset synchron, aber aufgrund von
> Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt
> versetzt ist.

Danke.

Sag mal hast du beruflich mit VHDL/FPGA's zu tun oder ist das nur ein 
Hobby?

Deine Antworten sind immer recht fundiert und hilfreich.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sag mal hast du beruflich mit VHDL/FPGA's zu tun
Ja
> oder ist das nur ein Hobby?
Ja, auch  ;-)


> Deine Antworten sind immer recht fundiert und hilfreich.
Danke

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Sag mal hast du beruflich mit VHDL/FPGA's zu tun
> Ja

Und was machst du genau?

Studienmäßig gehts bei mir auch in diese Richtung als Vertiefung.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und was machst du genau?
60% Hardware (PC, uC, Interface...)
20% FPGA     (Ankopplung PCI/PCIe nach CAN, SPI...)
20% prozessornahe Software (Treiber, Ansteuerungsbeispiele...)
Recht schöne Arbeit, sehr interdisizplinär   ;-)

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Und was machst du genau?
> 20% FPGA     (Ankopplung PCI/PCIe nach CAN, SPI...)
Interessant!
Würdest du denn eine CAN Bus Anbindung in der Regel mit einem FPGA 
realisieren oder mit einem CAN Controller, z.B. SJA1000, wenn der zu 
verwendende Mikrocontroller kein CAN integriert hat?

ja, das ist "etwas" OT...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Würdest du denn eine CAN Bus Anbindung in der Regel mit einem FPGA
> realisieren oder mit einem CAN Controller, z.B. SJA1000
Ich hatte genau diese Aufgabenstellung:
4 x CAN an einen PC anschalten. Als kleine Hürde sollte der möglichst 
ähnliches Mailbox-Verhalten haben wie ein 82527.

Weil der 82257 schon lange obsolete ist, und der Bosch CC770 nicht 
richtig in die Gänge kam (ROHS-Umstellung), blieb nur ein (halbwegs) 
aktueller CAN-Controller oder ein CAN-Core.
Nach eingehender Betrachtung über die für die 4 zu implementierenden 
Kerne benötigte FPGA-Größe (Mehrpreis) fiel die Wahl dann auf den 
SJA1000. Die Pufferfunktionalität wurde dann im FPGA implementiert.

Ich hätte die CAN-Kerne schon gern im FPGA gehabt, aber gegen Geld ist 
kein Kraut gewachsen  ;-)

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem
>> anderen Signal, dass sich so verhält.
> Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal
> an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den
> selben Zustand haben, wird der Reset verwendet. Sicher ist sicher  ;-)

Eine ganz andere Frage, wozu brauchst du bei deinen Designs noch ein 
externes Reset? Mein letztes Design mit externem Reset habe ich vor 4..5 
Jahren erstellt. Bei Xilinx-FPGAs habe ich gar kein Reset mehr, auch 
kein internes. Da geht alles über Signal-Initialisierung bei der 
Deklaration. Falls eine FSM  mal hängen bleiben kann, führe ich einen 
Timeout ein.

Für Actel-FPGAs erzeuge ich mir ein synchrones Reset wie im Posting 
oben.

Tom

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Die Pufferfunktionalität wurde dann im FPGA implementiert.
Puffer? Ist doch schon im SJA1000 integriert?
Welchen CAN Core hättest du denn eingesetzt?

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
"Nein, denn dann ist zwar der Reset synchron, aber aufgrund von
Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt
versetzt ist."

Wenn der Reset in der jeweilingen Taktdomäne asynchron bleibt, hast du 
so oder so einen oder mehrere Takte Ungewissheit. Sauberer wäre es 
meiner Meinung nach, das synchrone Abschalten des Resets für jede 
Taktdomäne separat vorzunehmen.

Gruß,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine ganz andere Frage, wozu brauchst du bei deinen Designs noch ein
> externes Reset?
Na klar: für den allgegenwärtigen Reset-Taster ;-)

Ich habe in meinen Designs eine einfache Regel, die ich versuche soweit 
als möglich einzuhalten:
Es gibt genau einen (1) Takt und keinen (0) Reset.

In 9 von 10 Fällen sind ohne weiteres beide Bedingungen leicht 
erfüllbar.



> Puffer? Ist doch schon im SJA1000 integriert?
Es geht um dem Sendepuffer.
Beim 82527 kann ich mehrere Messages einspeichern, die dann nacheinander 
versendet werden. Der SJA1000 hat nur 1 Sendepuffer und gibt nach 
Versenden einen Interrupt.

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Puffer? Ist doch schon im SJA1000 integriert?
> Es geht um dem Sendepuffer.
Autsch! Ja klar. Danke für die Antworten!
IP Core wird wohl nichts werden, für den Xilinx CAN Core müsste man ca. 
20'000 USD löhnen - zuviel bei unseren Stückzahlen.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Ich habe in meinen Designs eine einfache Regel, die ich versuche soweit
> als möglich einzuhalten:
>
>
> ... und keinen (0) Reset.
> 
>
> In 9 von 10 Fällen sind ohne weiteres beide Bedingungen leicht
> erfüllbar.

Wäre einer von 10 Fällen z.B. wenn ich ein kleines Spiel auf einem FPGA 
implementieren möchte und man mitten im Spiel statt es fertig zu spielen 
neustarten möchte? Da wüßte ich jetzt nicht wie ich das sinnvoll ohne 
Reset machen könnte (außer man schaltet das FPGA kurz aus und lässt es 
die Konfig neu laden).

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da wüßte ich jetzt nicht wie ich das sinnvoll ohne Reset machen könnte
Du mußt in deinen Zustandsautomaten "nur" einen Init-State definieren, 
in dem die ganzen Aufräumarbeiten erledigt werden. Das wäre dann sowas 
ähnliches wie ein synchroner Reset.

Aber quick and dirty könnte man sich auch einen Reset-Eingang dafür 
ausdenken, wobei dann z.B. die Block-RAMs nicht initialisiert werden.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Da wüßte ich jetzt nicht wie ich das sinnvoll ohne Reset machen könnte
> Du mußt in deinen Zustandsautomaten "nur" einen Init-State definieren,
> in dem die ganzen Aufräumarbeiten erledigt werden. Das wäre dann sowas
> ähnliches wie ein synchroner Reset.

Bisher ist das so, dass dem Reset ein Taster auf dem Board entspricht. 
Dieser Reset wird in einem Modul auf die Weise eingetaktet wie ichs auf 
deiner HP gelesen habe und das einsynchronisierte Signal wird an alle 
Teilmodule die einen Reset benötigen weitergeleitet und setzen sich dann 
in den von mir definierten Start/Ausgangszustand.
Bis jetzt funktioniert das mit den Teilmodulen die ich bisher habe auch 
wenn das Projekt noch nicht fertig ist.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.