mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL Debuging


Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Frage,

wie testet Ihr eueren Code?


Wenn ich in C etwas schreibe, baue ich Debuginformationen ein, die per 
#Define zu- bzw. abschaltbar sind.

VHDL Code testet man mit einer Testbench in einem Simulator. Da gibt es 
ein Taktdiagramm und man kann alle Signale verfolgen. Das ist soweit 
klar.
VHDL bietet auch die Möglichkeit von File Operationen. Hier kann man 
zusätzliche Outputs über read/write Zugriffe in Dateien oder die 
Standardausgabe ausgeben.

Solche Ausgaben würde ich an verschiedenen Stellen in meinen VHDL Code 
ausgeben. Leider gibt es kein Define in VHDL, zum an zuschalten der 
Debuginformationen. Oder ignorieren die Fitprogramme Filezugriffe und es 
wird automatisch beim Fitten übergangen? Ich habe keine Ahnung, wie so 
etwas am günstigen läuft.

Falls jemand hier ein paar Kniffe aus dem Nähkästchen hat, wäre das 
schön.

Danke Rene

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man kann mit --rtl_synthesis on/off direktiven auszeichnen welche 
codeteile bei der synthese nicht berücksichtigt werden sollen

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist das eine Standard Direktive oder was Herstellerabhängiges?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutze einfach generics, die Du mit constanten fütterst


Grüße,
Kest

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da müssen doch die Generics von unten überall durchgefädelt werden.

Ich hatte z.B. an eine Funktion oder eine Prozedure in einem Packgage 
gedacht. Dann müsste nur in der Funktion/Prozedure etwas auskommentiert 
werden.

Mal sehen was noch für Ideen kommen.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, Du verfolgt den falschen Debug-Ansatz.
Einmal wird VHDL mittels Simulator und Beobachten der Signale im 
Wave-Fenster debugt, das kennst Du ja schon. Damit korrigiert man 
meisten Überlegungsfehler, wenn man sieht, dass ein Signal doch nicht so 
kommt wie man es sich vorstellt.
Die zweite Methode funktioniert mit einer Testbench.
Dabei wird das zu testende Modul von AUSSEN mit Signalen gefüttert, und 
die zurückgelieferten Signale mittels VHDL-Mitteln auf korrektheit 
geprüft.
Diese Testbench ist nicht synthetisierbar, deshalb kann man dort alle 
Möglichkeiten wie File-IO, asserts usw. verwenden.
Im zu testenden Modul (DUT) wird nichts geändert, die Beobachtung und 
die Berechnung der Korrektheit erfolgt immer von außen.
Es gibt aber von manchen Simulatoren Spezial-Werkzeuge, mit denen man 
von der Testbench aus Signale innerhalb des DUTs lesend beobachten kann, 
ohne dass man dazu das zu beobachtende Signal über ein Port nach außen 
führen muß.

Suche einmal ein bischen nach Testbench und VHDL, das ist der korrekte 
Ansatz für das Debugging.
Vielleicht hilft Dir aber auch, dass man bei einem VHDL Simulator an 
bestimmten Stellen Breakpoints setzen kann und dann den Code 
schrittweise ausführen kann.
Von der Methode mit "printf"s im VHDL Code kann ich Dir nur stark 
abraten.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dito, kann mich nur dem Vorredner anschliessen,

anglotzen der Waveforms ist nur was fuer 'die Erstinbetriebnahme'. 
Ansonsten fuer die Module (koennen auch mehrere sein) eine saubere 
Testbench, die idealerweise Pseudo-Random Stimuli generiert. In der 
Testbench wird aus diesen Stimuli auch das erwartete Ergebnis berechnet 
(am besten von einer zweiten Person, um grobe Missverstaendnisse 
auszuschliessen) und dann wird mit 'assert' gnadenlos bei jedem Fehler 
angehalten.

Das bedeutet natuerlich etwas Aufwand, weil die 'low-level' Testbenches 
beim wachsen des Designs mitgepflegt werden muessen. Aber dann erzeugt 
dir ein 'vsim -c -do xxxxx_tb.do' ueber alle Testbenches auch ein 
sicheres Gefuehl, dass dein Design allen Anforderungen entspricht.

Meine Meinung: So und nicht anderst. Und schon gar nicht mit irgend 
einem proprietaeren Sch$%^^ der beim Wechsel der Plattform nicht mehr 
funktioniert!

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Und neben 'vsim -c ......' laeuft dann bei mir auch noch ein 'ghdl 
-r <xxxx_tb>' um auch Ungereimtheiten mit den Simulatoren 
auszuschliessen.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Berndl du hast schon was neues reingebracht.

Das assert!!

Auch schon angelesen.
Wie funktioniert das assert? An das habe ich auch schon gedacht. Nur 
fehlen mir dafür die praktischen Beispiele.
Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie 
Statemachine hat einen unzulässigen Zustand erreicht.

Kann man assert im Code außerhalb der Testbench benutzen?
Und zwar so, dass der Code syntheisierbar bleibt?

Leider hören an dieser Stelle die teueren Bücher immer auf.


PS: Ich habe auch  GHDL ;-)

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Leider hören an dieser Stelle die teueren Bücher immer auf.

Dann benutzt Du die falschen teuren Bücher ;)
Die Behandlung von assert-Anweisungen durch ein Synthese-Tool wird im 
Synthese-Standard NICHT festgelegt. d.h. es kommt auf das 
Synthese-Tool an was es damit macht. Allerdings ist mir kein einziges 
Tool bekannt das die assert-Anweisungen beachtet. Sie werden 
ignoriert...

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist sicher hier etwas anders die Sache zu betrachten.
VHDL ist eine Beschreibungssprache. Nur ein Teil des Sprachumfanges ist 
synthetisierbar.
Es steht nicht immer explizit dahinter ob diese Anweisung von einem 
Synthese-tool oder einem Simulation-tool umgesetzt wird.

>Mathi --Dann benutzt Du die falschen teuren Bücher ;)
Was empfiehlst du denn zu lesen?

Als Gutes Buch kann ich "FPGA Prototyping by VHDL Examples" von PONG 
p.CHU empfehlen. Leider benutzt der Autor kein assert und das 
Inhaltsverzeichnis ist zu schlecht. Da muss man immer zu lange suchen.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es um reines VHDL geht, dann den "Designer's Guide to VHDL".
Alles andere beschäftigt sich mehr oder weniger nur mit dem 
Synthese-Subset. Und auch nur mit dem was man oft benötigt.


> Es ist sicher hier etwas anders die Sache zu betrachten...

Warauf willst Du hinaus?

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mathi schrieb:
> Wenn es um reines VHDL geht, dann den "Designer's Guide to VHDL".
> Alles andere beschäftigt sich mehr oder weniger nur mit dem
> Synthese-Subset. Und auch nur mit dem was man oft benötigt.
>
Das Buch habe ich auch. Bin beim durchkämpfen.

>> Es ist sicher hier etwas anders die Sache zu betrachten...
>
> Warauf willst Du hinaus?

Es sind unterschiedliche Ansätze ob es was zum Simulieren gibt oder in 
den FPGA rein soll.

Für mich ist die Simulation eine Unterstützung.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es sind unterschiedliche Ansätze ob es was zum Simulieren gibt oder in
> den FPGA rein soll.

Naja, das kann man anders sehen. Aber vor allem muss es kein FPGA sein 
;)
ASIC ist viel spannender...

> Das Buch habe ich auch. Bin beim durchkämpfen.
Da steht das drinnen. Im Anhang zum Synthese-Standard. Das was du da 
findest sollte von jedem Tool unterstützt werden.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie funktioniert das assert? An das habe ich auch schon gedacht. Nur
>fehlen mir dafür die praktischen Beispiele.

Naja, ganz einfaches Beispiel: Du hast auf deinem Design einen 
SPI-Master, der einen externen Mehrkanal-ADC zyklisch einlesen soll. Der 
SPI-Master hat als Eingaenge eine Clock, evtl. einen Reset, dann die 
SPI-Signale nCS, SCK, MOSI, MISO. Er muss deinem Design natuerlich auch 
sowas wie adc0_wert, adc1_wert, adc0_valid, adc1_valid 'nach oben' 
durchreichen.

Diese SPI-Master Component kommt in eine TB rein. Eine weitere Component 
in der TB ist dein externer ADC. Der wird mit deinem SPI-Master in der 
TB verdrahtet und hat noch zwei weitere Eingaenge adc0_tb_wert und 
adc1_tb_wert.
Den kannst du mit der fuer die Simulation verfuegbaren VHDL Statements 
sehr einfach stricken, also z.B. erkennst du mit einem process und 'wait 
until falling_edge(SCK)' dass du ein Bit vom Master empfaengst, dito mit 
rising_edge fuer dein Ausgangsbit.

In der TB selber hast du jetzt eine procedure, die dir fuer den Master 
einen Request generiert und gleichzeitig auch die erwartete Response. 
Dazu nehme ich typischerweise pseudo-random Werte.

Eine weitere procedure stimuliert nun deinen SPI-Master mit request0 und 
merkt sich den. Beim naechsten request1 wird dir der ADC die response0 
zurueck geben. Dann einfach ein 'assert response0_expected=response0' 
und schon hast du's.

Die TB ist typischerweise deutlich umfangreicher als dein Design, aber 
du wirst das System dann eben auch besser verstehen.

Die ganzen request/response Sequenzen kannst du dann in einer loop 
zig-tausendmal laufen lassen und immer neue pseudo-random Daten 
generieren.

>Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie
>Statemachine hat einen unzulässigen Zustand erreicht.

Wenn deine Component ein Signal 'fsm_invalid' nach aussen/oben gibt und 
du die Logik dazu in der Component hast, dann kannst du das mit dem 
obigen Ansatz ja machen. Ich greife in keiner TB auf ein Signal 
innerhalb einer Component zu, sondern nur auf die I/Os der Components.

>Kann man assert im Code außerhalb der Testbench benutzen?
>Und zwar so, dass der Code syntheisierbar bleibt?

klar, wie oben schon angemerkt mit --rtl_synthesis on/off. Aber dann ist 
der Design den du simulierst nicht mehr der Design den du 
implementierst. Ob du das willst musst du selbst entscheiden.

>Für mich ist die Simulation eine Unterstützung.

Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht 
richtig simuliert ist, geht auch nicht raus...

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke berndl

> Die TB ist typischerweise deutlich umfangreicher als dein Design, aber
> du wirst das System dann eben auch besser verstehen.

Das ist eine ganz neue Erkenntnis.

Bis jetzt habe ich ohne Simulator gearbeit. Dabei habe ich sogar gute 
Sachen geschafft. Ich habe die Pakete geteilt und in der Hardware 
getestet.
Für ASIC ist es klar da kann man nicht groß anders testen.

Jetzt bin ich eben an meine Grenzen gekommen und nutzt die Simulation.
Dass jetzt die Simulation in den Vordergrund rückt, ist noch etwas 
ungewohnt.


Habt Ihr noch das Standardbuch für Verilog als Empfehlung?
Ich kann Verilog code lesen, doch wenn ich selber mit Verilog arbeite, 
kommt nichts gescheites heraus.

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

Bewertung
0 lesenswert
nicht lesenswert
> Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie
> Statemachine hat einen unzulässigen Zustand erreicht.
Wenn du für deine FSM 6 Zustände definierst und alle im Automaten 
verwendest, gibt es keinen ungültigen Zustand. Siehe dazu den 
Beitrag "Typedefinition mit 3 Zustaenden"

>>>> Wenn ich in C etwas schreibe, baue ich Debuginformationen ein...
Die Debug-Strategie bei Hardware (du debuggst keineswegs nur deinen 
VHDL-Code, sondern das, was daraus gemacht wird), ist eine komplett 
andere als bei Software (dort wird gern nach dem Try-And-Error Verfahren 
programmiert).
Mit einer Verhaltenssimulation findest du 90% der Fehler und brauchst 
dafür 10% der Debug-Gesamtzeit. Mit dem Oszi/LA findest du 10% der 
Fehler und brauchst dafür 90% der Debug-Gesamtzeit.

> Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht
> richtig simuliert ist, geht auch nicht raus...
Na, dann möchte ich aber hoffen, dass die Testbench die Umwelt korrekt 
abbildet. Denn eine Frage dürfte doch sein: wer testet eigentlich die 
Testbench?
Denn eigentlich dürftest du selber niemals eine TB für deinen Code 
schreiben. Sondern du darfst bestenfalls eine Schnittstellenbeschreibung 
abgeben.
Ich zeige dir gerne in 0,nichts ein Design, das problemlos 
durchsimuliert, aber gleich nach dem Einschalten einen Fehler zeigen 
wird. Du brauchst dazu nur einen entsprechenden Taktdomänenübergang...

> Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht
> richtig simuliert ist, geht auch nicht raus.
Das hört sich an, als ob alle deine Designs in der Version 1.0 stabil 
laufen. Tun sie das?  ;-)

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Naja, das kann man anders sehen. Aber vor allem muss es kein FPGA sein
>;)
>ASIC ist viel spannender...

Oh ja, und viel teurer ... es sei denn man arbeitet an der Uni ;O)

SuperWilly

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Na, dann möchte ich aber hoffen, dass die Testbench die Umwelt korrekt
>abbildet. Denn eine Frage dürfte doch sein: wer testet eigentlich die
>Testbench?
>Denn eigentlich dürftest du selber niemals eine TB für deinen Code
>schreiben. Sondern du darfst bestenfalls eine Schnittstellenbeschreibung
>abgeben.

Richtig, aber manchmal/oefters/immer muss man die TB selber machen, weil 
es sonst keinen anderen gibt. Umso wichtiger, dass man sich im Vorfeld 
klar darueber wird, was eigentlich zu tun ist. Ein Interface das ich 
selber nicht richtig kapiere kann ich auch in der TB nicht nachbilden. 
Du sagst ja selbst, das merkt man dann beim ersten HW-Test...

>Das hört sich an, als ob alle deine Designs in der Version 1.0 stabil
>laufen. Tun sie das?  ;-)

Jein! Sie laufen in der Simulation. Wenn es dann in der echten HW nicht 
tut, dann liegt ein falsches Verstaendnis des I/F vor oder ein 
Timing-Problem (was man auch sehr gut mit VHDL simulieren kann) oder ein 
'sonstiges' Schnittstellenproblem. Aber ich weiss durch die Simulation, 
wie mein eigener Design sich verhaelt. Und da ich ueblicherweise nur 
synchrone Designs mache (ich synchronisiere wenn immer moeglich 
konsequent auf einen Chiptakt ein), dann weiss ich sehr schnell wo ich 
anfangen muss zu suchen wenn mal was nicht tut...
Beispiel letzte Woche: Ein halbes Jahr (mit ~halber Kraft) den Design 
gebaut und simuliert. Ein paar Tage vorher zum ersten mal reingeflasht, 
tat alles. Dann Inbetriebnahme im System: Tat alles. Da werden sicher 
noch ein paar Sachen hochkommen, aber erstmal koennen die Kollegen mit 
dem Design arbeiten. Und ich weiss, dass z.B. meine externe SPI (ich bin 
Slave, an LVDS ueber 2.5m Kabel angebunden) wunderbar funktioniert. Wenn 
jetzt noch das Backend (Anbindung an uC und dahinter das grosse System) 
getestet wird und tut (SW ist noch nicht fertig), dann kann man richtig 
loslegen. Und ja, vermutlich habe ich bei einigen Dingen noch ein 
falsches Verstaendnis gehabt und deshalb falsch implementiert. Aber das 
spielt sich dann auf meinem FPGA innerhalb meiner 100MHz Clock-Domain 
ab. Das muessen dann eben die Systemtests aufzeigen...

Aber nochmal: Ohne meine Simulation die fehlerfrei laeuft geht nichts 
raus! Diese schnelle Bastelei fuehrt zu 2 Stunden Testzeit und dann 
meist zu einer Taskforce weil's nicht so tut wie's soll...
Ich habe, bevor ich FPGAs gemacht habe, ASICs gemacht. Vielleicht daher 
die Simulationsneurose...

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:

>Ich zeige dir gerne in 0,nichts ein Design, ...

?????

>Ich zeige dir gerne in 0,nichts ein Design, das problemlos
>durchsimuliert, aber gleich nach dem Einschalten einen Fehler zeigen
>wird. Du brauchst dazu nur einen entsprechenden Taktdomänenübergang...

Deine TB kann aber auch sehr einfach unterschiedliche Clocks an DUT und 
Stimuli-Generator anlegen und zusaetzlich auch noch Signallaufzeiten 
(variabel!) enthalten. Das sind maximal 50 Zeilen VHDL!

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

Bewertung
0 lesenswert
nicht lesenswert
>> in 0,nichts ein Design, ...
> ?????
in Null Komma Nichts
aka. Von jetzt auf Nachher     ;-)

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> in 0,nichts ein Design, ...
>> ?????
>in Null Komma Nichts
>aka. Von jetzt auf Nachher     ;-)

Autsch, den hab' ich nicht begriffen :o)

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur so als Hinweis für den OP: Es gibt eine Art printf-Package für VHDL 
(pck_fio). Damit lassen sich insb. zeitliche Abläufe oder umfangreiche 
Berechnungsergebnisse wesentlich besser debuggen und dokumentieren als 
mit dem Wellenformgewusel. Insbesondere kann man damit Ausgaben 
produzieren, die man recht einfach mit den Sollvorgaben aus einem 
(C/whatever)-Modell vergleichen kann. Gerade wenn das Timing unwichtig 
ist und nur die Ergebnisse zählen, ist das eine recht angenehme 
Methode...

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie
>> Statemachine hat einen unzulässigen Zustand erreicht.
> Wenn du für deine FSM 6 Zustände definierst und alle im Automaten
> verwendest, gibt es keinen ungültigen Zustand. Siehe dazu den
> Beitrag "Typedefinition mit 3 Zustaenden"

Ungültig ist falsch. Es gibt Zustände die nur während der Intialisierung 
durchlaufen, werden sollen. Halt die Grundkonfiguration der externe 
Chips einrichten. Ich hätte z.B. ein Logfile in welcher Reihenfolge die 
Zustände durchlaufen werden als sehr sinnvoll erachtet. Er gibt nur 
bestimmt Übergänge. Ab einer gewissen Komplexität ist eine Statmaschine 
so kompiziert, das bei einer Erweiterung schnell alles über den Haufen 
geworfen werden kann.

>>>>> Wenn ich in C etwas schreibe, baue ich Debuginformationen ein...
> Die Debug-Strategie bei Hardware (du debuggst keineswegs nur deinen
> VHDL-Code, sondern das, was daraus gemacht wird), ist eine komplett
> andere als bei Software (dort wird gern nach dem Try-And-Error Verfahren
> programmiert).

C geht mir besser von der Hand und auch der Debugger ist unschlagbar. 
Adress und Pointeroperationen, dynamischer Speicher, Strukturen. Notfall 
kann man Objektorientiert nach oben mit C++ weiter gehen.
Sicher ist C nicht besonders lesbar auf den ersten Blick. Um C kommt 
keiner herum. Bald laufen auf den Dinger häufiger Soft CPUs.


Wenn ich so ein Mathematische Problem habe, dann muss ich ein 
Bauchgefühl bekommen. Andere benötigen eben Programming by Maus 
Matlab/Simulink.
Der C code ist der Erste Schuß und kommt später in den Eimer. Danach 
schreibe ich erst es in VHDL. Sicher ist es doppelte Arbeit. Ich würde 
sagen es lohnt sich, weil bei dem Programmieren in C bekomme ich meine 
Ideen.

. Mit dem Oszi/LA findest du 10% der
> Fehler und brauchst dafür 90% der Debug-Gesamtzeit.

Ich habe lange so gearbeitet. Sicher sehr uneffektiv, gebe ich zu. Dafür 
habe ich dabei eine Menge gelernt. Jetzt ist es Zeit, dass ich davon 
wegkomme und ein anders Level der Programmierung erreiche.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um nochmal auf die Wertigkeit von TB und UUT zurück zu kommen. An 1. 
Stelle steht die Schnittstellenbeschreibung. Und noch bevor die das 
eigentliche Design geschreiben wird, kann oder sollte die zugehörige TB 
entstehen. Ich gebe zu, dass ich das aber auch noch nicht in der 
Reihenfolge gemacht habe. Aber gerade wenn man gezwungen ist zu seiner 
UUT selbst die TB zu schreiben, dann ist das der bessere Weg. Ansonsten 
kann die TB ja parallel zur UUT erfolgen.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe selber noch einen hammerharten Link zu dem Thema gefunden.
http://www.stefanvhdl.com/

Das sollte in jedem Buch stehen.

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.