mikrocontroller.net

Forum: FPGA, VHDL & Co. Xilinx ISE: Synthese hängt bei T51-Core


Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade den T51-Core 
(http://www.opencores.org/projects.cgi/web/t51/overview) in Xilinx ISE 
9.1i zu synthetisieren. Nur leider hängt die Synthese an einem Punkt und 
scheint nicht weiterzugehen (habe 15 min gewartet). Die letzten 
Meldungen:
Loading device for application Rf_Device from file '3s1000.nph' in environment C:\Xilinx91i.
INFO:Xst:2691 - Unit <SSRAM> : The RAM <Mram_RAM> will be implemented \
as a BLOCK RAM, absorbing the following register(s): <DOut>.
    -----------------------------------------------------------------------
    | ram_type           | Block                               |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 2048-word x 8-bit                   |          |
    |     mode           | read-first                          |          |
    |     clkA           | connected to signal <Clk>           | rise     |
    |     weA            | connected to signal <_and0000>      | high     |
    |     addrA          | connected to signal <A>             |          |
    |     diA            | connected to signal <DIn>           |          |
    |     doA            | connected to signal <DOut>          |          |
    -----------------------------------------------------------------------
INFO:Xst:2664 - HDL ADVISOR - Unit <T51_RAM> : The RAM <Mram_IRAMA> will be \
implemented on LUTs either because you have described an asynchronous read \
or because of currently unsupported block RAM features. If you have \
described an asynchronous read, making it synchronous would allow you to \
take advantage of available block RAM resources, for optimized device usage \
and improved timings. Please refer to your documentation for coding \
guidelines.
    -----------------------------------------------------------------------
    | ram_type           | Distributed                         |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 256-word x 8-bit                    |          |
    |     clkA           | connected to signal <Clk>           | rise     |
    |     weA            | connected to signal <Wr>            | high     |
    |     addrA          | connected to signal <Int_AddrA_r>   |          |
    |     diA            | connected to signal <DIn>           |          |
    -----------------------------------------------------------------------
    | Port B                                                              |
    |     aspect ratio   | 256-word x 8-bit                    |          |
    |     addrB          | connected to signal <Int_AddrA>     |          |
    |     doB            | connected to internal node          |          |
    -----------------------------------------------------------------------
INFO:Xst:2664 - HDL ADVISOR - Unit <T51_RAM> : The RAM <Mram_IRAMB> will \
be implemented on LUTs either because you have described an asynchronous \
read or because of currently unsupported block RAM features. If you have \
described an asynchronous read, making it synchronous would allow you to \
take advantage of available block RAM resources, for optimized device usage \
and improved timings. Please refer to your documentation for coding \
guidelines.
    -----------------------------------------------------------------------
    | ram_type           | Distributed                         |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 256-word x 8-bit                    |          |
    |     clkA           | connected to signal <Clk>           | rise     |
    |     weA            | connected to signal <Wr>            | high     |
    |     addrA          | connected to signal <Int_AddrA_r>   |          |
    |     diA            | connected to signal <DIn>           |          |
    -----------------------------------------------------------------------
    | Port B                                                              |
    |     aspect ratio   | 256-word x 8-bit                    |          |
    |     addrB          | connected to signal <Int_AddrB>     |          |
    |     doB            | connected to internal node          |          |
    -----------------------------------------------------------------------

Ist das einfach normal dass das so lange dauert? Oder ist es ein Fehler 
dass die IRAMs als Distributed RAM realisiert werden, und ist es das was 
so bremst?

Kann ich irgendwie herausfinden woran die Synthese da gerade knabbert?

Danke
Andreas

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt ist er tatsächlich noch fertig geworden (nur um mir dann eine 
Multi-source Fehlermeldung anzuzeigen...), nach ganzen 45 Minuten. Das 
kann doch nicht normal sein?
Advanced HDL Synthesis Report

Macro Statistics
# FSMs                                                 : 2
# RAMs                                                 : 3
 2048x8-bit single-port block RAM                      : 1
 256x8-bit dual-port distributed RAM                   : 2
# ROMs                                                 : 1
 256x4-bit ROM                                         : 1
# Multipliers                                          : 1
 8x8-bit multiplier                                    : 1
# Adders/Subtractors                                   : 33
 13-bit adder                                          : 2
 16-bit adder                                          : 10
 16-bit addsub                                         : 2
 2-bit adder carry in                                  : 1
 4-bit adder                                           : 3
 4-bit adder carry in                                  : 1
 5-bit adder carry in                                  : 1
 8-bit adder                                           : 6
 8-bit addsub                                          : 1
 8-bit subtractor                                      : 3
 9-bit adder                                           : 2
 9-bit subtractor                                      : 1
# Counters                                             : 15
 15-bit up counter                                     : 1
 16-bit up counter                                     : 1
 17-bit up counter                                     : 1
 2-bit up counter                                      : 2
 3-bit up counter                                      : 1
 4-bit up counter                                      : 8
 6-bit down counter                                    : 1
# Registers                                            : 774
 Flip-Flops                                            : 774
# Comparators                                          : 12
 2-bit comparator equal                                : 1
 4-bit comparator greater                              : 2
 8-bit comparator equal                                : 4
 8-bit comparator less                                 : 1
 8-bit comparator not equal                            : 4
# Multiplexers                                         : 3
 1-bit 4-to-1 multiplexer                              : 2
 8-bit 4-to-1 multiplexer                              : 1
# Decoders                                             : 1
 1-of-4 decoder                                        : 1
# Xors                                                 : 7
 1-bit xor2                                            : 3
 1-bit xor8                                            : 1
 8-bit xor2                                            : 3

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den nächsten Hänger gibt's bei der Low Level Synthesis (nach > 1 Stunde 
abgebrochen):
Optimizing unit <ROM52> ...

An das Place & Route will ich gar nicht erst denken.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

es ist nicht unüblich dass ISE lange für die Synthese braucht. Ich 
selbst habe zwar noch nicht so lange wie du warten müssen, aber ich habe 
auch noch nicht ein solch umfangreiches Projekt durchgezogen. Da hilft 
nur massig Arbeitsspeicher der zudem auch noch von der extrem fixen 
Sorte sein sollte. Zudem sollte das Projekt keinesfalls auf einem 
Netzlaufwerk liegen. Was soll's, dann bleibt halt mehr Zeit Kaffee zu 
kochen  ; )

pumpkin

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Speicher ist nicht das Problem, der Prozess belegt gerade mal 200 MB, 
bei der Festplatte tut sich auch nichts. Ich kann das nicht so richtig 
glauben dass er mehrere Stunden an einem einfachen Block RAM herum 
optimiert. Vielleicht muss ich doch mal Quartus ausprobieren.

Autor: Kim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoi
also ich hatte das slebe prob auch schon lag bei mir daran das mein 
Programm zu gross für den FPGA war. Denke könnte bei dir auch das 
Problem sein...

gruss

Kim

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich synthetisiere für einen Spartan 3 1000, der Core sollte eigentlich 
schon in den 400er reinpassen. Kann es sein dass es am Distributed RAM 
liegt, und das eigentlich Block-RAM sein sollte?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mhh, ich vermute auch mal, dass es an <Mram_IRAMB> liegen könnte, 
welches als LUT implementiert wird.

Habe ähnliches bei Quartus gehabt, allerdings habe ich da halbe Stunde 
gewartet und dann gings.

Kest

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:

Deine Vermutung ist richtig.
Schau im XST-Guide nach, wie der Speicher beschrieben werden muss. Xst 
versucht aus dem ROM eine Funktion zu machen. Zum einen dauert das und 
zum anderen lief es bei mir auch nicht. Nach der Umstellung ging es. Der 
T51 sollte in einen S3 400 reinpassen, zur Not auch in den 200er.

Rick

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim ROM dürfte er das eigentlich nicht machen, er erkennt das schon als 
Block RAM (siehe "2048x8-bit single-port block RAM" oben in der Tabelle, 
steht auch noch explizit im Report). Deshalb verstehe ich die 
Verzögerung beim "Optimieren" dieses Block-RAMs auch nicht. Das 
Distributed RAM will er nur beim IRAM machen, und da geht es m.E. auch 
nicht anders, weil die Adresse nicht in einem Register 
zwischengespeichert wird, sondern direkt ohne Taktverzögerung einen 
Ausgangswert erzeugt.

Weißt du noch was genau du geändert hast um es zum Laufen zu bringen?

Autor: Rick Dangerus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab einiges geändert, aber was?!
Ich häng hier mal das Projekt dran. board.sch ist das top-Modul. Das UCF 
muss entsprechend der Hardware angepasst werden. Das Design wird mit 50 
MHz Clkin getaktet. Die serielle Schnittstelle läuft von 300 (sehr 
nostalgisch) bis 115200 bps. Man muß als erstes ein Leerzeichen 
schicken, damit die Baudratenerkennung läuft.

Der T51 braucht ca. 25% vom S31000. Die Synthese dauert ca. 25 Minuten 
(@500MHz, ISE8.2.04i).

Viel Spass und frag ruhig
Rick

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke. Ich habe erst am Wochenende wieder Zugriff auf einen Rechner mit 
ISE, dann werde ich deinen Code ausprobieren. Auf den ersten Blick sehe 
ich aber keine Unterschiede an den Stellen die ich für kritisch halte. 
T51_RAM sieht z.B. genauso aus; ich nehme an der wird bei dir auch als 
Distributed RAM synthetisiert?

Vielleicht taugt die ISE 9.1 einfach nichts? Soll ja schon vorgekommen 
sein dass sich ISE von einer Version auf die andere verschlechtert.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@   Andreas Schwarz

>Vielleicht taugt die ISE 9.1 einfach nichts? Soll ja schon vorgekommen
>sein dass sich ISE von einer Version auf die andere verschlechtert.

Das kommt scheinbar immer öfter vor . . . :-(
Naja, 1GB Datenwust kann schon mal aus dem Ruder laufen.

MfG
Falk


Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"...Naja, 1GB Datenwust kann schon mal aus dem Ruder laufen..."

Und das auch noch gepackt vor der Installation. Version 8.2 hatte nach 
den ganzen Servicepacks bei mir am Ende eine stolze Größe von über 2GB 
:-/ Besser geworden ist es trotzdem kaum...

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
Ich hab es gerade nochmal unter ISE 9.1.03i durchlaufen lassen. Auf AMD 
X2 5000 dauert die Synthese 5 Minuten und benötigt ca. 50% von einem 
XC3S400 (optimiert ung getrimmt).

Hier ein Ausschnitt aus dem Log-File:
...
Synthesizing Unit <ROM52>.
    Related source file is ".../t51/rom52/testbench/ROM52_BASICX.vhd".
    Found 8192x8-bit ROM for signal <D$rom0000> created at line 2074.
    Found 13-bit register for signal <A_r>.
    Summary:
  inferred   1 ROM(s).
  inferred  13 D-type flip-flop(s).
Unit <ROM52> synthesized.


Synthesizing Unit <SSRAM>.
    Related source file is ".../t51/rtl/vhdl/SSRAM.vhd".
    Found 8192x8-bit dual-port RAM <Mram_RAM> for signal <RAM>.
    Found 13-bit register for signal <A_r>.
    Summary:
  inferred   1 RAM(s).
  inferred  13 D-type flip-flop(s).
Unit <SSRAM> synthesized.
...
# RAMs                                                 : 4
 256x8-bit dual-port distributed RAM                   : 2
 8192x8-bit single-port block RAM                      : 2
# ROMs                                                 : 3
 16x8-bit ROM                                          : 1
 256x4-bit ROM                                         : 1
 4x1-bit ROM                                           : 1

Der SSRAM ist nicht das Problem. Wichtig ist, das der ROM ins BlockRam 
wandert.

Ansonsten ist ISE 9 ca. 20% schneller (je nach Design) und synthetisiert 
etwas besser (auch je nach Design). Wer nicht soviel downloaden möchte 
nimmt ISE 6.3, das sollte für vieles ausreichend sein.

Rick

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dann liegt's wohl echt am ROM:
 8192x8-bit single-port block RAM                      : 2
Davon will er bei mir nur eines bauen. Komisch, wie gesagt bin ich mir 
ziemlich sicher dass er das als Block-RAM erkannt angezeigt hat. Werde 
das nochmal genauer anschauen.

Danke für die Hilfe!

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rick Dangerus schrieb:
>Ich hab es gerade nochmal unter ISE 9.1.03i durchlaufen lassen. Auf AMD
>X2 5000 dauert die Synthese 5 Minuten und benötigt ca. 50% von einem
>XC3S400 (optimiert ung getrimmt).

Welches Betriebssystem?
Und werden beide Cores genutzt?

Gruß

Stefan Salewski

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan Salewski
Win 2003 Server, die Prozessor-Cores werden jeweils zu 50% bis 55% 
ausgelastet. Vielleicht bringt ja ISE10 da eine Verbesserung?!

Rick

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:

Kein Problem. Vielleicht bekomme ich Dich ja noch dazu mit mir den 
AX8-Core aufzubohren. :-)

Rick

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eventuell eine Firewall laufen? Trenne ich meinen Rechner vom 
Netz und schalte die Firewall ab, läuft mein ISE 8.2i etwa zwei- bis 
dreimal schneller durch.

Autor: Tippgeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die ISE diesbezüglich mal getestet und kann keinen Unterschied 
ausmachen (?)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch schon gemerkt dass mein Antivirus-Programm ISE ausbremst, 
das war hier aber nicht der Fall.

@Rick: mir wäre ein AVR-Core eigentlich auch lieber als der 8051, u.a. 
weil da weniger Distributed RAM für die Register verschwendet wird, 
allerdings scheint mir der AX8 nicht so ausgereift sein wie der T51, und 
ich habe gehört dass der AX8 u.U. von Atmel-Patenten betroffen ist. 
Einen MSP430 gibt's leider nur in Verilog: http://bleyer.org/s430/
Die anderen Prozessoren bei Opencores sind entweder zu groß (OpenRISC, 
LEON) oder es gibt keinen passenden C-Compiler.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also es liegt doch am ROM, der mag aus diesem case-Konstrukt kein 
Block-RAM machen. Komisch, laut XST User Guide sollte if/case auch 
funktionieren. Ich habe das ROM zum Array umgebaut (Anhang), jetzt läuft 
die Synthese durch. Allerdings komme ich nur auf 43 MHz.

Ich habe TXD, RXD, Clk und Reset (low-aktiv) angeschlossen, und den Rest 
offen gelassen bzw. auf 0 gelegt. Wenn ich Leertaste drücke passiert 
aber nichts; da ist wohl noch ein wenig Debugging nötig.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:

Siehst Du den Unterschied?
type rom_type is array(8191 downto 0) of std_logic_vector(7 downto 0); -- aus ROM52_BASIC.vhd

type rom_type is array (0 to 8191) of std_logic_vector (7 downto 0); -- aus ROM52_BASICX.vhd
Hat mich auch mindestens einen Tag gekostet, das rauszufinden :(

Rick

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke. Ich habe gar nicht gesehen dass du das ROM in deinem Projekt 
auch geändert hast, habe nur ins rtl-Verzeichnis geschaut.

Jetzt gibt mein Board ca. 1-mal pro Sekunde lange 0-Pulse an TXD aus, 
reagiert aber nicht auf ein gesendetes Leerzeichen oder irgend etwas 
anderes. Muss das noch weiter untersuchen.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas

> allerdings scheint mir der AX8 nicht so ausgereift sein wie der T51, und
> ich habe gehört dass der AX8 u.U. von Atmel-Patenten betroffen ist.

Naja ich verwende den AX8 und ja, es gibt ein paar kleine Macken, aber 
im großen und ganzen recht brauchbar. Außerdem funktioniert die bekannte 
Toolchain.

Kannst Du Näheres zu den Patenten sagen?

Rick

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den Patenten habe ich in comp.arch.fpga gelesen, auch nur so als 
Gerücht. Kann also nichts genaueres dazu sagen.

Autor: Andreas Voggeneder (avg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

damit das Basic-52 läuft musst Du zumindest noch P3.0 und RXD 
miteinander verbinden (so wie es beim Intel-Original der Fall ist).
Die Autobaud-Detektion läuft über P3.0 ab.
Weiters MUSS der Array-ROM ein array (0 to 8191) sein, da ansonsten der 
Inhalt nicht stimmt (ist genau verkehrt).

Es ist ein bekanntes Problem dass die ISE-Synthese einige Schwächen hat 
(u.a. funktioniert ein Case-Rom nicht).

Der AX8-Core hat leider noch einige offene Bugs. Darum habe ich diesen 
Core bisher noch nicht eingesetzt (obwohl er sehr interessant wäre).
Und leider gibt es keine Hoffnung dass der Author (Daniel Wallner) diese 
jemals beheben wird.

MfG.
Andreas

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Voggeneder:
[AX8]
> Und leider gibt es keine Hoffnung dass der Author (Daniel Wallner) diese
> jemals beheben wird.
Warum?

Ich denke der AX8 ist ausbaufähig. Eine Erweiterung mit Watchdog, zwei 
zusätzliche Ports und auf 8k- Programmspeicher habe ich schon gemacht. 
Damit entpricht der Core dem AT90S8535.

Um einen ATMega8 draus zu machen, müssten einige Module erweitert werden 
(neuer Counter, I2C, Hardware-MUL, etc.). Sollte aber insgesammt nicht 
unlösbar sein.

Rick

Autor: Andreas Voggeneder (avg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Daniel Wallner hat seine OpenCores Tätigkeiten ohne Angabe von Gründen 
eingestellt. Die letzten Updates hat er 2002 gemacht. Seither konnte ich 
ihn nicht mehr erreichen.
Ich habe den T51 Core von ihm übernommen und fertiggestellt. Aber beim 
AX8 Core habe ich dies nicht vor (keine Zeit).
Mit dem T51 Core habe ich seither schon sehr viele Projekte realisiert 
(z.B. für Elektor FPGA Kurs). Diesen Core kann ich wirklich für ein 
Projekt empfehlen, da schon sehr gut getestet (ist auch schon in einigen 
ASICs im Einsatz).

Wenn Dir aber ein AVR lieber ist so kann den AVR_Core 
(http://www.opencores.org/projects.cgi/web/avr_core/overview) empfehlen.
Diesen habe ich schon ausgiebig verifiziert und eingesetzt, bisher ohne 
Probleme. Ist zwar nur ein Mega103, läuft aber prima.

MfG.
Andreas

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur leider kann man den avr_core nicht mehr herunterladen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das funktioniert.Vielen Dank.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis mit P3.0, das war's. Jetzt läuft das Basic.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat zwar nichts mit P3.0 zu tun.
Hast Du die Synthese inzwischen schneller hin bekommen geworden ?
Bei mir dauert die ca 20 Minuten auf einem Athlon64 3000.
Ganz schön nervig.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf meinem Athlon 64 4800 dauert es ca. 5 Minuten. Allerdings habe ich 
bisher nur RXD/TXD angeschlossen, kann sein dass deshalb schon früh viel 
wegoptimiert wird.

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.